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

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

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

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

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

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

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

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

第一、想办法让来源可靠

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

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

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

第三、让需求说人话

用户故事可以让所有的相关方理解趋近于一直，原型的表示方法更是能让大家直观的看到产品的样子。
这里的说人话，不是语言的问题，问题在于，让整个团队和相关方，都能明白你的需求想表达的意思，而且要认可这个意思，很多地方讲需求需要无二义性就是这个道理。我们如果在互相之间找不到一种共同的交流方式，那也没有关系，就去创造一种。

第四、让需求受控

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

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

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

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

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

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