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

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

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

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

臨時(shí)解決方案能不能作為“標(biāo)準(zhǔn)品”，就要還原當(dāng)時(shí)的場(chǎng)景，看看企業(yè)真要這么來管理需求，是不是亂用方子。

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

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

某國內(nèi)的頂尖企業(yè)，是一家以產(chǎn)品為核心能力的公司，它的內(nèi)部商業(yè)系統(tǒng)供應(yīng)商、客戶群，都是世界級(jí)的領(lǐ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’。

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

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

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

需求管理難點(diǎn)：

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

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

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

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

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

需求拆分又是為了啥？

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

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

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

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

如果你不能拆分，你就無法高效執(zhí)行，因?yàn)槟銓?duì)待辦需求的理解是不透徹的，對(duì)如何做是不清楚的。只是領(lǐng)一個(gè)需求的符號(hào)然后回到座位上慢慢摸索，效率怎么能高起來？

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

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

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

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

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

在什么樣的場(chǎng)景下，是我們提出或采用某個(gè)具體解決措施時(shí)，必須要問的問題。下一篇，我們將講一講需求交付的準(zhǔn)確度如何通過需求管理來改進(jìn)。

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

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

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