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

本文作者将根据自身的项目经验，来浅析一下需求分析。

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

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

1. 需求变更频繁

2. 上线阻力大（容易产生利益冲突 和增加工作量）

3. 产品运行效果差

4. 完全奔溃

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

1. 不完整的需求

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

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

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

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

2. 缺乏用户参与

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

• 事不关己，高高挂起：主动参与意识是与获得的利益成正比的。很多软件项目在实施之时，并没有清晰的目标，客户中的许多代表也不知道能通过新系统获得什么好处，因此没有积极性。针对这种情况的主要应对措施是充分研究不同用户代表的关注点、利益点，具体的方法就是对用户进行研究，我会在下一篇文章中提到，如何进行用户研究。

• 逃离无趣区：如果你不喜欢或不熟悉足球，当同事们讨论起足球时你会怎么办？我想选择离开的人不在少数吧！人本性中有一种逃离无趣区的趋向，对于那些自己没兴趣、不够专业的领域就不愿意多介入，一方面无趣，另一方面会丢面子！那么用户对于软件开发项目和你对于足球所遇到的情况不是一样吗？所谓，没有调查就没有发言权；用户对于软件的技术是没有兴趣的，对于业务流程来说却是很好的突破口。

• 被你赶走：当用户鼓起勇气开始参与需求活动时，难免不被那些“需求分析人员”用深奥的技术语言（也许他们还认为这样才是专业主义）吓走。好吧，通过业务利益争取用户参与到需求活动中，始终让技术解决方案在冰山之下以使用户不中途离开，也许是缓解该问题的很重要的策略。对于需求分析员而言，真正的专业主义是基于业务利益分析和沟通。

3. 不切实际的用户期望

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

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

4. 需求变更频繁

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

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

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

5. 提供了不再需要的

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

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

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

1. 业务需求

2. 用户需求

3. 软件需求

4. 功能需求

5. 非功能性需求

6. 设计约束

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

1. 捕获范围不足

2. 缺乏计划性

3. 缺乏科学性

4. 捕获对象不明确

5. 捕获手段不足 有时候就会导致项目的终止或失败。

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

1. 完整性

2. 不失真

3. 有优先级

4. 有技术早期介入

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

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

1、沟通失真

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

• 文档：如果信息在传递的过程中仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化。但这种方法只是用来辅助沟通的，而不是代替沟通，文档的好处就是有依据，避免了后期的扯皮，也有利于需求的管理及变更。

• Review：国内常将其翻译为“评审”，但这一翻译却容易给人误导。评审在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。顾名思义，Review就是再（Re）看（View）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。而最简单、最有效的Review就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。解决失真的最有效的办法就是及时的复述。

2. 客户的需求放大

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

• 客户希望支付的成本尽可能少，获得的效益尽可能多（想马好，又不想马吃草）。这种思维对于任何一个客户、任何一个人而言都是本能反应。而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损”了；因此，在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。要解决该问题并不是件容易的事，一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高。

• 解决方案的选择权交给了不熟悉技术的客户。许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。但是，这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而一旦客户代表选择的解决方案不是最合适的，就必将引发后续的需求变更。因为，对于一个特定的问题，可能的解决方案会有很多，因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而要缓解这一现象的关键就在于，在需求捕获的过程中多问“为什么”。

3. 项目经理的需求控制

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

4. 分析人员的技术加工

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

5. 开发人员的断章取义

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

不同的读者能够得到更多不同的启发。不过最为重要的一点在于反思这一现象后面的本质因素，构思真正有效的缓解手段，这样才能够有效的避免出现项目失败、走进“迷途”，这里的需求分析都是比较浅析，希望可以帮助你。以下是根据我这几年做产品及需求分析的总结：

1、需求规格书应采用业务导向的树型层次结构来组织

2、缓解沟通失真最有效的方法是及时复述

3、在需求捕获的过程中多问为什么？

4、在功能上加一个计数器，用来区分或者说切掉产品功能的重要性的依据

5、需求分析人员对于计划方法论的评价重在适用性

6、对预设计的需求是评判敏捷方法论是否适用的关键

7、高层管理人员的关注点往往在问题和机会

8、对于向用户的镶入式系统行为分析是要点，以场景为主

9、并行工作流是OA系统的关键线索和主要视图

10、业务需求是需求定的产物，用户需求是捕获的产物，软件需求是需求分析与建模的产物

功能需求的重点在于组织

11、非功能需求的要点在于保证信息有效传递和注意其局部性

12、设计约束包括非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类

13、业务导向的层次结构是保障完整性的关键

14、满意/不满意度模型是需求必要性评价的有效手段

15、在需求捕获活动中化被动为主动是关键，主动出击才是抓住商机和卖点

希望能帮助在产品和需求分析道路上的你。