碰到一味加需求的甲方爸爸，產(chǎn)品人需要學(xué)會拒絕，控制需求邊界，才能控制產(chǎn)品的上線時間，把握產(chǎn)品效能。

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

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

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

需求邊界的概念是指在一個明確的項目或產(chǎn)品版本中，需求的數(shù)量和范圍可控；不在外力的驅(qū)使下隨意改動或增加需求，知道該做什么，不該做什么。

我們做的B端產(chǎn)品，在工作中一般會分為兩種：一種是平臺化Saas產(chǎn)品，即標(biāo)準(zhǔn)化產(chǎn)品；一種是外包型產(chǎn)品，也叫外包項目，定制化產(chǎn)品。

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

需求邊界的重要性

可以想想，如果B端產(chǎn)品經(jīng)理沒有需要邊界的概念，會發(fā)生什么情況？

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

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

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

通過總結(jié)，我認(rèn)為可以通過三個層面控制。

需求層面

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

當(dāng)對需求還沒有認(rèn)知時，最好的辦法就是深入業(yè)務(wù)場景，通過調(diào)研、仿真、模擬，建立對需求理解的一致性，這樣使我們能想象最終的產(chǎn)品形態(tài)是什么樣的。

再從結(jié)果倒推出需求邊界，清晰界定自己的邊界，以及需要遵守的邊界。畢竟客戶只是需要解決問題，而如何解決，功能如何呈現(xiàn)，還是靠產(chǎn)品經(jīng)理決定。

項目層面

1. 規(guī)范流程控制邊界

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

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

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

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

2. 確定需求凍結(jié)時間

當(dāng)產(chǎn)品/項目有了明確的上線或交付時間，就需要在確認(rèn)需求郵件后開需求評審會，開發(fā)會評估需求的問題點以及實現(xiàn)難度。

評估結(jié)果出來之后，我們再去調(diào)整版本規(guī)劃表的需求劃分。例如，有些需求這個版本不能實現(xiàn)的，就下移到下一個版本；有些需求壓根不能實現(xiàn)的，就直接刪除；有些需求實現(xiàn)難度太大的，就可以直接放到待定版本需求里面去。

當(dāng)排期敲定之后，我們的需求就凍結(jié)了，我們向外界傳達(dá)出一個訊息就是，這一版本我們就做這些工作，不會增加新的需求，也是對開發(fā)負(fù)責(zé)任的態(tài)度。

商務(wù)層面

1. 落實合同和驗收標(biāo)準(zhǔn)

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

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

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

2. 轉(zhuǎn)移決策壓力程控制邊界

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

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

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

如若還拒絕不了時，要學(xué)會向領(lǐng)導(dǎo)借力，將需求邊界被打破，無法控制的情況說明清楚，最終決策權(quán)在領(lǐng)導(dǎo)手中。

總結(jié)

需求邊界對產(chǎn)品規(guī)劃的重要性不用多說，而如何控制邊界，需從需求、項目到商務(wù)層面層層把握，通常還需要經(jīng)歷多次教訓(xùn)，慢慢領(lǐng)悟。當(dāng)

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

作者：晴天；微信公眾號：impm6666

本文由 @晴天 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議