需求蔓延應該是產品日常工作中經常遇到的問題，尤其是B端項目制產品。雖然說具體問題具體分析，但是也有一些共性的問題、互通的方法能夠對需求蔓延產生一些合理的處置效果，一起來看看吧

三個月前我總結了一篇如何對待需求變更的文章，其中提到控制變更和控制蔓延有很多類似的方法，但兩者又有實質性的區別，所以今天將以需求蔓延為切入點整理產品研發、交付過程中需要面對和解決的難題。

首先我們把產品研發過程、項目交付過程區分開，因為不同的項目性質，蔓延產生的原因和應對策略也不盡相同。

產品研發過程更適用於自研產品，每個版本的需求都是自己提的。

當然需求來源會很多，比如領導的指示、用戶的反饋、市場的動態、競品的追趕等等，每個版本疊代之前，產品團隊會在這一大汪需求池中撈出一些優先級高的，作為本次疊代的核心內容。

項目交付過程則更適用於「標準化產品」對客的「定製化交付」，需求是客戶提的，我們要在有限的時間內完成這些需求內容。

而且在項目啟動前期還要經歷多階段的售前交流、商務搓談，最終項目中標後根據招標文件中的主體內容進行詳細的需求拆解和解決方案產出。

當然有些疊代優化項目不會有前期這麼複雜的過程，但本質是類似的。

雖然項目構成和合作關係不同，但我們在項目初期的需求分析階段，勢必要面對需求蔓延的問題。以下內容我會以項目交付過程的蔓延為主。

畢竟作為乙方在面對各種甲方項目時產生的蔓延場景更複雜，影響也更大。

01、為什麼會出現需求蔓延

1、原有範圍存在無法閉環的業務場景

這是最直接的原因，原來的方案有漏洞，而雙方都沒有及時察覺，在真正進行需求分析時發現了。為了解決這個業務問題，自然而然需要增加新的功能、新的規則

2、客戶想花小錢辦大事

這個問題我是切身遇到過，後來復盤時突然發現，當初從售前階段開始，就被客戶牽著鼻子給套路了。

甲方通過一些模稜兩可的要求先把乙方招進來，在正式實施時再提出各種各樣的特色化場景和訴求。

如果你碰到了這類客戶，那只能：自求多福~

3、為了拿標而做的過度承諾

這類原因也比較常見，畢竟在售前階段為了拿標，做出一些超綱的許諾為自己增加中標的可能性。

中了才有解決的可能性，不中一切都是0。

4、對甲方的偏好或政策要求了解不夠

不同的客戶在管理政策、實施政策上的要求也是不一致的。

比如同樣的產品在A客戶實施需要50個人月，在B客戶實施之前，功能範圍是一致的，但是實施時發現B有一套全局的業務規範要求，而這些業務規範的適配，需要額外增加10人月的工作量，這種需求蔓延即不好拒絕，又無法為平台帶來新的場景積累。

真的是「食之無味，卻絕不能棄」

5、售前階段雙方對部分功能的認知偏差

我遇到過一個很實際的例子，在售前階段我們對「數據遷移」功能的理解，甲乙雙方是不一致的，但是沒有人發現，大家都在按照自己的思路溝通。

結果中標後在需求分析階段發現，我們理解的「數據遷移」只是自己平台內部的用戶數據。而客戶理解的是多個舊系統的數據遷移和業務承接，兩者在工作量上相差十幾個人月。

因此我們不得不面對這個極大的需求蔓延問題，最終通過團隊幾個月高強度加班才解決。

6、關聯方的調研不足

現在很少有完全獨立的系統建設，平台的構建，都需要和多個關聯方進行對接、交互。而這也增加了需求的不可控性。

畢竟誰也不知道這些關聯方是否可以滿足我們的對接要求，甚至於對方是否願意配合我們。如果關聯方不滿足我們的對接要求，則針對實際場景的改造就需要大家一起商討一個新的解決方案，而且在此過程，還可能會引申出更多的不可控因素。

因此在正式實施開始之前，這些未知的因素都可能導致後續的需求蔓延。

7、新政策或新市場的對齊

每個項目交付都有一定的周期性，尤其是涉及到面對流程較複雜的甲方。從提出需求，到走完售前流程可能已經過去了很久。

此時市場上的新政策、新動態都可能會對原有的需求產生較大的衝擊。

02、怎樣看待需求蔓延

首先，蔓延幾乎不可避免，我們要做好充足的心理準備。

我遇到過很多需求人員，或者項目經理，要麼在對方剛提出就煩躁崩潰，要麼在商討解決方案和應對策略時聒噪不安。當然這也包括我自己~

需求蔓延控制不好所產生的後果不言而喻。

輕則增加交付工作量，造成團隊高強度加班、項目延期，項目成本不可控；重則因為蔓延的改造導致方案不完善，交付質量難以保證，從而產生嚴重的生產事故，對團隊、對公司、對客戶都會產生難以挽回的影響。

蔓延的需求，也可以反哺到產品中。

需求蔓延也不全都是弊端，從產品成熟度的角度來看，面對不同的客戶訴求，產生不同的應用場景，本身對產品的疊代發展也有補充。即便是無法歸併到產品標準版的特色化需求，也能提高我們在這個領域的業務經驗。

雖然說具體問題具體分析，但是也有一些共性的問題、互通的方法能夠對蔓延產生一些合理的處置效果，讓我們一起來看看吧。

03、如何應對需求蔓延

1、情緒上要先接納

客觀應對，不要被負面情緒影響。因為人都是感性的動物，當我們被情緒影響之後，會做出很多不可控的錯誤決定。而且也許原本在客觀條件下能夠解決的問題，帶上情緒之後也就很難解決了。

而後基於不同的原因，再採取不同的策略。

2、打鐵還需自身硬

很多蔓延的產生，都是因為產品本身的不完善，業務上的不專業，或是甲方的「偽需求」沒有及時辨別，或是在對客的引導上有欠缺，或是客戶對你的信任度不足。

所以說「打鐵還需自身硬」，通過自己的專業性快速獲得對方的信任，並在對方提出一些漫無邊際的想法時，能夠敏銳的覺察並適當引導，這些都是對我們極大的考驗。

當我們無法在第一時間控制住需求的蔓延時，那就儘快收拾心情，看看如何快速應對吧。

3、先解決首要目標，再梳理次要目標

蔓延出來的功能也有優先級，關鍵性問題（比如政策影響，比如MVP閉環缺失，比如不做會造成嚴重的生產事故等等）優先解決，非關鍵性問題是否可以往後安排？

而且每個功能在實施時都有多種解決方案，對於非關鍵場景的蔓延需求，我們也可以採用相對簡單的實現方式，當然這些要基於我們對業務、流程的熟練程度，才能分析出更優的解決方案

4、商討需求置換的可能性

比如蔓延的需求工作量為100人天，我們可以在原始合同中找一些80人天左右的非關鍵功能，進行置換。當然如果你可以置換出120人天的功能，那我願奉你為最強~

5、會哭的孩子有奶吃

非正式溝通時向客戶訴苦（前提是有一定的信任關係），起碼讓客戶從感情上認可我們多出來的工作量，最不濟也能為後期的合作賺點感情加成。

找領導訴苦，當無法控制變更時，儘量爭取更多的資源來配合按時交付。

假如你不說，那就抗著唄~

6、可以借力打力

比如靠自己已經搞不定了，那是否可以藉助領導或其他部門的力量旁敲側擊？

或者客戶A始終堅持要這樣做，我們是否可以通過客戶A的領導、或者A的關聯部門來配合，闡述其中的難點與風險等等，從而逐漸達成目標。

不要陷入思維怪圈，「曲線救國」也是救呀。

7、做好信息的及時同步

和領導同步，和項目組同步，和客戶同步。定期、高頻匯報因為蔓延將產生的風險，匯報我們的解決方案，匯報整體進度等等。而且一定要

留痕！留痕！留痕！

8、避免費力不討好

很多時候，我們加班加點把超綱的範圍做完了，但是由於進度、質量、或者完整性等問題，依然得不到客戶的認可。

或者當客戶的不滿傳到公司、傳到領導耳邊，也很可能得不到內部的認可。這時我們也會自我懷疑，更會覺得付出不值得。

所以我們要有一定的預知能力，在做之前做好心理準備，同時提前和客戶、公司保持及時的溝通和匯報。

就算最後接鍋，幾個人一起接，總比一個人接好一點。這雖然有「五十步笑百步」之嫌，但是類似的問題誰能保證不會發生在自己身上呢？

9、爭取攢個新需求

和領導一起，配合商務同事，看看是否可以把一些工作量確實很大，或者確實和原始需求關聯度不高的蔓延攢一個新的優化合同提上來。

這樣團隊既有新的合同額，工期又能適當往後緩一緩。但前提是我們要對這些需求有充足的理解，別在實踐的過程中被人問住了，屆時尷尬的可不僅僅是自己。

04、怎樣儘量避免蔓延的產生

1、售前階段與客戶的目標、過程，努力對齊

通過一次次的售前交流，儘量使得客戶與我們對於產品/項目的場景、關鍵流程達成一致，這樣客戶才能預先把自己的想法說出來，而不是等到需求分析階段再恍然大悟，然後發現和自己想的不一樣。

但是這一點很難，本身售前階段面對不同類型的客戶關係和客戶性格，很難做到目標對齊。但是不能因為難就不去做，前期多做一點點，後期可能會規避一個很大的坑。

之前我遇到過在售前交流階段，無意中捕捉到甲方科技人員的一段話，發現涉及到我們關聯方的對接方案在這裡不適用，所以針對此問題又做了兩次深入探討。

最終甲方不僅認可了我們的實施方案，還在招標範圍和工作量評估中做了一定程度的讓步，從而為這個項目的如期交付提前掃清了一個很大的障礙。

2、售前到實施之間的交接要把握關鍵

今年上半年，針對我們售前和實施兩個階段之間交接所遇到的問題，制定了交接規範。在交接規範中提到了一定要將這些內容和實施團隊的負責人、需求分析人員寫清楚、講清楚。

我們不僅不要打無準備的仗，更要打知己知彼準備充足的仗。

• 比如曾經許諾過的功能是什麼，為什麼，可以怎麼做；
• 比如售前所預知的需求蔓延風險可能有哪些；
• 甲方的交付管理要求有哪些
• 關聯方配合意願情況是否存在風險等等內容；

後續的文章中我會單獨進行總結。

通過售前與實施之間規範的交接及信息同步，讓交付團隊在面對需求蔓延時有充足的準備。

3、讓產品或方案更完善

一個成熟的產品或者成熟的方案，幾乎把客戶想到的問題都解決了，那也就不會存在需求蔓延的問題。

當然了，這種情況太理想化了。

可是這卻是我們產品人要為之奮鬥的目標，如果我們都沒有這樣的信念和決心，那這個產品勢必不會走的長遠。

05、產品研發過程的需求蔓延

最後簡單分析一下自研產品中的需求蔓延問題，其實很多方式方法和上面的內容有相通之處。

因為我們的需求池是來自於各方角色，因此每個版本中的需求合理性，或衝突性，或完整性是不太好保障的。

而且即便是自研產品，也要對客負責、對交付團隊負責、對市場負責，版本發布的節點也不能總是改來改去。

所以產品團隊針對需求池的維護、篩選、以及每個疊代版本內容的完整性分析，都是至關重要的。

如果很多問題都是在開發做的時候才發現了功能缺失，臨時修改不僅要面臨加班、發版延期的風險，還可能無法構建完整的解決方案，發布之後的未知問題會對後續工作產生長遠影響。

而且這些問題，則需要產品團隊、研發團隊、銷售團隊、交付團隊、運營團隊等多方好好battle一波。在這個過程中，產品團隊難免會成為大家集體PUA的對象。

畢竟，是我們在提需求的時候沒有分析清楚哇

06、寫在最後

一旦涉及到和人打交道，就充滿了變數。有限的文字終究不能覆蓋無限的場景。希望今天的總結能夠為有幸看到的你帶來一點點幫助。及時總結，適度復盤，在實踐中不斷嘗試新的方法，才能探索出一條適合自己的前行之路。

昨天的經驗不一定適用於今天的問題，今天的收穫不一定能面對明天的變化。但我們要堅信，自己所面對的困難沒有解決不了的。

ps：以上內容全部基於自身的經驗和經歷，觀點是否適用還請各位認真辨別

作者：不想延期，公眾號：不想延期

本文由 @不想延期 原創發布於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議。

該文觀點僅代表作者本人，人人都是產品經理平台僅提供信息存儲空間服務。