20年前是怎么做需求分析的？

需求分析有多么重要？

如果需求分析没有做好，那么就会出现：你做出来的东西不是客户想要的。而想要解决这个问题，那么就需要重新进行需求分析，重新开始返工。如果一次不行，可能还有下次。

在这个过程中就会花费大量的时间成本和人力成本，这对于整个项目的进度计划和项目预算来说无疑是巨大的隐患。

大侠的项目就出现过这样的情况。

一次需求迭代，在跟客户聊好需求后，产品经理就开始认真的做需求分析，接着画出了产品原型，做好UI设计，之后投入开发。

可是，在项目测试阶段的时候，客户仔细一看，却完全否定的需求内容。然后私底下跟大侠说：“你们产品经理是刚来的吗？怎么对不上当事说的需求呢？”

那么，问题来了？

20年前，产品经理还没有盛行的时候，项目经理是怎么做需求分析呢？

有了产品经理后，项目经理又该控制需求呢？

在那个时候，需求分析是指在需求开发过程中，对所获取的需求信息进行分析，即使排除错误和弥补不足，确保需求文档正确的反应用户的真实意图。

对于过去和现在，需求分析的宗旨都是相同的，而我们需要做的就是通过用户需求，抓住用户根本目的之后，进行系统需求的实现。

在20年前需求分析的方法分为两种：问答分析法和建模分析法。

问答分析法简单来说就是问“是什么”、“为什么”刨根问底地问，问到没有疑问，问到相互确认。

然后他们最常见的问题有：

l 需求存在二义性吗？

l 需求文档的上下文有矛盾吗？

l 需求完备吗？

l 需求必要吗？

l 需求可实现吗？

l 需求可验证吗？

l 需求的优先级确定了吗？

建模分析法也是现在的原型法，通过图形符号来表示、刻画需求。通过“一图抵千言”达到使人一目了然的效果。

建模分析还可以分为“结构化分析法”和“面向对象分析法”。

结构分析法是以数据字典为中心，描述软件种所有数据对象。通过“实体-关系图”来表示数据对象及他们之间的关系。通过“数据流图”指明数据在系统种移动时如何被变换。通过“状态-变迁图”表示系统存在的各种状态及他们之间的变迁方式。

面向对象分析法是采用建模工具Rose进行交互式构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等。

现在需求分析的工作大部分由产品经理来完成，他们拥有更专业的需求分析能力。这也让很多项目经理产生来一个疑问：需求分析这份工作对于项目经理来说，是否包含在工作范围内呢？

对于一些交付性项目经理或者若矩阵式组织结构里，项目经理在需求阶段主要要做的工作是需求的传达和需求的决策。

项目经理不仅需要听懂客户的需求，还要以一种简单明了的方式告诉公司的产品经理客户的具体需求是什么。当然，还必要传达的完整，只有保证完整性，需求才是可用的。这也就要求项目经理深入了解客户业务，明白客户提出需求的根本目的，刨根问底，做到没有疑问。

项目经理对需求分析做决策，这部分是要求项目经理在真正明白客户需求目的后，对产品经理设计出来的原型或需求文档进行评价，站在客户立场上提出修改建议。

最后，针对经常发生的需求冲突“公说公有理,婆说婆有理”的现象，提出来一些建议，希望对项目经理的工作有帮助。

1、如果一群人对需求有争议,并不是谁声音最响就要听谁的。需要根据生活经验,最保险的办法是：先听官儿大的或者威望高的,如果大家的职位和威望都差不多，那么采用“少数服从大多数”的原则。

这样做的好处是当出了差错时，就有理由为自己辩护，从而保护自身利益。不要觉得这种“明哲保身”的做法很低俗，因为项目经理背锅也是有极限的，一旦碰到来峰值，一切都会报警，包括工作、生活?

2、如果一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的喜好来开发。此时对需求的决策应当以商业利益为导向，即哪一类客户出钱最多就先满足他们的需求，以后再做那些获利相对较少的需求。

3、当开发者想像中的产品与客户所提的需求有冲突时，一般应当尊重客户的观点。但是不要陷入“客户总是对的”陷阱里，应当纠正明显不合理的客户需求。

如果产品很复杂，双方都不太明白需求，此时最好快速构造软件的原型，双方看着原型再分析需求。