返工，任何项目和项目经理都不愿意面对的一个事。一旦这件事发生，就意味着，要么PM 干不下去了，要么项目就干不下去了。但是有的时候，返工对项目经理个体来说是没有办法控制的，原因方方面面。
面对大量返工，如何梳理流程来控制进度和成本？
为什么会返工？
对于这个“大量返工”这个命题来说，首先我们应该确认返工的根本原因是什么造成的。
返工的原因无非 3 种：
1、需求不明确，需求变更导致可交付物无法定型，长期处于动荡状态，从而导致不断推翻重来的返工。
2、需求明确，质量控制不严，未能及时发现研发人员交付的功能的缺陷。
3、需求明确，质量控制严，但时间紧任务重，功能来不及验证，边上边改。
需要 PM 针对以上三种情况对症下药，同时也应该明确一点“预防的成本是最小的”，我们要随时都有这种危机意识。
一、对症下药
对于需求不明确
需求不明确，通常是需求描述不清楚，验收标准不明确。从需求管理范畴来说，引入一些敏捷的思想与方法，避免或缓解返工的举措，可以参考以下几点：
1）更频繁的交付和反馈
客户或者用户通常不清楚自己的需求，至少是讲不清楚自己的需求。所见即所得，能看到的东西才是最直观的，因而，可以尽量用一个 MVP（minimumviable product（最小可行产品），在客户与甲方的配合之下，用尽量低的成本去确认用户或甲方的需求。从而尽早识别变更，降低变更成本，从而降低成本，保证进度，减少返工。
2）需求判定漏斗
需求判定漏斗，是一种需求获取的建模工具，虽然说对这件事建模会显得比较奇怪，但是在实际工作中，用模型思想去做一些事情确实是有用的，通过需求获取建模，判定需求真伪。不要通过听到的东西确定需求而是通过确定需求的根本原因来确定需求。不至于做出来被废弃或者是返工。
3）用户画像和应用场景分析
通过用户画像与应用场景分析来确定目标用户的属性和行为特征，输出用户故事，也就是需求，这种描述方式会贴近于真实的应用环境和用户环境，从而保证需求的有效性。
4）原型环境下获取真实需要
语言或文字在不同的人思维中呈现出的画面下，绝对是不一样的，这样就很容易产生预期偏差，一旦产生预期偏差就会造成无价值交付，既然没有价值要么不要了要么重做。我们需要满足的不是客户指定的需求而是理解客户的需要，通过客户的真实需要确定真正需要实现的需求。
5）能引发讨论的，有明确验收标准的需求条目或者需求卡片
当需求被记录下来，或者被转述后，在团队不同角色对需求的理解是有明显偏差的，所以，敏捷中的方法对这件事提出了 3 个 C 的原则，即 Card，Communiacation，Confirmation，也就是说，用一张卡牌去传递需求，通过卡牌引发对需求的探讨，从而达成多方的一致，以保证需求不会被歪曲。另外，所有的需求都要定义什么叫 Done，这个 Done 绝对不是臆想出来的，也是要通过讨论和确认的。这样的做法旨在保证能够将最原始的需求传递到最后，并保障需求还原的质量。
6）做好项目的需求变更管理
VUCA 时代倡导拥抱变化。但拥抱变化并不是范围蔓延，更不是项目镀金，而是尽早地识别变化，以适应这些 VUCA。而管理变更，更不是阻止变更，是要让这些变化有序的发生。变更管理不善，特别容易产生交付困难，项目成本和周期的增加的问题。
二、对于质量控制不严
需求明确、质量控制不严导致的返工，可以通过加强管理手段与过程手段来做。
1）计划--项目启动阶段
需要 PM 在项目的全生命周期进行跟踪与关注，首先项目启动阶段，召开项目启动会议时将研发、测试人员叫到一起，让他们对系统功能实现做到心中有数，从而保证大方向步调一致。PM 必须制定项目的设计说明书，包括但不限于原型设计、pdr 文档等。
2）执行--项目研发阶段
然后是项目研发阶段，此时要求项目经理制定严格的开发计划，如果每一个功能点的开发时常不应该超过 2 个工作日，超过则检视是否为研发人员对需求理解不到位，同时开发计划的周期如果为 2 个工作周，后边的开发计划可以迭代进行。然后每个工作周组织测试人员对研发交付的功能进行验证（前提是研发人员完成功能自测），测试人员认为功能满足才能视为此功能开发完成。研发人员在执行开发计划过程中必须严格遵守设计说明书，严禁不看文档直接开发的情况发生。
3）检查--反馈总结问题
另外最好能做 15 分钟左右的一个站立会，组内成员汇报各自前一天的进展情况和当天工作计划，原则上要求回报与计划的偏离情况（正偏离，负偏离），保证任务保质保量的完成。
三、对于时间任务紧迫
时间紧任务重的情况造成返工。首先 PM 和技术 leader 沟通一下赶工的情况下能否完成指定的工作要求，如果无法完成，确认需要多少资源然后立即汇报领导，申请资源。如果在全力投入的情况下依旧无法完成的话，组织内部会议沟通出能完成的极限需求范围（保质），然后跟甲方、客户沟通是否舍弃一些非必要功能。
如果确认好需求范围之后，发现无法按时或者按照质量要求交付，就可以考虑是否增加成本与资源来达成既定目标。
那么综上所述，还是那句话“预防胜于治疗“，尽可能把风险掐死在摇篮里。
网友评论