我们如何控制需求质量？

海之月

我们如何控制需求质量？

在很多质量人员看来，研发质量管控是从设计质量开始的，我并不这么认为。比设计更重要的其实是需求，如果说，设计是正确的实现客户要求，那么需求质量体现在如何能正确的洞察客户的需求。如果需求都是错的或者有偏差，那么研发出来的产品返工和失败则是必然的。

但如何保证需求质量，在传统质量工具里面还没有涉及，如何挖掘需求，之前文章中已经谈过很多方法，这里不再累述，今天重点谈如何管控需求质量。

海之月

1 —

需求基本过程

我们首先看，需求的整个过程。
企业会选择用户，然后基于用户的场景，识别出用户的需求，或者销售人员在于客户沟通过程中，客户会反馈他们的一些需求。
因为这些需求主要是从用户的知识与生活经验出发得到的，但我们用我们具体产品来解决这些问题时，需要进行翻译，使得用户的问题或者痛点，通过我们的产品能给予解决，于是形成产品需求。
为了开发出这些产品，研发需要对需求进行设计，然后，把需求分配到不同系统予以实现，最后验证。
举个例子：
用户需求：我想随时随地的与他人进行交流沟通
于是诞生了产品--手机
当我们要提出手机做成什么样，就会变成产品需求，但用户不是专业人员所以，通常会说的比较抽象，比如：好用、时尚、使用流畅。我们称为，产品的特性，最后这些特性具体用什么功能体现，需要什么软硬件，定义好我们才能进入开发。
这个过程如下图所示：

海之月

所以，需求的形成是：

海之月

2 —

需求的关键控制点



1.需求的真伪判断


因为需求来源很杂乱，通常会有下面几个来源
1. 领导指示
2. 年度战略规划
3.  行业竞争
4、对市场上竞品的机械模仿
5、产品经理自己的假设
6、销售需求当产品需求
说起前面5种通常不太靠谱大家可能会会心一笑，但第6点，很多同学可能会问，销售不是最接近客户的吗他们应该提到就是客户亲口说的，还能有假。
是的，根据宋老师的实际经验看，确实很多时候都是假的，这里并非说销售说假话，而是因为，销售提出的需求，没有专业的洞察、不深入、不完整、杜撰需求。
有一次做一个项目咨询辅导时，销售提了一个需求：银行用户可以用手机来控制一个现金保管设备。听起来，还是很合理，而是很时髦。但是，如果深入到场景你会发现，在现金保管设备，在一个严密的保密空间里，根本没有任何无线信号，哪里能用什么手机控制呢？
这明显是，销售根据，客户喜欢方便不愿意再增加新设备而帮客户杜撰的需求。
所以，我们在进行需求进行筛选时，一定要对需求进行验证。
验证人可以是，质量人员，或者测试人员，甚至市场人员。
如何验证？很简单
让提出需求的人，回归到需求的提出的场景，以及具体提出人，然后电话或者现场实地考察或电话联系具体人员访谈。
有同学说，这个太麻烦了，但是你要知道，这里不费点时间，一旦这个需求当成真正需求进入后面的过程，那个成本可能是，10倍，甚至100倍，甚至项目失败。
因此，在IPD流程，概念阶段，其实有个关键活动就是，市场需求验证。但现在市面的资料上，基本都把这个忽略了。

海之月

2.需求的有效性


好经过前面验证，确定场景确实存在，但有没有必要做呢？又是一个问题，需求价值从来就是要从ROI来考量的事情。
因此要特别关注用户的习惯成本，需求如果做了，与用户现有的解决方案比有什么优势？
一个大多数人看不到的事实：在绝大多数情况下，用户远没有他自己说的那么痛，因为他已经在用一些工具或者方法解决他现有的问题。在这样的情况下，需求其实是一个“更”字：更快、更便宜、更方便等。比如：微信比短信的及时通讯方式更便捷，由于微信的解决方案对短信有极大的超越，导致微信颠覆了短信。
如果你将需求做进了产品，却对用户的现有解决方案没有“更”的超越，这个需求就白做了。而且，不是一个稍微“更”，而是极大的“更”。没有极大的超越，就不要着急做。
如果我们用，需求=刚需*频次  的公式来确定需求的有效性
图片
第一象限是兵家必争之地，一般企业可能没有机会，如果你发现有，那恭喜你，你有望成为巨头，或者被巨头收编，当然也可能是成为炮灰。
第二象限，只能做小而美的生意了，要求每单的利润要高。
大量需求，实际都会出现在第4象限，因此，可以要求市场部同事，对需求的2个维度进行论证，这样就靠谱多了。

海之月

3.需求的评审



我们知道需求的评审，是对需要质量把控的重要环节，但是很多公司评审实在的令人好笑。
有一家公司请IPD咨询公司做咨询，做完IPD流程，但告诉我他们需求评审没啥效果，开展让部门经理评，结果没评出什么问题，找总监评也没效果，老板最后亲自出马，也没评出啥问题，但是到客户那里以及后期生产环节，问题多多。
我仔细去看了一下。原来他们需求是研发人员写的里面，都细化到：
产品用什么模块，具有具体什么功能，产品规格如何？
有同学会有疑问？这样不是挺好吗？
但是你忘记了，公司不同专业人员，擅长是不同的。
比如，销售和用服人员，他们是不懂这些具体技术细节的，但他们能准确知道用户的使用场景。生产人员，不知道用户场景，但知道产品制造环节的痛点。
我们产品需求，也是要满足相关方需求的，因此，对需求我们必须提供不同的描述界面和层次，比如，让销售和用服人员，评需求的场景。   制造评审产品的DFM需求。研发架构师，评具体产品规格需求。
这样，每个人都能发挥自己常处，可以提出自己的问题了。
因此，每个企业要建立自己的需求系统工程，因为不同企业需求的划分层次是不同的。

海之月

4.需求文档的审核



即使前面都做好了，需求传递到后端时，还会出现信息的衰减导致问题。
需求的描述通常需要满足如下几点：
（1）完整性：每一项需求都必须将所要实现的功能描述清楚，使设计人员获得设计和实现这些功能所需的必要信息。
（2）正确定：每一项需求都必须准确地陈述其要开发的功能。（只有用户代表才能确定需求的正确性）
（3）可行性：每一项需求都必须是在已知的系统或环境内可以实现的。（建立数学模型，进行仿真）
（4）必要性：每项需求都是编写文档的根源，每项需求都唔那个回溯到具体用户。（用户需求，跟踪矩阵，WishList）
（5）无歧义性：对所有的需求，读者只能有一个明确统一的解释。（形式化的语言、图、表）
（6）可验证性：检查每一项需求是否能通过测试用例或其它验证方法。

海之月

在这里最重要的是，可验证性，因此在需求提出时，QA人员需要介入，对需求进行可验证性评估，对保证需求的传递的准确性，非常重要。
对于需求质量的评估可以采用下面这个checklist，供大家参考：
图片


需求是用用户的语言书写的吗？用户也这么认为吗？
每条需求与其他需求冲突么？
是否详细定义了相互竞争的特性之间的权衡；
是否避免在需求中规定设计方案？
需求是否在详细程度上保持相当一致的水平？有些需求应该更详细地描述吗？有些需求应该更粗略的描述吗？
需求是否足够清晰，即使转给另一个独立小组去构建，他们也能理解吗？开发者也这么认为吗？
每个条款与待解决的问题及解决方案相关吗？能从每条款上追溯到它在问题中对应的根源？
是否每条需求都是可测试的？是否可能进行独立的测试，以检验不满足各项需求？
是否详细描述了所有可能的对需求的改动，包括各项改动的可能性？
需求完备
对于在开始开发之前无法获得的信息，是否详细描述了信息不完全的区域？
需求的完备度是否能达到这种程度：如果产品满足所有需求，那么它就可接受的？
你对全部需求都感到很舒服吗？你是否已经去掉那些不可能实现的需求—那些只是为安抚客户和老板的东西？

海之月

3 —

总结

需求是规划的起点，也是研发的起点。质量是符合要求，符合是很重要，但这个要求是否正确，其实更重要。预防的起点，和更多的质量保证活动应该投入在这个环节。但实际上，这块质量如何管控在质量界还缺乏探讨和总结。

zhiliangqc

学习受教了