不要把账都算到CMMI和5000头上

——为何维护一个有几个似曾相识的风险的表，定期改了几个系数，但在项目任务中却看不到缓解风险做的事？
“因为这张表是CMMI需要的。”
——为何在度量表中填了一堆数据，但不知来自何方？用于何处？
“因为CMMI要求我们做度量。”
——为何五个高手要开个2小时的会，做出一个显而易见的决策？
“因为CMMI中有个DAR。”
——为何基本一字不改，把客户发的需求，换个名字又写一遍？
“因为CMMI要求既有客户需求，也要有产品需求。”
——为何…
“因为CMMI…”
这些话往往出自各家CMMI和5000组织内部的技术大拿，一线精英，是过程的执行者，为企业创造价值的人，他们的话是有分量的。一传十，十传百，CMMI和5000成了随手可以甩锅的对象。

最近听到
28
所张老师讲了一句话，“不要把账都算到
CMMI
头上！”这话一语中的，点出了问题的实质，把账算到
CMMI
头上成了许多人为自己不去试图理解组织过程的借口！
我们这个行业是硕士，博士扎堆儿，受教程度极好的行业。我有时一直纳闷，能设计出复杂算法，解决客户难题的人，怎么就
CMMI和5000玩不转？怎么就不会灵活使用一些开发、管理模板？怎么就会把Humphrey等大师总结的工程经验生生做成两张皮？
在CMMI和5000面前，这群聪明人的智商好像瞬间崩掉。原因很简单，组织过程仅仅被认为是CMMI和5000过级的工具，我们的精英团队把执行过程当成了项目活动之外的额外负担，他们的心思一点没有放在这上面。当被人发现过程是两张皮时，CMMI和5000无一例外成了接锅霞侠。而这些认为CMMI是罪魁祸首的朋友。有几个人真正花精力去理解给他们用的流程、模板、指南的目的？有几个人去认真了解裁剪给出的灵活度？又有几个人把自己的实际有效做法贡献出来，并在在使用过程中指出不合理之处以及可替代的有效做法？
这里我想说的是“不要把账算到CMMI头上！”因为你在项目里采用的一些有效实际做法就有许多CMMI和5000的影子，这里我不想再啰嗦CMMI为何是一部好经了，但它真不是你想的那样僵化无聊，如果你花些精力仔细琢磨一下，会有意想不到的收获。这里我不建议你通读CMMI或5000模型，但至少做到一件事：对组织流程要你做的每一件事，搞清楚为什么？对你的工作有何好处、价值在哪里体现？一定要有个答案。如果你认为不合适，那就给出一个替代做法，或者可以先做起来，在实践中完善，在实践中融会贯通，在实践中做过程的主人，在实践中介入到过程改进活动中。