因為程式設計師也要同步做出更改啊，如果程式設計師很忙，需求老是變更，肯定會煩的。不過這也不可避免的，需求確實會變、不停的完善，只要提交需求時，儘量想得周全些就可以了，為了最佳化，實現效果更佳，有的變更是必須的。

這個和個人工作思維習慣有關。程式設計具有很強的邏輯性，往往一個功能點的實現背後有一整套的邏輯程式碼，如果需求變更，需要修改的地方往往很多，甚至會擾亂整個程式設計之初的架構。在工作中儘量少提需求變更，在需求調研時儘量詳細，不要返工。

需求的改動不在計劃之中

“謀殺一個程式設計師最簡單的方式是，讓他改三次需求“雖然是一句玩笑話，但充分表達的需求的變更對程式設計師的影響之大。其實只有是設計和真正在乾貨的工種，在面臨需求變動的時候就會產生很大的影響。

實際上很多需求的變更，不在版本開發計劃之中，由於缺乏有效專案管理和版本管理，程式設計師就淪為了一臺機器，成為了版本迭代的苦力。叫苦不迭。

所以不要輕信一個人說這個功能很簡單，幾分鐘之類的話，很可能這是一個無底洞。

修改一個需求，改動一行程式碼，從程式設計師角度看，可能要重構某一部分程式碼，重構可能帶來巨大的工程風險，形成更多缺陷，給程式設計師帶來巨大的技術壓力，後期可能需要償還更多的技術債務，這個程式設計師不加班都難。

所以穩定的工程框架和牛逼的技術負責人牽頭，做需求評估是非常重要的。

改動需求，需要評估，需要重新排計劃，這勢必打亂原來的計劃，如果市場不允許時間上的推遲，那麼加班的風險非常之大。

加班往往很可能是專案延期的前兆，筆者見過不少團隊，天天加班，天天改BUG,天天改需求，每個版本都會延期，都會被老闆臭罵。

所以筆者看來，加班可以，但請不要是用來過多的償還技術債務。作為一個團隊需要更多的時間分析到底是什麼導致的加班這個很重要。

筆者看到過一些年輕的開發人員，白天改需求，晚上加班改昨天寫的BUG，這是惡性迴圈，需要更高一層的人，來解決這個問題，而不是這個年輕開發人員本身，畢竟他的技術積累是需要時間的，合理的安排任務和跟蹤任務非常重要。年輕開發人員容易迷失開發節奏，他是一個小成員，但最終會成為專案的一個最大的風險。

筆者個人畢竟推行敏捷開發，短平快的迭代和各自例會，能保證專案資訊的對等和產品精細程度更好的把握。

筆者曾經待過一個6人的敏捷開發團隊，每日有15分鐘早會，各自發言2分鐘，團隊負責人，需要知道每個人昨天干了什麼，今天干了什麼，有什麼問題。

版本啟動前需要開啟版本衝刺會議，確認任務細節、明確責任，確保資訊對等在團隊內部。

版本結束後需要開啟版本覆盤會議，總結存在的問題，這些問題規劃到下面哪一個版本，哪一些問題是牛皮癬，需要做專題，用1周的實際去全力解決。

團隊內部一定需要有自己的節奏，不能輕易被其他部門打亂，那這樣團隊才有發言權，才能掌握更多，不然就會淪為其他部門的工具，任人擺佈，這句話可能不好聽，但現實中，太多這樣的例子，很多程式設計師、運維人員，淪為了其他部門隨意使喚的“傭人”

所以你是一個精彩改動需求的程式設計師，可能不是你的問題，可能是你的技術負責人更多有問題，他更需要反省，只是他比你工資待遇要多，他要想更多，解決這些問題。你更多的是按部就班，不要被外部打擾，如果你經常被其他部門的人打擾，而你由不是部門負責人，拿就是這個門沒控制好，出問題，團隊內部要關起門來解決問題。提升團隊戰鬥力，幫公司解決問題，輸出價值。

對需求方來說，可能只是需求上一個小小的改動，但是在程式角度，可能意味著需要增加一個成員，一種方法，甚至改變整個類或者結構體的結構，如果更底層一點，可能對記憶體分配本身都會造成一定的影響，而且取決於改動發生的位置，其影響可能會遍佈整個系統，從而導致一個小小的需求，卻需要大量工作來實現。

另外為了保證產品的質量，每一次程式碼改動理論上都需要進行測試避免regression，而這種小的改動可能會頻繁發生，意味著上一次測試結果還沒出來，下一次需求已經提出來了，結果就是可能會由於衝突導致一些潛在的問題沒有被發現。

程式一般會從整體需求考慮去進行一個設計，如果不停地對需求進行改動的話，設計就定不下來，一個定不下來的設計用程式碼去實現就需要在很多部分留有修改的餘地，而且這個修改會自動被傳播給所有影響物件，來避免下一次修改的時候修改不會在所有地方生效。