程序員的主要職責就是通過編程來實現需求，那麼，爲什麼很多程序員會在遇到需求的時候生氣呢？在思考這個問題前，我們先來看看下面這個視頻，也許看完後你就有了這個問題的答案！
下面這個視頻是知乎中針對該問題的一個高評答案，鏈接地址：https://www.zhihu.com/question/350940491/answer/868161494
（因爲簡書只支持騰訊及優酷視頻，騰訊視頻包含廣告，且沒有字幕，如果需要不想看廣告或者想看有字幕的視頻，請前往IT老五站點看原文：https://itlao5.com/wp/archives/1650）
視頻中五個角色可以對應爲客戶（2女士）、商務（西裝男）、產品（襯衣領帶男）、開發（短袖男屌），在討論項目時，客戶的需求五花八門、各種不合理，商務則只管接項目、認爲任何問題都可行，產品會把每個問題都拋給程序員然後又否決程序員，程序員則在提出n個問題後仍然被壓迫執行客服需求；最後程序員【被成爲】能解決任何問題的【專家】。
當然，這只是程序員生氣原因的一小部分。另外再看看知乎上的另一個高評答案：
作者：貓愛喫魚不喫耗子
鏈接：https://www.zhihu.com/question/40712955/answer/87890964
來源：知乎
去飯店，坐下來。
“服務員，給我來份宮保雞丁！”
“好嘞！”
——————這叫原始需求
大廚做到一半。
“服務員，菜裏不要放肉。”
“不放肉怎麼做啊？”
“不放肉就行了，其它按正常程序做，不就行了，難嗎？”
“好的您稍等”
——————中途需求變更
廚房：
大廚：“你大爺，我肉都回鍋了”
服務員：“顧客非要要求的嘛，你把肉挑出來不就行了嗎”
大廚：“行你大爺”
然而還是一點點挑出來了
——————改動太大，部分重構
餐廳：
“服務員，菜裏能給我加點腐竹嗎？”
“行，這個應該簡單。”
——————低估改動成本
廚房：
大廚：“你TMD，不知道腐竹得提前泡水？炒到一半才說？跟他說，想喫腐竹就多等半天”
服務員：“啊你怎麼不早說？”
大廚：“早說你MLGB我怎麼知道他要往宮保雞丁裏放腐竹”
然而還是去泡腐竹了
——————新需求引入了新研發成本
餐廳：
“服務員，還是把肉加回去吧”
“您不是剛說不要肉嗎”
“現在又想要了”
“…好的您稍等”
——————某一功能點搖擺不定
廚房：
大廚：“日你啊，菜都炒過火了你讓我放肉？還好肉我沒扔”
服務員：“客戶提的要求你日我幹嘛？”
大廚：“你就不能拒絕他啊？啊？”
服務員：“人家是客戶嘛。”
——————甲方是大爺
餐廳：
“服務員！服務員！”
“來了來了，你好？”
“怎麼這麼半天啊？”
“稍等我給您催催啊”
——————改動開始導致工期延誤
廚房：
大廚：“催你M催，腐竹沒泡好，我還得重新放油，他要想喫老的也行，沒法保質保量”
——————開發者請求重新排期
餐廳：
服務員：“抱歉，加腐竹的話得多等半天，您彆着急哈”
“我靠要等那麼久？我現在就要喫，你們能快點嗎？”
“行…您稍等”
——————甲方催活
廚房：
大廚：“我日他仙人闆闆，中途改需求又想按期交付，逗我玩呢？”
服務員：“那我問問，要不讓他們換個菜？”
大廚：“再換我就死了”
——————開發者開始和中間人PK
餐廳：
“服務員，這樣吧，腐竹不要了，換成蒜毫能快點嗎？對了，順便加點番茄醬”
——————因工期過長再次改動需求
廚房：
大廚：“我日了狗啊，你TM不知道蒜毫也得焯水啊？還有你讓我怎麼往熱菜裏放番茄醬啊？？”
服務員：“焯水也比等腐竹強吧，番茄醬往裏一倒不就行了嗎？很難嗎？”
大廚：“草。腐竹我還得接着泡，萬一這孫子一會又想要了呢。”
——————頻繁改動開始導致大量冗餘
餐廳：
“服務員，菜里加茄丁了沒有？我去其它飯店喫可都是有茄丁的”
“好好好您稍等您稍等”
——————奇葩需求
廚房：
大廚：“我去他二大爺他喫的是斯里蘭卡三流技校炒的宮保雞丁嗎？宮保雞丁裏放茄丁？？”
服務員：“茄丁抄好了扔裏邊不就行了嗎？”
大廚：“那TM還能叫菜嗎？哪個系的？”
服務員：“客戶要，你就給炒了吧。”
大廚：“MB你順道問問他腐竹還要不要，我這盆腐竹還佔着地方呢不要我就扔了”
——————奇葩你也得做
餐廳：
“服務員，還要多久能好啊”
“很快，很快…”
“再給我來杯西瓜汁。”
“…好”
“我再等10分鐘，還不好我就走了，反正還沒給錢。”
“很快，很快…”
——————黑暗前的最後黎明
10分鐘後
“咦，我上次喫的不是這個味啊？”
從廚房殺出來的大廚：“我TM就日了你的狗…”
——————最終決戰——————
你=客戶
服務員=客戶經理+產品經理
大廚=碼農
請自行轉換…
如果是你，在生活中遇到一個這樣的客戶，會有什麼想法？而幾乎每個程序員都遇到過這樣的客戶或產品經理，一個程序的需求永遠在迭代、在升級，這本身就是一項繁瑣的任務，而如果遇到一個善變的客戶+一個不會分析及拆分需求的產品經理，那麼，這個程序的繁瑣程度將成倍的增加。想想，碰到這樣的情況，程序員會不會生氣？
程序開發本就是一件繁瑣的事情，如果碰到一個不斷變更需求的用戶或者一個無腦的產品經理，那麼，程序員面臨的就是末日。老五希望所有程序員（包括我O(∩_∩)O哈哈~）遇到的都是通情達理的客戶和會拆分需求、能安排優先級、會擋需求的產品經理！
博客:IT老五 簡書：ThinkinLiu
