我总结了几种常见的变更。

产品经理被程序员砍死的最大原罪之一。我们一般把来自用户、销售、产品经理团队外的直接的外部变更称之为需求；对来自内部的对产品改进一般归结为缺陷。

关于需求与缺陷的区别，此处省去3000个字。之所以省去，是觉得真没有那么的区别。

一般需求或者缺陷纳入问题跟踪系统以后，都会有个默认优先级(medium) ，不高不低，正好中间。研发人员就那么点，需要添加的功能和需要修复的缺陷却又那么多？那么办呢？文明的说法叫排优先级，土包子一点的说法就是撕逼。谁的理由更充分、更合理、也更符合团队的口味，那哪个优先级就可以排的高一点，相反则低一点。当然也和参与这项活动的人的嗓门大小，嗓门大的优先级可以乘以一个加成系数。

以前看项目例会的时候，项目经理打开问题跟踪系统，选择几个过滤条件，比如项目、模块名称、当前活动版本，优先级为中级以上、计划发布时间等等，把系统中的问题过滤一下，然后和所有的研发人员、测试人员、产品经理等看看下面一段时间应该把哪些放前面一些，哪些优先级调低一些。

转成 Scrum 作法后，每周的例会变成了每天的站立会。这个时候主要是每个研发人员自己挑卡片，调进度等。反馈频率增加了许多，进度更加清晰、可控。

这个涉及的东西就太多了，二进制文件，XML，conf, yml 等等的变更都可以划分到配置项变更。

大家经常遇到的权限变更就属于此类，通常为对系统的某些功能、访问时间、读写权限的变更。

其实，我们在企业里工作是有着各种各样的流程的。之所以产生这么多流程是因为很多流程是经过了很多前辈的优化，这么一步一步的去做最省时省力省钱。另外一方面是如果大家都按照一个流程，效率也最高。

但流程不是一成不变的，当公司组织结构变化了、组织成熟度变化了等等，流程也需要进行相应的调整。这个时候就是流程变更。因为流程变更涉及的人员广、影响也比较大，所以流程的变更都要走正式的变更流程、所有涉及的主要人员，尤其是关键节点的人都需要正式确认。

按照既定的流程去做固然整体效率最高。但是有的时候遇到紧急情况，就需要按照紧急变更流程去走。如果依然按照平时流程去走，就太呆板、僵化、没有情怀了，同时也会带来更大的损失。比如按照惯例，一般重大节日、或者公司一年流量高峰期都不得进行系统上线。以免某些问题对流量产生巨大的影响，毁了辛辛苦苦美化的财报。但是如果真的因为流量高峰期出现了平时没发现的严重问题，这个时候就要走一个紧急变更流程，比如副总发封邮件审批下，也是可以上线的。

规矩是死的，人是活的。但是既然是规矩，就是大家评审、点头通过的流程。不能随意地去变更；出了紧急问题，走特殊处理流程可以理解，也符合常理。但是别忘记事后总结，不能把特殊处理程序当成一般流程来用。否则正常处理流程也就成了摆设。

找到适合自己公司的变更管理流程，并且贯彻下去；在后续的使用中不断的收集反馈、改进。形成一个良性循环。