01

在開始之前，先插播一段花絮：

公司競標拿下一個水泥廠項目，該水泥廠為響應號召，計劃在2023年底實現數字化轉型，需要采購一個管理平臺，來幫助企業更好地經營管理。

作為這個項目的產品負責人，我們應該怎么辦？

需求就一句話，很虛、很籠統。有同學說，別管那么多，先干起來，去客戶現場和客戶去溝通交流，先收集一波需求出個方案再說。

沒毛病！

和客戶確認方案無誤后，帶領項目團隊熱火朝天地投入到后續開發當中。

產品上線后，A用戶使用后發現產品不好用，不是我想要的，又提出了這樣那樣修改意見和新的需求；B用戶說，我想XXX，你們給加一個唄？

大的小的需求、意見，一天十幾條就夠你喝一壺了。響應慢了投訴你，尾款不結；積極響應，改吧，項目成員diss你，怎么做的項目管理，整體變變變，客戶說什么就是什么，沒一點主見...

這一幕熟不熟悉？眼不眼熟？每天都在發生著，有你有我，一個都不能少~

難不難？！

02

不論是B端項目還是C端項目，在項目實際開發過程中，都避免不了需求變更這個問題。今天蝸牛就來聊聊這個話題。

從項目的全生命周期來看，一個項目可以劃分這么幾個階段：

當前產品/項目開發模式不論是采用瀑布還是敏捷模式，整體流程是一樣的，區別在于迭代節奏和迭代目標。

從這個流程上可以看出，一旦項目進入開發階段，再進行項目變更代價是很大的，甚至是推倒重來。

在我剛開始做產品經理的那兩年，和很多朋友一樣，接到需求就是一頓操作：溝通需求、設計原型、方案評審、項目啟動、迭代上線。潛意識里認為需求就是對的，作為一個工具人很少去主動思考需求的真偽和全面性。

最近這幾年換到B端賽道后，發現這套工作方法有點行不通了。

03

首先，我們很難接觸到B端用戶和競品。這也是B端產品的一個特點，有很強的行業屬性，與企業業務強關聯。

其次，B端產品的業務很復雜，正常一個B端產品會有多個業務子系統、多個角色構成。

最后，我們應該明白一個事實：客戶是很難清晰、準確地說出他們的訴求。通常，我們在溝通需求的時候，他們更多地是站在自身角度給你反饋一些在以往工作中所遇到的問題，希望你幫他解決。

以流程工業水泥行業為例，水泥生產工藝流程是這樣的：

石料破碎及預均化--生料制備--生料均化--預熱分解--熟料燒成--水泥粉磨--水泥包裝

這條完整的生產線背后是有多個部門組成：安全部、環保部、生產部（爆破車間、生料車間、燒成車間、制成車間、包裝車間）、質量控制部、工藝部、維修部、電氣自動化部、采購部、財務部、銷售部等。

水泥廠有這么多工藝線、這么多部門、N多用戶，需要怎么做才能保證這個項目可以圓滿落地？

先別往下看，仔細想2分鐘。

04

直接說答案：問題出現在產品設計階段，需求管理沒有做好。

產品設計階段又可以細分為4個階段，如下圖所示。

前面花絮中，我們也做了市場調研、用戶訪談、demo設計和方案溝通，和客戶確認無誤才往下開展的啊？怎么上線后還有這么多要求，還不滿意呢？

問題的癥結在于用戶需求管理不到位。

這里就考驗我們的業務抽象能力。用戶的上一層是什么？角色。

什么是角色？角色是一群有共同需求的用戶，就是用戶集。

面對這么大一個平臺，如此復雜的業務場景，如此多的部門和用戶，先別急著畫原型。該怎么做呢？我是這么做的？

1、干系人管理。

這里的干系人是指水泥廠用戶。我是按照縱橫維度進行干系人管理。縱向上，劃分為高層、中層和基層干系人；橫向上，按照生產工藝線和部門建立干系人名單。

接著和相關干系人進行頻繁溝通，了解清楚干系人對這個項目的態度和期望目標。這個項目總投資過千萬，背后牽涉的利益很復雜，不同干系人對項目的態度和支持程度差別很大，可以說這一步很關鍵，一定要做好干系人管理。

2、角色管理

干系人是用戶代表，接下來需要按照業務抽象角色，這一步需要回答清楚這個平臺有幾個角色，各個角色是如何定義的？每個角色的期望是什么？他們有什么核心訴求？

這時候可以嘗試以用例圖來梳理。這里的角色務必要全，必須覆蓋到所有用戶，缺一不可。

進行需求設計時，我們就要先管理好產品的相關干系人，這里主要說的是企業角色。

3、選取典型用戶訪談，摸清業務流程

在搞定干系人并確定清楚平臺角色后，接下來就需要深入業務現場，摸清企業的業務流程、存在的問題/痛點。

在這一環節，前面的干系人管理好處就體現出來了。干系人會為你協調資源，安排人員和你對接溝通，在條件允許情況的下，最好深入到客戶現場。

4、組織跨部門溝通，敲定方案

在摸清各個角色的需求之后，有時候還需要召集各方一塊坐下來，整體過下方案，看看有沒有遺漏的、需要調整的。

05

這里有三個關鍵點：

1）原型demo：這里不要求高保真，目的只有一個：作為與客戶溝通的一個載體，能清晰表達彼此的理解即可，避免理解偏差

2）用戶故事：就一個原則：應收盡收。盡可能把所有角色用戶的需求收集過來。可以按照高層、中層和一線基層這種維度，也可以按照部門、工藝線這種方式，前提是覆蓋面要全。用戶故事也是后面所有迭代的輸入物，非常關鍵

3）用例圖：用例圖是幫助項目團隊梳理各個角色的業務關系，后面會和具體頁面關聯

在完成這一步之后，最大程度上保證了產品的主線業務不會跑偏，不至于做出一個用戶不認賬的產品，是能夠給企業帶來真正幫助的一個產品。

06

后面的概要設計、詳細設計和原型設計，還是需要我們不斷地和客戶溝通，但不會像前期那么頻繁了。

在這一階段，有2個關鍵點：

1）業務流程。它關系到產品各個系統、模塊、頁面之間的業務流轉和數據流轉。在這一步確認清楚之后，可以說這個產品的框架已經出來了，后面再變的只是表單內容和頁面布局、頁面交互這些展現層面的東西，這些不會傷筋動骨。

2）數據庫設計：這塊一般是由開發完成，產品只是打輔助。這塊經常出現的問題在于數據庫的擴展性。數據庫設計時考慮的不全面，后面客戶新增一個表單、字段都需要調整很多，很顯然這塊是不合格的，這是我們的基本工作沒有做好。

07

完成了這些工作之后，剩下的我們就熟悉了，原型設計-方案評審-客戶確認-開發-測試-交付部署-上線-驗收。

項目實際開發過程中頻繁發生需求變更，拋開商務關系沒到位這個因素，大概率是前期設計工作沒有做好。

嘮哩嘮叨的說了這么多，都是淚。就說這么多吧，寫PPT去了。

撒有哪啦

蝸牛丨6.2