起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識需求變更時，初級產品經理應該關心的是如何盡快落實
作為一個初級產品經理，經常會遇到需求變更的情況，新手這個時候往往就會很崩潰。本文作者基于自己的工作經驗，提出了一點思考，希望對你有幫助。
01
項目開發(fā)，簡單來說，包含3個步驟：設計、執(zhí)行、驗收。
圍繞這3個步驟，我們一般會有2個樸素的愿望：
設計時，要考慮周全，安排妥帖。執(zhí)行時，要按照要求開發(fā)，按時按質按量落實。驗收時，要遍歷用例，把好關。
設計完成了，需求確認無誤了，不會再改了，再提交執(zhí)行。執(zhí)行完成了，按照要求全部落實了，自測沒有問題了，再提交驗收。
但是，愿望僅僅只是愿望，現(xiàn)實往往是另外一回事。
比如說，“敏捷開發(fā)”，大家說得很多了。它的思想，大家也都基本認同。
但是，現(xiàn)實中，能真正按照“敏捷開發(fā)”的要求去實施的團隊，卻非常少見。
不同的項目開發(fā)理論，雖然內容大不相同，但都包含了一種“分割”的思想。
“設計”確認無誤了，再執(zhí)行。開始“執(zhí)行”了，就不能再隨意修改設計了。
然而，在小廠的實踐中，情況往往不是這樣。
比較常見的情況是，“設計”環(huán)節(jié)不受限制地往后延伸。
“執(zhí)行”時，還在完善“設計”。甚至“驗收”時，都還在修改“設計”。
在需求還是曖昧不清的時候，產品經理可能就需要設計方案，然后不得不著急著開始執(zhí)行。
在執(zhí)行過程中，需求的內容可能才開始明朗。
甚至要到項目上線時，需求才算是“暫時”明確了。
這就導致，一個項目，在開發(fā)過程中，產品經理可能需要再補3、4個需求單，再發(fā)5、6個工作郵件，頻繁地進行方案調整。
02
有時候，技術同事會非常崩潰地對我說：“你們這次可得確定好??！這次改完，咱們能不能別再改了？”
對此，我也只能表示無能為力。因為這不是產品經理所能控制的。
為什么我們不能將“設計”和“執(zhí)行”進行分割，合理地安排項目開發(fā)？
相關的分析和吐槽，已經很多了，我就不再贅述。
這里我想強調的是，某種意義上講，這和初級產品經理沒有什么關系。
為什么呢？
能夠合理安排項目開發(fā)節(jié)奏的，只有少數(shù)有實力的大廠。大部分公司，或多或少都有些混亂。
如果公司想要改善這種情況，肯定需要領導來統(tǒng)籌。初級產品經理沒有能力，也沒有權力，去處理這樣的問題。
哪怕之后情況會逐步改善，也不可能說，我們先停下來，等情況變好了再開始推進項目。
如果有得選，那肯定是優(yōu)先選擇那些協(xié)作機制更合理的公司，沒必要給自己添堵。
但是，如果沒得選，那我建議，還是盡快“接受現(xiàn)實”為好。
我們當下，就是需要在這么一種混亂、不合理的機制下，開展我們的工作。
這是一個客觀存在的現(xiàn)實。
網上有很多相關的討論。比如說，國外先進的開發(fā)理念是怎樣的，如何重新打造公司的協(xié)作機制，要怎么進行組織變革，等等。
我覺得，至少對于初級產品經理來說，這些都是空談，沒有多少價值。
03
作為一名初級產品經理，我們可能會經常碰到需求變更的情況。
我認為，不管變更的原因是什么，作為一線的“執(zhí)行者”，初級產品經理在接到變更需求時，首先要關心的是“如何將之盡快落實”。
那么，面對需求變更，初級產品經理應該如何處理呢？
這里談談我個人的一些看法。
1. 過去的事情就讓它過去，不要扯皮，不要推諉
需求要變更，某種程度上講，意味著之前的做法存在“錯誤”。
出于自衛(wèi)心理，我們本能地會想要把鍋推出去：“之前是誰誰誰這么說的，怎么又要改了？”
我認為，這是沒有意義的，而且會顯得自己很沒有擔當。
當前最重要的是，明確需求是否確定要改，以及具體要怎么改。
任何一句推諉，都是在浪費時間。
哪怕之后有人需要為錯誤負責，哪怕那個人就是我自己，那也是之后的事情。
2. 快速回憶起，原來這么設計，是基于什么樣的場景、出于什么樣的原因
我們策劃時，雖不敢說“算無遺策”，但大部分的情況，都還是有考慮到的。
備選項被舍棄，是出于什么原因？
采用這個設計，是基于什么考慮？
這些，我們需要快速回憶起來。
一方面，如果領導問到了，我們能有個交代。
“我之前這樣設計，是有一定考量的，不是亂搞的。”
不該背的鍋，我們不要隨便亂背。
另一方面，這也有利于我們重新對需求進行評估。
原來是基于這樣的考慮做出的設計，現(xiàn)在要進行變更。
那么，是原來的邏輯有問題？還是現(xiàn)在的情況變了？
這些，都需要通盤考慮。
3. 確保自己理解新的需求內容，最好再三確認
需求方在說明新的需求內容時，要確保自己確實理解了對方的意思。
如果沒聽明白，直接表示不明白，讓對方復述一遍。
切忌囫圇吞棗、一知半解。
同時，要結合原先的需求設計，以及當前的開發(fā)情況，對有問題的地方一一確認。
最后，自己把需求復述一遍，確保沒有理解錯誤。
如果有需要另外確認的事項，一一列舉出來，標出相應的負責人，要落實到具體的個人。
需求變更，是一個很容易造成混亂的事情。我們要非常謹慎，不能慌亂。
4. 做好需求管理，安排好開發(fā)節(jié)奏
需求變更，有時候可能同時會有好幾個變更點。
這時候，需要產品經理結合需求的優(yōu)先級，以及當前的開發(fā)情況，合理安排。
比如說，需求方希望替換支付方式。而當前的情況是，正在使用的這個支付方式存在一點問題，正在處理。
表面上看，正好！原來的支付方式都不用改了，直接上新支付方式就行了。
其實不然。
如果直接上新支付方式，那就得等新的支付方式完全弄好了，才能重新上線。等待的時間比較長。
如果我們先把原來的支付方式快速改好，恢復上線。那么在開發(fā)新支付方式的時候，就能暫時先用著原來的支付，不至于長時間下架。
需要注意的是，改完一個需求點，要改下一個需求點時，最好重新與需求方確認。
因為很有可能，這個時候，情況又有了新變化。
5. 制定解決方案時，需要與技術團隊共同協(xié)商
因為項目已經開發(fā)了一半，有些東西可能已經做了，不好改了。
這個時候，要滿足新需求，哪些方案能做，哪些方案調整起來成本低一些，只有負責的程序員才清楚。
所以，需求變更的時候，產品經理尤其需要聽取技術團隊的聲音。制定解決方案時，需要與技術團隊共同協(xié)商。
6. 需求變更所需要的時間成本，需要與需求方和領導說明清楚
改需求，其實沒什么，畢竟大家就是來上班干活的嘛。
怕的是，既要改需求，又不能多給點時間，這就有些強人所難了。
產品經理向需求方和領導說明解決方案時，需要清楚說明該方案所需要的時間成本。
讓領導知悉，可能需要花費比預想中更多的時間，或者可能會占用其他項目的開發(fā)資源。
至于領導能不能多給點時間，那就是領導的事情了。
7. 每個需求點的緊急程度，需要清楚告知給團隊各成員
產品經理需要清楚告知團隊各成員，需求方和領導的意思是如何。
這個項目里面，哪些需求點是必須在某個時間節(jié)點內完成的，哪些可以適當延后。
如果某處碰到困難，無法解決，要及時切換到Plan B。
當前有幾個項目，如果撞在一起，先做哪個，后做哪個。
簡單說“需求很緊急”，是沒有意義的。
因為每個項目都是緊急的。
8. 后續(xù)的全部溝通，盡量在大群里面進行
有些人喜歡建小群，有問題在小群里面私下溝通解決。
我覺得這樣不對。
我覺得，建群，就要建大群，把相關領導都拉進來的那種。當然，涉及的所有人員，都要在里面。
所有溝通，都在大群里面進行。
這樣才能確保，所有人都能知悉當前的所有情況，降低溝通成本，避免遺漏。
04
我覺得，某種意義上講，“需求變更”，尤其是“緊急的需求變更”，是對初級產品經理的一次突擊考試。
因為它需要初級產品經理，在非常短的時候內，在非?；靵y的情況下，快速把握現(xiàn)狀，迅速制定方案，并馬上落實推進。
它是一場綜合性的考試，需要嚴肅對待。
作者：簡明產品論，個人公眾號：簡明產品論（ID：JianMingPM）
本文由 @簡明產品論 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協(xié)議
變更應該還好. 和相應的開發(fā)人員討論一下就有技術路線了. 后面就是評估成本和反饋了.
很不錯，去年6月轉行做產品，12月份自己負責一個新的項目，到現(xiàn)在7個月的時間項目落地，所有情況都遇到過，正在寫項目復盤，正好借鑒，感謝作者。
建大群很真實！
正遇到這樣的問題
替初級產品發(fā)聲?。?br /> 感覺作者非常務實，特別適合在一線打仗的那種