導致改需求的原因有很多，第一條就是產品經理策劃時考慮不周全，所以筆者提出了兩點建議，併進一步分享瞭如果實在要改需求的話怎麼處理？
01
“產品經理總是改需求”，是“產品經理”最出圈的刻板印象之一。
這個印象，或者說這句牢騷，顯然最開始是出自於程序員圈子。
因此，“需求”這個概念，就可以簡單地理解為“產品經理要求技術團隊開發的任務”。
那麼，“改需求”，就是“變更任務要求”。
根據我的經驗，程序員抱怨“改需求”，一般會是下麵的這2種情況：
- 在一個開發周期內，產品經理已經將開發任務安排下去，項目已經進入開發階段了，這時產品經理要改需求。
- 項目上線運行沒多久，產品經理要求在下一個開發周期對這個項目進行修改。
其中，容易引起程序員不滿的是第1種情況。一般說“產品經理改需求”的，大多也是指的第1種情況。
02
導致改需求的原因有很多，而首當其衝的就是，產品經理策劃時考慮不周全。比如，模塊前後矛盾，某個對象狀態缺失，交互設計不合理，等等。
對於剛入行的朋友，我建議你要把關註的重點放在這個上面。
一個產品經理，如果交付的PRD始終錯漏百出，那他肯定是走不長遠的。
至於其他原因，比如領導改變主意、合作方有新要求、市場環境變化，等等，大多不是產品經理所能控制的。這裡就先不討論了。
策劃時如何考慮周全，是一個非常複雜的問題，三言兩語說不明白。這隻能自己慢慢摸索，並不存在一步登天的捷徑。
這裡，根據我的經驗，分享2點建議。這些是我認為比較重要，但網上卻少有人提及的。
1. 通盤考慮項目在不同平臺上的實現形態，尤其要關註各個平臺自身的特殊情況和特殊要求
公司產品，一般會有PC端、觸屏端、安卓端APP、iOS端APP，有時還會有微信小程序。其中，觸屏端，還需要特別區分“微信框架下”和“非微信框架下”。
比如我們要做一個專題，這個專題將會放在觸屏端和APP端。那這個專題的“分享”功能需要怎麼策劃呢？
首先，APP的分享模塊，一般是原生的。形式大概是底部彈窗，在彈窗內選擇“微信好友”、“微信朋友圈”、“QQ好友”、“QQ空間”等方式。出於成本考慮，安卓端和iOS端，會採用一樣的設計，不用分開討論。
然後，再看微信框架下的觸屏端。因為我們無法調起微信的分享模塊，所以形式上就不能是底部彈窗，而是需要做一個遮罩層，提示用戶自行操作分享。
最後，我們來看非微信框架下的觸屏端。這個就非常複雜了。因為你無法確定，用戶到底會用什麼瀏覽器去訪問。所有瀏覽器都分別進行適配，又非常麻煩。這種時候，出於成本考慮，就要想，是不是可以把非微信框架下的分享模塊給隱藏掉。
類似的，我們在策劃的時候，需要通盤考慮不同平臺的情況，分別進行應對。
如果你的公司同時有多條產品線，或者和其他公司有商務合作，那就更複雜了，要根據公司業務情況綜合考慮。
2.確保自己已經正確掌握產品當前的真實狀態，尤其要註意以前做過的特殊處理
時不時會有這樣的新聞，一個小小的突發事故，就給某公司的軟件系統造成巨大的傷害。然後大家突然發現，這家公司外表光鮮亮麗，然而內部極其混亂，系統里不知埋了多少坑。
其實，這種情況並不鮮見。尤其是在各種普通小廠，幾乎是一種常態，只是暫時還沒暴雷而已。
因此，具體到產品策劃，你不能理所當然地認為，公司的產品有在正常有序地運轉著。反而是，很有可能在你不知道的地方，產品已經出問題了。
- 比如，某個功能，上線的時候好好的，後面不知道哪次更新，就給覆蓋掉了，沒人知道。
- 比如，某次開發，為了趕工期，只上線了部分內容，剩餘部分計劃以後再改，但是至今一直沒有搞。
- 比如，開發某個模塊時，把另一個模塊給搞壞了，然後進行了緊急修複。至於是怎麼修複，沒留下文檔。
- 比如，原來負責的程序員離職了，接手的人看不懂上一任的代碼，改著改著就面目全非了。
如果你不是在知名大廠，那麼這些情況，基本都是日常。
所以，策劃時，就需要自己先實際去跑一遍產品相關模塊，確保自己已經正確掌握產品當前的真實狀態。無法直接在前端頁面確認的，需要找到相應的程序員，通過查代碼來確認。
只有前提條件對了，後面的推演才有可能是對的。
03
一旦程序員開工了，再讓他修改，都可能把他惹惱。
所以，很多產品新人，在對接技術的時候，總是戰戰兢兢的，生怕哪句話說得不是，就把人家給惹惱了。
其實，大可不必如此。
改需求，是一件很頻繁的事情。也就是說，是產品和技術工作中的日常。就這麼一項日常的工作，每次都要發火、懟人、吵架，你覺得可能嗎？如果真是如此，公司早就倒閉了，員工早就因打架鬥毆而實現“財務自由”了。
實際工作日常，並沒有段子那麼有戲劇性。
比如說，曾有一次，我要求新增一個移動端的頁面。這個頁面有2種狀態（假定用“A”和“B”來表示）。當用戶訪問時，A賬號顯示A狀態，B賬號顯示B狀態。
然後，我要求，當用戶點擊“返回”時，要回到他進入時候的頁面。從首頁進的要回到首頁，從會員中心進的要回會員中心。這個很好理解，也沒什麼不合理的。
但是，在具體實現時，卻出現了問題。
接手的程序員不是做一個有“A、B”2個狀態的頁面。而是做了2個頁面，A頁面對應A狀態，B頁面對應B狀態。用戶訪問時，默認進入A頁面。如果是B賬號訪問的，那就在進入A頁面的瞬間，自動跳轉到B頁面。
這樣看起來也是能滿足要求的。
但是，我在驗收的時候發現，當B賬號用戶要從B頁面返回時，因為他是從A頁面來的，所以按照我定的要求，會跳回A頁面。可他剛進入A頁面，A頁面就會啟動判斷機制，自動又給跳回到B頁面去了。
那麼，從用戶的角度來看，就是，點了“返回”之後，一直在B頁面轉圈，回不去了。
這可怎麼辦呢？
頁面做都做了，沒辦法。我只能修改要求，改成把返迴路徑寫死，統一跳轉到會員中心。
以上這樣的例子，其實才是日常工作中的常態。
沒有段子裡面寫的那種劇烈衝突，也沒必要去追究是誰的錯。大家都是為了完成項目，出現問題互相協商解決，僅此而已。
所以，當你要進行需求變更時，不需要有太大的心理負擔。
而且，技術團隊普遍開發任務重。所以，能否準確快速地瞭解需求變更的內容，才是程序員真正關心的事情。
04
作為產品新人，很可能你的第一件工作，就是“改需求”。
你剛入行，還沒法獨立地去做一個需求。這時候一般會把其他產品同事手上的項目，分給你跟進，算是練練手，熟悉一下工作流程。
這個項目，不會太複雜。但是，也不至於簡單到可以放著不管。
你在跟進過程中，大概率上還是會遇到一些問題的。而你人生的第一次“改需求”，很可能就發生在這個時候。
還沒學會怎麼“提需求”，就要去“改需求”了，你肯定會感到措手不及。
這裡，我總結了4個要點，希望能給產品新人提供一些幫助。
1. 等到相關干係人明確說出“要改需求”，才可以行動
需求變更，是一件非常容易造成混亂的事情，所以必須要事先確認清楚。最好能得到公司領導，或者需求部門主管的確認。再不濟，至少得找需求經辦人確認。
同時，需求變更，意味上線時間可能推後，或者程序員需要加班趕工。嚴格來說，產品經理並沒有做出這種決定的權利。只有領導確認了，你才得到了授權，才可以行動。
2. 嚴格按照公司的需求變更規範去做
需求變更是一件經常發生的事情，任何公司都不可能一直讓它處於失控的狀態。
所以，每個公司，多少都會對需求變更有一些規範要求，有些是明文規定，有些是約定俗成。
這些規範，不一定完全合理，但肯定是公司團隊在實際工作中提煉出來的最優解。
如果不按公司的規範流程來，責任的問題就先不談了，你很可能會出現重大的疏漏。
最常見的，就是沒有通知到所有需要通知的人。比如有個程序員沒通知到。或者開發團隊都通知到了，但把測試團隊給漏了。
3. 儘量先改PRD，把變更落實到文檔中
除非特別緊急，否則，每次改需求，要儘量先改PRD。產品文檔更新後，再連同變更的需求發給相應同事。
要知道，項目的各個模塊，往往是互相關聯的。改動一個地方，很可能會影響到其他地方。在變更需求的時候，是很容易出現遺漏的。
而當你去更新PRD時，會比較容易進入策劃時候的思路，比較容易發現那些被遺漏的地方。
另一方面，如果後續出現爭議了，這個修改好的正確的文檔，還能保障你的生命安全。
4. 所有的變更，要親自和每個程序員說明清楚
改需求的時候，因為害怕被懟，不想直接面對程序員，這點不是不能理解。
但是，哪怕你嚴格按照公司的規範流程、準確全面地表達變更內容，在需求變更的過程中，還是很有可能出問題的。因為需求變更，本身就是一件非常容易造成混亂的事情。
而作為產品經理，這個時候，你是最瞭解需求的人，同時也是對當前每個程序員的開發情況瞭解最全面的人。所以，你必須親自去跟每個程序員當面說明情況，並解答他們的疑惑。
只有這樣，才能最大限度地避免出錯。
05
最後，我們再回過頭來，重新看看“產品經理總是改需求”這件事。
雖然主語是“產品經理”，但這並不是產品經理一個人的事情。
它本質上是一個系統性的問題，是協作機制內在缺陷導致的，是團隊中所有人共同作用的結果。並不是我們這些初級產品經理有能力解決的。
我們在進行產品策劃時，首先要做的就是明確需求的範圍。
同理，我們在工作時，也需要去明確自己的工作職責和工作範圍。不是把全部事情一股腦都攬在自己身上，而是應該去尋找自己能控制的局部，去優化可控的部分。
後記
大家好，我是Minami，一個普通小廠的4年產品人。
說來慚愧，我沒進過大廠，只能混跡在各種不知名的普通小廠。也正因如此，我發現，前輩們分享的一些優秀產品經驗，離開了大廠理想的環境之後，其實非常難應用到自己的日常工作中。
所以我想分享一些來自普通小廠的經驗教訓，給剛入行的朋友提供一個不一樣的視角。
我不是產品大牛，只是作為一個普通產品人，分享一些日常的思考總結。如果能幫到你，非常榮幸。如果哪些說得不對，歡迎你留言賜教。
作者：簡明產品論；簡明產品論（ID：JianMingPM）
本文由 @簡明產品論 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。