如何控制B端產品的需求邊界?
碰到一味加需求的甲方爸爸,產品人需要學會拒絕,控制需求邊界,才能控制產品的上線時間,把握產品效能。
最近,隔壁項目組開發花了一個月,但是驗收卻花了兩個多月的項目遲遲沒有上線。
和他們開發一聊才知道,每次他們拿著測試版產品去到客戶那邊驗收,客戶總會提出一大堆問題或者新的需求,他們只能回來繼續改——繼續去客戶那驗收——繼續回來改,如此循環。而且,當產品和測試從客戶那帶回新需求時,開發越來越“絕望”,代碼出現的Bug也越來越多。
于是,我意識到一個重要概念,那就是需求邊界。
需求邊界的概念是指在一個明確的項目或產品版本中,需求的數量和范圍可控;不在外力的驅使下隨意改動或增加需求,知道該做什么,不該做什么。
我們做的B端產品,在工作中一般會分為兩種:一種是平臺化Saas產品,即標準化產品;一種是外包型產品,也叫外包項目,定制化產品。
一般來說,公司外部的需求較難控制,不可預測的情況容易發生。因此,外包項目更需要做需求邊界的控制。
需求邊界的重要性
可以想想,如果B端產品經理沒有需要邊界的概念,會發生什么情況?
- 首先,在任何階段對客戶的需求來者不拒,肆意擴大邊界范圍,那么將導致項目遲遲無法交付上線;
- 其次,在開發階段,需求依然充滿變數,團隊將產生疲憊抗拒心理,對團隊士氣是”致命“的;
- 最后,對公司來說,階段性驗收形同虛設,無法交付就沒有項目尾款,最終造成項目虧損。
而需求邊界的好處就是明確階段性工作的方向和重點,對排期和進度更好把控,這樣就能避免出現上述“災難性”的問題。
那么如果可以控制需求邊界呢?
通過總結,我認為可以通過三個層面控制。
需求層面
我們需要有個認知,在業務方面,我們的客戶是專家,他們一定是有需要沒有得到滿足,所以希望我們提供解決方案。我們無法根據業務技能去識別產品需求,只有使用對象才能決定需求邊界的范圍和深度。
當對需求還沒有認知時,最好的辦法就是深入業務場景,通過調研、仿真、模擬,建立對需求理解的一致性,這樣使我們能想象最終的產品形態是什么樣的。
再從結果倒推出需求邊界,清晰界定自己的邊界,以及需要遵守的邊界。畢竟客戶只是需要解決問題,而如何解決,功能如何呈現,還是靠產品經理決定。
項目層面
1. 規范流程控制邊界
“需求從來不是靠過程中的控制來實現,一旦想控制‘進行中的邊界’,都會讓你處于一種極為不利的境地”。
這句話我非常認同,當出現邊界不可控,需求無線蔓延的狀況,最主要的原因就是沒有在項目開始之前梳理一個基本的規范。如果不在項目開始時就建立起規范的機制和流程,盲目依靠自己在過程中的包容性,只會越深入越困難。
一件事開始要做的時候,也就是項目開始的時候,一切都是“一派祥和”,無論是客戶還是團隊都是最好說話的時候。那么就,要抓住這最好的時機,建立整個項目過程中必須遵守的規則和流程。
做外包項目時,我們都需要進行階段性的驗收。其中一個重要的里程碑就是需求邊界確定,我們向客戶交付的原型和UI設計稿就劃定了我們本次開發的需求邊界??蛻艨陬^說Ok后,我們還需要通過一封正式的確認郵件,白紙黑字就是我們以后拒絕擴大需求邊界的武器。
2. 確定需求凍結時間
當產品/項目有了明確的上線或交付時間,就需要在確認需求郵件后開需求評審會,開發會評估需求的問題點以及實現難度。
評估結果出來之后,我們再去調整版本規劃表的需求劃分。例如,有些需求這個版本不能實現的,就下移到下一個版本;有些需求壓根不能實現的,就直接刪除;有些需求實現難度太大的,就可以直接放到待定版本需求里面去。
當排期敲定之后,我們的需求就凍結了,我們向外界傳達出一個訊息就是,這一版本我們就做這些工作,不會增加新的需求,也是對開發負責任的態度。
商務層面
1. 落實合同和驗收標準
不管是Saas還是外包,如何和客戶簽訂了合同,合同中明確了項目范疇和交付時間,也是需求邊界的一道墻;明確了項目解決方案,任何超出邊界的需求都可以拒絕。
比如,我們給線下親子門店設計線上預約和購買會員解決方案,那么如果客戶在之后想增加電商功能,我們是可以以合同約定的內容給予拒絕。
如果是合同范圍內的修改需求要求,說實話,有時候我們做不了主是否修改需求,畢竟面對金主爸爸。因此我們可以重新評估需求的變動成本,提供更簡單的解決方案或合理的拒絕理由給到客戶或領導,讓他們做出決策。
2. 轉移決策壓力程控制邊界
學會拒絕是個好方法,但是有的需求無法拒絕,我們就需要給出充足的理由。比如,提出需求池的概念,告訴客戶,這一版本我們的目標是完成什么主要功能,剛提出來的新需求我們會維護在需求池中,在下一版本中進行規劃。
如果客戶依然覺得新增需求是合理的,那么我們就將決策的壓力轉移到客戶身上。給客戶說明利害關系,是要盡快上線,慢慢優化,還是不停加需求無限期開發下去。
勢必要增加新需求,那么費用和時間成本也需要重新評估。為了保證能順利交付上線,遵守需求邊界的約定,新需求規劃到下一版本當是上上策。
如若還拒絕不了時,要學會向領導借力,將需求邊界被打破,無法控制的情況說明清楚,最終決策權在領導手中。
總結
需求邊界對產品規劃的重要性不用多說,而如何控制邊界,需從需求、項目到商務層面層層把握,通常還需要經歷多次教訓,慢慢領悟。當
需求蔓延的后果銘記于心時,自然更有魄力控制需求邊界,堅持不讓產品需求處于不可控的地步。
作者:晴天;微信公眾號:impm6666
本文由 @晴天 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
面向B端用戶使用的產品,技術團隊中如果沒有一個非常熟悉傳統業務的產品經理,技術再好,也會改到你哭的。
確定項目邊界比確定產品邊界更重要(你提到的是甲方)
做起來難!業務方自己對需求沒有清晰認知,產品出來落地難,試行困難,只能修改。
自己開公司,你就不這么想了。在利潤面前,只能跪下
需求無邊界,哪里來利潤?
外包也可能是人力外包,只管做項目,按投入人力算錢,這樣不必太糾結需求變動
越發覺得產品經理崗位是塊狗皮膏藥,哪里需要貼哪里。
哈哈哈 這個是!
還是有一點理想化。主要看甲乙雙方的談判地位如何。如果甲方是大客戶,你得罪不起,人家的臨時需求,乃至超邊界需求你還是會去滿足?,F實就是這樣。
能做到這樣還得自身公司的產品流程是規范的,對輸出的原型、UI設計圖是有自信的,目前來說能達到這種實力的公司團隊太少了
需求若是真到領導那里了,十有八九是給他做
還真是
有必要對公司商務、銷售等崗位加強業務邊界的培訓,從一開始的招標書就劃定邊界,就怕什么都敢往里面寫,后面產品經理和項目經理就很被動了。
點贊????
感覺是瀑布式研發流程
道理都懂,做起難啊。其實往往產品、項目經理能抗住,上面的領導,市場部的提前投降。
他們要賺錢,只要能接單就行。畢竟他們只負責簽單