面对大量返工，该怎么办？

话题描述

返工，任何项目和项目经理都不愿意面对的一个事。一旦这件事发生，就意味着，要么

PM 干不下去了，要么项目就干不下去了。但是有的时候，返工对项目经理个体来说是没有

办法控制的，原因方方面面。

面对大量返工，如何梳理流程来控制进度和成本？

听他们说

01

（一）找原因
     对于这个“大量返工”这个命题来说，首先我们应该确认返工的根本原因是什么造成的。我认为无非 3 种：
1、需求不明确，需求变更导致可交付物无法定型，长期处于动荡状态，从而导致不断推翻重来的返工。
2、需求明确，质量控制不严，未能及时发现研发人员交付的功能的缺陷. 3、时间紧任务重，功能来不及验证，边上变改。
需要 PM 针对以上三种情况对症下药，同时也应该明确一点“预防的成本是最小的”，我们要随时都有这种危机意识。

（二）对症下药
     对于需求不明确：
    需求不明确造成的返工，这点基本上不可避免总会发生的，而需求变更控制也是 PM 的基本功之一，之前在关于需求变更控制的分享中也有关于如何控制需求变更的一些个人见解，大家有兴趣的话可以找群精华看看。（文章末尾有链接）
     对于质量控制不严：
     需求明确、质量控制不严导致的返工。需要 PM 在项目的全生命周期进行跟踪与关注，首先项目启动阶段，召开项目启动会议时将研发、测试人员叫到一起，让他们对系统功能实现做到心中有数，从而保证大方向步调一致。PM 必须制定项目的设计说明书，包括但不限
于原型设计、pdr 文档等。
然后是项目研发阶段，此时要求项目经理制定严格的开发计划，我的理解是每一个功能点的开发时常不应该超过 2 个工作日，否则视为 PM 对项目的理解不到位，同时开发计划的周期为 2 个工作周，后边的开发计划可以模糊一点毕竟项目的本质是渐进明细。然后每个工作周组织测试人员对研发交付的功能进行验证（前提是研发人员完成功能自测），测试人员认为功能满足才能视为此功能开发完成。研发人员在执行开发计划过程中必须严格遵守设计说明书，严禁不看文档直接开发的情况发生。
另外最好能做 30 分钟左右的一个站立会，组内成员汇报各自前一天的进展情况和当天工作计划，原则上要求回报与计划的偏离情况（正偏离，负偏离），保证任务保质保量的完成。
基本上也就是咱们的 PMBOK 中说的“PDCA”模式。
     对于时间紧任务重：
     时间紧任务重的情况造成返工。首先 PM 和技术 leader 沟通一下赶工的情况下能否完成指定的工作要求，如果无法完成的情况下，确认需要多少资源然后立即汇报领导，申请资源如果在全力投入的情况下依旧无法完成的话，组织内部会议沟通出能完成的极限需求范围（保质），然后跟甲方、客户沟通阉割交付需求（尽可能给自己争取阉割一些非必要功能）。
因此赶工的情况下没什么好的办法只能硬着头皮上，但是切记权衡一下无法按时上线和交付出去后质量无法保证哪个对公司造成的打击更严重。毕竟赶工的必然会意味着质量不会被很好的保证。
    那么综上所述，还是那句话“预防胜于治疗“，尽可能把风险掐死在摇篮里。

02

（一）返工原因
     返工，任何项目和项目经理都不愿意面对的一个事，一旦这件事发生，就意味着，要么 PM 干不下去了，要么项目就干不下去了，但是有的时候，返工是作为项目经理个体来说没有办法控制的，原因方方面面。
     总的来说，作为项目经理和组织级项目管理部门还是要积极的应对，要么尽量试图修正这些返工带来的影响，要么避免类似情况在将来的项目中再发生。
       当然了，出现了返工的情况，而且如果是大量的返工情况，实际上我们第一个要做的是评估一下现在的状况，对于合同承诺履行的情况（如果是甲乙方项目的话），看看这个项目是不是还值得抢救一下，如果还一息尚存，该赶工赶工，该启动管理储备就启动管理储备，先将项目有序的做完，针对返工的情况做一些针对行的措施。
      要是已经死透了，该归档归档，也是要分析分析原因，定一定未来规划的。
      那对于返工来说，我们先得知道返工产生的根本原因，刨得越深刻，对解决这个事情越有利，往往在职场上，有些话不能说，怕得罪人，但是我只能说……尽量做个正直的人……抛去非正常变故还有比如说，资源故障，人员能力问题，技术不成熟等等这些特定因素，产生返工的根本原因无非是就是需求和质量两大方面（抛开在这两个过程中的人的因素，哪个组织无论什么岗位，总有那么一两个不靠谱的），那我们暂且先就研究这两个问题。
      先简单说说那些其他原因，对于项目经理来说，对项目最负责的态度我觉得应该是想方设法让项目可控，有些导致赶工的原因是能够在项目启动之前就能预见到的，就是我们俗称的风险。比如说技术不成熟的问题，是不是必须要用不成熟技术？如果要用，是不是要有一定的调研成本保障？要不要引入外部资源？资源故障的问题，是不是可以备份？等等，对于这些原因产生的返工，不太客气的说，都是自己作的，作为项目经理，只要能够预见和控制的，都应该想到。
      当然了，肯定还有一些不可控的原因，比如老板抽风之类的~尽人事，听天命，就是这个道理。
（二）如何应对
1、需求
    从需求角度讲，最常见的产生无非就是需求描述不清，验收标准不明确。这其实是需求管理范畴，我通常比较喜欢引入一些敏捷的思想和方法，避免或缓解返工产生的，能想到的做法大概如下：
1）更频繁的交付和反馈
      客户或者用户通常来说对自己的需要是不清楚的，至少是讲不清楚的，按照一个正常人的逻辑来说，实际上能看到的东西才是最直观的，所以我们尽量用一个 MVP（minimum viable product（最小可行产品），用尽量低的成本去确认用户或甲方的需要，当然了，这得需要甲方或客户最大成都的配合从而能够尽早的识别变更，降低变更成本，从而降低成本，保证进度，减少返工。
2）需求漏斗
      或者也叫需求判定漏斗，是一种需求获取的建模工具，虽然说对这件事建模会显得比较奇怪，但是在实际工作中，用模型思想去做一些事情确实是有用的，他是判定真伪需求的工具，实际上是，通过问好几个 Why 来决定 How 的一个需求过程。其基本宗旨就是，不要轻易相信你听到的是什么，要确定需求的根本原因是什么，那保证这个需求是有用的，不至于做出来被废弃或者是返工。介个东西大概长这样（灵魂画手上线，很多年前研究过需求工程，不知道画的对不对了已经）

3）用户画像和应用场景分析
      同样的，也是一种获取需求的一种方法，通常会用在产品类型的项目中，实际上就是对终端用户的一种行为模拟。通常我们定义一个人群，给这类人描述一定的属性和行为特征，这个过程就是用户画像。通过这些属性和行为特征，讲该类人群放在一个场景里面，来假设一些活动，从而判断活动产生的效果，这就是应用场景分析，最后我们会输出一系列的用户故事，也就是需求，这种描述方式会贴近于真实的应用环境和用户环境，从而保证这个需求是有效的。
4）原型
     大家都懂，在需求这件事上，通过语言或文字在不同的人脑补下，画面绝对是不一样的，这样就很容易产生预期偏差，一旦产生预期偏差就会造成无价值交付，既然没有价值要么不要了要么重做。在原型的环境下，我们所见即所得，引导激发需求来源的真实需要。
5）能引发讨论的，有明确验收标准的需求条目或者需求卡片
     当需求被记录下来，或者被转述后，在团队不同角色对需求的理解是有明显偏差的，所以，敏捷中的方法对这件事提出了 3 个 C 的原则，即 Card，Communiacation，Confirmation，也就是说，我们用一张卡牌去传递需求，通过卡牌引发对需求的探讨，从而达成多方的一致，以保证需求不会被歪曲。另外，所有的需求都要定义什么叫 Done，这个 Done 绝对不是臆想出来的，也是要通过讨论和确认的。这样的做法旨在保证能够将最原始的需求传递到最后，并保障需求还原的质量。
6）做好项目的需求变更管理
有的同学就问，VUCA 时代，不是应该拥抱变化嘛？但是我要说的是，拥抱变化并不是范围蔓延，更不是项目镀金，而是尽早的识别变化，以适应这些 VUCA。而管理变更，更不是阻止变更，是要让这些变化有序的发生。变更管理不善，特别容易产生交付困难，项目成本和周期的增加的问题。至于怎么管理变更，书上都写烂了，不多描述了。
因为需求是一个项目的根，方法很多，路子也很广，我列举的这些也就是就牛之一毛，大家还有什么想法都可以广泛的展开思路。

2、质量
    对于质量的问题，我更倾向于用一些强管理手段和强过程手段来做，毕竟敏捷对质量的管理，更注重与人和人的价值，更注重于团队本身，在实际操作来说，多数团队，特别是国内团队做这些实践有困难，大概是这样的情况；
1）首先我们要做一个尽量详细和到位的质量管理计划
    在这个计划中，着重点在于，质量评价的方法，质量的标准（这是底线），重点不在于多严格，多谨慎，重点在于能够在多大的范围内（包括发起人、相关方和团队内部甚至终端用户）达成一致的认识，这有助于在项目上能够自始至终和全部成员都能够按照统一的标准去工作。

2）评审！评审！评审！
    重要的事说三遍，在项目中评审是很重要的质量活动，大家都知道，质量≠测试，那为什么不能把质量控制都放到测试中去呢~因为有很多问题都能在测试之前 fix 掉，从需求、设计、代码、样品、用例等等，每一项成果物都做了评审，而且都与原始需要进行了对应那对于产品的质量和交付质量都是有百益而无一害的。

3）注重人员的培养
    人员技能的提升也是质量管理的重要的一部分，有的团队会采用传帮带的工作方式，我个人觉得是及好的，我也曾经做过导师，小朋友们在一对一的环境下成长的很快，更重要的是，会更趋近于所在团队，或者说师傅所在团队的工作风格，这不止是对质量，对团队和项目的健康发展也是有好处的
     质量崩塌导致返工，在我的工作中不是太常见，所以也没能举出很好的实际的例子来，但是对于团队来说，质量管理不到位，一定会产生返工甚至项目消亡等严重的后果。
    返工是谁都不想看到的，但是我觉得，有时候换个角度来看，如果返工的产生，能够推动项目进行制度或流程改革，甚至是推动组织变革，对项目、项目经理和组织来说，也未尝不是一件有意义的事。 

作者：田东

三年项目管理经验

一年 c++研发经验

作者：大懒

从业 12 年

程序员转项目经理、pmo 经理