1樓：孟武文卓
毫無疑問，很多做軟體的公司，幹的是服務業的行當，它的賣點就是服務，總是讓銷售或者客戶牽著技術走這本身就是乙個問題，你她媽的乙個銷售只能給乙個方向，具體的事情不要瞎指揮，如果不尊重設計，只是為了客戶一時興起而改動，沒有人會負這個責任，你尊重技術，技術才能為你服務，你不尊重技術，技術只能糊弄你，拿啥尊重，要不拿錢，要不別不懂裝懂瞎指揮，你懂我白送給你。
2樓：程式設計師客棧
對於產品經理的需求變更，我們早就表明了態度：不願改，但也不怕改，必要時不得不改。
面對產品經理的軟硬兩手，我們早已給出了答案。
不改，大門敞開；改，奉陪到底。
經歷了十幾年風風雨雨的軟體開發，什麼樣的陣勢沒有見過？
在現實需求順利上線的偉大程序中，必然有艱難險阻驚濤駭浪。
產品經理發起的需求變更，沒有什麼大不了。
程式設計師必將堅定資訊、迎難而上，化危為機，改出一片新天地！
我是程式設計師客棧，領先的程式設計師自由工作平台。
3樓：
搞得我都想離職了，你的程式設計師跟我現在的情況是一樣。
去年加入乙個遊戲創業公司，主策就是個sb。為什麼呢？聽聽他的言論！
需求文件不用寫那麼多程式一定會來問我的！一臉巨奇怪的很有經驗的感覺。然後一天給乙個bug單我，說這裡你沒做那裡你沒做。
啊我沒做（其實文件沒寫）？還有一句話程式設計師不看文件（黑人問號）！！！
我說一下我的工作方式，我每個需求都會認真記錄筆記，然後跟策劃共同確認怎麼做。所以說，他文件沒寫老子幹嘛浪費時間給自己加個需求。
我為什麼想離職，錢也是一部分問題，但更重要的是，誰受得了你一天乙個bug單這樣的工作方式，還說老子沒做。
4樓：
可能還是too young
對我來說不加班怎麼改需求都行。反正一樣的工時一樣的給錢，改不改需求沒區別。
不改需求不也是得做新任務？
5樓：空谷
呵呵，我是前端，然後今年過完年的時候開會。
聽產品說老闆要求把去年搞了一年的專案中的前端互動方式和樣式全部換掉。
回到去座位就開啟了拉X、BOSSXX等軟體開始投遞簡歷.
6樓：代號330
兩個問題，一是專案管理者的問題，二是程式設計師的問題。首先我是技術出身，需求變更時越來越常見的事情，這個是市場環境的不斷變化，管理者沒能很好把控整個專案流程，瀑布式的開發方式在客戶價值管理和團隊管理上存在缺陷；團隊成員在變化的環境中按照需求文件程式設計，沒有及時溝通，實踐交付價值。
軟體開發就像是在衝浪，一直處在動態、不斷變化的環境中。在專案研發過程中出現的需求變化和挑戰就是你在衝浪時要應對的海浪。不管是預料之外的波浪衝擊，還是預想不到的設計失敗，在兩種情況下都要求能夠做到快速地適應變化。
在如今全球市場的背景下，如何可以靈活變通，對於乙個企業來講，已然變得至關重要，因此，IT系統擁有靈活的能力是必不可少的。敏捷開發的目的，就是讓組織機構在面臨當今商業世界日益增長的的機遇和挑戰時，能及時作出應對，其中，敏捷思想已成為乙個關鍵的促進因素。
對於個人來講，系統儲備開發知識體系，定位自身角色和職業發展也是很重要的。
7樓：魏娟娟
小妹我剛開始寫程式，系統是完成乙個目標件測試，寫完調好後交付時領導說一次要測兩個目標件，瞬間懵了，給領導解釋：程式要重寫，時間上來不及了。領導：
「你copy一下不就行了！」(ω)
8樓：李維
作為乙個程式出身的pm，你說的能理解，那麼問題來了你有pm的思維有去說服過別人沒有，沒說服的話你有不斷堅持提沒有。站在整體的角度那麼多東西你週期時間內能落地多少，能不能拍拍胸脯提前完成。問題總是公司的，乙個創業公司老闆找錢找人做專案，他失敗的風險是什麼，這麼多創業公司倒閉，所有人後續出路？
一句話，多理解，多角度，說不定你會有新視野而不在是累不累苦不苦。
9樓：團結
既然你不尊重工程師，不認可勞動成果，把它們當作受僱於你的機器。
為什麼工程師要尊重你，認可你的方案和公司，當作事業而不是隨便混口飯吃的工作呢
10樓：RockLee
這個不就是推廣的帖子麼。。來推廣他們的產品麼。。。公司就乙個技術，還不對他好點，走了也正常。別用管理銷售的辦法來管理技術，會出事的。
11樓：
你只說開週會來調動大家的積極性，沒有說有什麼具體措施，所以我理解為你只是想在會上通過一些充滿「正能量」的言辭來激勵大家。工資沒漲、獎金沒漲、職級沒公升、工作量沒減，僅僅說幾句好聽的話，又不是傳銷公司，你覺得這樣能行起作用嗎？
只有乙個程式設計師。你確定你們的技術工作量是乙個人就能承擔的嗎？我可以猜測，所有技術問題都會堆在他身上。
你會認為反正他是技術，技術問題就是他的問題，不光技術問題，與技術相關的事也是他的事。他是不是很忙很累？經常加班？
如果是的話，你是不是該考慮加人，或者換人？
程式設計師說「100多套word啊」，這句話不知道具體什麼意思，但可以推斷肯定是有很多手工操作在裡邊，要不然他不會在乎是100套還是1000套的。讓我猜一下，你是不是把編輯Word文件內容的活也給程式設計師做了？
從權責對等的原理上來說，你大手一揮，就改了需求，就改了技術路線，那你是不是也應該負責由這個改變造成的損失？那程式設計師把完成時間推遲一兩倍是不是很正常？但如果他真這樣推遲，你會欣然接受嗎？
不會吧？你會說：「為什麼這麼慢？
不就是改一下嗎？」 就是這樣把你的權力造成的責任推到了程式設計師身上。這就是欺負人啊。
這就是欺負人啊。這就是欺負人啊。人啊。。。
人啊。。。人啊。。。
如果每改一次需求，時間都再加幾個月，另外再加幾千塊錢的「改需求小費」，估計程式設計師會笑得像花一樣。
另外，Stark Einstein 指出：技能成長對程式設計師很重要。你拿人家當機器，可人家自己還要拿自己當人啊。
12樓：王子揚
看到和解我很開心，不過我很想和題主來點建議：
產品經理不是你想當就能當，你真的以為什麼人都能當？你會什麼？有什麼優勢在其他人面前？
我承認有些人靠感覺能做的不錯，然而並沒有什麼用處，並不是你想的話就能做的好。你需要系統的學習很多東西，比如心理學之類的。除了把控使用者，員工的心理也需要注意吧
13樓：賀奕凱
程式設計師不怕你改需求，怕的是你改了需求他還不知道，好不容易做完後被測試提了BUG，你在屁顛屁顛的拿著新版需求過來告訴他做的與需求不符。
14樓：王醫生
看到了樓主後面的結果，很替你高興，人家程式設計師已經很不容易了。
但是，以我個人來看，你應該是乙個想法挺多的人，想一出是一出，加上你希望用人情關係替代管理制度混亂的不足。你可以試試把你專案外包出去，這樣變更一下需求，外包公司如何處理。
所以，我認為程式設計師遲早還是會走的。
15樓：
你這和生孩子一樣，你只負責播種，挺爽！程式猿要懷胎十月把孩子造出來. 造出來各種不滿意，你特馬還讓回爐。問問你媳婦她幹麼？！
16樓：
敢情不是你做了，這頓折騰啊，你確定需求之前不調研清楚的嗎？反反覆覆的工作量對別人來說根本沒意義，對於乙個有想法想突破想進步的人來說更是浪費時間浪費生命！
17樓：高玉龍
不僅僅是程式設計師，任何員工都是根據你的需求做事，你提出明確的需求，告訴他你的期望，而他利用自己的專業技能完成你的需求，證明自身的價值。這個價值不僅僅是對於你的，還有他的自我認可。
如果你的需求反覆變，那麼意味著之前的都是無用功。那麼是個人都會很失落，而對於設計開發人員來說更是如此。因為這個專案就好像是他自己的孩子一樣，他在其中投入如此之多，結果僅僅因為你乙個變更就要做非常大的更改，甚至推倒重來。
他會覺得自己非常累，而且沒什麼成就感。設計開發其實最看重的是成就感，他們為自己的創意驕傲，靈感就如小噴泉一樣。
不明確的工作方向是管理的大忌，題主你最好去買一些管理方面的書，多學學怎麼管人管專案。
18樓：蔡桑
程式設計師最討厭的就是那種不懂技術，跟你解釋難度的時候還理直氣壯地提需求，甚至拿別人產品來舉例說什麼別人能做你為什麼做不了呢？這就好像「你看別人家小孩能考第一 ，你為什麼不能？」你覺得該不該氣？
你要麼出錢去找個你滿意的，你的任何想法都能幫你實現的那種程式設計師。要麼就在提需求的時候好好和程式設計師交流，別總認為都是人家的錯，人家消極怠工，人不做，你覺得人家不好，人家跟你說有難度，你覺得人家推辭，人家做了，完成的不好，你又不滿，人家完成了，你又不要了。我不說是誰的錯，我只說這樣吃力不討好的環境還真不是人人能忍受的。
19樓：john young
改需求真的很煩，尤其是反覆改，尤其是反覆改還嫌慢，尤其是反覆改還嫌慢還沒有加班工資，尤其是反覆改還嫌慢還不給加班工資還不調休。。。
20樓：大漠白鯊
按照全公司只有7、8個人的體量計算(其他答主有證明)，程式設計師的上級是公司的最高領導(題主)，從題主的描述來看，是不對需求進行分析和背黑鍋的。
那麼問題來了，這個程式設計師不僅僅是全棧還把產品汪的工作給包了，業內朋友們可以幫我算一下這個程式設計師一共頂了多少人的工作麼？都頂替了哪些崗位？
21樓：
身為乙個程式設計師。。我也想回答一下這個問題。。。不是說需求不允許任何變動，但是一而再再而三的變更，給我的資訊只有乙個，你自己沒想清楚。
既然需求都沒有搞明白，為啥要讓開發一遍又一遍陪著你們折騰？溝通很重要，相互理解也很重要。
22樓：北北北
不知道什麼時候開始，PM和程式猿慢慢變得越來越難相處了。需求的每一次變更，都導致程式猿為PM的試錯或者不清晰的思路買單。特別是那種不斷改，不斷試錯的情況下，讓人毫無成就感。
乙個專案，如果只把程式猿當做乙個執行崗位，不給於充分的參與感，那和生產線上每天只負責不停擰螺絲有什麼區別呢？
我不知道這個東西的設計是什麼，用來幹什麼，做成後是什麼樣，而只負責一小塊，幾乎零成就感。
什麼時候，程式猿也可以更多的去參與產品的設計，發出自己的聲音可好？乙個專案是需要乙個PM去把控，去負責各個環節的銜接，掌握大局，但是適當的把程式猿當成是你的夥伴，而不是你的乙個執行者，每次需求都定的差不多了，設計稿都出來，才告訴程式有這麼乙個需求，也是醉了。更有些人，明明只是乙個產品經理，大家是合作夥伴，偏偏擺出一副，這個產品的一切都是我說的算，我並不需要聽你的意見，你需要做的只是把我提出的問題解決了，把我想實現的實現了，或者你先做出來，我看看效果，不行再改。
當然你也不需要知道我什麼要這麼做。呵呵。
寫著寫著就成抱怨貼了。= =！
啊，願人人都獻出一點愛，友好愉快的維護世界和平吧。
程式設計師如何應對頻繁的更改需求？
需求更改頻繁一般是不合理的。假定他是合理的，比如老闆說了，改不改怎麼改我說了算，我不是給你發錢了嘛。那我們就幹，要注意以下幾點。一，讓老闆簽字畫押。頻繁的變更沒事，最忌諱不留下書面材料。每次變更都要有會議紀要，郵件傳送。避免後面扯皮。二，設計要有一定的前瞻性 如果已經知道了會經常變化，那麼就要在很多...
如何看待女生當程式設計師？
科沃IT 國內it行業公司通常是996的工作模式，程式設計師們普遍是需要加班工作很晚的，同時週末也經常需要加班。工作壓力巨大，早出晚歸，精力這方便對於女生來說確實乙個劣勢。同時女生到了一定的年紀後，都要面臨著結婚生子的問題，如果1,2年不從事程式設計師工作，這也是不利的。況且程式設計師普普遍年齡都在...
如何看待程式設計師的中年危機？
灰灰灰灰小卉卉 說實話只有不努力的軟體從業人員才會有中年危機。發生中年危機的大多都是從事一些技術含量比較低的軟體開發工作，純屬搬磚碼農。經驗豐富，技術一流的程式設計師企業是願意花大價錢去支付工資的。 小兄弟，圖樣圖森破。非頭部的網際網路企業，碼農20K就算均值了。哪來的掙人家一輩子的底氣。頭部的話，...