传统软件行业技术团队 - 指导思想之如何开始

PDCA环里的C。

1. 前言

以自下而上方式推进组织内DevOps改良过程中，最容易遇到的一个困境就是我们现在有很多想法，这些想法是前辈们经过数十年验证过的，我们笃定践行它们会给团队带来非常明显的效能提升。

但是，这么多措施里，我们应该先推进哪些，哪些是需要做一定的裁剪才有落地希望，以及我们怎么确保它们的落地？

关于这些问题，过去几年的实践中不断出现在我的大脑里，推进了很多改良措施，绝大部分失败了，但也有一些幸运地活了下来。

如Google SRE团队所总结的"我们要从错误中学习，而不是简单地重复错误"，对于那些暂时失败的改良，我们并不认为是措施本身存在问题，而只是对于当下团队而言，它们出现得太早了。

我们要分析这些失败的改良，从中找出导致它们失败的共性，来给未来将要推进的改良措施一些指导，能够在早期就能给出一些措施被落地的概率预估，为资源分配提供参考，降低失败概率，并控制好各方的预期。

这些指导也要尽量少且明确，因为自下而上的改良注定了你无法得到专业的指导，问题和解决方案都需要你亲自去发掘。泛泛而谈的标准和指导只会让人反感。

本文正是这样的一个尝试。这里我给出我自己总结的一条标准：

如果你打算推进某项改良，那么请先思考这样的一个问题：你打算如何检查改良的效果？ 如何检查改良的执行过程？

2. 做好检查工作

以上便是在过去几年的迭代筛选之后，当下我们能想到的最具指导意义的参考标准。

在自下而上推进改良的过程中，我们出于各种考虑，各种诉求制定的标准和要求，也会依据当下的各种现实情况进行裁剪，但最终你都要面对这个问题：“如何检查？”

只有它能够告诉你需要裁剪多少，那个度在哪里。自下而上的改良过程中：

1. 丰富的理论知识只是让你知道哪些准则不能退，哪些底线不能碰。
2. 对于现实的了解和熟练的实战经验让你拥有实现目标的更多的变通方式，一定程度增加成功的概率。
3. 检查标准的制定才能让你从诸多方法中挑出落地可能性最高的那个，倒逼你去拆解细化出改良落地过程中的步骤，确保最终能够不可打折地达到目标，为下一步改良提供基础。

3. 意义

1. 重要的不是制定标准和颁布措施。我看到了无数领导和负责人很年轻地认为针对当前问题，只要我出台了某项措施，或者是只要下面这帮人责任心强一点，问题自然就会解决了。这种念头实在是太天真了，所谓的大力出奇迹也往往就是在这种背景下产生的，而且往往是只能管一时，风声过去之后情形就照旧了。问题很多人都看得到，也自然会产生相应的自认为解决方案。很多时候是方案一大堆，最终要求解决问题的时候，每个人都认为其他人不配合导致自己的方案不给执行，最终导致失败。
2. 重要的是如何确保标准和措施的落地。往往我们总是认为标准和措施的不落地是相关方缺乏职业素养，缺乏主观能动性导致"俺这天才方案明珠蒙尘了"。只是现实中更多的是相关方只负责扔个标准和措施下来，让下面的人遵照执行，然后就等着美好的结果会自己跑到它面前。
3. 普遍的认知，经典的PDCA环里，最重要的是那个A（改良），但是我恰恰认为这个C反而是最重要的。传统软件公司里，上到领导，下到一线员工，绝大部分时候都是D，D，D，干了再说。要不"没有功劳也有苦劳"能经久流传，缺乏过程和结果的量化检查，经常导致的就是"上面一片好心"导致各方怨声载道，最终制度的推进不了了之，再次回到原点。有了C才会有后面那个A。
4. 检查其实就是一种"以终为始"。
   a. 如果你想要的效果，你暂时想不到好的检查方案，那说明这个效果暂时还达不到，你就不该对最终的效果有所期待。成果一定是需要相应的检查来保证的，否则一定会是个半成品，白白浪费资源。
   b. 检查自然要求做好过程管理。检查要求你去推导在执行过程中的里程碑有哪些，每个里程碑需要满足哪些条件才能满足。 只有这样一步一个脚印地做好检查，做好过程管理，最终有资格去期待最终的那个完美结局。
   c. 检查倒逼成果量化。不少时候我们总是感觉看着差不多，问题不大。于是在过程中大家都是你好我好，但最终要交付的时候才发现与目标相去甚远，于是甩锅大赛再次开席，领导也是听着云里雾里，最后限于deadline也只能各打三十大板，并且再次强调下次要是再这样就xxxx。检查的加入会逼着各方去思考过程中要满足的那些标准有哪些是可以量化的，这样才能在检查时减少相互扯皮，减少沟通成本。
5. 思考如何检查能够让你对于改良方案的合理性有全面的了解。
   a. 如果不知道怎么检查，或者觉得检查成本太高，承受不起。就说明当下这个改良或措施不符合现状。
   b. 你接下来应该思考的是降低标准和要求，直到各方承认这个检查当下能够接受被检查，能够被执行，成本在可控范围内。
   c. 项目管理里经典的不可能三角"时间-成本-质量"同样适用于这里。检查就是来保证这个质量的，要求检查就是要求质量，你现在控制成本，而对检查避而不谈，那就是不在乎质量喽。
6. "无检查，不规范"。最终汇总下来其实就这一句。

4. 注意事项

1. 检查应该是收敛的。尽量以自治为目标，尤其是在制度推进的早起，在你的改良方案还没有成果展示，没有获得更多人支持的时候。推进方案细节已经耗费了你所有能够争取到的资源，虽然检查很重要，但你没有更多资源了，这就是现实。检查尽量做到不需要人工干预就能长期存活，否则很容易陷入一种"制度需要检查，那谁来检查检查者检查结果"的套娃式循环中。

2. 检查分为最终结果检查和过程检查。我们往往第一反应里以为检查就是最终的那个结果检查。但没有好过程就没有好结果，好的过程检查是好的结果检查的基石，而且过程检查也是给团队成员一个快速学习的机会，通过快速反馈让成员知道自己的每一步是否在正确的道路上，进而快速掌握我们希望团队所希望的技能和素养。

3. 上面我们强调了不可能三角，但这并不是为了让你望而却步，更多的是希望作为主导者的你能够有比较清晰的认识。认识到推进改良的艰难；认识到并不是你吸收的理论知识有问题，并不是你的想法有问题；认识到在这么多的改良方案里，我应该先做哪些，然后才去做哪些。

   理想是很好的，人性里都是希望一步到位，但现实里不允许，你需要不断积累小胜来建立各方信心，不断争取支持和资源，不断向着目标前进。这就是你为什么需要仔细斟酌接下来要推进哪些改良的重要原因。记住：你的每次失败，相当于对反对你的力量的一次成功。这个反对力量很可能并不具体，但你在推进的过程会无时无刻感受到它的存在。

5. 参考

1. “以自治为目标”
2. 【DEVOPS】DevOps推进过程中的一些最佳实践
3. 【DEVOPS】DevOps推进过程中的一些最佳实践2
4. 【DEVOPS】最佳实践和指导思想
5. 【DEVOPS】共识
6. 传统软件行业技术团队的发展 - 做好技术栈统一 --- "检查操作里人工占比和制度最终落地的失败率成反比，人工检查步骤多一步，制度落地概率就降低一成。"