1樓：產品一哥
題主你好，很多時候，產品經理在反覆改需求很煩這件事上能做的，只是讓設計和開發的同事盡量不那麼煩，盡可能的把修改的壓力壓在自己這邊，但還是很難。
產品經理改需求，很多時候都是原來設計上出現功能邏輯上的錯誤，這個產品的個人能力有關，如果在開發之前能認真看一遍原型，提前指出設計上的缺陷，能減少很多在開發過程中的重複翻工。
產品一哥：萬字乾貨！0基礎如何拿到產品經理offer《0基礎如何拿到產品經理offer-資料分享》，資料提取碼【z8nr】
0基礎如何拿到產品經理offer-資料分享產品經理求職-面經分享
產品經理求職-面經分享
2樓：
不懂技術的產品經理 +不懂技術的專案經理+產品改需求+專案經理催進度。
再加資訊不對稱、提倡加班文化的領導團隊。
無敵組合。
3樓：郭軻
你以為PM想改需求？
明明是因為底下的人為了節省開發時間，用的不是最優的解決方案。
比如：程式執行之後，發現有個查詢介面異常的慢，而且網路很容易超時，結果發現乙個SQL的查詢語句，連了3張表，不慢就出了鬼了。
明明是因為底下的人為了節省開發時間，介面一點美觀效果都沒有，也不考慮操作的簡易性
——只是舉個例子，沒有任何不尊重UI和RD的意思如果拋開技術的問題，那改改改就是市場和BOSS拍屁股決定的，不然，你以為PM想改啊？
4樓：星河系教育
其實對於改需求這件事，產品經理自己也很煩。
在正常的狀態下，改需求意味著重新修改需求文件、重新修改原型、流程圖和思維導圖。這些東西牽一發動全身，想改的話，可不容易。
而且修改需求還需要重新評估，專案經理也要介入。如果改得多了，測試部門也要介入。這是乙個大工程，不是那麼容易解決的。
所以，按照標準流程來說，改需求（學名叫做「需求變更」）首先是產品經理自己先麻煩起來，然後才輪到麻煩程式設計師。
除非，你所在的公司流程不嚴格。比如產品經理隨便說一句話，口頭傳達就能改需求。甚至產品經理根本不寫需求文件，就是屬於「連猜帶蒙」地開發。
這樣的話，由於公司流程不嚴格，就容易出現你說的問題。
所以，如果你覺得產品經理經常改需求，那就要向研發部總監提意見，要求所有需求必須走流程，提交書面文件。然後讓研發部總監向產品部總監反映，把工作流程標準化。這樣就會減少很多分歧。
還有，你要明確需求變更是誰的意見。有的時候，產品經理只是傳話筒，背後是老闆朝令夕改。所以，你一定要把問題看透徹才行啊。
5樓：夜夢醬
可能知道也可能不知道。不過一般大多數都知道。其實他們改需求估計也是沒啥辦法。或者是老闆提，或者他們自己覺得之前的不合適要改。他們跟程式提的時候估計也很忐忑怕被打吧哈哈哈哈
6樓：李嘉嘉
你以為的總改需求的產品經理自己不煩嗎？他自己想改嗎？他好好的日子不想過嗎？
有一次我求開發一件事:
開發:「是不是我幫了你，以後就可以不接你的需求了」
我:「可以」
開發:「什麼？」（不相信自己的耳朵）
我:「我有需求嗎？我沒有需求，我從來只轉達老闆的需求」
一般都是這樣的……
在改需求的時候已經完全知道自己要承受的黑臉，還是得改，畢竟是保住工作重要啊？還是被討厭重要啊？？
當然，無論是老闆想改需求還是開發到中途發現不合理要改，歸根結底還是一開始沒有找到最最佳的方案對不對，所以，開脫是不可能的。
所以，知道，自己也煩，但是也得改。
7樓：林夕
知道，但是乙個需求的變更不僅是由產品經理決定的，有來自領導老闆，開發或者基於事實條件等而變更的。產品經理能做的就是多思考需求變更給產品或各方帶來的影響降低到最小，不影響開發周期。
例如就我本身工作環境，上乙個月我們在開發乙個售賣功能，由於公司本身沒有支付這個牌照，所以支付功能是要依託其他公司合作公司。在前期，我們對這個情況是雙方有做乙個溝通，可是在後期開發過程中，發現這個支付流程並不是我們所想的那麼簡單。導致在後期對接過程中，需求變化很大，一直在不斷改動需求。
產品上線後也導致產品的使用者體驗很差。在這個過程中，我們應該反思，為什麼會出現這種情況，如何去杜絕這種情況出現。前期不僅僅要做好雙方各功能共同交流，更要去了解清楚相關政策會帶對需求的影響去尋找解決方案。
前期工作都準備好後，再進入開發模式。就會大大降低需求變更機率也保證了開發周期。
8樓：
很清楚，雖然我已經非常非常盡量的在需求確認完之後，主需求基本是不會動的了，除了補充錯漏的邏輯。這點我自認為還是做得挺好的，至今沒有說做到一半說要推倒重來的。大型需求的加入也真的真的做到盡量不會在中間插入。
但有時候在開發期用著用著發現或者老闆發現（其實這個是主要因素），某些地方有點體驗不好，那這麼辦？不改嘛，又要等下個週期，但其實工作量並不多，沒這個等待必要；改嘛，雖然每個單獨都是小優化，但積少成多，我知道加著加著就工作量就大了。
你以為我不糾結嗎？可是上對老闆，老闆說不行，這個體驗太差了。那我當然是選擇對給我發錢的人負責啊。
你以為我不尷尬嗎？只能厚著臉皮說「不好意思哈，這裡好像確實有個小小小問題」。
你以為我不知道開發在背後會說「怎麼又加需求」？可是我總不能直接說「這是老闆說要做」的吧（PS，經驗之談，我從來不會說這一句，因為這代表我沒能力把事情溝通清楚，需要拿老闆來壓制，建議各位也不要）。到時候其實開發只會更不爽，只能默默忍受了。
我有我的責任。對老闆盡量實現他的需求；對開發，盡量在實現老闆需求的前提下，分配好每個版本的工作量，加需求的時候還要安撫大家的負面情緒，不然下次提需求我都怕被當面噴（背後吐槽我可以當聽不見算了）。
我能理解程式不需要加需求改需求，所以每次都是以比較「溫柔」的語氣提出；但我也希望開發知道這不是因為我喜歡加喜歡改...現實情況所迫而已。說到底大家都是為了產品好為了公司好而已。
不過，幸運的是，我們團隊還沒有會抱怨的人。
9樓：Henry
如果不改那找外包就好啦，要禿頭們幹嘛；
真像是，需求並不是由產品經理控制的，需求的增加和變更往往由使用者（客戶），競品，上級領導，運營，市場走向，等等等等來決定的，產品經理在傳達需求到功能時可能會出現不中的而出現改需求的情況，但也佔少數；但是這樣的產品經理應該還處在中級或者初級的階段，他是把需求轉化為功能再交由開發來完成；高階的產品經理是需求的決策者，對提出需求的佔比會更多；提早發現需求，而不是執行外界的需求；這樣的產品經理也是知道很煩，但是沒辦法的；（好像說得有點跑題了）
10樓：張正
這可以說是公司工作的常見病，解決起來並不難。
俗話說，想清楚才能做明白（好像是我的俗話），乙個成熟的公司必須杜絕改來改去，這裡不展開說。今天只說怎麼避免總是改來改去，必須做到兩點：
一是做這項工作的戰略目的目標一定要明確，客戶、總監和員工在這個問題上必須達成高度一致的共識，工作的目的目標必須也只能是同乙個。並且要有公開的程式，把大家對這個目的和目標的認可記錄下來，防止事後不認賬。
當年賈伯斯要求工程師們只允許保留乙個home鍵時，許多罵他是瘋子，他為什麼死也要堅持？因為這是體現他極簡戰略的重要手段，多少人反對也決不動搖。
二是一定要建立評判工作的標準。許多任務作成果在評判的時候，各說各的理，也許都有道理，但是難免只站在自己的角度思考和判斷。怎麼辦？建立評判標準。
11樓：
最終的產品形態，除了產品自己之外，還有一堆指揮家，每個人提點建議，就會改來改去，發完版本，還要繼續改，這是網際網路的常態，不然為什麼出現了敏捷開發、迭代、小步快跑等這些名詞，就會為修改需求埋單的。
12樓：葉瑤
產品經理改需求有以下幾種情況。
老闆說這裡要改，那裡要改。
ok，先記錄一下，並備註老闆某年某月某日的想法，備案免得老闆忘了他曾經這麼說過
合理，拍馬屁說，對，X哥你說的真棒，改！
不合理，先委婉的說X哥你這個想法很好，但是這裡是不是有更好的實現方式，一分鐘後發現老闆執意要改，也不是核心功能，算了。改！
發現老闆要改核心功能，而且改了後患很大，力勸，成功，老闆不高興，逃。
失敗，被噴一頓，改！
可以，但是需要評估工作量和排期，
和技術估時間排期，
我和技術溝通過了，大概需要10天工作量，按1000/天計算。
甲方說ok，籤需求更改書，打錢。
改！你說的很好，很對，我捋捋
拖！他們以為我們和技術很空麼？
實在有必要的，酌情實現。
13樓：三十不立
先不說改不改煩人，就單純的求別人10次8次，這事本身就是煩的。
我們做產品的也希望一次性搞定，但是衝公司角度講，產品經理要為領導、使用者和公司負責，大多數修改是身不由己的。如果乙個產品，全程自己下需求連改4、5次需求，這事上層知道了不做掉他？
自從當了領導之後，也經常要去協調這些事。根本原因每個需求中間夾雜的人比較複雜，導致需求定位不清晰，即使清晰了，每個人想實現的方式也不一樣。不同維度的思考角度，得出的結論是不一樣的。
諷刺的是，最後得出的結果為什麼變成了最初那版？因為每個人想要的不一樣，均衡之後，變成都滿意的結果了嘛？其實結果是都沒那麼不滿意的那乙個方案。
但是再去想想，乙個產品是公司的結晶，要去打磨，不撕一撕，改一改，單一個人拍腦門什麼都一次成的公司。你敢長呆嘛？
14樓：槓槓
輕易不改需求，必須改也沒辦法，不想給rd同學添麻煩，但是出了問題鍋還要pm背。
借用我之前同事的一句話：大家都是打工掙錢的，相互理解吧。產品不可能一輩子不改需求，就像rd不可能一輩子不寫bug。
15樓：
知道啊，門清啊。
但是不煩咋辦呢？誰不想一次通過然後直接開發，定時定點交付產品？可能麼？且不說中小企業沒啥制度約束，就是大公司，照樣要改的啊。
你以為產品都是產品經理設計的？NO，自從《人人都是產品經理》這書出版之後，搞的大家都開始當產品經理了，誰都能對產品指手畫腳，提出心中偉大的idea，如果是一般人，打個哈哈就過去了，至多陪個笑臉，然後說，您的意見很好，我們慎重考慮下會加入到產品的改進當中，然後左耳朵進右耳朵出，該幹嘛繼續幹嘛。但問題最大的就是老闆也會思路奇多，一天乙個偉大夢想，我們要大幹快上，做出驚世駭俗的產品，獨佔市場，然後走向納斯達克，花上股民的錢，那咱就妥帖了。
於是，各種思路不斷衝擊你，然後扯了一大堆。後來發現，回歸根本，除了主業的產品，其它的偉大夢想都不過是一縷青煙，燒光了還是回到了最初。這也就是很多時候改來改去還是回到了最初的版本的根源。
一版版的需求，一版版的產品設計，都不過是附加工作量，有時候信誓旦旦的一定要做成，有時候不過是拍了腦袋臨時起意，產品經理畢竟只是對產品負責，產品的完整週期產品經理的資訊量未必清晰，所以，最終很可能就是老闆說啥就是啥了。
所以，煩就煩唄，然後咋樣呢？沒任何意義啊。放在現下，誰知道哪片雲彩有雨呢。
萬一老闆拍了腦袋來了乙個曠世想法，後來被驗證是成功的，那被產品經理擋了輝煌的腳步，估計那才是最難過的吧。
產品經理如何制定產品需求？
已重置 老闆讓你幹什麼，你就幹什麼。如果最後證實是偽需求，或者優先順序不高的那種，反正老闆背鍋啊。就這樣，我們只要領工資就好了，程式設計師也一樣，就說這個需求老闆提的，怎麼著？ 方小花 需求主要還是分兩種，一種自發的需求，一種是外部需求 而本來自己是產品，那麼產品需求就是自發的需求，我的理解是這樣的...
如何鑑別產品經理的真偽需求？
產品一哥 題主你好，看乙個產品經理的需求是否是從產品價值出發，通過提問的方式，多問為什麼，目標，核心點是找到產品 需求 的價值和目的，我把我的經驗總結出來分享給你。當我們說真需求的時候，我們可以將之定義為這一需求代表了特定群體大多數人的共同真實需要 反之則可以稱為偽需求。我們以下不會在真假需求上多費...
軟體需求分析怎麼轉產品經理或者專案經理？
Luo.David 看性格，外向點，有創意想法，對於軟體整個流程非常熟悉也願意設計軟體並且能夠說服客戶就轉產品經理。反之就專案經理，管理內部團隊，合適的崗位安排上合適的人就好了。特別注意的是，轉崗後可能需要暫時丟掉自己原來的身份，畢竟產品經理或者專案經理不能兼著需求分析的崗位的。 IT小蘭 從事企業...