太长不读版

既然“问题不能由导致该问题的思维方式所解决”，那么那些由“没空做改进”所导致的问题就不能用“有空才改进，没空不改进，一般都没空”的思维方式解决。如何用敏捷和持续交付的理念来做“持续过程改进”？“教练形”和“改进形”通过教练和学员一对一辅导的方式，通过1周左右的短迭代，每次具体解决学员个人在工作中的一处痛点，并根据迭代反馈进行方向调整，并快速进入下一个改进迭代，助其在改进过程中发现“成效”并视作奖励，令其进入持续过程改进的正向循环，从而将“没空做改进”变为“改进很给力”，最后达到“工作即改进”。

“没空做改进”很普遍

“团队平时忙于救火，没空做改进，你有什么办法吗？”我的一位敏捷和DevOps转型咨询项目的客户忧心忡忡地问我。

“唉，精心准备的2小时编程操练，竟然只来了1个参加者。”在一个测试驱动开发咨询项目的客户现场，与仅有的那一位程序员参加者结对操练了一个编程题目后，我回到酒店喃喃自语。

不仅是尚待转型的客户“没空做改进”，就连ThoughtWorks这样与“持续过程改进”密切相关的“敏捷”和“持续交付”的发源地也是如此。在两个月前我和王岩搞的一项有关我司持续过程改进的内部问卷调查中，74.3%的填表者认为持续过程改进最大的障碍是“项目进度压力无暇改进”。具体来说，就是“有空才改进，没空不改进，基本上都没空。”

用“改进形”和“教练形”来治“没空做改进”

提起“过程改进”这个词儿，我脑海里会蹦出“张建国”、“李翠花”这样的名字。是的，这个经常和“能力成熟度模型”（CMM）和“业务流程重组”（BPR）搞在一起的“过程改进”，与时下炙手可热的敏捷、精益、持续交付、DevOps、极限编程等“性感”的词儿相比，早就不那么时髦了。而且过去的我傻傻地分不清“过程”和“流程”这两个词儿的区别。但是，敏捷原则中的“追求技术卓越”就是在做技术的持续过程改进；精益软件开发方法中的“强化学习”原则就是在做认知的持续过程改进；持续交付中的部署流水线就是在做代码质量的持续过程改进；DevOps文化中的“自动化”就是在做实现层面的持续过程改进；极限编程的“测试驱动开发”就是在做代码编写的持续过程改进。“持续过程改进”就从来没有离开过我们。而且，我们可以用敏捷和持续交付的理念来做“持续过程改进”。

什么是“改进形”和“教练形”

要解释能把“持续过程改进”落地的“改进形”和“教练形”，需要先了解“过程”和“流程”的区别。先举例来说，比如在“团队通过举办每日30分钟的集体代码回顾，使得因为代码质量问题返工次数减少”这件事中，“每日30分钟集体代码回顾”这个行为就是“过程”，它是产生“返工次数减少”这个“结果”的“原因”。而这个团队在内部Wiki系统里面所写明的“每天下午5:00～5:30在会议室集体回顾当天所提交的代码”的约定，就是“流程”，这也是通过上述“过程”所产生的“结果”。可以据此下个大致的定义：“过程”就是产生结果的那些原因，一般指工作的行为；而“流程”一般指团队写在纸上或网页上的有关工作方法的约定，可以是由“过程”所产生的结果。简而言之：过程是活的，是原因；流程是死的，是结果；两者区别挺微妙；“流程”可以通过“过程”来改进。

“改进形”和“教练形”要改进的，就是上面所描述的“过程”。为什么一定要“改进过程”，而不是“责怪人”？首先，改进“过程”这个“因”，就能产生相应的果。“种瓜得瓜，种豆得豆”。而人本身不是“因”，而仅仅是“因”的执行者。第二，责怪人会破坏团队赖以存在的根基——信任。团队与团伙之间的区别就在于团队成员之间是否有信任，而责怪是信任的最大敌人。第三，责怪人会产生事与愿违的结果。根据心理学的研究，来自权威的信任与期待能让期望成真；而来自权威的责备无法令人在自信的基础上具备觉察和担当的能力，有的只是被动、不作为和推诿。这个规律已经在心理学领域得到了试验的验证，可以参考“皮格马利翁效应”和“罗森塔尔效应”。

问题不能被导致这个问题的思维方式所解决。所以既然是要改进过程来解决问题，那么就需要注意不要采用导致问题的思维模式。那么持续过程改进的思维模式是什么呢？有下面4个方面：

• “原因”高于“结果”；
• 常改进过程，多宽容同事；
• 日常工作本身就是在做持续过程改进
• 每个愿意改进的人都要找一位教练来一对一地学会如何做持续过程改进

做了以上铺垫，现在来解释什么是“改进形”和“教练形”（两词的英文分别为Improvement Kata和Coaching Kata，来自《丰田套路》一书）。

“改进形”就是教练和学员一对一地用短迭代（1周左右）的形式，每次针对学员一个具体改进点持续地改进过程，以改善其工作痛点并增加学员工作成效的方法。

“教练形”让“改进形”在团队发生，以改善工作过程，并向团队成员传授如何做持续过程改进的方法。

“改进形”和“教练形”是雷和闪电一样，一般是在一起发生的，最终的目的都是要改进不合理的工作过程。

“改进形”和“教练形”的特点如下：

• 一对一：教练和学员一对一地面谈，其间更新“改进形表格”（参见下图）；
• 信任人：教练本着“信任和期待”的原则和学员沟通，这样有助于让教练对学员的期望成真；
• 治痛点：教练每次和学员的一对一面谈，都是要针对学员的工作痛点或兴趣点来找改进点；
• 一件事：每次面谈，都只针对一个具体的改进点制定改进计划；
• 要具体：制定改进计划时，对于起止时间和做什么具体的事情，要在表格上写得越具体越好；
• 短迭代：每次制定改进计划，时间跨度一般在1周左右，到了截止时间，学员或教练要主动找到对方回顾计划完成情况，写下可以改进的过程，并制定下一个1周左右的新的改进计划；
• 改过程：每次回顾改进计划时，要记录收获，尤其要记录对过程的改进内容，并设法落实；
• 找成效：每次制定计划时，要设计度量成功的标准，在执行计划时注意搜集成效数据，并填写表格，这些成效会被视为“奖励”，促使继续改进；
• 滚动做：教练和学员一对一的面谈不是只做一次就完了，要不间断地一次接一次地做，最好能每隔几天就做一次；
• 常分享：当改进计划和一对一面谈执行了一段时间并取得阶段性成效后，要找合适的时机和场合在团队内分享其成效，鼓舞其他团队成员持续做过程改进。

“改进形”和“教练形”的实施步骤

1. 一对一面谈。教练和学员约1小时的一对一面谈。

2. 找一个改进点。这是“改进形”和“教练形”最具挑战的部分。找到学员当下的主要痛点并符合其兴趣的改进点，需要依赖教练丰富的实践经验。教练可以问以下问题来进行引导：“你对哪个方面的改进感兴趣？”“你最近在工作中的痛点是什么？”“谈谈你最近一周和下一周的工作内容。”对于软件开发团队的持续过程改进，可以考虑的改进点（注意，每次只要从这些改进点中选择一个改进即可）有：

   • 让团队愿景更加体现价值和质量；
   • 为用户旅程和主要的软件缺陷编写自动化测试；
   • 每周至少做一次结对编程；
   • 每天做一次30分钟的集体代码回顾；
   • 确保持续集成部署流水线的问题能在10分钟内修复；
   • 确保开发人员每天至少向团队代码主干合并一次代码；
   • 将SonarQube扫描出来的重复代码、高复杂度代码和代码缺陷用“技术债”墙可视化出来并请团队修复；
   • 建立全局性的度量指标并持续度量和改进度量指标；
   • 让团队业务、开发、测试人员共同将大型故事拆分为1周内可以完成的小故事，并对拆分好的高优先级小故事建立验收条件；
   • 开发人员在动手编写代码前，对照验收条件找业务和测试人员进行故事Kick-off答疑；
   • 开发人员在写完一个故事的代码并自行对照验收条件在测试环境上测试通过后，再对照验收条件给业务和测试人员进行desk-check演示，发现问题立即修复；
   • 确保至少每1～2周给用户演示一次产品，并听取用户反馈；
   • 确保每2周左右做一次团队内部实践经验分享；
   • 确保每2周左右做一次事后复盘（验尸报告）并分享；
   • 确保使用团队看板和部署流水线来可视化价值流和质量；
   • 确保每2周左右组织一次编程操练；
   • 确保每2周左右做一次“改进形”和“教练形”。

3. 制定“改进形”计划。在第一次教练和学员的一对一面谈中，可以填写一张“改进形表格”记录改进计划。其中：

   • “愿景”（Vision）要体现价值和质量；
   • “当前状况”（Current Condition）要可度量，并注意要实地考察；
   • “下一个小目标”（Target Condition）要将时间限制在1～2周，要把起止时间和具体改进写具体；另外要定义度量成功的方式，以便获得“成效”的奖励（注意度量成功的方式要面向“价值”和“质量”，避免仅仅度量输出）；
   • 识别障碍和资源（Obstacles and Support）；
   • 从“当前状况”到“下一个小目标”的具体计划（Moving from Current to Target Condition），写明具体行动的起止时间，搜集并改进“度量成功的方式”；
   • 要让完成信心达到8分及以上：当写完前面的内容后，教练一定要问学员：“把上述计划完成的信心从1到10打分，10分表示信心最足，你打几分？”如果学员说的分数是8分以下，那么需要调整计划，可以减少范围或者增加时间，来让信心达到8分及以上，以保证计划能够履行；
   • 写明面谈人姓名和时间；
   • 根据上述计划截止日期约定下次会面时间。

4. 在教练与学员的下次会面时，回顾这次计划的执行情况，并总结和分析“可以改进的过程”（Processes improved）及成效数据后，视情况做改进方向的调整，制定新的“改进形”计划，进行下一个迭代的改进。

   
   
   Screen Shot 2018-07-06 at 1.24.48 PM.png

实施“改进形”和“教练形”的注意事项

• 前提条件
  • 学员需要有来自“权威”的信任和期待。这里的“权威”包括教练、经理和能帮助学员的资深同事。“权威”在对学员进行辅导时，一定要从内心信任这个学员能够把事情做成，这样就能激发学员的自信、觉察和担当，最终把事情做成。反之，如果“权威”从内心认为学员不可救药，虽然不明说，但学员还是能从“权威”的神色语气中感知出来，从而让辅导失效，甚至会起反作用。
  • 教练需要具备相关领域的过程改进实践经验。比如在辅导软件开发团队进行敏捷和DevOps转型时，教练需要最好能具备上面实施步骤中列出的那些改进点的实践经验，以便帮助学员找到合理的改进点。这一点对于一些刚刚尝试做企业内部教练的人来说还是颇具挑战性的。此时一方面需要有经验的教练对这些新教练提供“教练形”的指导，另一方面需要新教练要不断学习和尝试，来用持续过程改进的方法来提升自己做“教练形”的水平。
  • 企业建立内部教练培养机制。企业内部教练最终的奋斗目标是“教练内建”，换句话说就是把自己“做没”——即让团队中的每一个人在与人协作时，都能起到教练的作用，来做“改进形”和“教练形”，从而把“日常工作本身就是做持续过程改进”落地。但要达到这个愿景，第一步的小目标或许就是建立某种内部教练的培养机制，让一部分人开始学会做“教练形”和“改进形”，从而逐渐做大。
• 小批量迭代。切忌做大批量的长期的一个改进计划，而应该做1周左右的短期计划，且每个计划只做一个具体的改进点，到了截止日期就紧接着总结收获并据此继续做下一轮短期计划。如此这般，才能让改进计划富有成效并切实落地。
• 学员在执行计划期间遇到困难时，需要找教练及时辅导。
• 管理层要充当教练。教练型的管理层能让团队成员发挥潜力，让期望成真。
• 管理层要参与“改进形”所产生的过程改进。学员在做过程改进时所做的一些试验，管理层需要参照其成效数据对过程的改进施加影响，让改进试验获得更大的成效。
• 建立全局性的度量指标，并持续度量和公布改进后的价值和质量。将成效数据视作“奖励”，促进下一步的改进。有关软件开发全局性的指标包括：
  • 度量用户价值质量的用户旅程自动化测试覆盖率
  • 度量用户满意度的净推荐值
  • 度量是否小批量发布的部署频率
  • 度量返工程度的用户故事开发周期（英文为lead time，指用户故事从提交第一行代码到上线所经历的时间）
  • 度量系统稳定性的线上故障平均恢复时间和变更失效率
  • 度量修复缺陷和创新投入的研发预算分配情况等等
• 本着“扩大公开范围，容易学习掌握”的原则持续小批量在企业内部和外部进行“教练形”和“改进形”的实践和成效分享，建立对持续过程改进的信仰，坚定大家持续做改进的决心。

总结

• “问题不能由导致该问题的思维方式所解决”，在治理“没空”前，要具备“原因高于结果”和“来自权威的信任和期待能让期望成真”的思维模式。

• “没空做改进”的原因是“改进的优先级不高”；“改进的优先级不高”的原因是担心改进“周期长见效慢”；对解决“痛点”的渴求产生“做改进试验”的愿望；通过短周期和“一次一件事”的迭代降低试验门槛使人愿意尝试；通过教练的信任与期待让学员建立“自信、觉察和担当”的心态，促使试验向好的方向发展；通过在改进试验中搜集成效数据来获得“奖励”；通过“成效数据”这个奖励来驱动做下一次改进试验；通过社区分享建立对改进的信仰，从而坚持做改进。

• “教练形”和“改进形”聚焦于解决个人在工作中的痛点，助其在改进过程中发现“成效”并形成奖励，令其进入持续过程改进的正向循环，从而将“没空做改进”变为“改进很给力”，最后达到“工作即改进”。