B端需求管理，無論是乙方對甲方的需求，還是甲方自己的需求，如何做到高效管理，是這幾年來大家都在熱議的話題。如果說2019年前大家都在追求需求交付的“快速”，那么2019年以來，需求管理的趨勢就是追求需求質(zhì)量的提升，追求交付的“準確”。

B端需求管理之所以長久以來是BA、產(chǎn)品經(jīng)理的心頭之痛，就在于它的復雜性，利益相關方、流程、場景、使用者、銷售過程……等等，本文分為兩個部分，分別講解如何通過針對性的管理措施，提升需求交付的速度和準確度。

Epic/Feature/Story/Task需求四層劃分是目前一些銀行的需求管理辦法。但已經(jīng)有客戶反饋說，并沒有感覺到交付速度提升，還向我咨詢，你有沒有一些案例，來證明這么做可以提升研發(fā)效能？

作為這套方案的構(gòu)建者，我只能說需求四層劃分其實是當年做的一個臨時解決方案，現(xiàn)在看起來很別扭，但在當年的那個場景下，這么做是解決當年的問題的。

臨時解決方案能不能作為“標準品”，就要還原當時的場景，看看企業(yè)真要這么來管理需求，是不是亂用方子。

Epic/Feature/Story/Task是怎么來的？

一句話講明白：就是整合解決方案和商業(yè)系統(tǒng)，專門為客制化IT系統(tǒng)開發(fā)服務的，這是個什么樣的場景呢？

某國內(nèi)的頂尖企業(yè)，是一家以產(chǎn)品為核心能力的公司，它的內(nèi)部商業(yè)系統(tǒng)供應商、客戶群，都是世界級的領先企業(yè)。

其客戶A，有自己的內(nèi)部系統(tǒng)A’，企業(yè)買了大廠的商業(yè)系統(tǒng)B，作為內(nèi)部IT系統(tǒng)，然后B不完全滿足企業(yè)自己的內(nèi)部需求，因此開發(fā)了內(nèi)部系統(tǒng)B’。

隨著時代的演進，IT突然成了增值服務，企業(yè)對客戶A，在一套解決方案中有了打通A’B’內(nèi)部系統(tǒng)以更快完成產(chǎn)品交付的需求，并且這個需求也是可收費的服務。很明顯，客戶A并不想改動A’，于是問題來了，如何把客戶A對企業(yè)產(chǎn)品的需求，轉(zhuǎn)化為行業(yè)共性的解決方案，又如何把這個解決方案，層層轉(zhuǎn)化為對B’及最終系統(tǒng)B的客制化開發(fā)任務？另外，如何在同一個客制化系統(tǒng)中分清內(nèi)部IT需求和外部客戶需求？

下圖灰色區(qū)域，代表開發(fā)不可控，綠色區(qū)域，代表增值服務中的客制化開發(fā)。在企業(yè)現(xiàn)行的解決方案、版本需求文檔、設計文檔的模式下，節(jié)奏混亂、緩慢。

解決方案層面痛點：需要對客戶承諾交付周期，但內(nèi)部IT項目及B商業(yè)產(chǎn)品實施復雜，且與內(nèi)部IT需求交織在一起，管理困難。

需求管理難點：

1. 解決方案跟隨對客戶的產(chǎn)品及服務銷售合同到達，承諾范圍廣，需求規(guī)模大，通常是面向某系列產(chǎn)品的完整業(yè)務的IT支撐。
2. 內(nèi)部技術可行性評估要一直深達B商業(yè)產(chǎn)品，耗時長、涉眾廣，最后壓縮開發(fā)周期，犧牲交付質(zhì)量。
3. 客戶A、B…多做了幾個直到N后，發(fā)現(xiàn)大量相似、重復工作，B’系統(tǒng)嚴重腐化，小改動引發(fā)大量回歸測試工作量，且線上事件量爆增。
4. 以解決方案為中心的開發(fā)模式，由于每個解決方案領域及分析師固定，每個版本周期需求量都會變化，導致研發(fā)不停地挪動開發(fā)人員，每個版本都要“重組”一次，解決方案分析師反復交接需求，如果沒在版本前期確認完成，轉(zhuǎn)眼就被工作量確定的另一個領域“奪走”了之前交接的開發(fā)資源，再次重新評估……反復折騰……人仰馬翻……

這種情況下，就需要一種更好的需求組織模式，來分門別類地處理各項事務。

• 第一，將解決方案拆解為專題管理，縮小規(guī)模。適用的拆解方式有基于業(yè)務類別的、業(yè)務問題的、業(yè)務場景的、業(yè)務流程的，總之，不能再直接把銷售合同轉(zhuǎn)為解決方案工作包。拆解之后的解決方案專題，要更充分考慮客戶所在的行業(yè)普適性，從業(yè)務層面降低開發(fā)工作量。
• 第二，解決方案專題對B系統(tǒng)的開發(fā)需求，識別為待開發(fā)特性，用于評估B系統(tǒng)客制化之后對各種其它外圍系統(tǒng)的影響。
• 第三，針對B’系統(tǒng)開發(fā)團隊作為內(nèi)部IT，用戶感知弱、體驗設計能力不足的情況，使用用戶旅程、用戶故事等方法，增強開發(fā)團隊對客戶使用場景的理解，提升B’系統(tǒng)面向客戶交付的正確性和易用性體驗。
• 最后，B’系統(tǒng)架設到B系統(tǒng)的客制化工作量依然巨大，拆解為任務，以更好地管理開發(fā)進度。

特性比專題更小，目的是為了在特性團隊內(nèi)部獨立完成開發(fā)。這樣，通過建立穩(wěn)定、產(chǎn)能近似的特性團隊，自主評估每個迭代的容量，由解決方案分析師協(xié)調(diào)特性分配，而不用跨團隊轉(zhuǎn)移調(diào)配開發(fā)人員，減少了資源協(xié)調(diào)時間，極大地提升了需求交接的效率。

從這里我們可以看到，需求管理的模式，需要針對組織具體的問題，提供針對性的管理辦法。Epic/Feature/Story/Task的目的，不是為了將需求層層分解，而是處理不同視角、共性與特殊性、內(nèi)外并存、定制化開發(fā)與商業(yè)系統(tǒng)運行升級的矛盾。

需求拆分又是為了啥？

也用一句話講明白：就是提升可管理性，包括計劃、執(zhí)行和監(jiān)控。小任務更容易跟蹤工作量，從而提升需求交付的速度，降低交付的風險。

需求過大，不容易在任務接收時完全理解和評估，導致進度不透明，每天都在做，但實際上無進展、風險不能及時暴露，等到最后迭代快完了，功能一跑才發(fā)現(xiàn)業(yè)務理解都有問題，漏做、錯做，不要太多。

很多客戶都在問：需求如何拆分？拆分到什么粒度算合理？

答案就是：現(xiàn)在你的看板上卡片每天有進展嗎？能看見進度嗎？團隊成員在早會上是含糊地報進度數(shù)字，還是有真實的代碼產(chǎn)出提交上來了？沒有的話，就拆分一下了。

如果你不能拆分，你就無法高效執(zhí)行，因為你對待辦需求的理解是不透徹的，對如何做是不清楚的。只是領一個需求的符號然后回到座位上慢慢摸索，效率怎么能高起來？

對管理者而言，這其實是管理中一個基本的常識：日清日結(jié)。

總結(jié)：需求管理之交付速度

從這個案例我們可以學習到，組織的交付響應力和速度的來源，就是一套合適的組織模式，把待辦事項、資源用最有效的方法、最合適的節(jié)奏組織起來，打造一個以任務為中心的組織。既不是一昧地追求“拆成多小”、“拆多少”，也不是一定要搞成“迭代開發(fā)”。

?而需求是什么呢？需求管理本質(zhì)是企業(yè)滿足市場、滿足客戶最重要的達成企業(yè)目標的手段。所以，對需求的管理，使用一種合適的結(jié)構(gòu)化需求的模式，事實上就是一種組織內(nèi)部任務的分解、協(xié)同、完成銷售目標的關鍵手段。

B端需求管理的挑戰(zhàn)，就在于數(shù)字化世界在不斷的內(nèi)外延伸，許多業(yè)務形態(tài)、模式都發(fā)生了變化，把挑戰(zhàn)落到了以前并不承擔這種挑戰(zhàn)的內(nèi)部IT團隊身上。關于企業(yè)內(nèi)部能力與效率提升，就不在此文討論范圍內(nèi)了，有興趣可以參考我的前一篇文章《B端：少談產(chǎn)品方法論，多看企業(yè)效率本質(zhì)》。

在什么樣的場景下，是我們提出或采用某個具體解決措施時，必須要問的問題。下一篇，我們將講一講需求交付的準確度如何通過需求管理來改進。

作者：陳加興，場量科技創(chuàng)始人，資深敏捷精益專家，精益企業(yè)認證產(chǎn)品概念領導者，微信號：one-oracle。

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

題圖來自Unsplash，基于CC0協(xié)議