需求的改动不在计划之中
“谋杀一个程序员最简单的方式是，让他改三次需求”虽然是一句玩笑话，但充分表达的需求的变更对程序员的影响之大。其实只要是设计和真正在干货的工种，在面临需求变动的时候就会产生很大的影响。
实际上很多需求的变更，不在版本开发计划之中，由于缺乏有效项目管理和版本管理，程序员就沦为了一台机器，成为了版本迭代的苦力。叫苦不迭。
需求改动背后可能隐藏了更多需求
一个需求变更，也许是一个小的按钮的改动，从软件设计上，初生牛犊不怕虎的程序员小张，在产品经理的一顿忽悠下，没经过评审就直接开干了。
殊不知，哪怕是一个按钮的增加或删除，他后面可能影响了一系列功能的变化，而这些变化后续都是需求，这些需求，可能完全不在版本迭代是主线上。有可能导致技术债务增多。
所以不要轻信一个人说这个功能很简单，几分钟之类的话，很可能这是一个无底洞。
BUG震荡
修改一个需求，改动一行代码，从程序员角度看，可能要重构某一部分代码，重构可能带来巨大的工程风险，形成更多缺陷，给程序员带来巨大的技术压力，后期可能需要偿还更多的技术债务，这个程序员不加班都难。
所以稳定的工程框架和牛逼的技术负责人牵头，做需求评估是非常重要的。
项目延期加班风险
改动需求，需要评估，需要重新排计划，这势必打乱原来的计划，如果市场不允许时间上的推迟，那么加班的风险非常之大。
加班往往很可能是项目延期的前兆，笔者见过不少团队，天天加班，天天改BUG,天天改需求，每个版本都会延期，都会被老板臭骂。
所以笔者看来，加班可以，但请不要是用来过多的偿还技术债务。作为一个团队需要更多的时间分析到底是什么导致的加班这个很重要。
笔者看到过一些年轻的开发人员，白天改需求，晚上加班改昨天写的BUG，这是恶性循环，需要更高一层的人，来解决这个问题，而不是这个年轻开发人员本身，毕竟他的技术积累是需要时间的，合理的安排任务和跟踪任务非常重要。年轻开发人员容易迷失开发节奏，他是一个小成员，但最终会成为项目的一个很大的风险。
敏捷开发也许是一条必经好的路
笔者个人毕竟推行敏捷开发，短平快的迭代和各自例会，能保证项目信息的对等和产品精细程度更好的把握。
笔者曾经待过一个6人的敏捷开发团队，每日有15分钟早会，各自发言2分钟，团队负责人，需要知道每个人昨天干了什么，今天干了什么，有什么问题。
版本启动前需要开启版本冲刺会议，确认任务细节、明确责任，确保信息对等在团队内部。
版本结束后需要开启版本复盘会议，总结存在的问题，这些问题规划到下面哪一个版本，哪一些问题是牛皮癣，需要做专题，用1周的实际去全力解决。
团队内部一定需要有自己的节奏，不能轻易被其他部门打乱，那这样团队才有发言权，才能掌握更多，不然就会沦为其他部门的工具，任人摆布，这句话可能不好听，但现实中，太多这样的例子，很多程序员、运维人员，沦为了其他部门随意使唤的“佣人”
所以你是一个精彩改动需求的程序员，可能不是你的问题，可能是你的技术负责人更多有问题，他更需要反省，只是他比你工资待遇要多，他要想更多，解决这些问题。你更多的是按部就班，不要被外部打扰，如果你经常被其他部门的人打扰，而你由不是部门负责人，拿就是这个门没控制好，出问题，团队内部要关起门来解决问题。提升团队战斗力，帮公司解决问题，输出价值。
