精益產品需求的要義

精益產品需求的要義

1. 需求的新定義

2. 需求的多重挑戰

3. 這麼多挑戰，有解嗎？

4. 精益產品需求是什麼

5. 寫在最後

1. 需求的新定義

我們這裡說的「需求「，是沿循計算機技術誕生以來的「軟體需求」，所以可以稍稍先回溯一下歷史。下圖是Michael Porter的「IT變革的三次變革」[^1]。作者的本意在於看待技術在時代變遷中扮演的角色和地位，我們這裡則去看看IT需求的變化特點。

圖1 Michael Porter IT發展的三個階段

• 信息技術時代：IT主要是用於實現業務、流程自動化，期望利用技術來提高「效率」，相對而言，因為工業時代的業務流程相對固化、計算機技術資源能力的相對稀少，商業市場對軟體的需求變化並沒有那麼大；
• Internet時代：互聯網變成新的營銷渠道，市場對技術的期望不單是自動化固有流程，而是延展業務，所以外部需求的不確定性、變化越來越多；同時也因為技術滲透更廣，軟體服務的競爭程度也更加激烈；
• 數字時代：技術滲透到生活方方面面，引領著消費、生活、商業生態的革新，市場變化日新月異，高度競爭，企業都在追求創新，市場對企業的期望是「高響應力「，甚至是引領力。需求變得更加易變、不確定。

我想大家都深切感受到了這個突出的變化，那就是：普遍來講，市場需求不確定性越來越高，競爭越來越激烈。

與此同時，如果對比軟體開發方法的發展，好像也對應有三個時代：

圖2 軟體開發方法的沿革和需求定義的演繹

• 軟體工程時代：對應於上圖的「信息技術時代」。市場需求聚焦在現有業務流程的自動化，大工業時代固化下的業務流程並不會天天變，所以對需求的定義是「軟體功能的規範說明」。工作方式是瀑布式的：先花大量的時間模型化業務流程，製作出詳細的「需求規格說明」，然後才進行開發實現。
• 敏捷轉型時代：對應於上圖的「互聯網時代」。隨著互聯網的出現，信息技術不再是自動化固有流程，而開始延展業務，如進行網上展示、銷售和營銷。這時，發現需求的不確定性變大了，用傳統的「瀑布」方法不能適應外部市場的需求變化，軟體項目失敗率非常高，於是開始尋找更輕量的、迭代試錯、小步前進的輕量級敏捷方法，來提升軟體團隊的響應力。這時，對需求的定義也演繹為「代表著業務價值的一個單元」。但是，這種變化始於IT也僅限於IT，敏捷方法簇[^2]里需求相關的實踐和方法大多是面向技術團隊的，如小步發布（Small Release），產品負責人(Product Owner)要和技術團隊在一起，來制定團隊的迭代計劃、排優先順序、澄清需求問題等等。雖然開始關注業務價值，但卻仍主要度量IT團隊的效率和產能。
• 精益企業時代：對應於上圖的「數字經濟時代」。面對高度不確定、激烈競爭的市場，發現需求和定義需求的過程，變成一個不斷試錯、然後逼近「正確結果」的過程，這已慢慢成為大家的共識；同時，面對市場的高響應力、引領力的要求，對需求的驗證環路必然要穿越IT、銷售、運營、市場等所有職能部門，才能形成端到端的閉環，持續創造市場價值，即「整個組織的更廣闊精益變革」[^3]。

因此上，在當前高度不確定性的市場環境下，有必要重新定義下「需求是」：

需求是「建立在商業、技術和人之間的一組動態的、待驗證的假設」；挖掘和定義需求的過程，是一個不斷驗證假設、在試錯中學習、逐步逼近直至找到與市場的「契合點」的過程。

2. 需求問題的多重挑戰

下面是我們在提供諮詢時收集到的一些常見的需求問題。看起來是不是很眼熟？

圖3 組織中常見的需求問題

如果仔細去分析這些問題，本質上會歸結為下面的挑戰：

圖4 需求的多重挑戰

挑戰之一: 需求產生時的「不確定性」。產品需求的本質都變成了「有價值的假說」，而不是傳統意義上是確定的、一開始就能準確定義出來的。「市場用戶需要一匹更快、永不疲倦的馬」，是一個「有價值的假說」；「用戶需要汽車」則是不斷轉向、學習的結果。人們善於解決確定性的問題，在面對不確定性的時候，往往束手無策。產品創新連接商業、技術和人，但方向有那麼多，該從哪個點開始？如何在首次提出產品想法時，就能(比競爭對手）找出「更靠譜的假設」？這是前所有未有的挑戰。

挑戰之二: 需求經過層層分解可能完全失去原有意圖。即使在最開始，我們獨具慧眼，已經識別出更接近「正確結果」的假設，但在落地實現時，因為組織分工、政治、計劃等約束，不可避免地會被拆解成零部件，然後再一一實現，組裝完了再去驗證。在這個過程中，拆解、組裝之後的結果很可能讓原始的意圖面目全非。

挑戰之三: 需求實現所必須的社會化協作導致的需求失真、或被「污染」。需求的交付是一個社會化協作的過程，所有參與其中的人背景、知識、能力、出發點、利益不同，在理解、表達、傳遞、接收、消化、再傳播需求時，都會「解釋過濾「一遍，這樣的協作過程的產物極有可能讓需求意圖失真、或被「污染」成另外的樣子。

挑戰之四：需求的時效性。在驗證假設的過程中，外部市場時刻發生著變化。可能就要上線驗證了，市場上突然來了一個其他的產品橫空出世，消費者行為因此而改變，「原有的可選項不再是可選項」。

3. 這麼多挑戰，有解嗎

如果我們認識到，需求只是一組假設，那麼我們就會：

• 轉變思維——我們的所有工作過程，不再是一個對確定問題求解的線性過程，而是一個構建（Build）- 度量（Measure）- 學習（Learn）的螺旋前進過程，我們會認為「不確定」是常態，積極主動地調整計劃以適應變化；
• 步子邁得更小一點——每次定的「需求目標和範圍」會更小一點，這樣儘可能讓錯誤的彎路更短一些，驗證的成本也更低一些；
• 盡量縮減驗證、反饋周期——因為這樣試錯成本更低，所以我們就要拚命靠近客戶和用戶，與他們對話，花精力研究他們、了解他們；
• 迫切想知道驗證結果——所以在在產生需求想法時，就確定好度量指標和驗證方法；
• 為了一開始找到更接近的假設，我們需要對用戶、領域問題、行業生態有更為深刻的洞察；

如果我們認識到，需求層層分解會導致需求變形，那麼我們就會：

• 需求目標定小一點，盡量避免不必要的分解；
• 簡化組織結構，層級少一點，減少層層分解；
• 建立跨職能部門，減少分解；

如果我們認識到，需求的社會化協作（溝通、傳遞、協調）會導致需求變形，那麼我們就會：

• 統一需求介面，減少溝通節點；
• 按照產品職責來設置團隊，讓市場、技術和消費者直接溝通，減少中間環節；
• 建立跨職能團隊，避免部門政治給需求帶來的污染；
• 採用更直接、更簡潔、更高效的方式去溝通，減少信息失真；

如果我們認識到，需求是具有時效性的，那麼我們就會：

• 需求目標定得儘可能小，因為目標越大、驗證學習周期就會越長，失效的可能性更大；
• 時刻關注市場變化，隨時做好調整轉向準備

所以，需求挑戰的應對，不單單是IT團隊負責需求的個人和團隊的事，更是思維和文化、組織結構、管理流程、領域洞見、溝通和協作能力等各個維度在各個層面的事。

4. 精益產品需求是什麼

當前，在諸多開始嘗試或已經實施敏捷轉型的企業里，應用最普遍的還是團隊級的「敏捷開發方法「，有關需求的方法和實踐，如果濃縮下來，大概像這張圖：

圖5 當前常用的「敏捷需求分析「

回頭檢視，我們會發現通過圖上這些方法、實踐和工具，主要是改善了IT交付團隊內部的「需求溝通和傳遞」，通過「小步發布「少量地改善了「時效性」的問題，而針對其他問題似乎沒怎麼改變。因此，也出現了類似這樣的疑問：「實施敏捷需求分析的效果，也就是團隊內合作和溝通更流暢了，對業務也沒什麼影響啊？」

如果想要全面應對這些需求挑戰，則需要應用「精益企業」[^4]的指導方法——把敏捷、精益的理念思維應用在與需求有關的組織結構、管理流程、領域洞見、溝通和協作能力等各個維度、各個層面。

另外，「傳統上，大多數企業秉承以範圍、成本和進度為中心進行交付管理，這使得所有人都迷失了，似乎項目交付就是目的，而忽視了投資本身的初衷所要達到的用戶和業務目標，更談不上持續創新。現代科技企業所面對的競爭環境越加激烈，用戶和市場的變化迅速，要能夠快速適應變化，真正創造用戶喜愛的，有競爭力的產品，並持續創新，需要告別以往多年「以項目為中心」的管理，建立一種以產品為中心的軟體交付模式」[^5]。要根據面向業務的能力來建立產品團隊，在看待需求時從產品的全生命周期——產品的機會發現、定義、啟動上線、成長、成熟以及演化去看待和管理需求。

如果嘗試給「精益產品需求」下個定義，就是以「精益企業」為指導，以產品為中心，把敏捷、精益的理念應用在產品全生命周期相關的組織結構、管理流程、需求溝通和協作中的方法和實踐。

結合第2部分的常見需求挑戰，無非就是在組織層面應用精益的思想和原則：

需求挑戰精益產品需求的應對策略方法和實踐舉例市場是不確定和高度競爭的通過設計思維去尋找有價值的需求假設；無論是在探索期和拓展期，構建(Build)-度量（Measure）-學習（Learn）的螺旋前進流程；建立產品團隊，每個產品都直接與自己的客戶/用戶打交道；對業務領域、市場、用戶需要洞察設計思維，MVP，假設驅動開發，驗證板（Validation Board），可選性原則，精益畫布，產品團隊，單一關鍵指標，在線受控實驗，可視化運營，持續的領域研究和洞見，用戶研究，用戶測試需求層層分解會導致需求變形去中心化組織架構、服務治理和數據存儲；以業務為邊界建立產品化團隊；度量響應力而非效率MVP，微服務設計，領域驅動設計，產品團隊，跨職能團隊需求的社會化協作（溝通、傳遞、協調）會導致需求變形協作需求分析；可視化需求；原型設計；輕量級文檔；建立團隊契約規則故事牆，看板牆，用戶故事，敏捷快速啟動，協作式需求工作坊，概念草圖，低保真原型，行為驅動開發(BDD)，實例化需求，價值點分析，優先順序契約，團隊協作契約需求的時效性小步前進，精益創業實戰流程，假設驅動開發，MVP，假設驅動開發，精益畫布，單一關鍵指標，縱向切分，在線受控實驗，可視化運營

精益產品需求的目標：

• 通過在組織、團隊、個人層面的精益需求發現、管理、溝通和協作實踐，來提升組織的響應力和創新力。

「精益產品需求」的原則：

• 對業務領域、市場、用戶需要有洞見，來主動驅動業務變化，而不是僅僅理解跟隨業務變化；
• 真正以客戶/用戶為中心，像客戶/用戶一樣思考，由客戶/用戶價值來驅動決策，而不是利用組織政治來決策；
• 共同一致的需求願景和目標，高度透明、可視化、協同地、高質量地需求溝通，而不是不寫文檔、頻繁但低效地溝通；
• 去中心化的產品體系架構和產品團隊，負責產品的整個生命周期，而不是項目團隊，只注重交付的速率不注重交付的價值；
• 以業務成效來度量和驗證價值，形成價值閉環，而不是單單衡量IT團隊的交付效率和產能；
• 產品的需求，少就是多(Less is More), 做減法；

圖6 精益產品需求的價值閉環

「精益產品需求」方法：

• 產品化方法，區分探索期和拓展期的工作方法

探索期拓展期基於可選性原則，快速對大量的「方案」（需求假設）逐一驗證，期望其中大部分會是不匹配的，而少量的能真正解決問題；以科學方式進行一系列快速、低成本的實驗，所有活動以驗證假設和消除不確定性為目的，來找到產品市場匹配點；以價值為核心要素並得到普遍共識的經濟模型來進行優先順序決策；將需求拆分為小粒度並限制在制品數量，以最快的流速持續為用戶和客戶創造價值，並收集反饋；將新的特性視為有待驗證的假說，基於實際的用戶和業務成效而非產出量來衡量取得的進展，並驅動產品的演進方向，甚至調整願景；將質量內建到交付的每個環節，以高度的自動化和可視化來提高交付效率和降低風險，同時兼顧吞吐量與穩定性

• 不同產品生命周期的關鍵方法：

圖7 產品的生命周期及關鍵方法

「精益產品需求」實踐和工具：

圖8 精益產品需求的實踐和工具舉例

我們在跟一家國外大型金融企業合作的過程中，他們實施了「以客戶為中心」的組織架構重組，他們已實施敏捷轉型5年，想借用此次架構重組來做到「精益產品化治理」，並解決「業務需求響應力慢」的問題。

他們面臨的具體挑戰是：

• 經過了幾十年的運營，IT系統非常複雜，僅客戶平台這塊新老系統超過200個，相互緊耦合。
• 以項目團隊進行工作，項目之間相互依賴，經常出現因為等待依賴而浪費大量的時間；
• 項目啟動基本上是瀑布方式，概念階段和啟動階段長達數月；
• 開發和運維分開，負責維護的團隊覺得不被重視，長期士氣低落；

他們的改進路線和應用實踐如下：

圖9 XX金融企業的需求改進路線

應用實踐：

• 「以面向業務的能力來構建產品團隊」，每個產品團隊自己規劃自己的項目，以持續交付、持續驗證的方式來演進自己的「能力」（如發展新產品，退役舊產品）；
• 每個產品團隊設立Product Owner和Product Architect，按照「業務能力職責」，共同規劃自己產品體系的發展藍圖及運維支持；
• 持續的產品需求技能提升訓練和實踐社區；
• 產品團隊建立後，運維放到產品團隊做了之後，發現總體人員規模可以減少1/5 - 目前這1/5的人用來識別創新機會，在團隊內開展創新項目。

5. 寫在最後

很多企業當面臨圖4中列出的需求問題時，第一時間想到的就是組織需求分析人員的技能培訓，給他們制定一個工作流程，發給他們一個有著「先進實踐」的Handbook，然後就期望這些需求問題都能迎刃而解。但這樣過了一年，發現好像沒什麼變化，那些存在的問題還依然存在。希望通過本文，大家能認識到：在新的數字經濟時代下，需求不確定性更強，挑戰來自於市場外部、組織內部的結構和管理、能力等多個方面。在實施轉型或改進時，企業能以一個更系統的視角來看待，真正實現「精益的產品化治理」。

另一方面，從個人和團隊來說，圖5所展示的「敏捷需求分析」方法和實踐依然適用，但應該有兩個關鍵的轉變：

• 一是「產品思維」，「人人都是產品經理」，認識負責產品的生命期，根據不同的生命期取捨不同的需求實踐，全面掌握不同生命期的實踐方法；

• 二是「精益思維」，以業務成效來度量，對需求要有效做減法。

參考資料：

[^1]：Michael Porter, http://www.faz-forum.com/scp/150121_SCP_Porter_Harvard_Heppelmann_PTC.pdf.

[^2]：「敏捷方法簇」，指代Scrum、XP等為代表的輕量迭代開發方法。

[^3]：肖然，」從敏捷轉型到精益企業」, http://insights.thoughtworkers.org/from-agile-transformation-to-lean-enterprise

[^4]：《精益企業》.

[^5]：姚安峰，「精益企業原則之：以產品為中心，而非交付項目」，http://www.infoq.com/cn/articles/the-principles-of-lean-enterprise-product-centric.

?
推薦閱讀：