如何在项目管理规划阶段对需求文件进行质量控制？

一、本期话题

IT行业中，如何在项目管理规划阶段对需求文件进行质量控制？

二、嘉宾分享

1

首先声明一下，我不认为关于需求文件的质量只是要在规划阶段控制，需求质量的控制是贯穿在项目所有阶段进行的，单一个规划阶段是解决不了问题的，而且这跟用的什么开发模型不相关。

我们先看看需求质量到底是个什么东西。

引用PMBOK中对基准的需求质量的要求是这样描述的“只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。”这是对需求文件的要求，也是对需求基准的要求。

“明确的”意思是任何需求都是必要的能够使用一定的标准去判断需求是不是能够得到满足，并且能够通过一些手段进行验证。

很多同学不知道需求要跟踪什么，其实对于需求来说，跟踪的内容其实会包含两个大部分。第一个大部分是指，需求的成果，即可交付成果是不是能够满足最初的需要，其实，并不是说，我们对成果进行验证这么简单，而是要在项目研发的每一个环节对项目原始需求对应。

所谓的完整，通俗来说，就是不能说半截子话，或者是，在表达需求的时候，要对使用场景和解决的问题说清楚。在表达需求的时候，一定把前因后果、场景用途表达清楚。

相互协调的，就是说，需求质量不只是单看某一部分，要整体来看。往往的，我们的一个需求整体是要解决一系列的问题的或者说，我们解决的问题都是有普遍联系的。那就预示着，需求整体来看，不能突兀关联，也不能相互矛盾。

相关方愿意认可的，这一点我觉得最重要，归根结底来说，你生产出的产品和成果事要交付给用户使用的，或者你的相关方希望能够从这个项目的成果中获取到什么利益。那就不能霸气的说，我不要你觉得，我要我觉得了。从根本上来说，你觉得更重要，即使不合理，即使反人类，但是当相关方愿意承认这就是真实需求的时候，那这就是真实需求了。

第一、想办法让来源可靠

找准关键需求方，只是让来源可靠的一个方面，另外一个更重要的方面要看咱们收集需求的时候，怎么去深入挖掘真实意图。所谓去伪存真，往往伪需求面具下藏着的就是用户的真实需求。说到这就得用一点手段了。

第二， 采用多样、多方位的需求收集手段。

标杆对照，引导，原型都是很好用的需求收集和分析工具，

需求采集和分析的手段很多，关键的问题在于，对不同的项目，不同的相关方，方法也不是一成不变的，这对项目经理和需求收集人员的要求是比较高的。见人说人话，见鬼说鬼话，不在于你用的这个方法的学术名词是什么，在于你真的可以把用户需求收集上来。不但要需求换收集上来，关键的哪句话，要完整，协调，且有人愿意承认。

第三、让需求说人话

用户故事可以让所有的相关方理解趋近于一直，原型的表示方法更是能让大家直观的看到产品的样子

这里的说人话，不是语言的问题，问题在于，让整个团队和相关方，都能明白你的需求想表达的意思，而且要认可这个意思，很多地方讲需求需要无二义性就是这个道理。我们如果在互相之间找不到一种共同的交流方式，那也没有关系，就去创造一种。

第四、让需求受控

很多的时候，我对面对需求变更，特别是IT行业中的需求变更是比较排斥的。但是在这里我想说的是，受控的意思并不是绝对的不能变更，或者说必须将需求锁定在某一个范围。随着我们对VUCA这个词越来越熟悉，我们也知道，这已经越来越趋近于一个不可能发生的事情了。也就是我们说的所谓“拥抱需求”

除此之外，受控的另一个方面是，我们要保证所有的需求都有过正式的发布，这与传统做法是相一致的。并不是说我们拥抱需求就可以在需求层面随意的发挥，需求通过获取、记录、评审、验证的过程也是必不可少的。换句话说，一口唾沫一个钉的事情还是要做。定义好的需求，要通过正式的发布，才能作为开发的依据。这是对团队负责，也是对用户负责。

第五、让专业的人做专业的事

从PMBOK第六版开始，PMI在每个过程中加入了“发展趋势和新兴实践”这个小结。另外，在每一年的《职业脉搏调查》中，也会对未来的一些趋势做数据层面的分析和预测。

PMI有个专门的认证叫PMI-PBA，即商业分析专业人士。这个认证对项目分析师的要求其实我们可以近似理解为现在大家都能够普遍接受的项目经理岗位。通过一系列的手段和方法，从实现商业价值的角度实现组织的战略目标。

所以有一个合作良好的商业分析师或者产品经理与项目团队进行合作，是最快也是最直接的解决需求质量问题的选择。

2

大家好，我是追星骑士，十年来服务于金融行业的IT系统。从运维做到项目管理，从乙方跳到甲方。

我觉得这类IT系统特点是严谨，需求范围边界明确，个性需求众多，开发周期相对宽松。相比其它快速迭代的系统来说，它对项目有更高的质量要求。

在分享之前先引入一个会计术语：勾稽。简单来说，是指数据、内容在各个输入、输出结果中有内在逻辑对应关系，如果不相等或不对应，这说明输出结果出现问题。

在这个话题里，可以理解为需求文件与质量管理工具、输出文件之间的对应关系。项目里经常用到的流程图和时序图，是很好的质量管理工具，可以通过它们来制定勾稽规则和校验需求。

通过流程节点与需求范围说明和基准进行勾稽，检查每个节点和文件内容找到对应关系，节点流向的逻辑和需求中的前后逻辑相通，可以校验需求文件内容是否完整，逻辑是否正确，是否还有逻辑漏洞和分支。

还有一种情况是由于需求方安排了多人向开发商讲解需求的不同部分，导致需求细节零散，各个小需求在对接上存在问题，甚至因用语导致双方理解存在似是而非的情况。可以通过会议、建立系统原型等方式，将需求落地，让需求的内部勾稽关系建立起来。

上面说的都是基本工作，相信项目经理都有尝试去做，但因时间和精力的影响，效果不理想，项目周期紧，变更频繁是制约需求文件质量的关键。

个人觉得首先是先明确需求范围，避免范围蔓延，如果有需求变更了，一样先明确需求范围；其次是按业务功能、流程分解好WBS，每个WBS分配人员负责，除输出项目需求文件和质量指标之外，还制定勾稽规则；最后抓好关键WBS，在关键功能上多下精力，勾稽结果尽量完备、统一。

3

/ 我有话说 /

啊潮-广州-互联网：

“从0到1开始梳理需求，从文件识别相关方，业务流程、人员结构、形成文件后，在进一步确认需求，确认后进行相关方确认记录，变更管理流程。”

EQ无-新疆-IT+教育：

“这个话题我的想法是：先收集客户需求，之后让PM先筛选一部分不合理需求直接反馈给客户，之后把剩余合理需求交给研发组一起讨论一下，最后把讨论出来的能实现的需求加上目前不好实现的，但是可以用其他方式实现功能的需求做一张表交给客户，进行下一步沟通，如果客户同意这些需求就直接上项目。如果还不行的话就和客户继续沟通。”

绿林豪杰：

“这个我有经验，之前有个项目，有大牛在规划阶段就定义好质量控制的指标，项目跟着指标走，用户也承认这个指标。这样来控制项目的质量。”

安可-重庆-软件：

“对于公招的项目 根据招标文件的需求方案 细化出来同甲方爸爸确认

非公招的项目 直接和甲方爸爸勾兑 但是一般甲方爸爸都会变 所以要设置边界。”

当铺当家：

需求质量有几个点需注意一下 ：1. 需求的输入 ；对客户或高层反馈的需求得进行市场调研、竞品分析等方式量化，选取妥当的实现路线。2.需求的梳理 ；梳理需求逻辑路线，建立闭环，进行优化。3.需求的输出 一方面是获得客户或高层的认可，另一方面对内召开评审 与项目组的开发、UI、测试等明确目标、达成一致。

小嘉Carrie-上海-互联网:

这个我有发言权了,如果这个是公司自有产品研发项目，一般先是商业论证吧，然后这个时候定下了产品的大方向，大目标。之后就看开发方式了。

像我们这种创业机构基本上就是敏捷方法（虽然我对敏捷开发管理这套不太熟）。我们基本上线产品规划大迭代方向，基本上三个月左右算一个大迭代周期吧，大概会规划3个以上，差不多覆盖1年。然后就是把每个大迭代拆成迭代计划+优化计划。迭代计划是可以确定的，基本上通过对需求的重要性分级，开发的时间等来拆，嗯，还有评审。主要是产品规划出来之后，各业务部门和技术部门一起来评估这次产品迭代计划，提出自己的问题，然后产品在会议再来反馈集合大家意见之后的调整，然后就直接进入开发阶段了。

我觉得对于质量的控制，除了规划之外，专家建议也是比较重要的。特别是目前很多产品不一定有运营经验或技术开发经验，所以需求有时候是非常天马行空的（我们喜欢用“反人类”这个词），因此评审是非常重要的，而且在开发过程中也会有各种变更的问题，所以项目管理的难度在于，对交付成果和最初需求的关联，因为在IT行业中，交付成果大变动完全跟当初需求不一致也是常常发生的呀。