研發效能提高 36 計第一課：互聯網時代研發效能的挑戰和應對之道

簡介： 《研發效能提高和敏捷實施 36 計》是阿里雲聯合Teambition打造的系列課程，課程將從團隊和項目協做、需求分析和管理、以及業務創新、以及設計編碼等 5 個方面，詳細介紹研發效能提高的方法、實踐和工具，並解析阿里巴巴的實踐案例。

前言

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

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

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

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

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

一方面：隨着競爭的加重，業務對研發效能的指望愈來愈高；另外一方面：隨着 IoT，以及互聯網向產業縱深的挺進，產品和協做的複雜度愈來愈高，研發效能有降低的趨勢。如何彌補指望和現實的差距，這是研發效能提高必需要解決的問題，關鍵是如何作到呢？

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

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

挑戰一：局部效率 不等於 高效交付

今天，無論是創業公司仍是 BAT 這樣的大公司，每一個人都很繁忙——至少是看上去是繁忙的。但用戶關注的並非，組織內部繁忙與否，他們在意的是：需求是否是快速、有效地被知足。對應組織能力就是：需求順暢和高質量的流動，直至交付。咱們稱之爲（用戶價值的）流動效率。

「局部效率不等於高效交付」這是研發效能面臨的第一個挑戰。 爲此，咱們必須：以流動效率爲核心，提高團隊的持續交付能力。

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

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

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

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

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

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

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

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

一、以流動效率爲核心提高團隊的持續交付能力

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

剛纔講效率豎井，若是追求效率，你會如何作呢？可能一些團隊會選擇攢一批需求，對某個職能來講，批量去作該職能的事情，從直覺上來講是最快的，如產品同窗批量去作需求分析、開發同窗攢一批需求，一塊兒完成開發。但若是從單個需求的視角來看，問題是什麼呢？單我的一段時間只能處理一個需求，其它需求就會處於等待，等待不只僅是由於批量，還多是各部門的協調問題，多是時間上沒有對齊，可能一我的作完的東西不是另外一我的當即須要的，一人作了 A，一人作了 B，時間上沒有對齊。此外，還有一些重要的緣由，好比流程的要求，例如要批量作測試，就會形成等待。這種等待從用戶角度來看是實實在在的等待；從業務響應的角度來講，它下降了響應；從效率的角度來講，這種等待會致使不少工做的重啓，問題延後的發現，不只下降了流動效率，也下降了資源有效的效率。

在互聯網開發當中，咱們應該避免效率豎井，可是每每有時因爲意識和方法作的不夠好，依然存在這樣的問題。效率豎井是效能提高的最大限令和誤區。

有時面對效率豎井也很無奈，因爲組織結構致使了這樣的狀態。在一些互聯網企業，這樣的鏈條不會太長，一些傳統型企業的鏈條則可能更長，有十多個職能。固然，互聯網行業也在發生變化，之前沒有面臨這些挑戰，如今也在面臨着新的挑戰，因爲技術變複雜了，有些行業類型的產品的交付鏈條也在變長，有時候也很難適應，因此這是傳統軟件開發和互聯網軟件開發面臨的共同挑戰。那麼咱們如何去應對挑戰呢？

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

縮短交付週期不只僅是提高快速交付價值能力，也快速的獲得反饋（後續還會講到快速反饋），能夠更好的調整和探索，這就須要看的是系統而非局部的改進。局部是看各個職能模塊，系統是看端到端整個完整鏈條。

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

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

二、以用戶價值爲核心規劃和探索有效的產品

首先咱們須要去規劃和探索有效的需求。如何去探索呢？過去是以組織和資源爲核心，一件東西只要生產出來就有人買，但今天選擇權已經從生產方轉移到用戶側，用戶有愈來愈多的選擇權，全部的公司都是圍繞用戶來作，這很是像地心說向日心說轉移的過程。因此，咱們要從以組織和資源爲核心轉變成以用戶價值爲核心。如何去作呢？

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

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

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

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

不少人也常常會問，怎樣把一個很大的需求拆分紅一些小一點的需求，其實這也是在澄清和分析的過程。之因此沒有去講需求拆分，由於咱們認爲它是需求分析的副產物，當帶着一個正確的價值觀去作，好比要更快的交付時，真正的作到有效需求分析時，需求天然就拆分開來。不該該把需求拆分當成一個獨立的話題，你會發現需求拆分在分析過程當中天然而然的發生了。
一個莫比烏斯環。但願把這兩個探索過程和持續交付的過程真正融爲一個總體鏈接在一塊兒，加快需求分析和探索、反饋的循環，減小其中的摩擦，這才能作到真正的以用戶價值爲核心規劃和探索必要的需求。

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

三、以長期效率爲核心沉澱優質軟件資產和工程能力

咱們能夠有兩條選擇，以下圖，一條紅線，一條綠線。若是爲了追求短時間效率，必定會選擇紅線，就是說開發的越多，接下來作的就越慢，代碼寫的很差，後面的測試、持續交付又沒跟上，所謂出來混老是要還的，前面欠的太多，就須要還債，甚至是利息，若是隻是還債，可能就會把這條紅線拉平。

團隊的高效交付，是應該創建在持續的基礎上的。「以長期效率爲核心」傳遞給你們的信息是不要積累債務，而要積累資產，這個資產既包含工程技術的資產，也包含代碼的資產。

工欲善其事，必先利期器，咱們要不斷的提高工程能力，好比說工具、平臺、還有一些好的實踐，甚至員工技能的問題。好比說持續交付實踐，好比說環境和相應的基礎設施建設，可以經過持續集成部署的方式，讓代碼快速的流動，安全放心的發佈軟件，發佈上機後，安全運維能確保服務的穩定性。

另外一個重要的觀念，就是軟件資產，經過領域分析、領域建模，發現一個領域資產，而後去沉澱它，讓資產盤活、增值，因此這裏面講到設計和代碼實踐時，資產的評估、評價和優化會是一個比較新鮮的內容。

總結

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

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

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

 

本文做者：KB小祕書

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。