研發效能的六個關鍵點

最近與某互聯網公司架構師討論了研發效能中的問題，整理分享如下。

01 視角

有許多評估團隊產出的辦法，比如代碼行、功能點、故事點和故事卡數量，這種度量方式不僅存在偏差，而且是一種非常局部的度量方式，現在都已不再適用。更有許多研發團隊存在著這種情況，開發編碼的效率很高，測試和部署工作量大，成為瓶頸，或者需求澄清和排程的時間長，壓縮了開發時間，無法詳細地設計和驗證，質量下滑拖累了效率。從而導致最後效能問題“每天工作投入度和響應上，自己感知已經夠快了，業務還說我們慢，原因在哪裡我也說不清楚”。

這裡的關鍵點在於，效能為誰度量，即以誰的視角來看待效能？由於研發最終的目標是交付到業務，那效能最終面對的還是業務視角。

02 感知

很多時候業務感知的“慢”，在於需求的端到端交付週期過長，也在於過程的信息不透明。“一個小需求，也要那麼久才能上線！”而開發感知到的是，需求的評估、排程和跨組/團隊協同過程太耗時了，是因為在這個過程中等待太久，才導致週期拉得很長。

一個需求從提出到發佈，通常會經過分析、澄清、計劃、設計、開發、測試、部署到正式發佈幾個階段。

那麼在各個環節中，究竟多長時間是合適的呢？精益思想給出了一個度量方法，就是最小積壓，理想狀態下是做到零庫存，即沒有需求積壓。如果業務持續不斷地接收到產出物，同時看到新需求不斷進入處理過程，就很難感知到“很慢”了。

舉個例子，同樣是等，在星巴克你能看到你的杯子正在什麼位置，咖啡師正在準備什麼；外賣下單後，你能看到騎手的位置和狀態，就能緩解等待的焦慮。而在研發過程中，因為信息不透明帶來的需要同步的“會議”實在是太多了。

03 時間

近些年我們推崇的是使用時間來度量效能，並且在數個諮詢項目上通過這種度量方式驅動，成功地幫助團隊找到了改進點，優化了整體的交付週期。

三個關鍵的時間度量指標是：

Lead Time（前置時間）：

業務感知效能的重要指示燈，是指從業務提出需求到最終需求發佈到業務的時間間隔（自然日）。如需求於9月1日提出，9月30日發佈，那Lead Time就為29天。又被稱為需求端到端交付週期。

Cycle Time（週期時間）：研發內部效能的重要指示燈，是指開發團隊接受需求到交付業務驗收的時間間隔（自然日），覆蓋了分析、設計、編碼、測試及修復缺陷的時間。通常也稱之為交付週期。

Takt Time（節拍時間）：研發節奏制定的重要參考值，是指開發團隊在週期時間內完成需求的平均時間。比如週期時間為29天，共產出10個需求，節拍時間就為2.9天。精益的理想狀態是單件流，即最小的批量不間斷流轉，節拍時間就是縮小批量大小，邁向不間斷流轉的重要依據。

度量了這幾個時間，那又如何來說明效能呢？

04 浪費

前面提到精益給出的度量標準，即最小積壓。在交付的各個環節中等待的任務，都是積壓，即是浪費。對研發中的浪費，我們設定在計劃啟動之後進行統計，並分類原因：

• 進入開發階段而未投入實際工作量：比如一次領了太多的任務，其中幾個任務並沒有產出，計為浪費，因計劃不當引起。
• 完成開發等待評審/測試：由於不同角色的協作不流暢引起。
• 重做/返工：由於需求理解不正確或實現不正確引起。
• 完成測試後等待驗收：由於不同職能的協作不流暢引起。

根據大量的諮詢經驗，許多效能問題，只需要消除浪費就能夠顯著地提升，這個提升比率最低在40%，最高在89%；一些跨團隊協作的痛點，僅僅通過統一拆分任務和計劃方式，就將協同任務的節拍時間下降了40%之多。

05 工作方式

推行敏捷最重要的就是帶給大家一種全新的工作方式：從一種自上而下領導式的計劃和管理，變成自下而上的團隊合作達成目標。為達成這個轉變，團隊需要掌握幾項技能：

設定目標：從業務和用戶的視角理解需求，瞭解業務價值、使用者和痛點，而不僅僅是功能說明清單。

需求分解：”需求跨不跨迭代“、”需求分幾個迭代開發完成“，也是迭代式開發中的一個常見問題。正確答案是：在敏捷開發裡，無論選擇哪類需求載體，特性、用戶故事還是任務，都不應該在計劃階段設定為跨迭代交付，除非迭代目標沒達成，在評審會議上轉入下一個迭代。沒有正確的需求分解方法，是排不出正確的迭代計劃的。

任務估算：ESTIMATE翻譯為估算一直以來都被視為一種對交付時間的承諾，所以讓開發團隊感覺很難操作。如果用中文更準確的表達應為“評估”，估算技術，是一種從時間上量化交付週期和風險的手段。比如採用斐波那契數列進行估算，就能夠很好地為不確定的風險添加緩衝時間。

迭代/看板計劃：許多團隊僅僅是劃分了一個更小的週期，就把它當作迭代。甚至還有團隊劃分出來的是開發人員的一個容量包，比如兩週的工作量，排進一個迭代，迭代N的交付物，是測試團隊在迭代N+1的測試版本，然後在N+1迭代中又擠進一些不可預測的缺陷修復工作量，最後在N+2/3迭代中發佈迭代N的需求。

這也是許多開發團隊自稱已做到“兩週一迭代”而業務覺得沒啥變化的原因：真實的”需求迭代“應該在六到八週左右，差不多一個半月到兩個月。看板又是另一種工作計劃方式，需要比迭代更細緻的優先級排序，形成任務隊列。在看板上，團隊自頂向下拉動任務卡至交付泳道。

規矩千萬條，最後都落牆角。工作方式大家都口頭接受了，但一執行又全跑歪，又該怎麼辦呢？

06 行為

討論中架構師談到，不止研發效能，還包括架構和代碼質量，都已經制定了嚴格的標準，團隊也接受了，但就是很難執行，現在針對一個200人級別的大型重構項目，不得不組建近30人的治理團隊，負責評審代碼和接口，以避免架構質量走偏。

我認為，這是一種治標不治本的方式。結果有偏差，問題的根源在哪裡？代碼已經不合格了，評審、退回、重做和返工都是浪費。效能的改進是致力於消除這種浪費，而許多技術型管理者關注和控制的落腳點在最終結果，而不是原因。有沒有親自到現場走查一下，這些不合格的代碼、接口是怎麼寫出來的呢？

許多規範只是原則，而開發人員執行的是操作。比如說一個接口的設計規範明明要求：滿足向前兼容。但開發出來的新版本卻把舊的功能破壞了。開發人員很可能並不知道什麼叫“向前兼容”，這些原則對並不瞭解它們的人來說，根本不具備指導意義。如果改成：

禁止修改不熟悉的代碼，如要修改，請和代碼編寫者或技術負責人溝通，並編寫對應的單元測試，以避免破壞系統功能。

禁止修改已發佈的接口實現代碼，應該使用擴展的方式添加新的代碼功能。

如果要停用某個接口，必須添加註解。示例：@Deprecated

這類問題就可以避免了。

許多開發人員並沒有養成高效的工作習慣。每天第一時間處理什麼任務？接到任務後第一時間處理什麼？下班之前哪些事項必須收尾？每個人在動手開動這一切時，指導他的，是他過去的經驗、習慣和思維方式，而不是在某個會議上突然聽到的聲音。把具體的工作步驟成文，並輔導團隊逐步形成習慣，結合績效對過程標準的考核，才能杜絕頻繁返工、銜接不暢的浪費。每個10人左右的小團隊內，一定要有人單對單的輔導，這就是公司作為一個有效的組織，而非一群人的關鍵原因。許多技術人員的關注點在於系統，而未關注到系統開發的過程，而這個過程中，最本質的就是人的行為，造成了研發效能的根本影響。

---

場量科技是一家專注於產品創新與效能優化的平臺服務商，我們基於十餘年的知名企業諮詢經驗，圍繞產品創新提供工具與數據交易平臺，並幫助企業優化產品研發效能。