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

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

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

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

需求变更频繁上线阻力大（容易产生利益冲突 和增加工作量）产品运行效果差完全奔溃

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

1. 不完整的需求

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

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

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

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

2. 缺乏用户参与

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

事不关己，高高挂起：主动参与意识是与获得的利益成正比的。很多软件项目在实施之时，并没有清晰的目标，客户中的许多代表也不知道能通过新系统获得什么好处，因此没有积极性。针对这种情况的主要应对措施是充分研究不同用户代表的关注点、利益点，具体的方法就是对用户进行研究，我会在下一篇文章中提到，如何进行用户研究。逃离无趣区：如果你不喜欢或不熟悉足球，当同事们讨论起足球时你会怎么办？我想选择离开的人不在少数吧！人本性中有一种逃离无趣区的趋向，对于那些自己没兴趣、不够专业的领域就不愿意多介入，一方面无趣，另一方面会丢面子！那么用户对于软件开发项目和你对于足球所遇到的情况不是一样吗？所谓，没有调查就没有发言权；用户对于软件的技术是没有兴趣的，对于业务流程来说却是很好的突破口。被你赶走：当用户鼓起勇气开始参与需求活动时，难免不被那些“需求分析人员”用深奥的技术语言（也许他们还认为这样才是专业主义）吓走。好吧，通过业务利益争取用户参与到需求活动中，始终让技术解决方案在冰山之下以使用户不中途离开，也许是缓解该问题的很重要的策略。对于需求分析员而言，真正的专业主义是基于业务利益分析和沟通。3. 不切实际的用户期望

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

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

4. 需求变更频繁

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

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

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

5. 提供了不再需要的

编辑：未知