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來判斷代碼質量的好與壞。

好了，故事講到這里就結束了。下一步，我們要制定解決方案和實施方法了。讓我們行動起來吧！