软件项目经理新手上路(6) - 不要进行小改进

改进是每个项目经理都会遇到的头疼事。

1. 小故事

张三有点烦恼。张三兴冲冲的到一个项目入职了，踌躇满志，这次一定要干点成绩出来。因为入职前，领导找张三谈过，项目目前存在不少问题，需要改进。在经过一段时间的调研后，张三拿出了一整套改进方案。张三将整套方案提交给领导，领导看了第一眼，说很好，我需要再研究研究。过了几天，领导还没研究完。张三去找领导，领导开始拖延，主意不错，但是是否适合我们公司，还需要观察和研究。最后，所谓改进不了了之，张三很失望。

 

2. 常规想法

很奇怪，这么好的改进方式，领导居然会拖延，张三还是觉得应该和领导讨论讨论。领导表扬了张三的方案和改进的愿望，就是这个“但是”比较意味深长。张三后来才慢慢弄懂，改进方案中推翻了该领导以前的某些措施，并且也不符合公司实际起作用的某些潜规则。

大改进的风险是如此之高，很容易就和某种看不见的规则发生冲突，引起敏感反应。那么小改进呢？

不要进行小改进。领导看不见的事就不能做，这是中国式的处事方式。也会有人提醒，你这么干“有些人”会不高兴的哦，这个“有些人”是谁？也会有人拒绝，这就是我们的做事方式，不能改。所以到最后，项目经理也只能看作不关我的事，独善其身。

 

3. 继续思考

小改进真的没什么效吗？它可以有效的。以一个6个月的项目为例，如果每两周（一次迭代）能够有2%的改进，确实很难看出不同。但是在6个月后，差异达到27%，这是极其明显的差异了。因此小改进很有效，但是难在持之以恒。而且没有小改进，哪来大改进，一口怎么也吃不出一个胖子。而且小改进容易找到，并且没有那么大的障碍。

另外，假如张三坚持进行小改进，而另一项目经理王磊不做任何改进，只在结束后进行总结（如果王磊有这个好习惯的话）。在6个月的项目结束后，张三碰到的状况和积累的经验将远远超出王磊。在3-5年后，会是多大的差异。

 

4. 参考案例

4.1 参考案例1

这是一个对比案例。

A项目和B项目是基于同一平台，不同细分市场的项目，极其相似。以两个项目组并行的时间进行比较。在前6个月，两个项目看不出明显的差别，都存在较多的Bug，并且有时都不能按期交付。但在6个月后，两个项目的差别开始显著，B项目的质量控制明显得力，响应变化速度快，持续交付成果。A项目代码质量堪忧，很难新增功能。在一年后，差别愈发加大。两个团队应对变化的方式也截然不同，A团队总是感叹又要改变，B团队则在商量这次进行什么改变。

分析，如果A项目以每两周2%的速度崩坏，B项目以每两周2%的速度改进，那么6个月结束后，B项目将优于A项目62%。（注，此计算仅作理论分析示例。）

4.2 参考案例2

这是一个已经历时5年的项目。

项目运转得一直不算顺利，但是真正令项目伤筋动骨的是数次大改进。其中一次是公司决定引入CMM。公司建立了SEPG组，SEPG组长非常强硬，强制规范项目中的各种行为，引发了极大的反弹。在各方抵制下，CMM改进失败了。

现在这个项目成为了改进的禁区，人们谈改进而色变。项目中的人也是得过且过，当一天和尚，撞一天钟。