对号入座，项目中那些灵魂拷问该怎么应对

本文由研发项目管理系统整理：

作为IT大军的一员，不论从事什么岗位，产品、开发亦或是测试，项目实施中，大家都可能问出或者被问以下这些问题，我相信屏幕前的你一定也是感同身受，下面谈谈当总被这些惊魂之问环绕时，我们可以做些什么。

一、被嫌弃的产品小白

写出一份优秀的需求文档，以产品经理的本领，不算是一件困难的事情。但实际项目过程中，需求写的太简化，变更太频繁，开发和测试的抱怨和投诉接踵而至，产品经理这样的经历一定不会少。

1、需求就这么两句话？

需求调研不可省：产品经理想要需求分析全面，初期可以“访谈式”沟通，通过访谈、问卷调查、调研会等获取业务真实诉求；中期可以“诱导式”演示，通过原型演示等收集业务反馈意见；在上述阶段成果基础上，可以通过“确认式”评审与业务进行达成一致。

文档模板标准化：好的需求说明书模板可以帮助产品经理将需求分析的更完备，特别是容易遗漏的非功能性需求，如安全性需求、性能需求、报表需求等；过程中可以根据反馈意见和常见问题，对模板进行持续升级。重要的事情说明三遍：模板制定后要使用，要使用，要使用。

需求评审有底线：需求文档是开发、测试阶段最核心的输入之一，开发和测试人员在参加需求评审时，针对需求描述不完整、有歧义、一笔带过的现象，主动提出评审意见，避免实施过程中自己对需求进行猜测和加工，带来各种返工。

2、需求怎么总在变？

提前识别、积极响应：大多数变更来源自业务方，产品经理要从源头识别存在的“假”需求，挖掘出业务真正的诉求（前文提到的“访谈式”沟通、“诱导式”演示、“确认式”评审），降低后期变更几率。项目过程中关注内外部环境（市场、政策等），定期对需求进行审视，发现需求不合适/遗漏的点，及时提出，做到“早发现、早治疗”，不可为避免变更而掩藏。

规范变更、守住底线：比变更更可怕的是变更不通知相关方，这也是测试常常吐槽产品经理的点；项目过程中各类变更应按规范组织变更评审，形成达成共识的结论。同时要控制评审准出，不是所有的变更都应得到批准，不合理的变更该拒绝的要拒绝，如临近上线要新加需求。

二、问题改不完的小开发

1、这么简单的功能也出错？

程序员群体流转一句话：不写代码就没有BUG。项目中我们不苛求每个开发都能不引入BUG，我们要做的是争取少引入BUG，争取一次把事情做对。

代码规范要能落地：绝大多数组织都有自己成熟的编码规范，而能真正落到实处才能让规范发挥作用。一方面，可以制定易记忆的简化规约和checklist等各场景进行应用，另一方面，可以使用代码扫描工具的自定义规则将组织规范进行固化。

代码评审要有效果：评审可以最好的发现BUG，也容易流于形式，实操时可以多样化，根据情况因地制宜。评审方式上交叉评审、会议评审、代码走读、专家评审等结合使用，范围上可以重点覆盖核心模块、复杂业务逻辑、新员工负责模块等；

自测试能力要建设：首先，要提升自测重视程度，自测通过才算编码完成，自测的工作量投入要得到保证；其次，自测范围需包含单元测试、接口自动化、冒烟测试，要能覆盖正向、逆向、正常、异常、并发等场景；最后自测的结果要保证，单测覆盖率、通过率、自测功能覆盖度等要符合准出要求。

2、这么点功能要这么长时间？

我们常常因为工作量和业务进行争论，业务认为一个简单功能报这么多人天是在坑他，总结来说就是业务认为工作量不合理，我们又说服不了业务，让业务认为这个工作量合理。

任务项分解合理是前提：可以基于需求功能清单进行拆解，估算各功能模块所需的产品、开发、测试等工作量，也可以基于项目阶段的WBS拆分进行各工作包的估算。需要注意的是避免有遗漏工作项，特别是支撑型活动，如评审类活动。这样各项任务所需工作量可以明明白白的展示给业务方。

工作量专家评审更权威：工作量屡屡遭到质疑时，引入专家评审是最能让各相关方信服的手段。通常可以选取同领域的同行专家对项目工作量进行评审复核，专家选择上要尽量保证其独立性（非直接利益相关方）、权威性（该领域内的资深人员）。

工作量最核心原则是要估算合理，其不仅预测未来，而且会影响未来，过低的估算会导致过低的质量，可能要返工，过高的估算可能减低工作效率。另外技术角度上，系统架构要做到可扩展和可复用，以弹性的架构来解决研发效率问题，降低研发成本投入。

三、总背锅的测试萌妹

1、这个BUG为什么测不出来？

这一定是大多数测试而言都是最怕遇到的灵魂拷问，漏测虽说是测试心中永远的痛，但只要不回避问题，不急于撇责甩锅，就是优秀的测试。

漏测分析第一步：遇到生产问题，测试最先做的是第一时间组织测试复现和漏测分析，使用根因分析方法（5WHY、鱼骨图等）分析各个环节存在的问题，制定相应改进措施，不断反省改进，才能提高。

测试案例最核心：测试人员在案例设计中做到全覆盖各业务场景是防止漏测的关键。我们遇到最多的漏测原因就是场景覆盖遗漏，这里推荐使用思维导图的方式对业务场景的各个分支进行梳理并针对性设计案例；同时要设计相应端到端测试案例，避免多个单场景测试时通过的，但多场景多系统组合串联时就会出现问题。

测试执行是保障：成功的测试离不开有效的执行，同样的一组案例，在不同的测试人员手中，测试结果应是一样的，其实际多数会存在差异。可能体现在发现BUG数、BUG单闭环跟进、回归验证等多个方面；测试执行做的好离不开一个词就是“严谨”，预置条件、测试数据、测试环境、测试步骤、预期输出是等测试执行活动都离不开“严谨”，一切“勉强凑合”、“得过且过”的行为都不该出现在测试过程中。

结尾语：

“看到了别人的需要，你就成功了一半；满足了别人的需求，你就成功了全部”。

当你被这些灵魂拷问环绕时，说明你上下游小伙伴们（产品/开发/测试）的诉求还未得到满足；真诚祝愿每位产品、开发、测试小伙伴，都能在这些灵魂拷问中提升自己的专业能力，一次把事情做对。