两年多前，A公司在某政府软件开发项目前期过程与测试中没做好，导致客户在验收时拒收，虽然团队尽力补救，但也于事无补。管理层为了避免项目烂尾影响声誉，虽然预计会导致巨额亏损，但还是与甲方协商承诺重做这个项目。从这个经验教训中，公司高层意识到软件开发项目的风险难以把控，要完善软件项目的质量，于是决定借用CMMI模型来做改进。

因为很多项目都是按敏捷迭代方式， 每两周一轮做开发，我们建议他们每次迭代回顾时，所有团队成员一起分析迭代的缺陷曲线与返工工作量，头脑风暴，找出根本原因，制定纠正措施，在下一轮迭代做改进措施，最后汇总成A3总结报告，加快改进速度，尽早看出效果。 

总监从一开始就努力推动，但下面的部门经理对它的看法和支持存在很大的差异，有些明显只希望以最低的投入满足，有些希望借用这个模型和体系过程，加强部门的管理，获得提升。 

两年过去，如今到了最终正式评估阶段。

我：跟高层访谈的目的是希望听听管理层的诉求，这样才能在后面的差距分析报告里反馈你们团队现在的情况。 所以，想先听听你们的最主要关注点。 

“减少返工工作量。”
“控制进度偏差，减少延误。”
“提高团队的生产率。” 

我在白板上写上他们的诉求后说：因为软件开发项目跟办公楼建设项目不一样，每天只看到开发人员在电脑屏幕前默默工作，但进展如何，很多时候是个谜。如果你问他们，他们都会说不用担心，能按期交付。 

总监：软件开发项目与我们其他工程项目不同，如果到后期交付时才发现问题，就很难修正，会导致大量返工工作量，所以希望借用CMMI这个模型帮管理层更好地监控项目的情况。不要等到项目后期接近交付的时候，才发现有很多问题需要补救。 

我：我看你们年初制定的长期改进目标是降低返工工作量，请问在过去的6个月里，你们每个部门实际从多少降到多少？没有数据就无法管理，好比准备参加马拉松半马比赛，你需要有半年、一年的锻炼计划，最通常的指标就是跑一公里要多少分钟。可能本来要八九分钟，后面就会降到六分半钟，这样才知道自己在进步。下图是你们4个部门过去一年里试点项目做根因分析的A3报告历史（每种颜色代表一个部门）：

图B4-1

虽然有些部门连续半年每月都做A3报告，但有些只做了一次或两次，A3报告只是某一轮冲刺的衡量。而且有些A3报告体现不出做了改进措施以后，有什么实际效果。例如：某报告只是说需求引起的返工量有显著降低，但不知道总体返工量是否有降低；某些报告说后面的缺陷总数有显著降低，因还未交付，这些都是组内评审和自测的缺陷，每轮冲刺缺陷少不代表质量好，而且可能恰恰相反，应尽量多发现缺陷才能避免验收时暴露大量缺陷，所以也看不出来每一段冲刺的实际效果如何。虽然每个部门每个月都要汇报给高层，但差异也很大，有些部门只是整理一些描述性的文本，一个数据都没有。有些部门会做PPT，里面有当月项目的进度偏差总结报告。但进度只是一个维度，如果质量不好、返工多也会影响项目，所以如果要持续改进的话，就必须收集相关数据并保留这些数据，分析指数趋势，是上升还是下降。 

所以要想过程改进持续, 部门必须成立一个虚拟的内部改进组，并制定3个月、半年的改进计划，有具体量化可衡量的改进目标。 

虽然你们对上次半年前的差距分析有开会跟进，但是我发现有不少差距还是没有具体改善、行动。例如上次提到改进计划，要按项目来监督，但有些部门还是按月定期监控，没有把计划分成具体的任务来监控，很容易产生延迟。因为人一般不到截止日期也不会采取行动，所以经常会延误。其实不需要用什么项目管理工具也可以加强，你们可以在大白纸上用蓝色水笔记录这些任务的每次冲刺，比如在项目启动时，写上每个任务的开始日期、计划结束日期，然后用红色笔标注实际开始与完成日期，也可以简单拍照记录。 

虽然高层对改进有决心，持续了两年，但是从效果看，还是有不少可改善的地方。例如，建议加强QA岗位的培训，让其能指出团队的不足并提出改进方法。如果公司缺乏内部QA资源，短期难以安排，也可以考虑外部QA，还可以同时帮公司培养内部QA。 

我：你们公司都已经接近50年历史了，但这段时间总共累积了多少经验教训、公司级的知识库？ 

某部门主管：好像不多。 

我：如果在改进的同时，鼓励每位员工把做到的、做错的都记录在公司的平台，像历史书一样提供经验教训，那么能起到很好的参考作用。现在越来越多的企业，尤其是IT企业，觉得要开始累积公司的知识，这需要有一个公开的平台，让员工可以随时随地做记录。 

另一位部门主管：我们其实也有类似的平台，但想不到有什么好的方式可以鼓励员工写分享和经验教训，因为他们都忙于项目。 

我：可以尝试定期举办一些内部分享会，比如每周借用某个午饭的时间。自己当老师，其实是最佳的学习方式，不仅能让学员学到新的知识，更可以让自己理清思路，更好地理解背后的原理。在这个过程中，分享者就会知道需要把实际工作中遇到的情况记录下来，才能累积成为有吸引力的分享故事，所以能激励大家把日常遇到的成功或失败经验记录下来。分享不仅是针对软件开发人员，对其他员工也有启发作用。 

部门主管：赞同。 

我：以前跟你们的开发人员提过这个建议，他们都很感兴趣，但是碍于项目实在太忙，没有空，所以必须得到管理层的理解，让团队空出一些时间来分析、回顾、分享。 

总监：我也很希望我们公司开始有这种经验教训的积累。其实我们也遇到过类似的问题，公司有很多经验丰富的员工，但是他们都快退休了，想不到一个好方法，把自己的宝贵经验保留在公司，尝试过录视频，但发现这种方式还是比较零散，不容易作为日后参考。 

我：是的，有些人可能喜欢录视频，面对面交流，让他写东西很困难，但有些人相反，不喜欢说话，让他写出来更方便。我建议，不局限于形式，但是要把那些宝贵的经验，无论成功或者失败的，都记录下来，像历史书一样，供后人参考，这很重要。 

总监：是的，我们公司现在也非常关注成本，好像比较难跟董事会申请给员工腾出时间来做这个分享会，尤其你说这会占15—20%的工作量。 

我：赞同，你这一点提醒了我，虽然你们部门都定了改进目标，但是只有百分之十几，太低了。记得第一次培训时跟你们说，目标要减一个位，要×10 。如果这些改进，包括经验教训的积累，能给公司带来巨大的价值，这个投入绝对比现在把这个成本放银行定期收利息好，而且能激发员工的创新。与当初我们建议你们每轮迭代回顾，所有团队成员花半天时间分析数据，找根因，制定纠正措施一样，让团队成员利用自己的智慧，减少返工，提高团队的质量与生产率，为公司增值。

从以上对话，可以感觉到公司要推行量化管理并持续，会遇到很多困难，顾问需要不断指出和纠正一些误解。虽然可以收集各种度量，但针对质量缺陷和返工比较容易，以迭代做开发交付，并每次迭代、定期做回顾，应该能更快速看到成效。

各种客观条件都具备了，过程改进才有可能持续。 例如，管理层是否关注和有要求是很重要的。A公司某一组因为部门经理希望改善，有要求，团队开始持续改进，其他部门都是为了应付高层的要求，做了一两次A3报告就停止了。 

正因为各团队不同，所以都应先试点，按效果做调整。例如，在迭代回顾时收集数据，分析根因，采取纠正措施，各团队可能会有自己的最佳做法，所以试点后大家应一起分析，找到最合适的方法，然后扩大范围推广。因为持续改进过程漫长，高层需要不时地在员工大会上分享成功案例，表示公司对持续改进的重视与支持，公司才有可能逐渐形成以数据说话的量化管理企业文化。