需求分析文档模板_手把手教你项目管理之三：项目管理之需求管理

我是乐风，如果对项目管理的全部内容感兴趣 ，请参考我的live:

如何快速成为一个顶尖的项目经理？​www.zhihu.com

需求管理是项目管理的基石，根据我的经验，项目失败或者延期的原因十之八九都源于需求管理没做好。

先分辨两个概念：一个是需求，一个是想法。

需求必须是明确的、可行的和确定的，而想法不是。想法是不严谨，或者未经过实践验证成熟的伪需求。需求管理的第一要务就是要将这些伪需求排除，只做确定性的需求。

需求管理有三大任务：需求收集，需求细化以及需求管控，如下图3-1所示：

图3-1 需求管理三大任务

如何快速成为一个顶尖的项目经理？​www.zhihu.com

3.1 需求收集

需求一般由业务人员或者产品经理提出。我们经常发现绝大多数人提需求很容易，但是不会写需求文档，所以很多情况下在项目组里要配备专业的需求分析员来完成这个工作，如果没有专业的需求分析员，那么产品经理就要承担这个角色。

图3-2 需求收集六部曲

一、 需求访谈

并不是所有的需求收集阶段都需要需求访谈。对原有系统或项目小的优化，或产品经理自己就可以撰写需求的情况下是无需访谈的。如果针对大型的复合型项目，比如需求方牵扯多个部门或者多个地区时，一定要做好需求访谈，因为几乎不大可能有人能够对所有业务部门的工作细节和需求都了如指掌。在需求访谈阶段需要注意如下5个点：

1. 制定访谈计划

在工作中基本上每个人都身兼多项工作，不大可能将100%的时间和精力只投入到一个项目。因此，在需求访谈期初一定要确定好被访谈对象的时间，并尽早与对方完成时间的确认，以便被访谈人提前做好安排。制定需求访谈计划针对有多个业务方时尤为重要。

2. 确定访谈对象

在制定访谈计划的同时需要确定访谈对象。需求的提出方要对自己提的需求承担责任，站在多一事不如少一事的角度，必然存在互相推诿的情况，因此框定需求访谈对象就是框定需求责任负责人。

3. 框定访谈内容

框定访谈内容就是撰写访谈的提纲。为了提升访谈的效率，被访谈对象必定需要提前准备相关的材料、梳理业务流程和逻辑。撰写访谈提纲的任务一般由产品经理或需求分析员完成，他们不一定精通相关业务，但至少需要对业务范围有大致的了解，对项目目标非常清晰。

4. 记录访谈纪要

需求访谈获取的信息量很大，因此在访谈过程中要有专人记录访谈纪要，必要时可使用录音设备。访谈纪要是需求文档的基础素材，在撰写需求文档的时候经常会反复查看或者回放录音。

5. 确认访谈内容

根据经验，大型项目的需求访谈一般需要进行三轮，每一轮访谈都会比上一轮访谈更深入。常见的情况是：

第一轮：产品经理或需求分析员对业务了解不足，访谈过程中发现有些内容在访谈提纲中没有考虑到；被访谈者第一轮准备的材料不充分或者有些业务流程细节不清楚，要回去确认后答复。

第二轮：产品经理或需求分析员根据第一轮获取的信息撰写需求文档，发现业务流程不通顺或者还有更好的优化方案，对第一轮访谈之后提交的补充材料或流程细节有疑问。

第三轮：需求访谈双方互相确认对业务及需求的理解达成一致，过滤掉不成熟的想法，确定了相对明确的需求范围。

如何快速成为一个顶尖的项目经理？​www.zhihu.com

二、 制定需求模板、划分需求类别

前面说到过，绝大多数人能提出需求，但是写不出来需求文档，就是因为对需求的划分没有概念。因此项目经理需要制定需求模板，分发给不同模块的需求撰写负责人填充需求内容。

需求划分方法因项目不同而不同，以软件类项目为例，需求分为9类：流程性需求、数据性需求、接口性需求、界面性需求、权限性需求、表单性需求、报表性需求、功能性需求、非功能性需求。其中非功能性需求指的是性能、吞吐量及批处理等。

三、 制定需求撰写详细计划

需求类别和模板确定之后，就要分配给项目相关负责人去撰写需求。对中大型项目来说，撰写需求说明书的人应该有多个，所以需要切分工作任务，切分的原则是：每个任务尽可能独立，任务的安排尽可能并行。每个任务必须要确定完成时间，如果时间不满足项目进度，需调配其它人力资源进行协助。有些项目比较特殊，可能现有项目成员的专业能力无法覆盖，此时需要引入外部专家或者将这部分任务外包出去。

交付物的形式在制定需求模板和划分需求类别的时候已经确定，任务执行者不能擅自改变交付物的形式，比如需求文档约定使用PPT形式来交付，就绝对不能做成Excel或Word。

为了把控需求收集的进度，需求撰写计划中要安排几个检查点。举个例子，假如需求撰写的排期是1个月，那么就可以设置3个检查点。第一个检查点为第一周结束，第二个检查点为第三周结束，第三个检查点为第四周结束前2天。每到一个检查点，各个需求撰写人需将成果汇总到项目经理手里做review，根据review的意见或建议迅速调整或整改。

为什么要在第四周结束前2天设置检查点？这是成熟的项目管理者和项目管理新手的区别，就是每个大的里程碑都会给自己留一点时间来容错或者应急。项目过程中永远都会有无法预料到的坑等着你，单纯的回避和抱怨都是不成熟的表现，正确的做法是提前做好备用预案。

计划制定好之后要要同步给所有项目参与者，这样每个人都知道自己在什么时候应该交付什么东西，项目经理只需要按照检查点跟踪计划即可。

四、 项目内审查

一般来说，需求文档是很重要的交付物之一，为了确保需求文档的质量，就需要建立互查机制：项目组内互查、项目组间互查。该任务发生在最后一个检查点结束之后。

项目组内互查：确定交付物业务流程是否正确，格式是否出现不一致；

项目组间互查：大型项目可能涉及多个项目组，项目组间相互依赖，此时需要项目组间互查，以确保项目组间的输入输出是否对接的上。

五、 与业务确定需求

当需求文档完成审查之后，即可交付给业务负责人做确认。为了加速业务负责人确认需求文档的时间，可以邀请业务负责人参加需求评审会，或者讲述一遍业务需求，然后再让业务负责人线下确认，如果有修改意见，可约定邮件或者备注形式反馈，同时要跟对方说清楚确认完成时间。

六、 修改需求

当业务在确认需求说明书的过程中有反馈意见提出时，需尽快讨论并确认意见的合理性，对合理的需求需尽快更新到需求说明书中，再次提交确认。必要时可能需要再次访谈。

如何快速成为一个顶尖的项目经理？​www.zhihu.com

3.2 需求细化

业务主流程一般在需求访谈阶段都能梳理清楚，所以本节不再讨论细化流程的内容。我们重点讨论数据细化、界面细化、权限细化、报表细化、及批处理。

1. 数据细化

业务访谈过程中获取到的数据很多情况下是非结构化、异词同意的，或者格式不符合系统化管理，此时就需要数据细化。

数据细化的过程一般如下：

第一步：挖掘各个业务需求方提出的数据项（源于需求访谈阶段获取的表单、表格、报表或台账等），再梳理各数据项的含义，以及使用场景。

第二步：合并每个需求方梳理出的数据项，将这些数据项合并，去除冗余、合并同义词，确定各数据项的取值范围。

第三步：确定数据项之间的运算关系、依赖关系、输入输出关系。

细化后的数据应该由专人管理，项目进行期间对数据项的增加、删除、修改都应该统一维护，否则很容易出现不一致。

2. 界面细化

界面细化主要是为产品设计做好铺垫，这个阶段需要确定哪些界面应该展现哪些数据项、界面之间的跳转关系、正常或者异常时的交互方式、不同权限的用户看到的界面有何不同。

3. 权限控制

在需求分析阶段，越早梳理用户权限越好。一方面，如果需求分析早期没有梳理用户权限，后期很容易疏漏，下次发现时往往是系统上线的时候，再改代价很大；另一方面，权限对用户非常敏感，一旦用户发现自己的权限不足或过大，对整个项目的整体评价容易走极端。

4. 报表细化

报表是很多经验不足的产品经理或需求分析员非常容易忽略的内容，甚至有些人不认为报表需求是需求文档的一部分，这是不对的。

5. 批处理

批处理主要涉及的任务有报表和上下游系统的交互。

3.3 需求管控

需求管控包含四个方面：需求跟踪、需求差异控制、需求变更控制及需求解释。

1. 需求跟踪

需求跟踪指的是牵头或推进一个非体系化的需求成为体系化需求的过程。举例来说：用户需要管理一个银行的流动性，而流动性的管理建立在对历史n天每日资金的进出情况以及未来m天每日资金的进出情况的分析基础上的。这是一个很确定的需求，但是历史资金进出情况及未来资金进出预测的数据从哪来？这些数据很可能分布在全行很多部门或者系统当中。那么跟踪这个需求就是安排专人在指定的时间范围之内拿到这些数据，再基于数据建模。

2. 需求差异控制

需求差异控制指的是控制用户对需求实现的期望。

还以上面流动性的例子为例：用户期望在3个月之内做一套管理银行流动性的系统，但项目经理评估，因人力资源或者其它原因，无法实现3个月之内达成这个目标。此时就需要降低用户的预期，协商能否3个月之内先实现三分之二业务品种的流动性管理，剩下的三分之一在5个月之内完成或者用户手工完成。当然，需求差异控制需要一定的技巧，至少要让用户觉得是有理有据。

3. 需求变更控制

需求变更控制简单的说就是控制需求尽量不要发生变化，但不绝对。比如项目进行期间业务模式发生变化，之前提出的业务模式已经不适用了，那么就一定要允许变化，否则失去了项目的意义。

当发生需求变更时，项目经理要从以下四个层面进行评估：变更的目标、变更的性质、变更的影响以及变更的方式。如下（图3-3 评估需求变更）所示。

图3-3 评估需求变更

需求变更控制最简单的方法，就是提高变更的代价，比如通过制定需求变更的模板及很长的审批链条来控制变更的频率。如果需求变更没有代价，那么用户提需求的时候就容易草率，对项目管理百害而无一利。当然，这个需求变更的模板由用户自己来填。图3-4就是一个比较复杂的需求变更模板。

图3-4 需求变更申请模板

复杂的模板并不只是为了增加需求变更的阻力，更是为了留痕和归档。不然对周期很长的项目，做到后面项目组成员都换了一遍，需求从最初到现在没人说的清楚。

添加微信：shangqi00001，可交流项目管理中各种疑难杂症。

关于项目管理的live，之前讲过一次，有兴趣的也可以去翻牌：

如何快速成为一个顶尖的项目经理？​www.zhihu.com

抖了这么多干货，有所收获的请点个赞再走呗~~