第2章 精益產品開發的核心原則（上）：聚焦價值流動效率

第1章分享了從傳統開發方法到敏捷的嬗變。本章討論精益產品開發——有了敏捷軟件開發，為什么還需要精益？它可以解決什么問題？

聚焦用戶價值端到端的流動

“更早地交付價值，更靈活地應對變化”，這是敏捷產品開發的業務目標，為此，我們從瀑布進化為迭代。然而，現實中僅僅實現階段的迭代是不夠的，我們真正需要的是端到端快速靈活地交付價值。這里的端到端是指從用戶的問題到交付用戶解決方案。

實現階段的迭代是不夠的

如圖2-1所示，盡管在實現階段進行了迭代開發（例如使用Scrum框架），實現了從需求分析到測試驗收的迭代，但需求分析之前還有業務的規劃和產品的定義，測試驗收之后還有方案實施和驗證。從更宏觀的范疇看，產品從創意到交付的過程仍然是瀑布的，并沒有完全解決瀑布開發模式帶來的問題，比如業務反饋不夠及時，響應不靈活等。業界把這樣的開發模式稱為Water-Scrum-Fall。

部分環節的迭代有它的價值，至少讓我們在實現階段能夠及時發現技術及協作相關問題，并做出調整。但價值的交付還是很遲才能完成，而且業務閉環未能打通，得到的反饋也不夠真實。可以這么說：“我們在昏暗的隧道中小步前行，只是讓自己不要摔倒；但只有真實的業務交付和反饋，才是照亮前行的光。”

開發環節的實施，并不帶來真正的價值交付和真實的反饋，也無法交付完整的客戶價值。

我們的美好愿望是“更早地交付價值和得到反饋。”然而，殘酷的現實卻是“實現階段的迭代并不帶來真正的價值交付和真實的反饋。”

從聚焦資源效率到聚焦流動效率

如何真正實現端到端快速價值交付？精益產品開發給出的答案是：“從以資源效率為核心，轉變為以流動效率為核心來組織產品交付過程。”資源效率指的是從組織內部的角度，審視各個獨立環節的產出效率；而流動效率是指從用戶的角度，審視用戶價值順暢流動的程度。聚焦流動效率，是精益產品開發在方法學層面的核心原則之一。

為了理解“流動效率”和“資源效率”的不同，讓我們看一個具體實例，它摘自一本書，書名為This is Lean，描述了兩位女士在面臨同一個問題時的不同經歷。

圖2-2中這位女士叫Annie，她感覺胸部不適，懷疑長了腫塊。于是她預約了社區醫院的醫生，圖中描述了她的診斷過程。社區醫生初診后，告訴她需要去胸科醫院檢查；預約并等待后，Annie做了超聲和影像檢查；然后預約、等待外科醫生的門診，確定還需要進一步生理檢驗；再預約穿刺生理檢查，等待結果；再次預約外科醫生，最后得到診斷結果。從初次接觸到確診整個過程花了42天，其中真正接受檢查的時間是兩個小時，Annie大部分時間都處于焦急的等待之中。

再看第二位女士，Sarah也感覺胸部可能長了腫塊，她選擇了新出現的一站式胸科診所，圖2-3中所示的是她的診斷過程。到診所后，護士安排做了初步檢查，確認需要進一步診斷，立刻安排醫生進行了超聲和影像檢查，確認腫塊的存在，安排穿刺生理檢查，結果出來后，醫生給出了診斷意見。整個過程耗時2個小時，其中接受診斷的時間為80分鐘。

如圖2-4所示，護士、醫生和檢查設備是資源，負責注入價值；而病人是流動單元，接受價值。對應于產品開發，團隊是資源，而用戶的需求則是流動單元。

上面兩個例子中，組織流程的出發點不同，一個聚焦內部的資源效率；一個聚焦用戶價值的流動效率，其結果也截然不同。

如圖2-5所示，在Annie的例子中，聚焦的是資源效率，試圖最大化每個資源環節的利用率，如優化醫生和設備的利用率。把鏡頭對準醫生，他們始終忙碌，長長的病人隊伍在身后等待。而把鏡頭對準流動單元——病人，則會發現他們走走停停，大部分時間處于等待狀態。

如圖2-6所示，在Sarah的例子中，聚焦的是流動效率，把加快病人診斷過程作為目標。鏡頭對準病人，會發現過程很少出現中斷。即使排隊，時間也很短。而把鏡頭對準資源——醫生和設備，則會發現他們身后的隊伍總是很短，甚至偶爾還有空閑。

比較Annie和Sarah的歷程，“42天（1008小時）vs.2小時”，從時間的角度，病人體會到的是500倍的效率差異。圖2-7綜合比較了關注資源效率和關注流動效率帶來的不同結果。除前面已經提到的目標和結果不同外，我們還看到，如果關注流動效率，就必須著眼用戶價值而非孤立的資源，尋求整個系統而非局部的優化。

需要指出的是，資源效率和流動效率都重要。以快遞業務為例，流動效率關系客戶體驗和服務承諾；資源效率關系運營成本。我會在第19章討論資源效率和流動效率的關系，以及如何同步優化它們。本章關注的是，應該以哪個為核心來組織和優化用戶價值交付過程，兩者的區別是很明顯的。

回到產品開發，盡管很多組織都宣稱“以用戶為中心，價值驅動”，但實踐上卻總是以資源效率為焦點，進行流程優化，結果往往事與愿違。資源效率的過度局部優化，增加了并行和排隊，使用戶需求走走停停，經常處于等待狀態，在環節內和環節間形成隊列，隊列又帶來額外的工作，如對其的管理、任務的切換及重啟，額外知識的傳遞和再學習等，導致系統整體協調難度增加，讓看上去很高的資源效率無法轉化為真實的生產力，這是很多傳統開發方式共同面對的困境。

從資源效率到流動效率

Don Reinertsen在其經典著作The Principles of Product Development Flow中指出：

在產品開發中，我們的問題幾乎從來不是停滯的資源（工程師），而是停滯的產品需求（用戶價值）。

問題是，幾乎所有傳統方法都把資源效率優化作為首要目標，這是有必然性的。

圖2-8的故事中，一個醉漢在路燈下踉踉蹌蹌地尋找著什么，警察遠遠地看著他。半個小時過去了，警察終于忍不住走上前去說：“你在找什么？”“找我的鑰匙。”醉漢回答。警察很快掃視了一下地面：“沒有啊，是丟在這的嗎？”“不是！”醉漢肯定地說。“那你在這干嘛呢？”警察不解地問。“因為只有這地方有光線，看得見啊！”醉漢反而有些不耐煩了。

對于產品開發組織，時時刻刻都能看到資源，承擔改進的主體也是資源團隊。那是路燈照亮的地方，自然成為焦點，卻并不是真正的價值。為了回歸用戶價值，精益產品開發必須重新聚焦流動效率，它首先要分析和可視化用戶價值端到端流動。讓我們看一個具體的例子。

圖2-9是某個30人左右團隊的看板墻。看板墻以可視化方式呈現了用戶需求從提出到交付的端到端過程，直觀呈現了團隊協作交付價值的步驟，交付過程中的問題、阻礙和瓶頸等。

這里有兩個關鍵。其一，可視化的主體是用戶價值的流動，也就是看板系統中流動的主體是用戶需求而不是內部任務。其二，要反映端到端的價值流動，也就是從用戶問題提出到交付用戶解決方案的全過程，包括過程中的問題、阻礙和瓶頸。以可視化的價值流動為基礎，團隊才能聚焦用戶價值，并改善價值的流動效率。關于這一案例的詳細背景，請參見第7章。

上例中，團隊使用的是“看板方法”，它包含5個核心實踐，其中可視化價值流動是第一個也是最基礎的實踐。而其他4個實踐也都與價值流動直接相關。如圖2-10所示，它們分別是：顯式化流程規則；控制在制品數量；管理價值流動；建立反饋，持續改進。看板方法是最有代表性的精益產品開發方法，這些實踐的共同目標是提高用戶價值的流動效率，從而順暢、高質量地交付價值。我們將在第6章詳細介紹看板方法實踐體系。

協調多個團隊才能提升流動效率

上面的實例是精益看板方法在小規模團隊中的應用，它打通了組織的交付流程，是實施其他精益開發實踐的基礎。然而，相對復雜的產品，單個團隊還是無法完成用戶價值的交付。

圖2-11是電信產品的實例，為了交付移動網絡方案，通常需要數以千計的人員協作，包含若干個網元設備的聯合開發。在解決方案層面，面對的是原始的用戶需求；在下一層次，用戶需求被分解成為各個網元的功能需求；而一個網元的開發可能就涉及好幾百人，所以還需要分解到各個功能模塊，成為模塊任務。在如此復雜的產品中，單個團隊的敏捷，并不能帶來用戶價值的更早交付和有效反饋的獲取。

為此，有人認為敏捷只適合簡單產品開發，如互聯網應用。但互聯網應用就一定簡單嗎？以外賣為例，圖2-12是簡化后的外賣服務鏈接圖，它涉及地圖、搜索、推薦系統、客服系統、團購系統、支付服務、用戶系統、配送服務、商家管理系統、結算系統等，而這些服務和系統可能是不同團隊開發和維護的。要及早交付價值和獲取反饋，各個團隊獨立實施顯然是不夠的。

在復雜的產品和組織中，單個團隊或服務的敏捷還無法交付完整的客戶價值。

互聯網向線下、縱深的發展已是大勢所趨，服務的連結變得越來越復雜，經常需要多個團隊有效協作才能更快交付用戶價值。

在復雜的組織或產品中，產品是分層次的，相應的價值和價值的流動也是分層的，我們最終追求的是頂層用戶價值的流動效率。圖2-13是前面提及的電信設備，無線產品線的看板系統設計方案，與價值流動相匹配，看板系統也是分層的。

圖2-13中，上方是解決方案層面的看板系統，主線是用戶需求（綠色卡片）的流動，同時它也包含下一層次的價值項——網元層的功能需求（藍色卡片），下層的功能需求隸屬于上層的用戶需求，底層的流動單元向上層價值對齊，實現用戶價值的快速交付；圖片下方是項目（網元）層的看板系統，每個網元都有自己的項目看板，其上的基本流動單元是功能需求，關注功能需求的流動效率，模塊任務與功能需求關聯，力求向功能需求對齊，快速完成功能需求。

這兩個層次的看板系統，通過功能需求實現聯動，讓整個組織能夠協調一致，快速交付用戶的價值。我會在第18章中專門討論這個案例，介紹分層看板設計背后的原則以及運作細節。

總結前面提到的兩個看板系統案例，為了更順暢、更早交付用戶價值，首先要打通端到端——從用戶問題到方案交付——的價值流；面對復雜的產品和組織時，還必須連接和融合各個團隊或服務的工作，協調一致，實現最終用戶價值的快速交付。我們可以將其總結為：“前后拉通，左右對齊”，而聚焦用戶價值在整個組織端到端的流動效率是其中的關鍵。

小結

從“聚焦資源效率”轉變為“聚焦流動效率”，是精益產品開發的核心原則之一，為了持續改善流動高效率，我們必須關注端到端價值流動過程，并做到“前后拉通，左右對齊”，在本書第II部分，我們將詳細描述具體做法。

本章要點

? 僅僅實現過程的迭代，還不能完全滿足更早交付價值和更靈活應對變化的需求。

? 從聚焦資源效率轉變為聚焦流動效率，這是精益產品開發的核心原則之一。

? 產品開發中的主要問題不是停滯的資源，而是停滯的價值流動。可視化端到端的價值流動，有助于我們更好地關注和改進它。

? 復雜的產品中，單個團隊的迭代是不夠的，為了順暢地交付價值，必須面向價值流動做到前后拉通、左右對齊。

常見問題

問題：我們準備應用規模化的敏捷實施方案，比如SAFe和LeSS等，還需要掌握精益的思想和實踐嗎？

回答：需要。當前的規模化敏捷實施方案都深受精益思想和精益實踐的影響，以SAFe為例，它的全稱是Scaled Agile Framework（規模化敏捷框架），由Dean Leffingwell等人提出，已經發展為4.0版本，最早版本的SAFe是在Scrum的基礎上引入相關項目和產品組合的管控機制以及跨團隊的計劃、協調和跟蹤實踐；從2.0版本開始，SAFe開始更多應用精益思想和實踐，強調流動，并把看板作為跨團隊協調和價值流打通的工具，在團隊層面仍然以Scrum作為基本工具；到了4.0版本，SAFe將看板方法引入團隊級別。而SAFe原則，差不多也是精益原則的翻版。可以說，SAFe的演進過程也是其精益化的過程。

每個組織都有自己不同的上下文和既有的現狀，不可能完全照搬所謂既定的框架。這就需要應用精益思想和實踐，圍繞用戶價值加以適配和調整。否則不理解目標和原則，照樣學樣，往往是畫虎不成反類犬。掌握和應用精益思想、原則和實踐，才能演進出更適合組織上下文的框架，具體哪個規模化的框架反而不那么重要。

問題：精益是不是只適合比較大型的組織，小型組織應用敏捷方法就足夠了？

回答：不是。首先，敏捷和精益本來就有許多共通之處。Scrum和XP方法的發明人都說自己深受精益思想的影響。而敏捷的實踐，特別是需求和技術實踐，讓小批量的交付和流動成為可能，這是精益實踐能夠應用到軟件開發領域的一個重要基礎。另一方面，精益更強調以端到端的價值流動為基礎的流動效率提升，對業務目標的改進更為直接，也為組織的敏捷和精益化變革提供了更平滑的路徑。總體上講，精益和敏捷的結合是相得益彰的。最后，以用戶價值為中心來組織產品交付過程，對大型組織和小型組織都是非常必要的。