Ⅰ 为什么程序员那么讨厌改需求
这不是“程序员”的问题，做其他行业也一样，比如策划，老板让你交一份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。为此拆东墙补西墙，从兄弟业务手里抢流量入口；甚至杀鸡取卵，以严重破坏用户体验的方式拉量。遇到这种事，程序员一定要坚持自己的原则，守住自己的底线。