云项目最薄弱的部分就是发现阶段，如果搞错了会让你会损失惨重。
不管在什么体量的云项目里，发现都是项目风险的症结。尽管项目的发现和架构阶段仅代表总体付出的15%，但早期的任何一个错误或疏忽都会导致150%或更多的蔓延。
不幸的是，这也是项目的蜜月阶段，过度乐观和对安全的错误意识会掩盖内在的风险。这就是供应商的项目带头人必须最坚定的时候，引导客户做出艰难的决定并迫使客户承认这种不愉快的交易。真诚的客户牵手是发现阶段的成功因素。
50年前的今天，佩珀军士(注：披头士一首歌曲中的角色)就参透了这一点。让我来向您介绍云项目中最薄弱的部分，老生常谈的需求发现!
奇幻之旅
即便客户收集了很多需求并在项目开始前就创建了需求文档，这些大部头不可避免地遭受以下四个问题：
1.文件深受供应商的宣传和行业分析师的影响，而受业务流程实际需求的影响十分不足。这导致了技术上的“功能炎症”并对实际用户的偏好视而不见。
2.没有对需求给予足够的优先级别，只是就符合项目预算和时间表所需的艰难交易提供蜻蜓点水式的指导。
3.需求不完整，在端对端的业务流程中缺乏重要的过渡。往往是到了项目开展的时候才发现缺漏，“隐形的需求”在发现阶段结束后很久才被发现。当主要的需求在系统接受度测试中突然出现的时候是最戏剧性的。
4.业务在项目的生命周期里一直进化着，而每一个重组或策略变更都会使原始文档无效，甚至与原始文档矛盾。这一点不好玩，但确有其事。
因为预先编写的需求文档对大项目的整个历程来说往往是不可靠的路线图，顾问喜欢把项目分解为几个阶段，每一个阶段都以它自己的发现和需求批准周期开始。敏捷的项目方法把这个推到了逻辑上的极限，在每一次短跑开始时都有一个微发现。
生命中的一天
甚至是敏捷方法也会让项目陷入困境，如果顾问没有带客户做“生命中的一天”练习，从实际客户的视角探索端到端的业务流程(可怕!)。高层往往不知道业务实际的运作细节，而低级别的人员只管自己的一亩三分地。有了面向客户的应用，你会发现有时只有客户才知道你的系统有多让人沮丧，而内部没有人花时间将这些小细节串联起来并以端到端的视角看待流程。
深度发现的起点就是将系统表述为一系列的业务流程，比如：
·将营销瞄准合格的销售线索
·销售和渠道管理
·合同报价
·交付、安装和客户熟悉产品
·开票和收款
·保修和服务授权
·案例管理和服务调度
·问题解决方案和服务电话
·跟进客户调研
经历了这种分析的大公司将很快发现他们的整个业务没有一个单一的流程工序流。跨国运营可能有很多变体要适应，它们包括：
·地区性的或全国性的业务惯例(例如美国的vs欧洲的vs亚洲的)
·上下游行业准则和监管制度(客户隐私、合同规则或财务上的)
·分销渠道与合资公司
·不属于项目的一部分的旧系统(例如企业资源计划或电子商务)
·公司内外的政治领地
要把这些变体中的每一个都以有自身需求的并行流程的形式罗列出来。
公司都愿意相信云可以大大地简化他们多年来积累的系统混乱。它们可以做到，但前提是确实有人在简化积累多年的流程混乱时做足了功课。简化意味着理解所有可移动部分交互的目的，长远地想出一个智能的统一和替代策略。
蜿蜒盘旋路
这听起来很复杂、昂贵、耗时，的确如此。顾问和客户都适应了超过总项目付出的“标准的15%”的深度发现流程。当云系统正在取代一个或更多的经历了多年演变(以健康的或不健康的方式)的旧系统时尤其如此。
高层想项目快点完成的欲望必须受到遏制，他们要知道心急只会制造一个将旧习自动化，将淘汰的业务规则加强的新系统。真正的业务转型意味着要在业务流程上做足够的工作，将它们变成一种优势。
本文转自d1net（原创）
相关资源：七夕情人节表白HTML源码(两款)