如果你的项目失败了，应该是做了失败的需求分析(2)

曾经尝试过这样一些小技巧，在每个功能模型的入口页暗藏了一个计数器功能，一段时间后只要收集回log记录，一看就知道哪些是“不再需要的”，也就不必再费心去做更多的升级了。当然，这种举动只能起到“马后炮”的效果，无法“防范于未然”，仍然浪费我们大量的开发资源与时间。

是否能够事先预防呢？这必须从另外一个角度来看，那就是能否在最开始有效地划分优先级。也许这样的回答会令你失望，优先级划分经常是“拍脑袋”的产物，没有理由也没有原因，它就是最高优先级。这样的方法显然是不正确的，真正基于业务领域知识来衡量需求的必要性和充分性是解决之道。

需求分析就是向下分解+向上提炼，外加一些规范化。需求分析是什么？需求分析是业务分析，需求分析是一种分解活动，需求分析是一种提炼与整合行动，需求分析是一种规格化活动。需求分析我们输出的产物就是需求规格说明书（PRD也叫需求文档），需求分析也是检验一个合格产品经理的标准，产品做什么？最主要的还是以把握客户需求为准。需求又可分为：

业务需求用户需求软件需求功能需求非功能性需求设计约束

其实，需求获取也有失败，并不是完整的表现；需求获取的问题主要表现在：

捕获范围不足缺乏计划性缺乏科学性捕获对象不明确捕获手段不足 有时候就会导致项目的终止或失败。

那我们的需求标准是什么呢？怎样的需求才能被记入到PRD里面呢？也就是我们的标准，需求的标准：

完整性不失真有优先级有技术早期介入

这样的PRD才不会有争议，即使有变更也需要及时的知会项目组成员。需求分析的过程我在前篇文章中有提到，需求的验证和评审是一个反复的过程，就是为了解决争议。

从我参与的软件项目过程中来看，主要的原因如下，也希望给你得到些许提醒：

1、沟通失真

沟通失真，从客户的描述到项目经理的理解、分析员的设计、程序员的编码、商业顾问的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工，从而导致信息的内容有了很大的改变。因此，对于软件需求工程而言，克服沟通失真就成了一个要点。根据相关的研究显示，在信息的传递过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达60%。而在软件开发过程中，需求信息通常要经历用户代表、需求人员、设计人员再到开发人员，因此最坏的情况下，开发人员获得的信息仅是原来的8.4%，这是一个十分可怕的结果。怎样才能够更好地避免这种问题的出现呢？其实关键的手段有两个：

文档：如果信息在传递的过程中仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化。但这种方法只是用来辅助沟通的，而不是代替沟通，文档的好处就是有依据，避免了后期的扯皮，也有利于需求的管理及变更。Review：国内常将其翻译为“评审”，但这一翻译却容易给人误导。评审在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。顾名思义，Review就是再（Re）看（View）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。而最简单、最有效的Review就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。解决失真的最有效的办法就是及时的复述。2. 客户的需求放大

用户在描述自己的需求时做了许多“添砖加瓦”的事。“用户要么不会说，要么就会添油加醋”的现象，在我的实践中是屡见不鲜的。而在这种现象的背后有什么潜在的原因呢？我认为至少有两方面关键因素：

客户希望支付的成本尽可能少，获得的效益尽可能多（想马好，又不想马吃草）。这种思维对于任何一个客户、任何一个人而言都是本能反应。而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损”了；因此，在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。要解决该问题并不是件容易的事，一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高。解决方案的选择权交给了不熟悉技术的客户。许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。但是，这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而一旦客户代表选择的解决方案不是最合适的，就必将引发后续的需求变更。因为，对于一个特定的问题，可能的解决方案会有很多，因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而要缓解这一现象的关键就在于，在需求捕获的过程中多问“为什么”。3. 项目经理的需求控制

项目经理在沟通的过程中会导致需求产生偏差。由于国内许多软件项目经理们通常是一身兼多职，项目管理、需求分析、架构设计一肩挑，因此在需求捕获的过程中，总会“及时”地在脑海里勾勒出技术框架和路线，然后尽可能地控制需求的范围。但实际上，有些需求“表面上”是控制下去了，但却在后面以“需求变更”的形式全回来了。其实，在我的工作经理当中这也是司空惯见，老板为了减少开支总会这样做，但是，后果却没有想到。实际上，我的体会是需求分析人员是有必要对需求进行有效的控制的，问题出在控制的策略和方向上。从前面的描述中不难看出，项目经理经常会从技术的角度来对需求进行控制，这样就可能造成无法形成对需求的有效理解。我认为应该以业务为线索来组织需求，基于“Why”的层面对需求建立高层次的认识。

4.分析人员的技术加工

每次在跳槽时，就会想起现在许多名称中包含“需求分析”、“系统分析”之类的职位，大多是由技术骨干担任的，因此在工作中很少从业务角度进行分析，更多还是追求技术框架、新技术。对于这种现象，究其根源，关键还在于“技术能力”对他们的未来发展更为重要，而“业务能力”却不是那么重要。但为了使需求工作有更好的提高，我会强烈呼吁那些Title上有“分析”之类名称的人们，加强业务分析吧！毕竟，需求分析的本质在于业务分析，而非技术分析。

5. 开发人员的断章取义

编辑：未知