1.1 故事开启

铛，铛，铛！

随着CTO办公室的门被敲开，我们的DevOps故事正式开始。

1.1.1 故事背景

效能团队开始是向CTO直接汇报，中间经历多次组织架构调整，汇报对象也历经多次变更，但是CTO一直比较关心技术团队研发效能的提升。这也是效能团队工作比较好开展的原因，不过离“权力”太近，导致和一线研发人员在形式上形成一种“向下管理、向下施策”的错觉，也导致和技术部门负责人之间形成一种“命令传达”的关系。

所以，我们第一步就是消除这种错觉和隔膜，说白了就是要和一线研发人员线下打成一片，辅助技术部门负责人发现问题和解决问题，以便当我们开展工作的时候，大家能够齐心协力地解决问题，而不是形成故意刁难的错觉。

我们第二步要解决效能团队接下来工作的重点问题。

敲门的前两天，我们说技术团队效能提升能够在半年内见效果。话都说出去了，接下来该怎么做？我们心想若能像产品人员一样找业务人员聊聊需求，可能这事就没那么难了。不过但凡CTO和各部门负责人有解决招数，肯定不会组建一个“三方”团队来解决问题了。再加上目前效能团队人力严重不足，招人也需要一段时间。于是，这两天我整理了技术团队遇到的问题，预估了各个问题的解决难度和投入产出比，决定先把代码质量提升上去。

于是，我们主动找到CTO进行沟通，旨在达成如下两个目的。

1）让CTO独立授权效能团队去做代码质量提升，让技术团队各负责人配合我们一起做改进，每个迭代能够留给技术团队一定比例时间去偿还技术债。

2）让CTO退出代码质量提升群。这个用意大家应该知道，就是不想让他的权力潜移默化地影响我们和一线研发人员之间的关系。

1.1.2 故事内容

我们：今天主要是给您看一下下个季度效能团队要做哪些工作？

CTO：好嘞，说下你的思路和想法。

我们拿出笔记本，花了10min简单讲述了技术团队的三大问题，以及每个问题的解决方案和实施方法。（这些内容下文都会有讲解，这里不再详细描述。）

……

CTO：可以啊，考虑得挺周到。（先试试吧，看看效果再说。）

我们：综合考虑这些问题的紧急程度和技术团队现状，团队现阶段的代码质量问题亟待解决，不然随着时间的推移，一些可重构的业务逻辑代码很难再去更改了。（引出话题。）

然后，我们详细罗列出代码质量方面的问题。

CTO：确实，技术团队也很重视代码质量，但缺乏一些流程规范和查缺补漏的方法，你们可重点从这两点做起。

我们：好，我们下个季度先从这两方面入手，下周针对性地制订一个详细方案和规划。

CTO：正好这个季度你们团队的人力也不足，可以先带着大家把代码质量提升的氛围带动起来。（说到心坎上了吧！）

我们：是，是，是。（思考2s，回顾一下我们进门时的目的。）对了，我们还有一个问题，能否组建一个技术中心代码质量委员会，让技术负责人都能参与进来，以便专项治理和协调解决代码质量问题。不过，我们希望代码质量问题能够在研发核心例会（CTO主持的例会）上再向你汇报。

CTO：可以，你们会前先组织技术负责人把常规问题解决掉。

……

我们：好的，那我们先去忙了。

1.1.3 故事结论

以上对话透露出3个重点信息，也是我们后续制定方案时要考虑的。

首先，技术团队的代码质量确实是管理者头疼的问题，一线研发人员对提高代码质量没有太高的兴致，缺乏良好的氛围。

其次，技术团队在提高代码质量上没有形成一定的制度和规范，无章可循。

最后，技术团队缺乏度量代码质量的手段，大家都知道要提升代码质量，但不知道代码质量现在差到什么程度，需要朝哪个方向努力。之前，技术团队基本是靠线上是否有Bug来判断代码质量的好与坏。

好了，故事讲到这里就结束了。下一步，我们要制定解决方案和实施方法了。让我们行动起来吧！