01
在開始之前,先插播一段花絮:
公司競標(biāo)拿下一個(gè)水泥廠項(xiàng)目,該水泥廠為響應(yīng)號召,計(jì)劃在2023年底實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型,需要采購一個(gè)管理平臺(tái),來幫助企業(yè)更好地經(jīng)營管理。
作為這個(gè)項(xiàng)目的產(chǎn)品負(fù)責(zé)人,我們應(yīng)該怎么辦?
需求就一句話,很虛、很籠統(tǒng)。有同學(xué)說,別管那么多,先干起來,去客戶現(xiàn)場和客戶去溝通交流,先收集一波需求出個(gè)方案再說。
沒毛病!
和客戶確認(rèn)方案無誤后,帶領(lǐng)項(xiàng)目團(tuán)隊(duì)熱火朝天地投入到后續(xù)開發(fā)當(dāng)中。
產(chǎn)品上線后,A用戶使用后發(fā)現(xiàn)產(chǎn)品不好用,不是我想要的,又提出了這樣那樣修改意見和新的需求;B用戶說,我想XXX,你們給加一個(gè)唄?
大的小的需求、意見,一天十幾條就夠你喝一壺了。響應(yīng)慢了投訴你,尾款不結(jié);積極響應(yīng),改吧,項(xiàng)目成員diss你,怎么做的項(xiàng)目管理,整體變變變,客戶說什么就是什么,沒一點(diǎn)主見...
這一幕熟不熟悉?眼不眼熟?每天都在發(fā)生著,有你有我,一個(gè)都不能少~
難不難?!
02
不論是B端項(xiàng)目還是C端項(xiàng)目,在項(xiàng)目實(shí)際開發(fā)過程中,都避免不了需求變更這個(gè)問題。今天蝸牛就來聊聊這個(gè)話題。
從項(xiàng)目的全生命周期來看,一個(gè)項(xiàng)目可以劃分這么幾個(gè)階段:

當(dāng)前產(chǎn)品/項(xiàng)目開發(fā)模式不論是采用瀑布還是敏捷模式,整體流程是一樣的,區(qū)別在于迭代節(jié)奏和迭代目標(biāo)。
從這個(gè)流程上可以看出,一旦項(xiàng)目進(jìn)入開發(fā)階段,再進(jìn)行項(xiàng)目變更代價(jià)是很大的,甚至是推倒重來。
在我剛開始做產(chǎn)品經(jīng)理的那兩年,和很多朋友一樣,接到需求就是一頓操作:溝通需求、設(shè)計(jì)原型、方案評審、項(xiàng)目啟動(dòng)、迭代上線。潛意識里認(rèn)為需求就是對的,作為一個(gè)工具人很少去主動(dòng)思考需求的真?zhèn)魏腿嫘浴?/p>
最近這幾年換到B端賽道后,發(fā)現(xiàn)這套工作方法有點(diǎn)行不通了。
03
首先,我們很難接觸到B端用戶和競品。這也是B端產(chǎn)品的一個(gè)特點(diǎn),有很強(qiáng)的行業(yè)屬性,與企業(yè)業(yè)務(wù)強(qiáng)關(guān)聯(lián)。
其次,B端產(chǎn)品的業(yè)務(wù)很復(fù)雜,正常一個(gè)B端產(chǎn)品會(huì)有多個(gè)業(yè)務(wù)子系統(tǒng)、多個(gè)角色構(gòu)成。
最后,我們應(yīng)該明白一個(gè)事實(shí):客戶是很難清晰、準(zhǔn)確地說出他們的訴求。通常,我們在溝通需求的時(shí)候,他們更多地是站在自身角度給你反饋一些在以往工作中所遇到的問題,希望你幫他解決。
以流程工業(yè)水泥行業(yè)為例,水泥生產(chǎn)工藝流程是這樣的:
石料破碎及預(yù)均化--生料制備--生料均化--預(yù)熱分解--熟料燒成--水泥粉磨--水泥包裝
這條完整的生產(chǎn)線背后是有多個(gè)部門組成:安全部、環(huán)保部、生產(chǎn)部(爆破車間、生料車間、燒成車間、制成車間、包裝車間)、質(zhì)量控制部、工藝部、維修部、電氣自動(dòng)化部、采購部、財(cái)務(wù)部、銷售部等。
水泥廠有這么多工藝線、這么多部門、N多用戶,需要怎么做才能保證這個(gè)項(xiàng)目可以圓滿落地?
先別往下看,仔細(xì)想2分鐘。
04
直接說答案:問題出現(xiàn)在產(chǎn)品設(shè)計(jì)階段,需求管理沒有做好。
產(chǎn)品設(shè)計(jì)階段又可以細(xì)分為4個(gè)階段,如下圖所示。

前面花絮中,我們也做了市場調(diào)研、用戶訪談、demo設(shè)計(jì)和方案溝通,和客戶確認(rèn)無誤才往下開展的???怎么上線后還有這么多要求,還不滿意呢?
問題的癥結(jié)在于用戶需求管理不到位。
這里就考驗(yàn)我們的業(yè)務(wù)抽象能力。用戶的上一層是什么?角色。
什么是角色?角色是一群有共同需求的用戶,就是用戶集。
面對這么大一個(gè)平臺(tái),如此復(fù)雜的業(yè)務(wù)場景,如此多的部門和用戶,先別急著畫原型。該怎么做呢?我是這么做的?
1、干系人管理。
這里的干系人是指水泥廠用戶。我是按照縱橫維度進(jìn)行干系人管理??v向上,劃分為高層、中層和基層干系人;橫向上,按照生產(chǎn)工藝線和部門建立干系人名單。
接著和相關(guān)干系人進(jìn)行頻繁溝通,了解清楚干系人對這個(gè)項(xiàng)目的態(tài)度和期望目標(biāo)。這個(gè)項(xiàng)目總投資過千萬,背后牽涉的利益很復(fù)雜,不同干系人對項(xiàng)目的態(tài)度和支持程度差別很大,可以說這一步很關(guān)鍵,一定要做好干系人管理。
2、角色管理
干系人是用戶代表,接下來需要按照業(yè)務(wù)抽象角色,這一步需要回答清楚這個(gè)平臺(tái)有幾個(gè)角色,各個(gè)角色是如何定義的?每個(gè)角色的期望是什么?他們有什么核心訴求?
這時(shí)候可以嘗試以用例圖來梳理。這里的角色務(wù)必要全,必須覆蓋到所有用戶,缺一不可。
進(jìn)行需求設(shè)計(jì)時(shí),我們就要先管理好產(chǎn)品的相關(guān)干系人,這里主要說的是企業(yè)角色。
3、選取典型用戶訪談,摸清業(yè)務(wù)流程
在搞定干系人并確定清楚平臺(tái)角色后,接下來就需要深入業(yè)務(wù)現(xiàn)場,摸清企業(yè)的業(yè)務(wù)流程、存在的問題/痛點(diǎn)。
在這一環(huán)節(jié),前面的干系人管理好處就體現(xiàn)出來了。干系人會(huì)為你協(xié)調(diào)資源,安排人員和你對接溝通,在條件允許情況的下,最好深入到客戶現(xiàn)場。
4、組織跨部門溝通,敲定方案
在摸清各個(gè)角色的需求之后,有時(shí)候還需要召集各方一塊坐下來,整體過下方案,看看有沒有遺漏的、需要調(diào)整的。
05
這里有三個(gè)關(guān)鍵點(diǎn):
1)原型demo:這里不要求高保真,目的只有一個(gè):作為與客戶溝通的一個(gè)載體,能清晰表達(dá)彼此的理解即可,避免理解偏差
2)用戶故事:就一個(gè)原則:應(yīng)收盡收。盡可能把所有角色用戶的需求收集過來??梢园凑崭邔印⒅袑雍鸵痪€基層這種維度,也可以按照部門、工藝線這種方式,前提是覆蓋面要全。用戶故事也是后面所有迭代的輸入物,非常關(guān)鍵
3)用例圖:用例圖是幫助項(xiàng)目團(tuán)隊(duì)梳理各個(gè)角色的業(yè)務(wù)關(guān)系,后面會(huì)和具體頁面關(guān)聯(lián)
在完成這一步之后,最大程度上保證了產(chǎn)品的主線業(yè)務(wù)不會(huì)跑偏,不至于做出一個(gè)用戶不認(rèn)賬的產(chǎn)品,是能夠給企業(yè)帶來真正幫助的一個(gè)產(chǎn)品。
06
后面的概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)和原型設(shè)計(jì),還是需要我們不斷地和客戶溝通,但不會(huì)像前期那么頻繁了。
在這一階段,有2個(gè)關(guān)鍵點(diǎn):
1)業(yè)務(wù)流程。它關(guān)系到產(chǎn)品各個(gè)系統(tǒng)、模塊、頁面之間的業(yè)務(wù)流轉(zhuǎn)和數(shù)據(jù)流轉(zhuǎn)。在這一步確認(rèn)清楚之后,可以說這個(gè)產(chǎn)品的框架已經(jīng)出來了,后面再變的只是表單內(nèi)容和頁面布局、頁面交互這些展現(xiàn)層面的東西,這些不會(huì)傷筋動(dòng)骨。
2)數(shù)據(jù)庫設(shè)計(jì):這塊一般是由開發(fā)完成,產(chǎn)品只是打輔助。這塊經(jīng)常出現(xiàn)的問題在于數(shù)據(jù)庫的擴(kuò)展性。數(shù)據(jù)庫設(shè)計(jì)時(shí)考慮的不全面,后面客戶新增一個(gè)表單、字段都需要調(diào)整很多,很顯然這塊是不合格的,這是我們的基本工作沒有做好。
07
完成了這些工作之后,剩下的我們就熟悉了,原型設(shè)計(jì)-方案評審-客戶確認(rèn)-開發(fā)-測試-交付部署-上線-驗(yàn)收。
項(xiàng)目實(shí)際開發(fā)過程中頻繁發(fā)生需求變更,拋開商務(wù)關(guān)系沒到位這個(gè)因素,大概率是前期設(shè)計(jì)工作沒有做好。
嘮哩嘮叨的說了這么多,都是淚。就說這么多吧,寫PPT去了。
撒有哪啦
蝸牛丨6.2