作為一個初級產品經理，經常會遇到需求變更的情況，新手這個時候往往就會很崩潰。本文作者基于自己的工作經驗，提出了一點思考，希望對你有幫助。

01

項目開發(fā)，簡單來說，包含3個步驟：設計、執(zhí)行、驗收。

圍繞這3個步驟，我們一般會有2個樸素的愿望：

設計時，要考慮周全，安排妥帖。執(zhí)行時，要按照要求開發(fā)，按時按質按量落實。驗收時，要遍歷用例，把好關。

設計完成了，需求確認無誤了，不會再改了，再提交執(zhí)行。執(zhí)行完成了，按照要求全部落實了，自測沒有問題了，再提交驗收。

但是，愿望僅僅只是愿望，現實往往是另外一回事。

比如說，“敏捷開發(fā)”，大家說得很多了。它的思想，大家也都基本認同。

但是，現實中，能真正按照“敏捷開發(fā)”的要求去實施的團隊，卻非常少見。

不同的項目開發(fā)理論，雖然內容大不相同，但都包含了一種“分割”的思想。

“設計”確認無誤了，再執(zhí)行。開始“執(zhí)行”了，就不能再隨意修改設計了。

然而，在小廠的實踐中，情況往往不是這樣。

比較常見的情況是，“設計”環(huán)節(jié)不受限制地往后延伸。

“執(zhí)行”時，還在完善“設計”。甚至“驗收”時，都還在修改“設計”。

在需求還是曖昧不清的時候，產品經理可能就需要設計方案，然后不得不著急著開始執(zhí)行。

在執(zhí)行過程中，需求的內容可能才開始明朗。

甚至要到項目上線時，需求才算是“暫時”明確了。

這就導致，一個項目，在開發(fā)過程中，產品經理可能需要再補3、4個需求單，再發(fā)5、6個工作郵件，頻繁地進行方案調整。

02

有時候，技術同事會非常崩潰地對我說：“你們這次可得確定好?。∵@次改完，咱們能不能別再改了？”

對此，我也只能表示無能為力。因為這不是產品經理所能控制的。

為什么我們不能將“設計”和“執(zhí)行”進行分割，合理地安排項目開發(fā)？

相關的分析和吐槽，已經很多了，我就不再贅述。

這里我想強調的是，某種意義上講，這和初級產品經理沒有什么關系。

為什么呢？

能夠合理安排項目開發(fā)節(jié)奏的，只有少數有實力的大廠。大部分公司，或多或少都有些混亂。

如果公司想要改善這種情況，肯定需要領導來統(tǒng)籌。初級產品經理沒有能力，也沒有權力，去處理這樣的問題。

哪怕之后情況會逐步改善，也不可能說，我們先停下來，等情況變好了再開始推進項目。

如果有得選，那肯定是優(yōu)先選擇那些協(xié)作機制更合理的公司，沒必要給自己添堵。

但是，如果沒得選，那我建議，還是盡快“接受現實”為好。

我們當下，就是需要在這么一種混亂、不合理的機制下，開展我們的工作。

這是一個客觀存在的現實。

網上有很多相關的討論。比如說，國外先進的開發(fā)理念是怎樣的，如何重新打造公司的協(xié)作機制，要怎么進行組織變革，等等。

我覺得，至少對于初級產品經理來說，這些都是空談，沒有多少價值。

03

作為一名初級產品經理，我們可能會經常碰到需求變更的情況。

我認為，不管變更的原因是什么，作為一線的“執(zhí)行者”，初級產品經理在接到變更需求時，首先要關心的是“如何將之盡快落實”。

那么，面對需求變更，初級產品經理應該如何處理呢？

這里談談我個人的一些看法。

1. 過去的事情就讓它過去，不要扯皮，不要推諉

需求要變更，某種程度上講，意味著之前的做法存在“錯誤”。

出于自衛(wèi)心理，我們本能地會想要把鍋推出去：“之前是誰誰誰這么說的，怎么又要改了？”

我認為，這是沒有意義的，而且會顯得自己很沒有擔當。

當前最重要的是，明確需求是否確定要改，以及具體要怎么改。

任何一句推諉，都是在浪費時間。

哪怕之后有人需要為錯誤負責，哪怕那個人就是我自己，那也是之后的事情。

2. 快速回憶起，原來這么設計，是基于什么樣的場景、出于什么樣的原因

我們策劃時，雖不敢說“算無遺策”，但大部分的情況，都還是有考慮到的。

備選項被舍棄，是出于什么原因？

采用這個設計，是基于什么考慮？

這些，我們需要快速回憶起來。

一方面，如果領導問到了，我們能有個交代。

“我之前這樣設計，是有一定考量的，不是亂搞的?！?/p>

不該背的鍋，我們不要隨便亂背。

另一方面，這也有利于我們重新對需求進行評估。

原來是基于這樣的考慮做出的設計，現在要進行變更。

那么，是原來的邏輯有問題？還是現在的情況變了？

這些，都需要通盤考慮。

3. 確保自己理解新的需求內容，最好再三確認

需求方在說明新的需求內容時，要確保自己確實理解了對方的意思。

如果沒聽明白，直接表示不明白，讓對方復述一遍。

切忌囫圇吞棗、一知半解。

同時，要結合原先的需求設計，以及當前的開發(fā)情況，對有問題的地方一一確認。

最后，自己把需求復述一遍，確保沒有理解錯誤。

如果有需要另外確認的事項，一一列舉出來，標出相應的負責人，要落實到具體的個人。

需求變更，是一個很容易造成混亂的事情。我們要非常謹慎，不能慌亂。

4. 做好需求管理，安排好開發(fā)節(jié)奏

需求變更，有時候可能同時會有好幾個變更點。

這時候，需要產品經理結合需求的優(yōu)先級，以及當前的開發(fā)情況，合理安排。

比如說，需求方希望替換支付方式。而當前的情況是，正在使用的這個支付方式存在一點問題，正在處理。

表面上看，正好！原來的支付方式都不用改了，直接上新支付方式就行了。

其實不然。

如果直接上新支付方式，那就得等新的支付方式完全弄好了，才能重新上線。等待的時間比較長。

如果我們先把原來的支付方式快速改好，恢復上線。那么在開發(fā)新支付方式的時候，就能暫時先用著原來的支付，不至于長時間下架。

需要注意的是，改完一個需求點，要改下一個需求點時，最好重新與需求方確認。

因為很有可能，這個時候，情況又有了新變化。

5. 制定解決方案時，需要與技術團隊共同協(xié)商

因為項目已經開發(fā)了一半，有些東西可能已經做了，不好改了。

這個時候，要滿足新需求，哪些方案能做，哪些方案調整起來成本低一些，只有負責的程序員才清楚。

所以，需求變更的時候，產品經理尤其需要聽取技術團隊的聲音。制定解決方案時，需要與技術團隊共同協(xié)商。

6. 需求變更所需要的時間成本，需要與需求方和領導說明清楚

改需求，其實沒什么，畢竟大家就是來上班干活的嘛。

怕的是，既要改需求，又不能多給點時間，這就有些強人所難了。

產品經理向需求方和領導說明解決方案時，需要清楚說明該方案所需要的時間成本。

讓領導知悉，可能需要花費比預想中更多的時間，或者可能會占用其他項目的開發(fā)資源。

至于領導能不能多給點時間，那就是領導的事情了。

7. 每個需求點的緊急程度，需要清楚告知給團隊各成員

產品經理需要清楚告知團隊各成員，需求方和領導的意思是如何。

這個項目里面，哪些需求點是必須在某個時間節(jié)點內完成的，哪些可以適當延后。

如果某處碰到困難，無法解決，要及時切換到Plan B。

當前有幾個項目，如果撞在一起，先做哪個，后做哪個。

簡單說“需求很緊急”，是沒有意義的。

因為每個項目都是緊急的。

8. 后續(xù)的全部溝通，盡量在大群里面進行

有些人喜歡建小群，有問題在小群里面私下溝通解決。

我覺得這樣不對。

我覺得，建群，就要建大群，把相關領導都拉進來的那種。當然，涉及的所有人員，都要在里面。

所有溝通，都在大群里面進行。

這樣才能確保，所有人都能知悉當前的所有情況，降低溝通成本，避免遺漏。

04

我覺得，某種意義上講，“需求變更”，尤其是“緊急的需求變更”，是對初級產品經理的一次突擊考試。

因為它需要初級產品經理，在非常短的時候內，在非?；靵y的情況下，快速把握現狀，迅速制定方案，并馬上落實推進。

它是一場綜合性的考試，需要嚴肅對待。

作者：簡明產品論，個人公眾號：簡明產品論（ID：JianMingPM）

本文由 @簡明產品論 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

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