如果你的项目失败了，应该是做了失败的需求分析思维导图

作为一名合格的需求分析人员，对于一些基本的需求开发和需求管理，必须需要学会总结及多问“为什么？”。其实，很多项目的失败，经过总结和归纳，很大的原因在于需求分析不足而导致。需求捕获和分析是解决产品的前提，也是解决争议的前提，也是产品立项的基准；如果需求分析做不到位，后续的开发、测试等产品研发和运营都需要花费很大的人力、财力来填补空白。然而，清晰的项目目标和范围定义，能够引导需求工作顺利进行。

从我们接触到的项目中，有不少的项目是失败的，其实，根据业内数据统计，80%的项目是失败的，20%的项目才是我们成功的范例；并且这20%的项目还有延期交付、需求变更、上线阻力大等原因；从我个人的经历看，项目失败的本质分析主要有：

然而，项目的失败归根结底就是需求分析的失败，根据CHAOS报告总结的“软件项目十大败因”中，有五项是与软件需求直接相关的。这些因素在我几年的实践经验中也深有同感，因此针对这些因素我在几篇文章中都进行了一些论述，也得到了一些有趣的视角。以下就简要地对这些败因做个初步的分析。

1. 不完整的需求

我总是喜欢问这样的一句话：“什么样的需求是完整的呢？”实际上，在我以前的工作实践中，该问题也始终是一个困惑！如果没有一个有效的“完整性评价标准”，那么这个问题也必将是无解的。要破解这个问题，首先应先回答一个铺垫性的问题：“谁更有可能可以对需求的完整性进行评价？”。我想大家一定会认同“用户代表要比开发人员更适合对完整性进行评价”这一观点吧！而当我们回头去审视“软件需求规格说明书”时，却发现其中充斥着诸如数据字典管理、报表子系统、新增客户之类的以技术动词唱主角的字眼与结构，这样做显然会将技术功底并不深厚的用户代表排除在有效读者群之外。

因此，要想让用户代表能够更好地参与到完整性评价中来，就必须采用“业务导向”的组织结构，而不是让用户将一大堆技术动作翻译到自己的业务场景中去。除此之外，在实际的操作过程中还有一个要点，那就是利用树型层次结构将宏观信息与微观信息进行有效的剥离。

在我从业的经历中，很多项目组的人员觉得，需求分析就是技术分析，并且很多公司要求需求分析人员需要懂技术，可是；如果需求从技术的角度去看，就失去了业务的可塑性；根本创造不了机会，解决的只是一时问题，并不能真正的把控项目或者产品的发展。

业务需求是需求之魂，对于需求分析而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控能力等）的问题，不是技术问题，我们不是造原子弹，没有那么大的工程和高技术，所以，一些软件技术的发展是随着需求深耕才产出，技术伴随需求而来；有需求才有技术的发展，技术是解决需求。其实，这也是软件迭代和敏捷的要求，快速响应和及时呈现。

2. 缺乏用户参与

在很多的软件项目中，用户都不能有效地参与到项目中来，也许诸如“你们先做，做出来我们试试后再改”之类的话，早已经听得你的耳朵生茧了。实际上这个现象的背后存在几个方面的因素：

3. 不切实际的用户期望

很多时候，软件开发从业人员也很无奈！用户总是很天真地提出了大量的需求，有些是技术上根本无法实现的，有些则是原本就脆弱的费用与时间预算内无法实现的。就像孩子们不知道能够飞上月球的航天飞机要多少钱一样，客户也不知道自己提出的需求真的需要多大的成本。那么问题的根源是什么呢？其实原因就在于软件的无形和成本的不透明。也许“客户就像三岁小孩”这样的潜台词，从而导致我们将“不切实际的需求”归罪于客户。

实际上要解决这样的问题，更需要的是从业人员主动地帮助用户更好地理解软件的成本。简单地说，做不到是无效的，要说明为什么做不到才能解决问题。我们需求分析人员提出的就是产品的整个解决方案，不管是从业务角度还是技术角度，都是为了解决用户的需求，解决他的痛点。

4. 需求变更频繁

这是一项特别有意思的因素，在CHAOS报告中将其列为第四位，这种排名上的问题背后有什么道理呢？

当有人和我探讨解决需求变更频繁问题的方法时，我总会先问一句“你们经常遇到的变更主要是哪种类型？”，但就是这样的一个问题却往往难住了许多人。也就是说，在国内软件行业中，对变更进行分类、统计的做法仍然不是很普遍。但如果只是简单地将所有的需求变更都当作一个问题来看待，那么是无法有效地找出问题的根源的，也无法有针对性地改进需求过程，提高设计的弹性。这也许就是经验和经历之间的区别吧！

另外一方面，用户并没有意识到变更对软件项目的负面影响。而究其原因，其实与绝大多数软件企业一样缺乏统一的变更处理渠道，使得变更相对而言比较散落，没有集中地体现出来。在我的实践中，曾经就有用户代表说：“我们的变更不多吧，我总共只提了两个。”，岂不知他这样提两个变更的用户就近百个……需求变更和管理也是需要需求人员重点把控，不然变更得不到有效的遏制以及需求得不到更好的放大，需求变更管理需要设置条件及在时候进行论证。

5. 提供了不再需要的

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

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

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

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

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

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

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

1、沟通失真

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

2. 客户的需求放大

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

3. 项目经理的需求控制

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

4. 分析人员的技术加工

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

5. 开发人员的断章取义

对于客户描述的需求，可以用一句生动的话来概括：“你要绳子，我给你了；你要木板，我也给你了；你为什么说这不是你想要的呢？”。我想程序员也有类似的问题想问自己的客户，“你要文本框，我提供了；你要一个表单，我也有了；你为什么说这个程序不是你想要的呢？”。这是需求吗？也许很多人会有不同的看法！但如果缺乏对业务场景的了解，又如何能够真正理解需求呢？业务场景是需求之魂，需求分析人员最重要的就是将客户的业务场景分析透彻，将后续的产出输入给开发人员。