对于返工的一些猜想

返工，任何项目和项目经理都不愿意面对的一个事，一旦这件事发生，就意味着，要么PM干不下去了，要么项目就干不下去了，但是有的时候，返工是作为项目经理个体来说没有办法控制的，原因方方面面。总的来说，作为项目经理和组织级项目管理部门还是要积极的应对，要么尽量试图修正这些返工带来的影响，要么避免类似情况在将来的项目中再发生。

当然了，出现了返工的情况，而且如果是大量的返工情况，实际上我们第一个要做的是评估一下现在的状况，对于合同承诺履行的情况（如果是甲乙方项目的话），看看这个项目是不是还值得抢救一下，如果还一息尚存，该赶工赶工，该启动管理储备就启动管理储备，先将项目有序的做完，针对返工的情况做一些针对行的措施。要是已经死透了，该归档归档，也是要分析分析原因，定一定未来规划的。

那对于返工来说，我们先得知道返工产生的根本原因，刨得越深刻，对解决这个事情越有利，往往在职场上，有些话不能说，怕得罪人，但是我只能说……尽量做个正直的人……

抛去非正常变故还有比如说，资源故障，人员能力问题，技术不成熟等等这些特定因素，产生返工的根本原因无非是就是需求和质量两大方面（抛开在这两个过程中的人的因素，哪个组织无论什么岗位，总有那么一两个不靠谱的），那我们暂且先就研究这两个问题。

先简单说说那些其他原因，对于项目经理来说，对项目最负责的态度我觉得应该是想方设法让项目可控，有些导致赶工的原因是能够在项目启动之前就能预见到的，就是我们俗称的风险。比如说技术不成熟的问题，是不是必须要用不成熟技术？如果要用，是不是要有一定的调研成本保障？要不要引入外部资源？资源故障的问题，是不是可以备份？等等，对于这些原因产生的返工，不太客气的说，都是自己作的，作为项目经理，只要能够预见和控制的，都应该想到。当然了，肯定还有一些不可控的原因，比如老板抽风之类的~尽人事，以听天命，到该就是这个道理

从需求角度讲，最常见的产生无非就是需求描述不清，验收标准不明确。这其实是需求管理范畴，我通常比较喜欢引入一些敏捷的思想和方法，避免或缓解返工产生的，能想到的做法大概如下：

1、更频繁的交付和反馈

客户或者用户通常来说对自己的需要是不清楚的，至少是讲不清楚的，按照一个正常人的逻辑来说，实际上能看到的东西才是最直观的，所以我们尽量用一个MVP（minimum viable product最小可行产品），用尽量低的成本去确认用户或甲方的需要，当然了，这得需要甲方或客户最大成都的配合。从而能够尽早的识别变更，降低变更成本，从而降低成本，保证进度，减少返工。

2、需求漏斗

或者也叫需求判定漏斗，是一种需求获取的建模工具，虽然说对这件事建模会显得比较奇怪，但是在实际工作中，用模型思想去做一些事情确实是有用的，他是判定真伪需求的工具，实际上是，通过问好几个Why来决定How的一个需求过程。其基本宗旨就是，不要轻易相信你听到的是什么，要确定需求的根本原因是什么，那保证这个需求是有用的，不至于做出来被废弃或者是返工。介个东西大概长这样（灵魂画手上线，很多年前研究过需求工程，不知道画的对不对了已经）

3、用户画像和应用场景分析

同样的，也是一种获取需求的一种方法，通常会用在产品类型的项目中，实际上就是对终端用户的一种行为模拟。通常我们定义一个人群，给这类人描述一定的属性和行为特征，这个过程就是用户画像。通过这些属性和行为特征，讲该类人群放在一个场景里面，来假设一些活动，从而判断活动产生的效果，这就是应用场景分析，最后我们会输出一系列的用户故事，也就是需求，这种描述方式会贴近于真实的应用环境和用户环境，从而保证这个需求是有效的。

4、原型

大家都懂，在需求这件事上，通过语言或文字在不同的人脑补下，画面绝对是不一样的，这样就很容易产生预期偏差，一旦产生预期偏差就会造成无价值交付，既然没有价值要么不要了要么重做。在原型的环境下，我们所见即所得，引导激发需求来源的真实需要。

5、能引发讨论的，有明确验收标准的需求条目或者需求卡片

当需求被记录下来，或者被转述后，在团队不同角色对需求的理解是有明显偏差的，所以，敏捷中的方法对这件事提出了3个C的原则，即Card，Communiacation，Confirmation，也就是说，我们用一张卡牌去传递需求，通过卡牌引发对需求的探讨，从而达成多方的一致，以保证需求不会被歪曲。另外，所有的需求都要定义什么叫Done，这个Done绝对不是臆想出来的，也是要通过讨论和确认的。这样的做法旨在保证能够将最原始的需求传递到最后，并保障需求还原的质量。

6、做好项目的需求变更管理

有的同学就问，VUCA时代，不是应该拥抱变化嘛？但是我要说的是，拥抱变化并不是范围蔓延，更不是项目镀金，而是尽早的识别变化，以适应这些VUCA。而管理变更，更不是阻止变更，是要让这些变化有序的发生。变更管理不善，特别容易产生交付困难，项目成本和周期的增加的问题。至于怎么管理变更，书上都写烂了，不多描述了。

因为需求是一个项目的根，方法很多，路子也很广，我列举的这些也就是就牛之一毛，大家还有什么想法都可以广泛的展开思路。

对于质量的问题，我更倾向于用一些强管理手段和强过程手段来做，毕竟敏捷对质量的管理，更注重与人和人的价值，更注重于团队本身，在实际操作来说，多数团队，特别是国内团队做这些实践有困难，大概是这样的情况；

1、首先我们要做一个尽量详细和到位的质量管理计划，在这个计划中，着重点在于，质量评价的方法，质量的标准（这是底线），重点不在于多严格，多谨慎，重点在于能够在多大的范围内（包括发起人、相关方和团队内部甚至终端用户）达成一致的认识，这有助于在项目上能够自始至终和全部成员都能够按照统一的标准去工作。

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

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

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

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