導(dǎo)致改需求的原因有很多，第一條就是產(chǎn)品經(jīng)理策劃時考慮不周全，所以筆者提出了兩點(diǎn)建議，并進(jìn)一步分享了如果實(shí)在要改需求的話怎么處理？

01

“產(chǎn)品經(jīng)理總是改需求”，是“產(chǎn)品經(jīng)理”最出圈的刻板印象之一。

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

因此，“需求”這個概念，就可以簡單地理解為“產(chǎn)品經(jīng)理要求技術(shù)團(tuán)隊(duì)開發(fā)的任務(wù)”。

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

根據(jù)我的經(jīng)驗(yàn)，程序員抱怨“改需求”，一般會是下面的這2種情況：

1. 在一個開發(fā)周期內(nèi)，產(chǎn)品經(jīng)理已經(jīng)將開發(fā)任務(wù)安排下去，項(xiàng)目已經(jīng)進(jìn)入開發(fā)階段了，這時產(chǎn)品經(jīng)理要改需求。
2. 項(xiàng)目上線運(yùn)行沒多久，產(chǎn)品經(jīng)理要求在下一個開發(fā)周期對這個項(xiàng)目進(jìn)行修改。

其中，容易引起程序員不滿的是第1種情況。一般說“產(chǎn)品經(jīng)理改需求”的，大多也是指的第1種情況。

02

導(dǎo)致改需求的原因有很多，而首當(dāng)其沖的就是，產(chǎn)品經(jīng)理策劃時考慮不周全。比如，模塊前后矛盾，某個對象狀態(tài)缺失，交互設(shè)計不合理，等等。

對于剛?cè)胄械呐笥?，我建議你要把關(guān)注的重點(diǎn)放在這個上面。

一個產(chǎn)品經(jīng)理，如果交付的PRD始終錯漏百出，那他肯定是走不長遠(yuǎn)的。

至于其他原因，比如領(lǐng)導(dǎo)改變主意、合作方有新要求、市場環(huán)境變化，等等，大多不是產(chǎn)品經(jīng)理所能控制的。這里就先不討論了。

策劃時如何考慮周全，是一個非常復(fù)雜的問題，三言兩語說不明白。這只能自己慢慢摸索，并不存在一步登天的捷徑。

這里，根據(jù)我的經(jīng)驗(yàn)，分享2點(diǎn)建議。這些是我認(rèn)為比較重要，但網(wǎng)上卻少有人提及的。

1. 通盤考慮項(xiàng)目在不同平臺上的實(shí)現(xiàn)形態(tài)，尤其要關(guān)注各個平臺自身的特殊情況和特殊要求

公司產(chǎn)品，一般會有PC端、觸屏端、安卓端APP、iOS端APP，有時還會有微信小程序。其中，觸屏端，還需要特別區(qū)分“微信框架下”和“非微信框架下”。

比如我們要做一個專題，這個專題將會放在觸屏端和APP端。那這個專題的“分享”功能需要怎么策劃呢？

首先，APP的分享模塊，一般是原生的。形式大概是底部彈窗，在彈窗內(nèi)選擇“微信好友”、“微信朋友圈”、“QQ好友”、“QQ空間”等方式。出于成本考慮，安卓端和iOS端，會采用一樣的設(shè)計，不用分開討論。

然后，再看微信框架下的觸屏端。因?yàn)槲覀儫o法調(diào)起微信的分享模塊，所以形式上就不能是底部彈窗，而是需要做一個遮罩層，提示用戶自行操作分享。

最后，我們來看非微信框架下的觸屏端。這個就非常復(fù)雜了。因?yàn)槟銦o法確定，用戶到底會用什么瀏覽器去訪問。所有瀏覽器都分別進(jìn)行適配，又非常麻煩。這種時候，出于成本考慮，就要想，是不是可以把非微信框架下的分享模塊給隱藏掉。

類似的，我們在策劃的時候，需要通盤考慮不同平臺的情況，分別進(jìn)行應(yīng)對。

如果你的公司同時有多條產(chǎn)品線，或者和其他公司有商務(wù)合作，那就更復(fù)雜了，要根據(jù)公司業(yè)務(wù)情況綜合考慮。

2.確保自己已經(jīng)正確掌握產(chǎn)品當(dāng)前的真實(shí)狀態(tài)，尤其要注意以前做過的特殊處理

時不時會有這樣的新聞，一個小小的突發(fā)事故，就給某公司的軟件系統(tǒng)造成巨大的傷害。然后大家突然發(fā)現(xiàn)，這家公司外表光鮮亮麗，然而內(nèi)部極其混亂，系統(tǒng)里不知埋了多少坑。

其實(shí)，這種情況并不鮮見。尤其是在各種普通小廠，幾乎是一種常態(tài)，只是暫時還沒暴雷而已。

因此，具體到產(chǎn)品策劃，你不能理所當(dāng)然地認(rèn)為，公司的產(chǎn)品有在正常有序地運(yùn)轉(zhuǎn)著。反而是，很有可能在你不知道的地方，產(chǎn)品已經(jīng)出問題了。

• 比如，某個功能，上線的時候好好的，后面不知道哪次更新，就給覆蓋掉了，沒人知道。
• 比如，某次開發(fā)，為了趕工期，只上線了部分內(nèi)容，剩余部分計劃以后再改，但是至今一直沒有搞。
• 比如，開發(fā)某個模塊時，把另一個模塊給搞壞了，然后進(jìn)行了緊急修復(fù)。至于是怎么修復(fù)，沒留下文檔。
• 比如，原來負(fù)責(zé)的程序員離職了，接手的人看不懂上一任的代碼，改著改著就面目全非了。

如果你不是在知名大廠，那么這些情況，基本都是日常。

所以，策劃時，就需要自己先實(shí)際去跑一遍產(chǎn)品相關(guān)模塊，確保自己已經(jīng)正確掌握產(chǎn)品當(dāng)前的真實(shí)狀態(tài)。無法直接在前端頁面確認(rèn)的，需要找到相應(yīng)的程序員，通過查代碼來確認(rèn)。

只有前提條件對了，后面的推演才有可能是對的。

03

一旦程序員開工了，再讓他修改，都可能把他惹惱。

所以，很多產(chǎn)品新人，在對接技術(shù)的時候，總是戰(zhàn)戰(zhàn)兢兢的，生怕哪句話說得不是，就把人家給惹惱了。

其實(shí)，大可不必如此。

改需求，是一件很頻繁的事情。也就是說，是產(chǎn)品和技術(shù)工作中的日常。就這么一項(xiàng)日常的工作，每次都要發(fā)火、懟人、吵架，你覺得可能嗎？如果真是如此，公司早就倒閉了，員工早就因打架斗毆而實(shí)現(xiàn)“財務(wù)自由”了。

實(shí)際工作日常，并沒有段子那么有戲劇性。

比如說，曾有一次，我要求新增一個移動端的頁面。這個頁面有2種狀態(tài)（假定用“A”和“B”來表示）。當(dāng)用戶訪問時，A賬號顯示A狀態(tài)，B賬號顯示B狀態(tài)。

然后，我要求，當(dāng)用戶點(diǎn)擊“返回”時，要回到他進(jìn)入時候的頁面。從首頁進(jìn)的要回到首頁，從會員中心進(jìn)的要回會員中心。這個很好理解，也沒什么不合理的。

但是，在具體實(shí)現(xiàn)時，卻出現(xiàn)了問題。

接手的程序員不是做一個有“A、B”2個狀態(tài)的頁面。而是做了2個頁面，A頁面對應(yīng)A狀態(tài)，B頁面對應(yīng)B狀態(tài)。用戶訪問時，默認(rèn)進(jìn)入A頁面。如果是B賬號訪問的，那就在進(jìn)入A頁面的瞬間，自動跳轉(zhuǎn)到B頁面。

這樣看起來也是能滿足要求的。

但是，我在驗(yàn)收的時候發(fā)現(xiàn)，當(dāng)B賬號用戶要從B頁面返回時，因?yàn)樗菑腁頁面來的，所以按照我定的要求，會跳回A頁面?？伤麆傔M(jìn)入A頁面，A頁面就會啟動判斷機(jī)制，自動又給跳回到B頁面去了。

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

這可怎么辦呢？

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

以上這樣的例子，其實(shí)才是日常工作中的常態(tài)。

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

所以，當(dāng)你要進(jìn)行需求變更時，不需要有太大的心理負(fù)擔(dān)。

而且，技術(shù)團(tuán)隊(duì)普遍開發(fā)任務(wù)重。所以，能否準(zhǔn)確快速地了解需求變更的內(nèi)容，才是程序員真正關(guān)心的事情。

04

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

你剛?cè)胄?，還沒法獨(dú)立地去做一個需求。這時候一般會把其他產(chǎn)品同事手上的項(xiàng)目，分給你跟進(jìn)，算是練練手，熟悉一下工作流程。

這個項(xiàng)目，不會太復(fù)雜。但是，也不至于簡單到可以放著不管。

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

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

這里，我總結(jié)了4個要點(diǎn)，希望能給產(chǎn)品新人提供一些幫助。

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

需求變更，是一件非常容易造成混亂的事情，所以必須要事先確認(rèn)清楚。最好能得到公司領(lǐng)導(dǎo)，或者需求部門主管的確認(rèn)。再不濟(jì)，至少得找需求經(jīng)辦人確認(rèn)。

同時，需求變更，意味上線時間可能推后，或者程序員需要加班趕工。嚴(yán)格來說，產(chǎn)品經(jīng)理并沒有做出這種決定的權(quán)利。只有領(lǐng)導(dǎo)確認(rèn)了，你才得到了授權(quán)，才可以行動。

2. 嚴(yán)格按照公司的需求變更規(guī)范去做

需求變更是一件經(jīng)常發(fā)生的事情，任何公司都不可能一直讓它處于失控的狀態(tài)。

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

這些規(guī)范，不一定完全合理，但肯定是公司團(tuán)隊(duì)在實(shí)際工作中提煉出來的最優(yōu)解。

如果不按公司的規(guī)范流程來，責(zé)任的問題就先不談了，你很可能會出現(xiàn)重大的疏漏。

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

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

除非特別緊急，否則，每次改需求，要盡量先改PRD。產(chǎn)品文檔更新后，再連同變更的需求發(fā)給相應(yīng)同事。

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

而當(dāng)你去更新PRD時，會比較容易進(jìn)入策劃時候的思路，比較容易發(fā)現(xiàn)那些被遺漏的地方。

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

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

改需求的時候，因?yàn)楹ε卤粦?，不想直接面對程序員，這點(diǎn)不是不能理解。

但是，哪怕你嚴(yán)格按照公司的規(guī)范流程、準(zhǔn)確全面地表達(dá)變更內(nèi)容，在需求變更的過程中，還是很有可能出問題的。因?yàn)樾枨笞兏旧砭褪且患浅Ｈ菀自斐苫靵y的事情。

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

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

05

最后，我們再回過頭來，重新看看“產(chǎn)品經(jīng)理總是改需求”這件事。

雖然主語是“產(chǎn)品經(jīng)理”，但這并不是產(chǎn)品經(jīng)理一個人的事情。

它本質(zhì)上是一個系統(tǒng)性的問題，是協(xié)作機(jī)制內(nèi)在缺陷導(dǎo)致的，是團(tuán)隊(duì)中所有人共同作用的結(jié)果。并不是我們這些初級產(chǎn)品經(jīng)理有能力解決的。

我們在進(jìn)行產(chǎn)品策劃時，首先要做的就是明確需求的范圍。

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

后記

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

說來慚愧，我沒進(jìn)過大廠，只能混跡在各種不知名的普通小廠。也正因如此，我發(fā)現(xiàn)，前輩們分享的一些優(yōu)秀產(chǎn)品經(jīng)驗(yàn)，離開了大廠理想的環(huán)境之后，其實(shí)非常難應(yīng)用到自己的日常工作中。

所以我想分享一些來自普通小廠的經(jīng)驗(yàn)教訓(xùn)，給剛?cè)胄械呐笥烟峁┮粋€不一樣的視角。

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

作者：簡明產(chǎn)品論；簡明產(chǎn)品論（ID：JianMingPM）

本文由 @簡明產(chǎn)品論 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

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