项目经理学习笔记(一)：理解需求

理解需求是软件工程师所面对的最困难的任务之一，现代企业明确的分工下，产品经理往往担任着承担需求分析的重任，能不能对目标系统提出完整、准确、清晰、具体的要求，这很是考验产品经理的功力。纵观软件工程历史，许多大型应用系统的失败，最后均归结到需求分析的失败。

我自己也经历过这种天坑，由于前期的设计不当，导致后期的项目成型后核心功能跟客户要求的差异很大，但是代码已经写好了，很难通过小修小补去解决。究其原因首先是产品经理获取需求的方法不当，使得需求分析不到位或不彻底，导致开发自己还需反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；另外客户配合不好，导致客户对需求不确认，但这归根结底也可以算是产品的原因，客户本身不知道他需要什么，需要产品用合理的方式进行引导。

一：需求分析面对的几个难题

需求分析是最困难的，现在进行需求分析主要存在以下几个问题：

（1）用户与程序开发者存在天然的交流屏障

在软件生命周期中，用户能够参与的仅仅只有软件需求分析阶段。需求分析是对用户的业务活动进行分析，以便明确在用户的业务环境中软件系统应该“做什么”。但是在开始时，程序开发者和用户双方都不能准确地提出系统要“做什么”，因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以让技术人员跟用户沟通，存在天然的交流屏障。

（2）用户的需求是动态变化的

对于一个大型而复杂的软件系统，用户很难精确、完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。这无疑给软件开发带来困难。

（3）系统变更的代价呈非线性增长

需求分析是软件开发的基础。咱们假定在需求分析的阶段发现一个错误，解决它需要用一个小时的时间，到设计、编程、测试和维护阶段解决，则要花费n倍的时间。

因此跟客户获取需求的过程最重要的是建立一个明确的目标，我们要去积极的引导客户去分享他们的目标，一旦抓住目标，立即建立基于目标的优先机制，思考能不能建立起初步的架构。

二：产品需求的来源

1：领导的提议

公司领导作为公司产品的决策者，往往直接下达指示，但这种指示往往比较模糊，需要我们好好揣摩，但很多时候领导都是拍脑袋想问题，一天N个想法，所以作为产品经理就需要仔细地评估这些目标的价值和成本，做一个可行性的评估，我们用可行性评估的结果，来告诉他们，他们的哪些想法，针对于目前的企业情况是不适合实施的，哪些想法是当下迫在眉睫的首要目标。

2：行业新动态

产品经理需要获取业务领域内的相关知识，了解行业动向，当行业内有了新的知识（也就是说要掌握风口，但不要被风口带偏）并且与需求发生矛盾时，产品经理可以利用行业知识对各种需求进行权衡。

3：用户调研

对于toC的软件产品进行问卷调查是很有效的方式，但是我们应充分考虑不同用户群体的需求，如果只强调某一角色的需求，忽略其他角色的需求，往往将导致互联网产品的失败。对于toB的专业产品，需要驻场进行实地调研，了解产品运行环境，单位类型等。

4：地域等客观因素的影响

不同的地域限制，实时性要求，性能要求将有可能给产品经理带来新的需求

5：客户的组织架构

在不同的企业，会受到组织结构、企业文化和内部政策的影响。组织架构的影响会给我们产品经理带来新的需求，而且标准化的产品也需要按照实际的情况进行个性化的定制

三：表达需求

1：需求评审讲解前：

提前利用axure，所见即所得的特点，并辅助PRD，用来展示需求。先和需求同事、开发同事、测试同事沟通部分难点需求，事先沟通，看看他们会提什么问题，反正是不当着领导面的，也不会尴尬。

2：需求评审表达时

要有自己的逻辑线，在讲解的时候，语言要简明、准确、完整。有些开发只关心自己要开发的东西，对于一些他认为无关的客户背景、部门业务没有那么关注，会让你跳过总体介绍，然后打乱你的节奏。注意不要被牵着鼻子走。

3：需求评审结束后

不是讲完需求就结束了，总结每次讲解的效果，不断提高自己表达需求能力。记录开发和测试问的问题，总结经验。