在新的數(shù)字經(jīng)濟(jì)時代下，需求不確定性更強，挑戰(zhàn)來自于市場外部、組織內(nèi)部的結(jié)構(gòu)和管理、能力等多個方面。在實施轉(zhuǎn)型或改進(jìn)時，企業(yè)能以一個更系統(tǒng)的視角來看待，真正實現(xiàn)“精益的產(chǎn)品化治理”。

1.需求的新定義

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

圖1 Michael Porter IT發(fā)展的三個階段

• 信息技術(shù)時代：IT主要是用于實現(xiàn)業(yè)務(wù)、流程自動化，期望利用技術(shù)來提高“效率”，相對而言，因為工業(yè)時代的業(yè)務(wù)流程相對固化、計算機技術(shù)資源能力的相對稀少，商業(yè)市場對軟件的需求變化并沒有那么大；
• Internet時代：互聯(lián)網(wǎng)變成新的營銷渠道，市場對技術(shù)的期望不單是自動化固有流程，而是延展業(yè)務(wù)，所以外部需求的不確定性、變化越來越多；同時也因為技術(shù)滲透更廣，軟件服務(wù)的競爭程度也更加激烈；
• 數(shù)字時代：技術(shù)滲透到生活方方面面，引領(lǐng)著消費、生活、商業(yè)生態(tài)的革新，市場變化日新月異，高度競爭，企業(yè)都在追求創(chuàng)新，市場對企業(yè)的期望是“高響應(yīng)力“，甚至是引領(lǐng)力。需求變得更加易變、不確定。

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

與此同時，如果對比軟件開發(fā)方法的發(fā)展，好像也對應(yīng)有三個時代：

圖2 軟件開發(fā)方法的沿革和需求定義的演繹

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

因此上，在當(dāng)前高度不確定性的市場環(huán)境下，有必要重新定義下“需求是”：

需求是“建立在商業(yè)、技術(shù)和人之間的一組動態(tài)的、待驗證的假設(shè)”；挖掘和定義需求的過程，是一個不斷驗證假設(shè)、在試錯中學(xué)習(xí)、逐步逼近直至找到與市場的“契合點”的過程。

2. 需求問題的多重挑戰(zhàn)

下面是我們收集到的一些常見的需求問題?？雌饋硎遣皇呛苎凼?？

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

如果仔細(xì)去分析這些問題，本質(zhì)上會歸結(jié)為下面的挑戰(zhàn)：

圖4 需求的多重挑戰(zhàn)

挑戰(zhàn)之一

需求產(chǎn)生時的“不確定性”。產(chǎn)品需求的本質(zhì)都變成了“有價值的假說”，而不是傳統(tǒng)意義上是確定的、一開始就能準(zhǔn)確定義出來的。“市場用戶需要一匹更快、永不疲倦的馬”，是一個“有價值的假說”；“用戶需要汽車”則是不斷轉(zhuǎn)向、學(xué)習(xí)的結(jié)果。人們善于解決確定性的問題，在面對不確定性的時候，往往束手無策。產(chǎn)品創(chuàng)新連接商業(yè)、技術(shù)和人，但方向有那么多，該從哪個點開始？如何在首次提出產(chǎn)品想法時，就能(比競爭對手）找出“更靠譜的假設(shè)”？這是前所有未有的挑戰(zhàn)。

挑戰(zhàn)之二

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

挑戰(zhàn)之三

需求實現(xiàn)所必須的社會化協(xié)作導(dǎo)致的需求失真、或被“污染”。需求的交付是一個社會化協(xié)作的過程，所有參與其中的人背景、知識、能力、出發(fā)點、利益不同，在理解、表達(dá)、傳遞、接收、消化、再傳播需求時，都會“解釋過濾“一遍，這樣的協(xié)作過程的產(chǎn)物極有可能讓需求意圖失真、或被“污染”成另外的樣子。

挑戰(zhàn)之四

需求的時效性。在驗證假設(shè)的過程中，外部市場時刻發(fā)生著變化。可能就要上線驗證了，市場上突然來了一個其他的產(chǎn)品橫空出世，消費者行為因此而改變，“原有的可選項不再是可選項”。

3. 這么多挑戰(zhàn)，有解嗎

如果我們認(rèn)識到，需求只是一組假設(shè)，那么我們就會：

• 轉(zhuǎn)變思維——我們的所有工作過程，不再是一個對確定問題求解的線性過程，而是一個構(gòu)建（Build）- 度量（Measure）- 學(xué)習(xí)（Learn）的螺旋前進(jìn)過程，我們會認(rèn)為“不確定”是常態(tài)，積極主動地調(diào)整計劃以適應(yīng)變化；
• 步子邁得更小一點——每次定的“需求目標(biāo)和范圍”會更小一點，這樣盡可能讓錯誤的彎路更短一些，驗證的成本也更低一些；
• 盡量縮減驗證、反饋周期——因為這樣試錯成本更低，所以我們就要拼命靠近客戶和用戶，與他們對話，花精力研究他們、了解他們；
• 迫切想知道驗證結(jié)果——所以在在產(chǎn)生需求想法時，就確定好度量指標(biāo)和驗證方法；
• 為了一開始找到更接近的假設(shè)，我們需要對用戶、領(lǐng)域問題、行業(yè)生態(tài)有更為深刻的洞察；

如果我們認(rèn)識到，需求層層分解會導(dǎo)致需求變形，那么我們就會：

• 需求目標(biāo)定小一點，盡量避免不必要的分解；
• 簡化組織結(jié)構(gòu)，層級少一點，減少層層分解；
• 建立跨職能部門，減少分解；

如果我們認(rèn)識到，需求的社會化協(xié)作（溝通、傳遞、協(xié)調(diào)）會導(dǎo)致需求變形，那么我們就會：

• 統(tǒng)一需求接口，減少溝通節(jié)點；
• 按照產(chǎn)品職責(zé)來設(shè)置團(tuán)隊，讓市場、技術(shù)和消費者直接溝通，減少中間環(huán)節(jié)；
• 建立跨職能團(tuán)隊，避免部門政治給需求帶來的污染；
• 采用更直接、更簡潔、更高效的方式去溝通，減少信息失真；

如果我們認(rèn)識到，需求是具有時效性的，那么我們就會：

• 需求目標(biāo)定得盡可能小，因為目標(biāo)越大、驗證學(xué)習(xí)周期就會越長，失效的可能性更大；
• 時刻關(guān)注市場變化，隨時做好調(diào)整轉(zhuǎn)向準(zhǔn)備

所以，需求挑戰(zhàn)的應(yīng)對，不單單是IT團(tuán)隊負(fù)責(zé)需求的個人和團(tuán)隊的事，更是思維和文化、組織結(jié)構(gòu)、管理流程、領(lǐng)域洞見、溝通和協(xié)作能力等各個維度在各個層面的事。

4. 精益產(chǎn)品需求是什么

當(dāng)前，在諸多開始嘗試或已經(jīng)實施敏捷轉(zhuǎn)型的企業(yè)里，應(yīng)用最普遍的還是團(tuán)隊級的“敏捷開發(fā)方法“，有關(guān)需求的方法和實踐，如果濃縮下來，大概像這張圖：

圖5 當(dāng)前常用的“敏捷需求分析”

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

如果想要全面應(yīng)對這些需求挑戰(zhàn)，則需要應(yīng)用“精益企業(yè)”[4]的指導(dǎo)方法——把敏捷、精益的理念思維應(yīng)用在與需求有關(guān)的組織結(jié)構(gòu)、管理流程、領(lǐng)域洞見、溝通和協(xié)作能力等各個維度、各個層面。

另外，“傳統(tǒng)上，大多數(shù)企業(yè)秉承以范圍、成本和進(jìn)度為中心進(jìn)行交付管理，這使得所有人都迷失了，似乎項目交付就是目的，而忽視了投資本身的初衷所要達(dá)到的用戶和業(yè)務(wù)目標(biāo)，更談不上持續(xù)創(chuàng)新?，F(xiàn)代科技企業(yè)所面對的競爭環(huán)境越加激烈，用戶和市場的變化迅速，要能夠快速適應(yīng)變化，真正創(chuàng)造用戶喜愛的，有競爭力的產(chǎn)品，并持續(xù)創(chuàng)新，需要告別以往多年“以項目為中心”的管理，建立一種以產(chǎn)品為中心的軟件交付模式”[5]。要根據(jù)面向業(yè)務(wù)的能力來建立產(chǎn)品團(tuán)隊，在看待需求時從產(chǎn)品的全生命周期——產(chǎn)品的機會發(fā)現(xiàn)、定義、啟動上線、成長、成熟以及演化去看待和管理需求。

如果嘗試給“精益產(chǎn)品需求”下個定義，就是以“精益企業(yè)”為指導(dǎo)，以產(chǎn)品為中心，把敏捷、精益的理念應(yīng)用在產(chǎn)品全生命周期相關(guān)的組織結(jié)構(gòu)、管理流程、需求溝通和協(xié)作中的方法和實踐。

結(jié)合第2部分的常見需求挑戰(zhàn)，無非就是在組織層面應(yīng)用精益的思想和原則：

精益產(chǎn)品需求的目標(biāo)：

• 通過在組織、團(tuán)隊、個人層面的精益需求發(fā)現(xiàn)、管理、溝通和協(xié)作實踐，來提升組織的響應(yīng)力和創(chuàng)新力。

“精益產(chǎn)品需求”的原則：

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

圖6 精益產(chǎn)品需求的價值閉環(huán)

“精益產(chǎn)品需求”方法：

• 產(chǎn)品化方法，區(qū)分探索期和拓展期的工作方法

• 不同產(chǎn)品生命周期的關(guān)鍵方法：

圖7 產(chǎn)品的生命周期及關(guān)鍵方法

“精益產(chǎn)品需求”實踐和工具：

圖8 精益產(chǎn)品需求的實踐和工具舉例

以一家國外大型金融企業(yè)為例，他們實施了“以客戶為中心”的組織架構(gòu)重組，已實施敏捷轉(zhuǎn)型5年，想借用此次架構(gòu)重組來做到“精益產(chǎn)品化治理”，并解決“業(yè)務(wù)需求響應(yīng)力慢”的問題。 他們面臨的具體挑戰(zhàn)是：

• 經(jīng)過了幾十年的運營，IT系統(tǒng)非常復(fù)雜，僅客戶平臺這塊新老系統(tǒng)超過200個，相互緊耦合。
• 以項目團(tuán)隊進(jìn)行工作，項目之間相互依賴，經(jīng)常出現(xiàn)因為等待依賴而浪費大量的時間；
• 項目啟動基本上是瀑布方式，概念階段和啟動階段長達(dá)數(shù)月；
• 開發(fā)和運維分開，負(fù)責(zé)維護(hù)的團(tuán)隊覺得不被重視，長期士氣低落；

他們的改進(jìn)路線和應(yīng)用實踐如下：

圖9 XX金融企業(yè)的需求改進(jìn)路線

應(yīng)用實踐：

• “以面向業(yè)務(wù)的能力來構(gòu)建產(chǎn)品團(tuán)隊”，每個產(chǎn)品團(tuán)隊自己規(guī)劃自己的項目，以持續(xù)交付、持續(xù)驗證的方式來演進(jìn)自己的“能力”（如發(fā)展新產(chǎn)品，退役舊產(chǎn)品）；
• 每個產(chǎn)品團(tuán)隊設(shè)立Product Owner和Product Architect，按照“業(yè)務(wù)能力職責(zé)”，共同規(guī)劃自己產(chǎn)品體系的發(fā)展藍(lán)圖及運維支持；
• 持續(xù)的產(chǎn)品需求技能提升訓(xùn)練和實踐社區(qū)；
• 產(chǎn)品團(tuán)隊建立后，運維放到產(chǎn)品團(tuán)隊做了之后，發(fā)現(xiàn)總體人員規(guī)?？梢詼p少1/5 – 目前這1/5的人用來識別創(chuàng)新機會，在團(tuán)隊內(nèi)開展創(chuàng)新項目。

5. 寫在最后

很多企業(yè)當(dāng)面臨圖4中列出的需求問題時，第一時間想到的就是組織需求分析人員的技能培訓(xùn)，給他們制定一個工作流程，發(fā)給他們一個有著“先進(jìn)實踐”的Handbook，然后就期望這些需求問題都能迎刃而解。但這樣過了一年，發(fā)現(xiàn)好像沒什么變化，那些存在的問題還依然存在。

希望通過本文，大家能認(rèn)識到：在新的數(shù)字經(jīng)濟(jì)時代下，需求不確定性更強，挑戰(zhàn)來自于市場外部、組織內(nèi)部的結(jié)構(gòu)和管理、能力等多個方面。在實施轉(zhuǎn)型或改進(jìn)時，企業(yè)能以一個更系統(tǒng)的視角來看待，真正實現(xiàn)“精益的產(chǎn)品化治理”。

另一方面，從個人和團(tuán)隊來說，圖5所展示的“敏捷需求分析”方法和實踐依然適用，但應(yīng)該有兩個關(guān)鍵的轉(zhuǎn)變：

• 一是“產(chǎn)品思維”，“人人都是產(chǎn)品經(jīng)理”，認(rèn)識負(fù)責(zé)產(chǎn)品的生命期，根據(jù)不同的生命期取舍不同的需求實踐，全面掌握不同生命期的實踐方法；
• 二是“精益思維”，以業(yè)務(wù)成效來度量，對需求要有效做減法。

參考資料：

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

[2]：“敏捷方法簇”，指代Scrum、XP等為代表的輕量迭代開發(fā)方法。

[3]：肖然，”從敏捷轉(zhuǎn)型到精益企業(yè)”, http://insights.thoughtworkers.org/from-agile-transformation-to-lean-enterprise

[4]：《精益企業(yè)》. [^5]：姚安峰，“精益企業(yè)原則之：以產(chǎn)品為中心，而非交付項目”，http://www.infoq.com/cn/articles/the-principles-of-lean-enterprise-product-centric.

作者：亢江妹，ThoughtWorks的首席商業(yè)分析師、咨詢師，中國區(qū)行業(yè)研究團(tuán)隊的負(fù)責(zé)人，負(fù)責(zé)金融（銀行和保險）企業(yè)數(shù)字化轉(zhuǎn)型的研究，以及精益產(chǎn)品創(chuàng)新方法的咨詢。

本文由 @亢江妹?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。 亢江妹