Ⅰ 為什麼程序員那麼討厭改需求
這不是「程序員」的問題，做其他行業也一樣，比如策劃，老闆讓你交一份XX策劃，提交之後老闆不滿意，需要再次修改，同樣會讓人感到煩惱，這關乎人自身的問題，不是某種職業的問題。
Ⅱ 我是一名程序員剛入職一周，已經開發一年多的游戲讓我改需求，代碼還沒熟悉，什麼也找不到，怎麼改我改
謝謝邀請。
從你的描述中，可能心中有很大不愉快，這會影響你的判斷和工作效率。趁中午午休時間簡單聊一下：
1、你的崗位和你現在說的工作問題不矛盾，是你職責所在，份內的工作而已，這沒抱怨的必要。我們公司技術部門也會出現這樣的問題，一個BUG，要連續加班幾晚上，不停修改。這是你這個崗位的工作性質決定的。
2、你現在面臨的是無法完成工作，中途接手，不熟悉，心裡煩躁，這個可以理解。但入職一周了，還沒了解自己公司開發的一個游戲邏輯，這有點說不過去，再怎麼忙，熟悉了解的這個過程所需的時間總有的吧。
3、找不到問題，就虛心請教，向前面的同事向其他高手求教，三人行必有我師，這個應該不難吧？
4、攤牌，，，，，這個太過激了。
或許是你的一時氣話吧，但很不恰當！說嚴重點就是不負責任！在我的理解中，工作中發生問題一點都不可怕，完全可以坦然面對。難以接受的是問題發生了，沒有窮盡人力沒有千方百計的去設法解決它，而是投降，撂挑子或不幹了，，，，這真的是職場大忌！
不要灰心也不要意氣用事，誰還沒遇到過麻煩事嗎？
端正態度 然後 去執行！
就這么簡單！
與你共勉。
希望對你有所幫助。 來自職Q用戶：邢先生
新官上任三把火，新員工入職三個困難，這是第一個吧？降臨一個艱巨的任務在你的頭上，公司的陳舊問題希望得到解決，這是老闆的期望！先別急著投降，也先別攤牌，認真思考一下問題在哪裡，評估同事和你個人有沒有這樣的能力能力，帶上一兩套方案，跟老闆商量這件事怎麼解決~《白日夢想家》主角米提華特的經歷說明，只要你盡全力，甚至突破自己，希望和機會總是會在最後出現的~ 來自職Q用戶：匿名用戶
Ⅲ 頻繁更改需求，為什麼會令程序員煩
比如：「殺一個程序員不需要用槍，改三次需求就可以了。」
下面把多個網友的段子綜合一下：
你去飯店，坐下來。
「服務員，給我來份宮保雞丁！」
「好嘞！」
——————這叫原始需求
大廚做到一半。
「服務員，菜里不要放肉。」
「不放肉怎麼做啊？」
「不放肉就行了，其它按正常程序做，不就行了，難嗎？」
「好的您稍等」
——————中途需求變更
廚房：
大廚：「你大爺，我肉都回鍋了」
服務員：「顧客非要要求的嘛，你把肉挑出來不就行了嗎」
大廚：「行你大爺」
然而還是一點點挑出來了
——————改動太大，部分重構
餐廳：
「服務員，菜里能給我加點腐竹嗎？」
「行，這個應該簡單。」
——————低估改動成本
廚房：
大廚：「你TMD，不知道腐竹得提前泡水？炒到一半才說？跟他說，想吃腐竹就多等半天」
服務員：「啊你怎麼不早說？」
大廚：「早說你MLGB我怎麼知道他要往宮保雞丁里放腐竹」
然而還是去泡腐竹了
——————新需求引入了新研發成本
餐廳：
「服務員，還是把肉加回去吧」
「您不是剛說不要肉嗎」
「現在又想要了」
「…好的您稍等」
——————某一功能點搖擺不定
廚房：
大廚：「日你啊，菜都炒過火了你讓我放肉？還好肉我沒扔」
服務員：「客戶提的要求你日我幹嘛？」
大廚：「你就不能拒絕他啊？啊？」
服務員：「人家是客戶嘛。」
——————甲方是大爺
餐廳：
「服務員！服務員！」
「來了來了，你好？」
「怎麼這么半天啊？」
「稍等我給您催催啊」
——————改動開始導致工期延誤
Ⅳ 作為一名程序員，你真的理解需求嗎
作為一個程序員，最重要的職責就是： 按時保質保量地完成需求開發。
像開發新業務這樣的復雜需求， PM （Proct Manager，產品經理） 一般會寫出詳細的 PRD （Proct Requirement Document，產品需求文檔） ，甚至可能會製作高保真原型。
而像調換兩個按鈕順序這樣的簡單需求，PM有可能只會口頭通知一下，最多在JIRA之類的項目管理平台上創建一條只有標題的ISSUE。
如果是有和用戶交互的需求，負責設計的部門或人員一般會提供設計圖。專業一點的話還會幫你把圖都裁好，並准備不同屏幕解析度下使用的多個尺寸版本。
當然，如果你在一個剛剛成立的創業公司，很有可能是創始人在白板前（或者是飯桌上）講了半個小時，然後就問你：「需要多長時間把它做出來？」
不管提出需求的是PM還是創始人，他們的腦海中一定為這個需求設想好了一個自洽的邏輯和形態。PRD也好，口頭宣講也罷，都是在描述這個邏輯和形態。他們提出需求，就是希望程序員能夠最大程度地還原他們的設想。
說起來簡單，做起來難。 我們可以通過一個小實驗來揭示這一點。
首先，你需要找一張長方形的紙。如果你在辦公室，那就找一張A4紙；如果你在家，那就找一張紙巾。然後按照下面的步驟進行操作：
你的作品是什麼樣子？中間開洞了嗎？邊上呢？角上呢？如果再做一次，你能完成同樣的作品嗎？
你可以拿著同樣的紙去找你的家人、同事或朋友，請他們來完成同樣的操作。在你不施加影響的前提下，他們完成的作品極有可能和你截然不同。
為什麼會這樣呢？
如果你仔細觀察他們操作的過程，就會發現：
由於每次對折都會可能產生兩種不同結果，在撕第一個角時紙的朝向有四種可能性，旋轉180度時有兩種可能。所以僅僅兩個撕角的位置，就至少有 2 x 2 x 4 x 2 = 32 種不同的可能性。
就這樣，我們還沒有考慮撕角的大小、角度的區別，還有極少數人是會沿對角線對折的……
上面撕紙的需求，其實是我自己拿了張紙隨意擺弄，然後記錄下來的操作流程。我照著這個流程，可以十分輕松地做出完全相同的作品。但是如果讓別人來做，結果就完全不一樣。其原因就是，我在完成作品的過程中，不光是按照流程進行操作，還隱含了自己的一些小習慣，卻並沒有把這些細節記錄下來。
如果把所有細節都完整地記錄下來的話，需求應該是這樣的：
同樣，PM在寫PRD時，很有可能會漏掉一些自己認為應該是「常識」，無需再進一步說明的內容。比如「把一張紙對折」，我們很容易想當然地認為，應該是沿著長邊對折，但事實上並非所有人都是這么理解「對折」的。
由於每個人的成長經歷不同，其認知結構之間必然存在差異，因此對同一概念未必持有相同的理解。 你所認為的「常識」，我可能並不知道，或者擁有和你截然不同的理解。所以程序員在看PRD時，一定要把自己對需求的理解復述出來，跟PM確定是不是這么回事。否則就容易出現開發中、提測甚至上線後發現邏輯性錯誤，需要緊急修復甚至返工的情況。
此外， 很多問題在設想階段是發現不了的，只有到了具體實施時才會暴露出來。 PRD不可能真正做到完備，也不能保證沒有錯誤和遺漏。比如一個表單需求，很可能在做的過程中發現某個非法數據case是PRD里沒考慮到的，這時的用戶交互怎麼做？文案怎麼定？這都要和PM溝通來解決，而不能自己拍腦門決定。
PRD只是需求的一個快照性描述文檔，並不是需求本身。 程序員應該對需求負責，而不是對文檔負責。 只有和PM保持溝通，不斷地細化需求，才能讓需求真正落地。當發現PRD里有不合理或者有疑問的地方時，一定要提出來讓PM進行解釋。千萬別視若無睹，甚至乾脆將錯就錯，等著看PM笑話。
如果我們拿到了一份圖文並茂、十分詳盡的PRD，是不是應該馬上照著文檔開工呢？那可不一定。
一位優秀的程序員，應該在開工之前把下面這些問題想清楚：
程序員有責任對需求方案進行review，並協助PM改進設計。 要知道，PM一般不會從技術角度對需求進行考慮，所以往往提出的並非最優方案。有時只要做一點點調整，技術實現的難度就會大大降低，卻不影響目標的達成效果。
比如某個業務需要用到日期選擇器組件，PM為此專門設計了一個，而你知道系統中某個功能頁面里有現成可用的同類組件。這時就應該和PM溝通是否可以直接復用，或者在原有組件的基礎上進行功能擴展。這樣既節省了開發資源，又保持了用戶體驗的一致。
程序員要對整個產品的可用性負責，全面評估需求可能導致的不良影響，謹慎對待有破壞性的需求。 PM由於不了解系統的底層實現和實際數據的組織方式，所以很可能無法全面地評估需求的影響面。如果程序員忽視在這方面的思考，只是機械地按部就班地執行方案，就很可能導致嚴重的線上事故。
比如要對某數據進行批量修改，在做的過程中時發現該數據有多個業務正在使用。這時就應該必須停下來和PM溝通，因為PM可能只了解自己負責的那一塊業務，不知道修改可能會對其他業務產生影響。此類需求要和相關各方溝通協商，確認修改沒有不良影響後才能繼續。
程序員要有魄力去拒絕那些明顯不靠譜的需求。 有的時候，PM提出需求的動機不是為用戶創造更多的價值或提升用戶體驗，而是為了沖績效完成自己的KPI。為此拆東牆補西牆，從兄弟業務手裡搶流量入口；甚至殺雞取卵，以嚴重破壞用戶體驗的方式拉量。遇到這種事，程序員一定要堅持自己的原則，守住自己的底線。