來自：IT人的職場進階
“ 對於正處於創業期的互聯網公司來說，研發效率就是生命線。員工人數的增加並不等於公司在變好，一家沒有效率的創業公司，將以最快的方式死去。”
在互聯網快速發展的這些年，軟件工程的協同方法也在同步升級：從傳統的瀑布，到敏捷，再到微服務和中臺化。但是先進的開發模式並非萬能的解藥，996幾乎成為了程序員的標配，似乎有種效率不行、工時來湊的趨勢。
前幾天和同事聊天，談到了一個特別有意思的現象：我們一起經歷了兩家創業公司，但是能明顯感覺到新公司在研發效率和研發質量上都比前公司好太多，然而這兩家公司的基礎設施以及工程師水平差距並不大。
下面這些現象更是在創業公司屢見不鮮：
- 研發團隊人很多，大家也很辛苦，但是仍然被業務吐槽迭代速度慢。
- 開發、測試、產品彼此不信任，害怕背鍋，整天各種扯皮。
- 開發人員疲於應付新需求，同時線上故障頻繁出現，一邊做新feature一邊改BUG，迭代節奏完全被打亂。
隨著創業公司的快速發展，研發效率跟不上是最容易出現、也是最急需解決的問題。如何快速做出調整真的非常挑戰組織能力和管理水平。
做好了，能為業務發展保障護航，讓技術同學的投入更有價值；做不好，不僅會拖業務後腿，而且很有可能讓團隊氛圍變糟，優秀人才流失，最終徹底擊垮一個團隊。
這篇文章，我將結合自己的經驗和理解，分別從組織架構、流程制度、工程方法、團隊文化4個角度聊聊：如何讓研發團隊的工作更加高效？
01 組織架構
做到和技術架構同步升級
組織架構決定了協作方式。當一個組織變成一個「利益共同體」時，效率才能真正體現出來。否則組織之間只會相互推諉，人為增加各種流程制度來保護自己的利益，進一步降低效率。
《人月神話》這本軟件工程領域的經典著作中，引用並推廣了一個非常著名的定律：康威定律（Conway's law）.
設計系統的組織，其產生的架構設計等同於組織之間的溝通結構。
通俗理解就是：組織架構需要和技術架構相匹配。在團隊內部進行高頻、細粒度的溝通，和團隊外部，定義好契約，只進行粗粒度的溝通。這一點和軟件設計的高內聚、低耦合原則一致（看來組織管理和軟件設計有時候是相通的）。
創業公司初期，一般採用職能型組織架構，比如：研發團隊、測試團隊、運維團隊、產品團隊等，各個團隊彼此獨立，早期因為人數少、業務單一，這種架構通常不會出現效率問題。
真正的挑戰從此時開始：公司從單條成功的業務線裂變出不同產品和服務的過程，人員快速增加，業務逐漸複雜，並行項目變多，如果繼續維持職能型的組織架構就會出現資源衝突，溝通成本變高，進而引發一系列的協作問題，最終阻礙業務的發展。
此時，大部分公司的做法都是：推進微服務、DevOps... 殊不知這些手段能發揮出價值的核心因素並不在於技術本身。而是需要公司頂層合理地劃分服務邊界，規劃出相匹配的組織架構，但是能做到這一點的公司真不多，要麼沒經驗，要麼高層大佬們各懷心思、不想放棄自己的利益。
端到端的跨職能組織架構，是目前被廣泛認可、並且適合推進微服務技術和敏捷開發的最佳組織形式，它同時能夠滿足業務快速、多變的特點。
職能線負責專業能力的培養與專業規範的制定，為業務線提供技術資源。每個業務線都是全功能的團隊，有自己專屬的運營、產品、研發和測試人員，大家圍繞同一個業務目標不斷的迭代開發。這樣的團隊是全棧、自治和扁平的，能根據業務節奏自行決定迭代速度，同時絕大部分時間裡可獨立完成整個業務功能的全生命週期管理。
02 流程制度
從源頭提升效率，對流程做減法
針對高頻的工作流程設定製度是必須的（比如基本的項目管理流程），但是過細的過程管理則顯得多餘，反而會抑制工程師們的創新能力，降低工作效率。
太多的管理者，一出問題就喜歡定個制度，引入一系列的流程和追責機制來約束大家的行為，但是很多時候並沒有抓住問題的本質，因此定出來的制度既蹩腳還不受歡迎。
從源頭解決問題往往是最高效的，舉幾個例子：
- 一個複雜的業務，如果經常出現：改動A模塊的代碼引發B模塊的BUG。很可能就是架構設計有問題，兩個模塊過於耦合。如果管理者認為是研發週期短沒梳理到影響點導致的就是沒抓住本質。
- 線上BUG頻繁出現，管理者不抓研發質量，怪罪測試不仔細就是沒抓住本質。
- 一個迭代，研發平均要花費20%的時間去修復線上故障。管理者不去提高線上質量，而是認為每個迭代都需要預留出足夠多的時間去改BUG就是沒抓住本質。
分析問題入木三分，從源頭把控好質量，是技術管理者最應該做的，它能保證團隊不偏離方向，減少無效勞動。從項目的交付過程來看，需求的質量是第一位，其次是技術設計的質量，然後是代碼和自測的質量，最後才是測試質量，前一步做到位了，後一步的效率才能有保證。在制定項目流程時，我認為明確好每個環節的交付目標即可，而不是非常細的執行要求，這樣各個環節的執行者能選擇自己最高效的方式去操作。
另外，管理者要定期review制度的執行效率，多聽聽底層的聲音。對於工程師而言，如果沒辦法將大多數時間投入到技術環節，那麼流程制度一定是有問題的。比如說：每天要參加大量的會議，一項工作要頻繁彙報細節，決策層級太多等等，這些是最常見的效率殺手。
對於一個高效的團隊，高素質的研發人員加上一些基本的制度是最理想的狀態。日常工作中的很多案例，如果僅僅是因為個別工程師的經驗或者能力不足導致的，做好覆盤和培訓遠比一個新制度有效。
03 工程方法
標準化、自動化、工具化
用技術性思維解決日常研發過程中的效率問題應該是技術人的特長。受益於開源軟件、虛擬化技術以及各種實用工具，我們基本不需要自己造輪子，結合自己的實際需求用好這些就已經可以大大提高研發效率了。
基礎設施建設、運維自動化、服務治理與監控，這3個方面都是利用開源紅利日趨成熟的體系化方案，一般都有專門的架構運維團隊和工程效率團隊不斷地迭代升級。
- 基礎設施建設：分佈式框架、存儲中間件、消息隊列、任務調度平臺、日誌平臺等。
- 運維自動化：源代碼管理、持續集成、配置標準化、自動化部署、測試環境管理、灰度發佈、虛擬化等。
- 服務治理與監控：服務註冊和發現、集群協同、調用鏈跟蹤、服務質量監控等。
除此之外，還有很多事情可以進一步通過標準化、工具化和自動化來提高效率。參考懶人思維：重複的事情儘量讓機器來做。
「標準化」主要是為了拉齊團隊的溝通界面，將常規性的工作採用統一的輸出方式，從而減少理解成本，比如：技術設計文檔模板、週報模板、團隊周例會模板、項目迭代報告等等。
「自動化」更多和DevOps結合起來，讓研發測試工作進一步提效。比如：集成代碼時自動進行編碼規範的檢查、利用腳手架自動生成新項目的框架代碼、定時執行業務監控程序、各種測試自動化（包括：單元測試、接口測試、核心流程的集成測試）。
「工具化」則是通過技術手段將重複性的工作用程序來實現，比如：線上問題的排查工具、測試數據或者線上數據的構造工具等等。
另外，我認為測試左移和測試右移是非常好的工程實踐方法，如果能讓團隊中的每個成員意識到它們的好處並推動落地執行，將會使得研發質量更有保障，真正做到「唯快不破」而且快得更加持久（此時你就不會苦惱如何推行單元測試了）。
04 團隊文化
信任、主動、知識共享
要想車子快，全靠車頭帶，和高效的人一起工作，你也會變得更加高效。當高效成為了團隊基因，它能不斷影響新加入的同學，變成一種傳遞的力量（道理有點虛，不過我認為是最實用的一點。如果你是管理者，請先反思自己是不是一個高效率的人）。
「信任」是高效協作的第一前提。管理者交代清楚目標，確定好執行計劃即可，不做執行上的干預，這是絕大部分技術同學最喜歡的工作方式，不被束縛，有發揮空間，同時管理成本低。
之前看過一個研究分析，一項工作如果員工的心態是Want to do，而不是Have to do，最終的工作效果差4倍。如何讓組員更加「主動」，提供3點參考意見：
- 交代清楚工作的價值（這個價值儘量和員工的核心訴求產生關係，比如能力提升、升職、加薪或者精神層面的認可）。
- 有相應的獎勵機制或者績效措施作為牽引，做得好與壞必須要區別對待。
- 如果前面兩點還沒有效果，可以直接淘汰。
「知識共享」對於構建一個開放、自學習的團隊非常關鍵，如果團隊具備了快速成長的能力，將獲得更長期的高效。通過知識沉澱和分享，一方面可以將有用的經驗或者技能傳遞給更多人，形成團隊的長期資產；另一方面，在這種文化牽引下，每個人都會變得更加自驅，並不斷突破自己的思維和認知邊界。
寫在最後的話
如何讓研發團隊更加高效？有無數條路徑和上千個細節，而每一點都和「人」相關。是的，當大家都認可了當前所做的事情，認可了時間是一種稀缺資源，高效似乎也挺簡單。
閱讀更多 啟迪雲Tuscloud 的文章
