说确实，CMMI 认证那套流程，那会儿总听着冷冰冰，像是要把人切成一块块零件去流水线一样的。但目前我躺在工位上，脑子里想的却是如何让研发、测试、运维这些不同地方的同事，在各自的节奏里把事儿办完，不至于天天加班改需求要么发bug。
实际上核心就一点：就是如何把“干完活”这件事，变成“干得好”这件事。 这过程最扎心的一点，就是大量时候团队认定自己在“干活”，脑袋里想的却是“如何把活干快点”。我们习惯了按部就班，但 CMMI 要质疑的就是这种惯性。
那会儿我们好办陷入“过程管住”的误区，认定只要流程跑通了就行，结局就是流程像条死蛇，长得慢但管不了东西。目前我认定得反着来，流程不是为了束缚人的手脚，而是为了帮人把散乱的想法收敛好，让干活的效率像水一样流起来。 说到落地，最让我头疼的就是不同团队对流程的接纳度。有些团队，特别是小时制公司，会认定整个流程要改个天翻地覆，那直接建议大家把流程交给外包团队去跑，我们内部只负责对接验收。但我认定这个方案不中，出于验收出来的东西和服务客户没本质区别，客户能感觉到的是结局，不是哪位名下的流程。
故此，我希望我们团队内部也能把流程拆解开，哪怕是半条线，也好让一线听得懂，能照着改。 举个例子，在软件团队里，我们那会儿流程里有个“需求评审”环节，往往就是大家对着文档大眼瞪小眼，半天聊聊不出个来，最终还得改回去。
后来我们试着把流程里的“评审”简化，改成“任务拆解对齐”，让开发人员直接在任务单上写清楚用了啥技术，预计交付工夫。结局呢，大家不再去纠结技术细节的争论，而是直接对任务本身负责。
这个改动别看小，但感觉团队内部的情绪流动快了大量，沟通成本低得离谱。 自然，流程不是改完就束之高阁了，它得活下来。记得有一次项目上线，发现测试阶段漏单子，出于测试人员认定需求文档跟代码对不上。但当时我们改流程的时候，没嚷嚷着要改流程，而是让测试负责人带着老家伙，把漏单的那个小模块单独拎出来，重新跑了一遍验证流程。
原来大量漏单是出于流程说的“验证”忒不清楚，执行的人没弄清标准。
后来我们把这个小模块的验证标准固化进流程里，发现漏单率直接降了一半。
这时候再回头看，流程本身没变，变的是大家执行时的颗粒度和标准。 有人说流程就是文档，是那种密密麻麻的表格和模板。我不应允。真正的流程是有温度的，是跟着人走的。
要是流程里没有任何人的签字、任何人的反馈，那它就是个死的文件。我们在推行时，最怕的就是那些不愿意改的人。
这时候得讲究策略，有时候得给个解释，有时候得给个面子，就连得让流程里包含一些“人性”的考量，比如准用口头确认代替邮件回复，出于邮件回复忒慢了。 还有一个点我特别想强调，就是“持续改进”。大量团队做完一个项目，认定万事大吉，结局下个版本又烂尾了。
这是出于他们根本没把流程当成工具，只当成个目标地。CMMI 的精神里，强调“生命周期管理”，就是要把流程当成一个一辈子在变的小火车。
每次项目终止，回头看这套流程有没有用？
有没有地方卡住了？
有没有出于流程忒死板而限制了创新？要是有，就得动。 在实际操作中，我们团队也不是全盘推翻重来。我们是把那些经过验证、被大家熟悉但用得不对的流程局部保留下来，然后针对那些痛点，像修车一样一点点修好。
比如有些团队的审批流程忒慢，我们就砍掉非关键的审批节点，要么用自动化工具。
这种“杀鸡取卵”式的局部优化，往往比盲目标全面改造更有效。
毕竟，流程是为了让团队运转得顺畅，不是为了增添行政上的摩擦。 故此，CMMI 认证对于你我而言，实际上不是啥高不可攀的证书，而是一次自我审视的机会。它逼着我们要看到流程之外的难题，要看到人之外的难题，要看到那些出于流程而丧失效率的地方。当我们将流程真正融入日常工作的血肉里，变成团队默契的一局部时，你会发现，所谓的“过程管住”，最终变成的是“客户中意”和“交付质量”的增量。 最终，我想说，不要恐惧流程的迭代。就像人成长一样，流程也会随着团队的变化而变化。
只要方向是对的，哪怕形式再老，只要能让团队省事一点，这一点就是值得肯定的。
毕竟，我们做这一切的终点，不是为了证明哪位的管理好，而是为了让客户用得顺手，让产品真正有价值。