復(fù)雜商業(yè)模式下,B端如何進(jìn)行需求管理(上)
B端需求管理,無(wú)論是乙方對(duì)甲方的需求,還是甲方自己的需求,如何做到高效管理,是這幾年來(lái)大家都在熱議的話題。如果說(shuō)2019年前大家都在追求需求交付的“快速”,那么2019年以來(lái),需求管理的趨勢(shì)就是追求需求質(zhì)量的提升,追求交付的“準(zhǔn)確”。
B端需求管理之所以長(zhǎng)久以來(lái)是BA、產(chǎn)品經(jīng)理的心頭之痛,就在于它的復(fù)雜性,利益相關(guān)方、流程、場(chǎng)景、使用者、銷售過(guò)程……等等,本文分為兩個(gè)部分,分別講解如何通過(guò)針對(duì)性的管理措施,提升需求交付的速度和準(zhǔn)確度。
Epic/Feature/Story/Task需求四層劃分是目前一些銀行的需求管理辦法。但已經(jīng)有客戶反饋說(shuō),并沒(méi)有感覺(jué)到交付速度提升,還向我咨詢,你有沒(méi)有一些案例,來(lái)證明這么做可以提升研發(fā)效能?
作為這套方案的構(gòu)建者,我只能說(shuō)需求四層劃分其實(shí)是當(dāng)年做的一個(gè)臨時(shí)解決方案,現(xiàn)在看起來(lái)很別扭,但在當(dāng)年的那個(gè)場(chǎng)景下,這么做是解決當(dāng)年的問(wèn)題的。
臨時(shí)解決方案能不能作為“標(biāo)準(zhǔn)品”,就要還原當(dāng)時(shí)的場(chǎng)景,看看企業(yè)真要這么來(lái)管理需求,是不是亂用方子。
Epic/Feature/Story/Task是怎么來(lái)的?
一句話講明白:就是整合解決方案和商業(yè)系統(tǒng),專門(mén)為客制化IT系統(tǒng)開(kāi)發(fā)服務(wù)的,這是個(gè)什么樣的場(chǎng)景呢?
某國(guó)內(nèi)的頂尖企業(yè),是一家以產(chǎn)品為核心能力的公司,它的內(nèi)部商業(yè)系統(tǒng)供應(yīng)商、客戶群,都是世界級(jí)的領(lǐng)先企業(yè)。
其客戶A,有自己的內(nèi)部系統(tǒng)A’,企業(yè)買(mǎi)了大廠的商業(yè)系統(tǒng)B,作為內(nèi)部IT系統(tǒng),然后B不完全滿足企業(yè)自己的內(nèi)部需求,因此開(kā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’,于是問(wèn)題來(lái)了,如何把客戶A對(duì)企業(yè)產(chǎn)品的需求,轉(zhuǎn)化為行業(yè)共性的解決方案,又如何把這個(gè)解決方案,層層轉(zhuǎn)化為對(duì)B’及最終系統(tǒng)B的客制化開(kāi)發(fā)任務(wù)?另外,如何在同一個(gè)客制化系統(tǒng)中分清內(nèi)部IT需求和外部客戶需求?
下圖灰色區(qū)域,代表開(kāi)發(fā)不可控,綠色區(qū)域,代表增值服務(wù)中的客制化開(kāi)發(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):
- 解決方案跟隨對(duì)客戶的產(chǎn)品及服務(wù)銷售合同到達(dá),承諾范圍廣,需求規(guī)模大,通常是面向某系列產(chǎn)品的完整業(yè)務(wù)的IT支撐。
- 內(nèi)部技術(shù)可行性評(píng)估要一直深達(dá)B商業(yè)產(chǎn)品,耗時(shí)長(zhǎng)、涉眾廣,最后壓縮開(kāi)發(fā)周期,犧牲交付質(zhì)量。
- 客戶A、B…多做了幾個(gè)直到N后,發(fā)現(xiàn)大量相似、重復(fù)工作,B’系統(tǒng)嚴(yán)重腐化,小改動(dòng)引發(fā)大量回歸測(cè)試工作量,且線上事件量爆增。
- 以解決方案為中心的開(kāi)發(fā)模式,由于每個(gè)解決方案領(lǐng)域及分析師固定,每個(gè)版本周期需求量都會(huì)變化,導(dǎo)致研發(fā)不停地挪動(dòng)開(kāi)發(fā)人員,每個(gè)版本都要“重組”一次,解決方案分析師反復(fù)交接需求,如果沒(méi)在版本前期確認(rèn)完成,轉(zhuǎn)眼就被工作量確定的另一個(gè)領(lǐng)域“奪走”了之前交接的開(kāi)發(fā)資源,再次重新評(píng)估……反復(fù)折騰……人仰馬翻……
這種情況下,就需要一種更好的需求組織模式,來(lái)分門(mén)別類地處理各項(xiàng)事務(wù)。
- 第一,將解決方案拆解為專題管理,縮小規(guī)模。適用的拆解方式有基于業(yè)務(wù)類別的、業(yè)務(wù)問(wèn)題的、業(yè)務(wù)場(chǎng)景的、業(yè)務(wù)流程的,總之,不能再直接把銷售合同轉(zhuǎn)為解決方案工作包。拆解之后的解決方案專題,要更充分考慮客戶所在的行業(yè)普適性,從業(yè)務(wù)層面降低開(kāi)發(fā)工作量。
- 第二,解決方案專題對(duì)B系統(tǒng)的開(kāi)發(fā)需求,識(shí)別為待開(kāi)發(fā)特性,用于評(píng)估B系統(tǒng)客制化之后對(duì)各種其它外圍系統(tǒng)的影響。
- 第三,針對(duì)B’系統(tǒng)開(kāi)發(fā)團(tuán)隊(duì)作為內(nèi)部IT,用戶感知弱、體驗(yàn)設(shè)計(jì)能力不足的情況,使用用戶旅程、用戶故事等方法,增強(qiáng)開(kāi)發(fā)團(tuán)隊(duì)對(duì)客戶使用場(chǎng)景的理解,提升B’系統(tǒng)面向客戶交付的正確性和易用性體驗(yàn)。
- 最后,B’系統(tǒng)架設(shè)到B系統(tǒng)的客制化工作量依然巨大,拆解為任務(wù),以更好地管理開(kāi)發(fā)進(jìn)度。
特性比專題更小,目的是為了在特性團(tuán)隊(duì)內(nèi)部獨(dú)立完成開(kāi)發(fā)。這樣,通過(guò)建立穩(wěn)定、產(chǎn)能近似的特性團(tuán)隊(duì),自主評(píng)估每個(gè)迭代的容量,由解決方案分析師協(xié)調(diào)特性分配,而不用跨團(tuán)隊(duì)轉(zhuǎn)移調(diào)配開(kāi)發(fā)人員,減少了資源協(xié)調(diào)時(shí)間,極大地提升了需求交接的效率。
從這里我們可以看到,需求管理的模式,需要針對(duì)組織具體的問(wèn)題,提供針對(duì)性的管理辦法。Epic/Feature/Story/Task的目的,不是為了將需求層層分解,而是處理不同視角、共性與特殊性、內(nèi)外并存、定制化開(kāi)發(fā)與商業(yè)系統(tǒng)運(yùn)行升級(jí)的矛盾。
需求拆分又是為了啥?
也用一句話講明白:就是提升可管理性,包括計(jì)劃、執(zhí)行和監(jiān)控。小任務(wù)更容易跟蹤工作量,從而提升需求交付的速度,降低交付的風(fēng)險(xiǎn)。
需求過(guò)大,不容易在任務(wù)接收時(shí)完全理解和評(píng)估,導(dǎo)致進(jìn)度不透明,每天都在做,但實(shí)際上無(wú)進(jìn)展、風(fēng)險(xiǎn)不能及時(shí)暴露,等到最后迭代快完了,功能一跑才發(fā)現(xiàn)業(yè)務(wù)理解都有問(wèn)題,漏做、錯(cuò)做,不要太多。
很多客戶都在問(wèn):需求如何拆分?拆分到什么粒度算合理?
答案就是:現(xiàn)在你的看板上卡片每天有進(jìn)展嗎?能看見(jiàn)進(jìn)度嗎?團(tuán)隊(duì)成員在早會(huì)上是含糊地報(bào)進(jìn)度數(shù)字,還是有真實(shí)的代碼產(chǎn)出提交上來(lái)了?沒(méi)有的話,就拆分一下了。
如果你不能拆分,你就無(wú)法高效執(zhí)行,因?yàn)槟銓?duì)待辦需求的理解是不透徹的,對(duì)如何做是不清楚的。只是領(lǐng)一個(gè)需求的符號(hào)然后回到座位上慢慢摸索,效率怎么能高起來(lái)?
對(duì)管理者而言,這其實(shí)是管理中一個(gè)基本的常識(shí):日清日結(jié)。
總結(jié):需求管理之交付速度
從這個(gè)案例我們可以學(xué)習(xí)到,組織的交付響應(yīng)力和速度的來(lái)源,就是一套合適的組織模式,把待辦事項(xiàng)、資源用最有效的方法、最合適的節(jié)奏組織起來(lái),打造一個(gè)以任務(wù)為中心的組織。既不是一昧地追求“拆成多小”、“拆多少”,也不是一定要搞成“迭代開(kāi)發(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í),必須要問(wèn)的問(wèn)題。下一篇,我們將講一講需求交付的準(zhǔn)確度如何通過(guò)需求管理來(lái)改進(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)載
題圖來(lái)自Unsplash,基于CC0協(xié)議
啥也沒(méi)有講清楚。