一個好產品確實是不斷打磨的過程，但是，產品經理有時候在經驗方面有欠缺，導致需求分析不準確，業務邏輯不清晰，需求確定的時候沒有和程式部門的負責人進行商議，達成共識，導致反覆修改，讓程式設計師新生憤怒。這是工作流程上的不足，雖然無法100%的杜絕，但是可以透過完善流程，在允許一定調整冗餘的情況下，緩解一下需求不準確導致開發反覆的問題。

產品經理頻繁的該需求，有時候也不是他自己的意願，大部分時候，這是一個產品的正常發展過程中的必經階段。

對於產品經理來說，他需要面對一個變化的市場，而在這個市場中的需求也是隨著時間的推移發生著變化。所以，產品經理在一週前的分析結果可能在一週會發生了變化，而這時的產品正在研發過程中，為了保證適應現在的市場，就必須做出一定的調整。

當然，還有可能是因為運營的需求在變化，運營一般會提前一定的時間提出自己的需求，例如：雙11要搞活動，需要有一定的支援。但是，運營計劃會根據公司的戰略隨時發生調整，甚至還可能顛覆之前的運營計劃。

而雙11這個時間點是不會變的，這就出現了產品經理和運營部分之間的PK，而衡量最後誰會“獲勝”的，從來不是誰脾氣大，誰牛逼，而是對於公司來說，那個方案的利益能夠最大化。

而這個過程一定也會出現需求的變化的，這個時候的產品經理也屬於無可奈何。

不過，還有一種需求的變化，不是由於這些客觀的原因引起的，而是產品經理自身能力的問題。在前期的需求挖掘和分析的過程中，對使用者的潛在需求瞭解不足，所以最終出現了貨不對板的情況。而這就出現了在專案後期，客戶看到了產品的雛形，對自己的需求也逐漸的明晰，從而各種的不滿意，產品也就進入了一個悲催的不斷重複微調的過程。而且對於時間的要求非常嚴格，可能出現一週一次迭代，甚至3天一次迭代的情況。

至於程式設計師，其實只要放平心態就行了。

程式設計師就好像生產線上的工人一樣，做的事情就是保證足夠的生產力。產品經理的需求變化了，更多是和產品討論一個能夠速度最快，效率最高的解決方案。而不是糾結於這個問題是誰的錯誤導致的。最終，程式設計師也是為前線輸出彈藥的，戰事不會因為你的抱怨而改變。

所以，雖然頻繁的需求改變很煩，但是也必須要做。只是在做的過程中，作為程式設計師也應該更多的進行系統的設計和分析，把風險點控制在前期。預料到一些風險點的時候，減少透過寫死Code的方式來將就，多一些可擴充套件性，這樣讓系統在未來的需求變化中能夠更加的堅強一些。

作為一個程式設計師，改變不了什麼，除了抱怨，可能更多的只能接受。拿人錢財，替人消災嘛！