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

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

一、背景介绍

返工，任何项目和项目经理都不愿意面对的一个事。

一旦这件事发生，就意味着，要么PM干不下去了，要么项目就干不下去了。

但是有的时候，返工对项目经理个体来说是没有办法控制的，原因方方面面。

二、嘉宾分享

（1）嘉宾：田东分享内容

（一）找原因

对于这个“大量返工”这个命题来说，首先我们应该确认返工的根本原因是什么造成的。我认为无非3种：

1、需求不明确，需求变更导致可交付物无法定型，长期处于动荡状态，从而导致不断推翻重来的返工。

2、需求明确，质量控制不严，未能及时发现研发人员交付的功能的缺陷.

3、时间紧任务重，功能来不及验证，边上变改

4、有需要的可以加项目交流群660345027，考PMP的都在这。

需要PM针对以上三种情况对症下药，同时也应该明确一点“预防的成本是最小的”，我们要随时都有这种危机意识。

（二）对症下药

对于需求不明确：

需求不明确造成的返工，这点基本上不可避免总会发生的，而需求变更控制也是PM的基本功之一，之前在关于需求变更控制的分享中也有关于如何控制需求变更的一些个人见解，大家有兴趣的话可以找群精华看看。（文章末尾有链接）

对于质量控制不严：

需求明确、质量控制不严导致的返工。需要PM在项目的全生命周期进行跟踪与关注，首先项目启动阶段，召开项目启动会议时将研发、测试人员叫到一起，让他们对系统功能实现做到心中有数，从而保证大方向步调一致。PM必须制定项目的设计说明书，包括但不限于原型设计、pdr文档等。

然后是项目研发阶段，此时要求项目经理制定严格的开发计划，我的理解是每一个功能点的开发时常不应该超过2个工作日，否则视为PM对项目的理解不到位，同时开发计划的周期为2个工作周，后边的开发计划可以模糊一点毕竟项目的本质是渐进明细。然后每个工作周组织测试人员对研发交付的功能进行验证（前提是研发人员完成功能自测），测试人员认为功能满足才能视为此功能开发完成。研发人员在执行开发计划过程中必须严格遵守设计说明书，严禁不看文档直接开发的情况发生。

另外最好能做30分钟左右的一个站立会，组内成员汇报各自前一天的进展情况和当天工作计划，原则上要求回报与计划的偏离情况（正偏离，负偏离），保证任务保质保量的完成。

基本上也就是咱们的PMBOK中说的“PDCA”模式。

对于时间紧任务重：

时间紧任务重的情况造成返工。首先PM和技术leader沟通一下赶工的情况下能否完成指定的工作要求，如果无法完成的情况下，确认需要多少资源然后立即汇报领导，申请资源。如果在全力投入的情况下依旧无法完成的话，组织内部会议沟通出能完成的极限需求范围（保质），然后跟甲方、客户沟通阉割交付需求（尽可能给自己争取阉割一些非必要功能）。

因此赶工的情况下没什么好的办法只能硬着头皮上，但是切记权衡一下无法按时上线和交付出去后质量无法保证哪个对公司造成的打击更严重。毕竟赶工的必然会意味着质量不会被很好的保证。

那么综上所述，还是那句话“预防胜于治疗“，尽可能把风险掐死在摇篮里。

（2）嘉宾：大懒分享内容

（一）返工原因

返工，任何项目和项目经理都不愿意面对的一个事，一旦这件事发生，就意味着，要么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）注重人员的培养

人员技能的提升也是质量管理的重要的一部分，有的团队会采用传帮带的工作方式，我个人觉得是及好的，我也曾经做过导师，小朋友们在一对一的环境下成长的很快，更重要的是，会更趋近于所在团队，或者说师傅所在团队的工作风格，这不止是对质量，对团队和项目的健康发展也是有好处的

质量崩塌导致返工，在我的工作中不是太常见，所以也没能举出很好的实际的例子来，但是对于团队来说，质量管理不到位，一定会产生返工甚至项目消亡等严重的后果。

返工是谁都不想看到的，但是我觉得，有时候换个角度来看，如果返工的产生，能够推动项目进行制度或流程改革，甚至是推动组织变革，对项目、项目经理和组织来说，也未尝不是一件有意义的事。

（3）我有话说：

啊潮-广州-互联网：

“面对大量返工，一般收集返工内容，分析与需求不一致的内容，对症下药。归类问题原因，按重要程度进行排序，影响正常生产流程的为1级，低频异常流程为2级，UI界面类为3级。给到正确的返工日期后，开工。”

Shiryu-广州-咨询：

“我认为大量的项目返工要查清楚返工的原因，然后重新进行需求确定，制定好变更流程，把返工比较多原因进行分类，定好重要程度，计算好成本，制定好相关的措施。

项目不要复盘，应该针对返工，重新跟客户沟通清楚需求和返工的成本。让自身项目团队和客户 提高工作效率，做好例会检查和反省。返工或者变更较大的时候，需要客户承担的也要说明，另外就之前返工的原因和应对策略，也要给项目团队做好培训和指示。是客户原因的返工，也要跟客户领导沟通清楚，必要时需要承担相关的成本。”

聆风-上海-通信：

“还是梳理清楚需求，做好资源管控吧。做好干系人管理，还有就是分阶段核查，分模块进行验收，做好资源管理和排期，一定要确认项目经理的管控权，如果不能就做好权责说明和管理。”

浩－深圳南山－金融行业：

“大量返工，帕累托图。”

半城-贵阳-IT：

“必须要有详细的任务分解，然后制定计划，按计划推进。管控点越小，越容易控制。只是投入的管理成本就越高。”

㊧佚名氏㊨-上海-IT：

“我个人的经验一般是这样： 计划阶段，跟客户算工数的时候，事先根据作业内容的难易度量，来按照一定比例算好返工所需的工数，分别为预估会有多少bug，预估会有多少的需求，设计变更。 其次，当返工来的时候，先对返工进行分类，是因为甲方的变更导致的返工，还是因为我们自己做的质量不行导致的返工，然后分别去对应事先预估好的工数。

如果是甲方的变更，甚至这个返工超出我们可承受的工数范围，就要求客户按照通常的变更流程来。”

小明童鞋-长沙-集成：

“对于客户来说，有时候客户的需求是比较片面的和局限的，这也会造成需求调研出现偏差，造成后续的返工。对于选择小步快跑还是大步快走也是一种权衡。”

（4） QA

Q：通过测试减少返工工作，我也在推这个事情，我们做的测试没有规范、连质量标准也少有，也就是桌前检查+找个人点点点检查··· 有没有好办法呢？

A：质量≠测试，单通过测试活动是没有办法避免一些返工发生的，持续的质量管理才是正道。

Q：返工时人员跑路了咋搞？

A：那说明项目经理对团队已经失控了。

总结：

预防胜于治疗。