研發效能提升 36 計第一課：網際網路時代研發效能的挑戰和應對之道

前言

網際網路時代，業務與協作複雜度與日俱增，競爭日趨激烈，提升研發效能已成為軟體行業的共同挑戰。《研發效能提升和敏捷實施 36 計》是阿里雲聯合 Teambition 打造的系列課程，課程將從團隊和專案協作、需求分析和管理、以及業務創新、以及設計編碼等5個方面，詳細介紹研發效能提升的方法、實踐和工具，並解析阿里巴巴的實踐案例。

本課程是這個系列的開篇，主講人——阿里研發效能資深專家 何勉、張燎原，圍繞影響研發效能的三個核心問題，分享了研發效能提升的實踐體系。

文末可預約今晚第 3 課的課程直播喔！

研發效能成為企業的核心競爭力

馬雲在第四屆世界網際網路大會指出：過去 20 年網際網路從無到有，未來 30 年網際網路從有到無，“無”指的是無所不在。未來，任何一家企業的業務都會構建在網際網路的基礎上。

軟體正在吞噬世界。未來，企業的業務都將構建在軟體和網際網路的基礎之上。軟體交付能力成為企業的核心競爭力，研發效能成為企業的共同挑戰。下圖描述了這一挑戰狀況。

一方面：隨著競爭的加劇，業務對研發效能的期望越來越高；另一方面：隨著 IoT，以及網際網路向產業縱深的挺進，產品和協作的複雜度越來越高，研發效能有下降的趨勢。如何彌補期望和現實的差距，這是研發效能提升必須要解決的問題，關鍵是如何做到呢？

研發效能提升的三個核心思路

為了提升研發效能，我們首先要知道，是什麼影響了研發效能——我們究竟面臨怎樣的挑戰?

挑戰一：區域性效率 不等於 高效交付

今天，不管是創業公司還是 BAT 這樣的大公司，每個人都很繁忙——至少是看上去是繁忙的。但使用者關注的並不是，組織內部繁忙與否，他們在乎的是：需求是不是快速、有效地被滿足。對應組織能力就是：需求順暢和高質量的流動，直至交付。我們稱之為（使用者價值的）流動效率。

“區域性效率不等於高效交付”這是研發效能面臨的第一個挑戰。 為此，我們必須： 以流動效率為核心，提升團隊的持續交付能力。

挑戰二：高效交付 不等於 業務成功

除此之外，高效交付一定會帶來業務的成功麼？顯然不是，我們還必須保障交付的是有用的需求，而不是高效交付一堆垃圾。只有保證交付的是有效價值，才能助力業務成功。

“高效交付 不等於 業務成功”這是研發效能面對的第二個挑戰。為此我們必須： 以使用者價值為核心，規劃和探索有效的產品。

挑戰三：高效交付 不等於 持續高效

第三個方面。僅僅短期高效是不夠的。隨著時間的推進，一個優秀的組織應該不斷積累自己的軟體資產，如：技術和業務中臺；工程基礎設施和能力，如：良好管理的開發、測試環境，持續交付設施等），交付效率持續提高。然而現實中，很多團隊的情況恰恰相反，他們積累的不是資產，而是債務——糟糕的設計、劣化的程式碼、工程能力的缺失，都會讓效率不可持續。

“高效交付不等於持續高效”這是研發效能面對的第三個挑戰。為此我們必須： 以長期效率為核心，沉澱優質軟體資產和工程能力。

下圖總結了這些挑戰和應對。我們的系列課程都將圍繞它們展開，構建研發效能的提升的系統解決方案。

接下來，我們會大致介紹一下這三個方面的具體實踐。

1、以流動效率為核心提升團隊的持續交付能力

透過這張圖我們來了解下區域性效率與高效交付之間的關係。上圖展示的是典型的效率豎井，即我們常常說的 silo。什麼叫效率豎井呢？在產品開發過程中，企業通常是按職能組織團隊的，如業務部門、產品部門、開發部門、測試部門及運維部門等，每個職能都可以說自己很高效，從各自的視角去提升效率，看上去每一個職能都很繁忙，看似高效。但是從使用者/客戶的角度去看，使用者關心的是需求是以多快速度交付到他的手中，滿足他“所想即所得”的述求。我們看單個需求在研發過程流動的整個週期，從需求提出到完成的整個時間線上，我們分別用紅線表示等待時長，綠線表示被處理的時長，紅長綠短。為什麼會這樣呢？

剛才講效率豎井，如果追求效率，你會如何做呢？可能一些團隊會選擇攢一批需求，對某個職能來說，批次去做該職能的事情，從直覺上來說是最快的，如產品同學批次去做需求分析、開發同學攢一批需求，一起完成開發。但如果從單個需求的視角來看，問題是什麼呢？單個人一段時間只能處理一個需求，其它需求就會處於等待，等待不僅僅是因為批次，還可能是各部門的協調問題，可能是時間上沒有對齊，可能一個人做完的東西不是另一個人立即需要的，一人做了 A，一人做了 B，時間上沒有對齊。此外，還有一些重要的原因，比如流程的要求，例如要批次做測試，就會造成等待。這種等待從使用者角度來看是實實在在的等待；從業務響應的角度來說，它降低了響應；從效率的角度來說，這種等待會導致很多工作的重啟，問題延後的發現，不僅降低了流動效率，也降低了資源有效的效率。

在網際網路開發當中，我們應該避免效率豎井，但是往往有時由於意識和方法做的不夠好，依然存在這樣的問題。效率豎井是效能提升的最大限令和誤區。

有時面對效率豎井也很無奈，由於組織結構導致了這樣的狀態。在一些網際網路企業，這樣的鏈條不會太長，一些傳統型企業的鏈條則可能更長，有十多個職能。當然，網際網路行業也在發生變化，以前沒有面臨這些挑戰，現在也在面臨著新的挑戰，由於技術變複雜了，有些行業型別的產品的交付鏈條也在變長，有時候也很難適應，所以這是傳統軟體開發和網際網路軟體開發面臨的共同挑戰。那麼我們如何去應對挑戰呢？

要把以區域性資源效率為核心變成以使用者價值流動效率為核心。區域性效率看單點資源是否被充分利用，即每個人忙不忙。而流動效率不再指人，是指使用者的價值、使用者的需求的從起點到終點的流速。當換一個視角時，方法體系也會被重構，所以要以流動效率為核心來提升團隊的持續能力交付，用這個視角來重新組織、構建和度量整個研發的過程。

縮短交付週期不僅僅是提升快速交付價值能力，也快速的得到反饋（後續還會講到快速反饋），可以更好的調整和探索，這就需要看的是系統而非區域性的改進。區域性是看各個職能模組，系統是看端到端整個完整鏈條。

為了提升持續、快速交付價值的能力，這需要精益和敏捷協作實踐，包括：第一部分端到端的拉通和視覺化，即可見到使用者需求的交付過程，它有沒有走走停停，如果發生了等待是什麼原因，只有可見才能管理這個過程；第二部分是怎麼管理價值的流動，即可控，控制不是控制人而是流程，目的是讓價值的流動更加順暢;第三部分要講流動的度量、反饋和持續改進，度量和反饋永遠是個熱門話題，卻又永遠也不簡單，其中有很多陷阱和誤區，我們試圖去破解這些陷阱和誤區，度量的目的是幫助改進而不是責備誰，它能回答流動效率怎麼樣，可以在哪些方面改進。

以流動效率為核心提升團隊的持續交付能力，把每個人的工作變成一個整體的有效快速交付就夠了嗎？高效交付不等於業務成功，我們還要以使用者價值為核心規劃和探索有效的產品。

2、以使用者價值為核心規劃和探索有效的產品

首先我們需要去規劃和探索有效的需求。如何去探索呢？過去是以組織和資源為核心，一件東西只要生產出來就有人買，但今天選擇權已經從生產方轉移到使用者側，使用者有越來越多的選擇權，所有的公司都是圍繞使用者來做，這非常像地心說向日心說轉移的過程。所以，我們要從以組織和資源為核心轉變成以使用者價值為核心。如何去做呢？

解決問題的框架如上圖所示，整個過程還是比較複雜的，我們會分兩個主題來講，一個是精益創新實踐，另一個是精益敏捷需求管理。

精益創新實踐主題，關注在如何做價值分析和業務分析，業務分析後瞭解解決使用者的問題是什麼、業務目標是什麼、解決問題的實現過程是什麼樣的、實現過程中有什麼樣的阻礙，這是價值和業務分析的過程。

就像上圖所示，從業務目標或者使用者目標出發做出兩條路，這兩條路哪個更重要？有強烈的價值主張的一定是使用者目標更重要。一定是從使用者目標開始，因為只有解決了使用者問題，才能實現你的業務目標。基於它去分析業務，做出迭代規劃，後續還會講組織好這些需求怎樣傳遞給開發。

接下來在精益需求管理主題中，再看如何設計需求，然後做出迭代規劃，如何在快速交付情況下把需求交給開發之前保證質量，不僅僅是要把需求寫好，更要讓開發真正理解需求。所以講需求分析和澄清，溝透過程很重要，資訊不僅要準確地表達，還要無損地傳遞。

很多人也經常會問，怎樣把一個很大的需求拆分成一些小一點的需求，其實這也是在澄清和分析的過程。之所以沒有去講需求拆分，因為我們認為它是需求分析的副產物，當帶著一個正確的價值觀去做，比如要更快的交付時，真正的做到有效需求分析時，需求自然就拆分開來。不應該把需求拆分當成一個獨立的話題，你會發現需求拆分在分析過程中自然而然的發生了。
一個莫比烏斯環。希望把這兩個探索過程和持續交付的過程真正融為一個整體連線在一起，加快需求分析和探索、反饋的迴圈，減少其中的摩擦，這才能做到真正的以使用者價值為核心規劃和探索必要的需求。

總結一下，以使用者價值為核心，規劃和探索有效產品，就是把問題給定義出來，再找到一條路徑走過去，解決這個問題。

3、以長期效率為核心沉澱優質軟體資產和工程能力

我們可以有兩條選擇，如下圖，一條紅線，一條綠線。如果為了追求短期效率，一定會選擇紅線，就是說開發的越多，接下來做的就越慢，程式碼寫的不好，後面的測試、持續交付又沒跟上，所謂出來混總是要還的，前面欠的太多，就需要還債，甚至是利息，如果只是還債，可能就會把這條紅線拉平。

團隊的高效交付，是應該建立在持續的基礎上的。“以長期效率為核心”傳遞給大家的資訊是不要積累債務，而要積累資產，這個資產既包含工程技術的資產，也包含程式碼的資產。

工欲善其事，必先利期器，我們要不斷的提升工程能力，比如說工具、平臺、還有一些好的實踐，甚至員工技能的問題。比如說持續交付實踐，比如說環境和相應的基礎設施建設，能夠透過持續整合部署的方式，讓程式碼快速的流動，安全放心的釋出軟體，釋出上機後，安全運維能確保服務的穩定性。

另一個重要的觀念，就是軟體資產，透過領域分析、領域建模，發現一個領域資產，然後去沉澱它，讓資產盤活、增值，所以這裡面講到設計和程式碼實踐時，資產的評估、評價和最佳化會是一個比較新鮮的內容。

總結

以流動效率為核心提升團隊的持續交付能力；以客戶價值為核心規劃和探索有效的產品；以長期效率為核心沉澱優質軟體資產和工程的能力。這三個核心構成了我們的研發效能過提升之道。

我們的研發效能課程將分成 5 個模組。它們分別是：精益創新實踐、精益敏捷需求管理、精益和敏捷協作、持續交付實踐、設計和程式碼實踐。這五個實踐構成完整體系，一方面做到高效交付；一方面實現業務價值，實現從業務到交付的全棧敏捷。

36計系列課程五大主題分享會持續半年的時間，下圖是這個體系的概述。

️本文作者：KB小秘書

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。