精益產品需求的要義

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.