在以技術為導向、產品不愁賣的企業，面對業務頻繁更改需求的問題，開發人員，也就是程式設計師，還是可以硬氣一點的，但是如果是銷售為導向的企業，那麼，能帶來現金的業務員確實就底氣要足一些，對於改需求的行為，程式設計師可能要忍氣吞聲一點了。
那麼，作為開發，應該如何應對呢？
1、為什麼要改需求？
是因為目前的功能不能滿足業務發展的需要了嗎？還是說，只是某個老闆看到了更酷炫的東西，覺得也想要那些效果，所以要求改需求？
是給外包客戶做的產品需要改需求，還是公司內部的產品需要改需求？
如果說，產品確實已經不能滿足業務發展需要了，那麼，無論如何都是要改的，開發人員怎麼都躲不過了。但是，如果只是老闆想要一個酷炫的功能而已，那麼，程式設計師還是可以透過和業務好好溝通，把修改需求的利弊說清楚，說不準能讓老闆改主意。
外包的產品，一般需求都是簽訂在合同裡，如果是小規模更改，不影響整體專案進度和交付，那問題不大，但如果改動很大、很頻繁，可能會影響到專案整體情況，嚴重的影響上線、影響後續資金回籠，所以，要改需求，可能涉及重新談判，相當複雜，開發人員要把改動需要的時間和人員增員情況都核算好，和領導好好溝通。
內部的話，要看修改的必要性和時間安排，有的週期長，但改動之後帶來的效果不明顯，開發還是要據理力爭，以免自己熬夜苦心寫的程式碼最終還是在冷宮待著。
程式設計師小華就遇見過這樣的事情，在做官網的時候，領導要求必須弄購物車和支付功能，必須要自己寫程式碼，為此，他熬夜做了很久，才把功能實現出來。但是後來網站上線，只是用來展示產品而已，所有下單的操作，全部連結到了電商店鋪，他辛苦加班熬夜做出來的功能，一點用也沒有。 所以，程式設計師真的需要和領導做更多溝通，瞭解清楚領導要求實現一個功能的真正目的，然後去分析這個功能會用到的機率有多大，如果幾乎用不到，可以說服領導不要增加這些需求的。畢竟有些領導也是比較外行，加功能的目的自己也不清楚的。程式設計師能說服他們不加是最好的。
2、改需求的成本誰來承擔？
是公司內部改需求，願意給開發更多時間？
還是外包客戶改需求，然後願意多付錢？
如果說，公司內部的產品要改需求，而且願意延長交付的週期，那就改好了，開發人員反正也是要幹活的。如果是外包客戶改需求，而且願意多付錢，那更要改了。“厲害”的業務員是非常善於說服客戶改需求的，把10萬的需求，改成100萬，再改成500萬的 ，只要客戶願意付出成本，而業務員挖掘出來的需求也是客戶認可的，那作為開發，還有什麼好說的？使勁幹活，反正獎金少不了。
許多程式設計師都是一心只搞技術，懶得搭理辦公室政治、辦公室八卦，更不去想跨部門交朋友、搞人際關係了。但其實，如果能內部協調好和業務部門的關係，開發人員會省力很多。
業務是和客戶打交道的，對客戶的需求最瞭解，但是多數業餘對於開發領域並不熟悉，所以他們無法把客戶的需求非常準確地體現在對產品的描述上，所以，程式設計師如果能和業務有較好的關係，透過業務對客戶的需求能有更多瞭解，在最初需求溝通、設計環節就能為開發最準備，那麼，產品的功能和客戶的要求匹配程度也就高多了，未來需要修改的地方也就少了。
總之，改需求是開發人員逃不掉的宿命，尤其是對待外包的客戶。當然，如果能在籤需求文件的時候，儘量多完善一些，後期改動會少很多。此外，開發人員也可以多和業務員交流工作量的問題，比如客戶要改需求，那麼，可能要增加多少行程式碼，需要多更多時間，牽一髮而動全身，整體的進度要延後等等，業務人員慢慢地瞭解開發的難處，也會盡量幫忙協調的。至於內部開發專案的需求，程式設計師要提升自己開發之外的業務能力，能判斷開發的產品用處在哪，都有哪些需求，哪些是必要，哪些不必要。只有這樣，程式設計師才能言之有理地去拒絕上司提出的不合理需求。
在以技術為導向、產品不愁賣的企業，面對業務頻繁更改需求的問題，開發人員，也就是程式設計師，還是可以硬氣一點的，但是如果是銷售為導向的企業，那麼，能帶來現金的業務員確實就底氣要足一些，對於改需求的行為，程式設計師可能要忍氣吞聲一點了。
那麼，作為開發，應該如何應對呢？
先分清楚更改需求的真正原因 ，以及成本誰來承擔。1、為什麼要改需求？
是因為目前的功能不能滿足業務發展的需要了嗎？還是說，只是某個老闆看到了更酷炫的東西，覺得也想要那些效果，所以要求改需求？
是給外包客戶做的產品需要改需求，還是公司內部的產品需要改需求？
如果說，產品確實已經不能滿足業務發展需要了，那麼，無論如何都是要改的，開發人員怎麼都躲不過了。但是，如果只是老闆想要一個酷炫的功能而已，那麼，程式設計師還是可以透過和業務好好溝通，把修改需求的利弊說清楚，說不準能讓老闆改主意。
外包的產品，一般需求都是簽訂在合同裡，如果是小規模更改，不影響整體專案進度和交付，那問題不大，但如果改動很大、很頻繁，可能會影響到專案整體情況，嚴重的影響上線、影響後續資金回籠，所以，要改需求，可能涉及重新談判，相當複雜，開發人員要把改動需要的時間和人員增員情況都核算好，和領導好好溝通。
內部的話，要看修改的必要性和時間安排，有的週期長，但改動之後帶來的效果不明顯，開發還是要據理力爭，以免自己熬夜苦心寫的程式碼最終還是在冷宮待著。
程式設計師小華就遇見過這樣的事情，在做官網的時候，領導要求必須弄購物車和支付功能，必須要自己寫程式碼，為此，他熬夜做了很久，才把功能實現出來。但是後來網站上線，只是用來展示產品而已，所有下單的操作，全部連結到了電商店鋪，他辛苦加班熬夜做出來的功能，一點用也沒有。 所以，程式設計師真的需要和領導做更多溝通，瞭解清楚領導要求實現一個功能的真正目的，然後去分析這個功能會用到的機率有多大，如果幾乎用不到，可以說服領導不要增加這些需求的。畢竟有些領導也是比較外行，加功能的目的自己也不清楚的。程式設計師能說服他們不加是最好的。
2、改需求的成本誰來承擔？
是公司內部改需求，願意給開發更多時間？
還是外包客戶改需求，然後願意多付錢？
如果說，公司內部的產品要改需求，而且願意延長交付的週期，那就改好了，開發人員反正也是要幹活的。如果是外包客戶改需求，而且願意多付錢，那更要改了。“厲害”的業務員是非常善於說服客戶改需求的，把10萬的需求，改成100萬，再改成500萬的 ，只要客戶願意付出成本，而業務員挖掘出來的需求也是客戶認可的，那作為開發，還有什麼好說的？使勁幹活，反正獎金少不了。
協調好內部關係，儘量清楚客戶需求，開發前期工作打好基礎。許多程式設計師都是一心只搞技術，懶得搭理辦公室政治、辦公室八卦，更不去想跨部門交朋友、搞人際關係了。但其實，如果能內部協調好和業務部門的關係，開發人員會省力很多。
業務是和客戶打交道的，對客戶的需求最瞭解，但是多數業餘對於開發領域並不熟悉，所以他們無法把客戶的需求非常準確地體現在對產品的描述上，所以，程式設計師如果能和業務有較好的關係，透過業務對客戶的需求能有更多瞭解，在最初需求溝通、設計環節就能為開發最準備，那麼，產品的功能和客戶的要求匹配程度也就高多了，未來需要修改的地方也就少了。
總結總之，改需求是開發人員逃不掉的宿命，尤其是對待外包的客戶。當然，如果能在籤需求文件的時候，儘量多完善一些，後期改動會少很多。此外，開發人員也可以多和業務員交流工作量的問題，比如客戶要改需求，那麼，可能要增加多少行程式碼，需要多更多時間，牽一髮而動全身，整體的進度要延後等等，業務人員慢慢地瞭解開發的難處，也會盡量幫忙協調的。至於內部開發專案的需求，程式設計師要提升自己開發之外的業務能力，能判斷開發的產品用處在哪，都有哪些需求，哪些是必要，哪些不必要。只有這樣，程式設計師才能言之有理地去拒絕上司提出的不合理需求。