導致改需求的原因有很多，第一條就是產品經理策劃時考慮不周全，所以筆者提出了兩點建議，并進一步分享了如果實在要改需求的話怎么處理？

01

“產品經理總是改需求”，是“產品經理”最出圈的刻板印象之一。

這個印象，或者說這句牢騷，顯然最開始是出自于程序員圈子。

因此，“需求”這個概念，就可以簡單地理解為“產品經理要求技術團隊開發的任務”。

那么，“改需求”，就是“變更任務要求”。

根據我的經驗，程序員抱怨“改需求”，一般會是下面的這2種情況：

1. 在一個開發周期內，產品經理已經將開發任務安排下去，項目已經進入開發階段了，這時產品經理要改需求。
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頁面?？伤麆傔M入A頁面，A頁面就會啟動判斷機制，自動又給跳回到B頁面去了。

那么，從用戶的角度來看，就是，點了“返回”之后，一直在B頁面轉圈，回不去了。

這可怎么辦呢？

頁面做都做了，沒辦法。我只能修改要求，改成把返回路徑寫死，統一跳轉到會員中心。

以上這樣的例子，其實才是日常工作中的常態。

沒有段子里面寫的那種劇烈沖突，也沒必要去追究是誰的錯。大家都是為了完成項目，出現問題互相協商解決，僅此而已。

所以，當你要進行需求變更時，不需要有太大的心理負擔。

而且，技術團隊普遍開發任務重。所以，能否準確快速地了解需求變更的內容，才是程序員真正關心的事情。

04

作為產品新人，很可能你的第一件工作，就是“改需求”。

你剛入行，還沒法獨立地去做一個需求。這時候一般會把其他產品同事手上的項目，分給你跟進，算是練練手，熟悉一下工作流程。

這個項目，不會太復雜。但是，也不至于簡單到可以放著不管。

你在跟進過程中，大概率上還是會遇到一些問題的。而你人生的第一次“改需求”，很可能就發生在這個時候。

還沒學會怎么“提需求”，就要去“改需求”了，你肯定會感到措手不及。

這里，我總結了4個要點，希望能給產品新人提供一些幫助。

1. 等到相關干系人明確說出“要改需求”，才可以行動

需求變更，是一件非常容易造成混亂的事情，所以必須要事先確認清楚。最好能得到公司領導，或者需求部門主管的確認。再不濟，至少得找需求經辦人確認。

同時，需求變更，意味上線時間可能推后，或者程序員需要加班趕工。嚴格來說，產品經理并沒有做出這種決定的權利。只有領導確認了，你才得到了授權，才可以行動。

2. 嚴格按照公司的需求變更規范去做

需求變更是一件經常發生的事情，任何公司都不可能一直讓它處于失控的狀態。

所以，每個公司，多少都會對需求變更有一些規范要求，有些是明文規定，有些是約定俗成。

這些規范，不一定完全合理，但肯定是公司團隊在實際工作中提煉出來的最優解。

如果不按公司的規范流程來，責任的問題就先不談了，你很可能會出現重大的疏漏。

最常見的，就是沒有通知到所有需要通知的人。比如有個程序員沒通知到?；蛘唛_發團隊都通知到了，但把測試團隊給漏了。

3. 盡量先改PRD，把變更落實到文檔中

除非特別緊急，否則，每次改需求，要盡量先改PRD。產品文檔更新后，再連同變更的需求發給相應同事。

要知道，項目的各個模塊，往往是互相關聯的。改動一個地方，很可能會影響到其他地方。在變更需求的時候，是很容易出現遺漏的。

而當你去更新PRD時，會比較容易進入策劃時候的思路，比較容易發現那些被遺漏的地方。

另一方面，如果后續出現爭議了，這個修改好的正確的文檔，還能保障你的生命安全。

4. 所有的變更，要親自和每個程序員說明清楚

改需求的時候，因為害怕被懟，不想直接面對程序員，這點不是不能理解。

但是，哪怕你嚴格按照公司的規范流程、準確全面地表達變更內容，在需求變更的過程中，還是很有可能出問題的。因為需求變更，本身就是一件非常容易造成混亂的事情。

而作為產品經理，這個時候，你是最了解需求的人，同時也是對當前每個程序員的開發情況了解最全面的人。所以，你必須親自去跟每個程序員當面說明情況，并解答他們的疑惑。

只有這樣，才能最大限度地避免出錯。

05

最后，我們再回過頭來，重新看看“產品經理總是改需求”這件事。

雖然主語是“產品經理”，但這并不是產品經理一個人的事情。

它本質上是一個系統性的問題，是協作機制內在缺陷導致的，是團隊中所有人共同作用的結果。并不是我們這些初級產品經理有能力解決的。

我們在進行產品策劃時，首先要做的就是明確需求的范圍。

同理，我們在工作時，也需要去明確自己的工作職責和工作范圍。不是把全部事情一股腦都攬在自己身上，而是應該去尋找自己能控制的局部，去優化可控的部分。

后記

大家好，我是Minami，一個普通小廠的4年產品人。

說來慚愧，我沒進過大廠，只能混跡在各種不知名的普通小廠。也正因如此，我發現，前輩們分享的一些優秀產品經驗，離開了大廠理想的環境之后，其實非常難應用到自己的日常工作中。

所以我想分享一些來自普通小廠的經驗教訓，給剛入行的朋友提供一個不一樣的視角。

我不是產品大牛，只是作為一個普通產品人，分享一些日常的思考總結。如果能幫到你，非常榮幸。如果哪些說得不對，歡迎你留言賜教。

作者：簡明產品論；簡明產品論（ID：JianMingPM）

本文由 @簡明產品論 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

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