垃圾的產品確實能激發程式設計師憤而離職的衝動。使用者需求自己都整不清楚，經常是他們搞得邏輯程式碼寫到最後發現走都走不通，反而甩鍋這個，甩鍋那個。經常是臨上線整個模組邏輯大變。最可怕的是，一點技術都不懂，還頤指氣使要求這樣要求那樣，根本不考慮方案是否可行[酷拽]，哥們深受其害，尥蹶子了！希望下一家能有一個好一點的團隊[祈禱]

我本身就是程式設計師，對此還是深有感觸，需求反覆變更也就說明自己想要的是什麼都不清楚，反應公司或者業務定位不清晰由此可見公司發展潛力也一般，或者產品能力不足無法準確把控業務需求。反覆變更需求浪費各方精力，增加成本，消耗程式設計師耐心，從個人發展角度來說也不是很好，自然引起離職。

這涉及到開發和產品部門的工作模式，還有公司的管理體系。

產品部門和開發部門的工作模式是不一樣的，產品負責宏觀和功能設定，而開發負責實現。

軟體開發中很多時候不是一次性完成一個產品，很多時候為了開發的效率和穩定性會把開發分成很多階段，每一個階段要開發不同的功能，一個階段完成開發之後要進行測試，改bug才會進入下一個階段，下一個階段會禁止修改上一階段的程式碼，這樣才能保證開發的效率，否則出了問題都不知道哪裡出了問題，這種開發模式下，如果出了問題，那就可以排除上一階段引入的問題，從而提高定位問題的效率，同時避免問題的交叉引入。那麼問題來了，如果到了第四階段要修改第一階段的問題，同時第一階段的功能還和第二第三階段耦合，那麼試想一下，可能非常小的改動，就要引起產品四個階段的改動和測試，這時候產品還要趕進度，出了問題還要開發背鍋，試想開發能不惱火嗎，所以明確需求是所有開發過程中最重要的階段，其實整個開發寫程式碼的過程只是產品開發過程中非常小的一部分，明確需求，產品測試，組內溝通才是產品開發的大頭。站在開發角度，一個產品連需求都明確不了，就會讓開發人員覺得這非常混亂，而且改需求這種沒有產出的活，說實話沒有幾個人喜歡，所以一個優秀的產品首先要能明確產品的需求，而且要對改需求這種開起來小，其實非常繁鎖的是保持敬畏之心，理解開發的工作模式，否則不但讓開發惱火，還會浪費公司大量的資源。

程式設計師就是因需求而生

榮幸回答

同學請坐下，聽我一言。

程式設計師的一生都是在實現一個又一個需求的體系中無限迴圈。沒有需求程式設計師則失去了開發物件，就像演員失去了表演的舞臺。為了生存和適應新社會背景下的環境，程式設計師從網頁開發到web客戶端開發，再到app小程式不斷的作出改變，實現了一個又一個的需求來滿足社會的要求，重蹈覆轍的程式人生進入需求的迴圈模式。

一個程式設計師永遠不會只限滿足掌握一門語言和技術，在app熱門時代無數的程式設計師選擇安卓和ios開發，小程式的出現讓他們做出了改變，大資料和人工智慧的出現又多了無數個熱衷於演算法的程式設計師和工程師。

為了追求高薪和更美好的生活，程式設計師在不斷的脫變，現象級的離職換崗現象，從後端工程師變為前端，app開發變為主攻小程式輕應用開發。這一切都是需求在導演著程式設計師的變動。

程式設計師的價值在於實現需求，面對需求選擇最佳的解決方案，這個是程式設計師生態定律。

我一名普普通通的程式設計師，當初懷著熱情和夢想學習了程式設計，加入了程式設計師的大家庭，多少次想證明自己我能行，時常對自己說：“這個需求我可以完成”，很多時候我會陷入焦慮，思想的偏差讓我不安，有時候想選擇安於現狀，但是程式設計師的高度是一個無法想象的度，於是我並不想停止我在程式設計道路上的腳步，我想挑戰自己的能力極限，程式設計不死我將往死裡學。

程式設計師小夥伴你們是否有這樣的困惑？

我覺得這個現象沒有一般性。改需求，是一個幾乎無法避免的事情。得說清楚為什麼改需求會造成這麼大的困擾～ 你改，還不要推工期，逼著加班，那肯定是不可取的。如果改需求有正常的流程，會相應地改工期，那似乎也不會對程式設計師的工作和生活有什麼困擾。

如果寫的程式碼質量太差，沒有好的設計，修改成本大，那主要是程式設計師的問題...

需求變更在軟體專案中是普遍存在的。幾乎在所有的專案中都會存在需求變更的情況。作為程式設計師應該直面專案中的需求變更，可以嘗試從以下幾個方面努力：

1、保持健康合理的心態，從心態上積極的面對需求變更。

2、對於需求變更冷靜的分析，排列優先順序以及技術可行性。快速響應使用者需求。提高使用者滿意度。

3、膽大心細，不要被需求變更任務壓垮，便壓力為動力，使自己有所成長。