如何控制B端產品的需求邊界?

17 評論 12173 瀏覽 109 收藏 9 分鐘

碰到一味加需求的甲方爸爸,產品人需要學會拒絕,控制需求邊界,才能控制產品的上線時間,把握產品效能。

最近,隔壁項目組開發花了一個月,但是驗收卻花了兩個多月的項目遲遲沒有上線。

和他們開發一聊才知道,每次他們拿著測試版產品去到客戶那邊驗收,客戶總會提出一大堆問題或者新的需求,他們只能回來繼續改——繼續去客戶那驗收——繼續回來改,如此循環。而且,當產品和測試從客戶那帶回新需求時,開發越來越“絕望”,代碼出現的Bug也越來越多。

于是,我意識到一個重要概念,那就是需求邊界。

需求邊界的概念是指在一個明確的項目或產品版本中,需求的數量和范圍可控;不在外力的驅使下隨意改動或增加需求,知道該做什么,不該做什么。

我們做的B端產品,在工作中一般會分為兩種:一種是平臺化Saas產品,即標準化產品;一種是外包型產品,也叫外包項目,定制化產品。

一般來說,公司外部的需求較難控制,不可預測的情況容易發生。因此,外包項目更需要做需求邊界的控制。

需求邊界的重要性

可以想想,如果B端產品經理沒有需要邊界的概念,會發生什么情況?

  • 首先,在任何階段對客戶的需求來者不拒,肆意擴大邊界范圍,那么將導致項目遲遲無法交付上線;
  • 其次,在開發階段,需求依然充滿變數,團隊將產生疲憊抗拒心理,對團隊士氣是”致命“的;
  • 最后,對公司來說,階段性驗收形同虛設,無法交付就沒有項目尾款,最終造成項目虧損。

而需求邊界的好處就是明確階段性工作的方向和重點,對排期和進度更好把控,這樣就能避免出現上述“災難性”的問題。

那么如果可以控制需求邊界呢?

通過總結,我認為可以通過三個層面控制。

需求層面

我們需要有個認知,在業務方面,我們的客戶是專家,他們一定是有需要沒有得到滿足,所以希望我們提供解決方案。我們無法根據業務技能去識別產品需求,只有使用對象才能決定需求邊界的范圍和深度。

當對需求還沒有認知時,最好的辦法就是深入業務場景,通過調研、仿真、模擬,建立對需求理解的一致性,這樣使我們能想象最終的產品形態是什么樣的。

再從結果倒推出需求邊界,清晰界定自己的邊界,以及需要遵守的邊界。畢竟客戶只是需要解決問題,而如何解決,功能如何呈現,還是靠產品經理決定。

項目層面

1. 規范流程控制邊界

“需求從來不是靠過程中的控制來實現,一旦想控制‘進行中的邊界’,都會讓你處于一種極為不利的境地”。

這句話我非常認同,當出現邊界不可控,需求無線蔓延的狀況,最主要的原因就是沒有在項目開始之前梳理一個基本的規范。如果不在項目開始時就建立起規范的機制和流程,盲目依靠自己在過程中的包容性,只會越深入越困難。

一件事開始要做的時候,也就是項目開始的時候,一切都是“一派祥和”,無論是客戶還是團隊都是最好說話的時候。那么就,要抓住這最好的時機,建立整個項目過程中必須遵守的規則和流程。

做外包項目時,我們都需要進行階段性的驗收。其中一個重要的里程碑就是需求邊界確定,我們向客戶交付的原型和UI設計稿就劃定了我們本次開發的需求邊界??蛻艨陬^說Ok后,我們還需要通過一封正式的確認郵件,白紙黑字就是我們以后拒絕擴大需求邊界的武器。

2. 確定需求凍結時間

當產品/項目有了明確的上線或交付時間,就需要在確認需求郵件后開需求評審會,開發會評估需求的問題點以及實現難度。

評估結果出來之后,我們再去調整版本規劃表的需求劃分。例如,有些需求這個版本不能實現的,就下移到下一個版本;有些需求壓根不能實現的,就直接刪除;有些需求實現難度太大的,就可以直接放到待定版本需求里面去。

當排期敲定之后,我們的需求就凍結了,我們向外界傳達出一個訊息就是,這一版本我們就做這些工作,不會增加新的需求,也是對開發負責任的態度。

如何控制B端產品的需求邊界

商務層面

1. 落實合同和驗收標準

不管是Saas還是外包,如何和客戶簽訂了合同,合同中明確了項目范疇和交付時間,也是需求邊界的一道墻;明確了項目解決方案,任何超出邊界的需求都可以拒絕。

比如,我們給線下親子門店設計線上預約和購買會員解決方案,那么如果客戶在之后想增加電商功能,我們是可以以合同約定的內容給予拒絕。

如果是合同范圍內的修改需求要求,說實話,有時候我們做不了主是否修改需求,畢竟面對金主爸爸。因此我們可以重新評估需求的變動成本,提供更簡單的解決方案或合理的拒絕理由給到客戶或領導,讓他們做出決策。

2. 轉移決策壓力程控制邊界

學會拒絕是個好方法,但是有的需求無法拒絕,我們就需要給出充足的理由。比如,提出需求池的概念,告訴客戶,這一版本我們的目標是完成什么主要功能,剛提出來的新需求我們會維護在需求池中,在下一版本中進行規劃。

如果客戶依然覺得新增需求是合理的,那么我們就將決策的壓力轉移到客戶身上。給客戶說明利害關系,是要盡快上線,慢慢優化,還是不停加需求無限期開發下去。

勢必要增加新需求,那么費用和時間成本也需要重新評估。為了保證能順利交付上線,遵守需求邊界的約定,新需求規劃到下一版本當是上上策。

如若還拒絕不了時,要學會向領導借力,將需求邊界被打破,無法控制的情況說明清楚,最終決策權在領導手中。

總結

需求邊界對產品規劃的重要性不用多說,而如何控制邊界,需從需求、項目到商務層面層層把握,通常還需要經歷多次教訓,慢慢領悟。當

需求蔓延的后果銘記于心時,自然更有魄力控制需求邊界,堅持不讓產品需求處于不可控的地步。

 

作者:晴天;微信公眾號:impm6666

本文由 @晴天 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 面向B端用戶使用的產品,技術團隊中如果沒有一個非常熟悉傳統業務的產品經理,技術再好,也會改到你哭的。

    來自新疆 回復
  2. 確定項目邊界比確定產品邊界更重要(你提到的是甲方)

    來自浙江 回復
  3. 做起來難!業務方自己對需求沒有清晰認知,產品出來落地難,試行困難,只能修改。

    回復
  4. 自己開公司,你就不這么想了。在利潤面前,只能跪下

    回復
    1. 需求無邊界,哪里來利潤?

      回復
    2. 外包也可能是人力外包,只管做項目,按投入人力算錢,這樣不必太糾結需求變動

      回復
  5. 越發覺得產品經理崗位是塊狗皮膏藥,哪里需要貼哪里。

    回復
    1. 哈哈哈 這個是!

      來自浙江 回復
  6. 還是有一點理想化。主要看甲乙雙方的談判地位如何。如果甲方是大客戶,你得罪不起,人家的臨時需求,乃至超邊界需求你還是會去滿足?,F實就是這樣。

    回復
  7. 能做到這樣還得自身公司的產品流程是規范的,對輸出的原型、UI設計圖是有自信的,目前來說能達到這種實力的公司團隊太少了

    來自江蘇 回復
  8. 需求若是真到領導那里了,十有八九是給他做

    來自中國 回復
    1. 還真是

      回復
  9. 有必要對公司商務、銷售等崗位加強業務邊界的培訓,從一開始的招標書就劃定邊界,就怕什么都敢往里面寫,后面產品經理和項目經理就很被動了。

    來自浙江 回復
    1. 點贊????

      回復
  10. 感覺是瀑布式研發流程

    來自江蘇 回復
  11. 道理都懂,做起難啊。其實往往產品、項目經理能抗住,上面的領導,市場部的提前投降。

    來自四川 回復
    1. 他們要賺錢,只要能接單就行。畢竟他們只負責簽單

      回復