在历经了一个重要的软件推广后，发布经理Ken Vane深呼了一口气。“每一个VP都曾依照我们的方式，”总部设在维吉尼亚的Navy Federal信贷协会的IT变更和配置经理说。“抵押贷款、贷款、汽车贷款的人，都是一步步经历了这样的过程。”

　　VP观察了发布经理和他的团队推出一个新版本的信贷协会的应用程序来管理成员账户。Vane说，“这是一个运行还是不运行的问题，我们一直听到的是，‘运行，运行，运行，运行……’”对团队的最大安慰，就是新软件能够有效地运作起来。

　　一旦有环节出现错误，VP就会权衡利弊，然后停止软件的运行。他们要对签署的每一组发布的代码修改负责。如果一个错误出现——例如，在更新总账账户时出现一个不正确的值——那么Vane和他的团队已经发布的这一应用，将会影响成百上千的交易，最终会使交易被迫停止。

　　Vane说，这次成功的软件推广并不是偶然，其中涉及到250名员工的参与，业务部门和IT部门的分配量是50/50。发布经理和他的团队花费18个月来准备2012年11月份的升级和信贷，他们的成功涉及到以下几个方面：

　　制定一个完善的计划，对重要的升级实施控制，同时规划将要进行的升级；

　　全面测试升级软件将要运行的试生产环境；

　　密切协调业务经理和发布经理的工作；

　　更好的管理代码修改，将其与业务目标绑定在一起；

　　实行备份计划，该团队在软件发布前要试运行。

　　Vane与其他的发布经理们分享了他在发布新软件方面的意见。

　　问题：太多的自定义代码

　　发布管理项目组是对大型应用程序的重要升级，如Fidelity Services，处理超过四百万会员账户信息，他们分部在世界各地的220个分支机构的信贷协会中。Navy Federal公司自20世纪90年代以来就依赖打包应用软件，该公司是一家向美国军队成员提供银行及金融服务的非盈利公司。但多年来，该软件受到了广泛的定义，以至于难以跟踪所有的连锁部分，并且很难有效地管理软件更新。Vane说，“随着时间的推移，代码修改的主体，影响的不仅仅是一种服务，而是影响了继承这些更改代码的其他许多服务。”银行做出了去除定制化的决定，其本质是要从一个新的状态开始。“我们说，让我们记录下接口是如何工作，我们是如何相互交谈的。” 信贷协会取代了其老化的应用程序定制版本，使用了Fidelity大型软件的最新成品版本。

　　策略1：对管理代码修改实施控制措施

　　在2012年11月软件发布前的十八个月，Vane的团队坐了下来问道，“我们需要做到什么样的程度才算成功？”在过去，代码修改的过程是相当不正式的。“你将代码修改的任务输入到【软件变更和配置管理】工具上然后就可以说，任务完成了，周五我们将发布一个新的版本。”但Vane知道没有严格控制的大型软件升级计划是不可能成功的。所以团队想出了一个结构化的流程：在代码修改工作之前，员工需要填写一个变更管理票据登记，确切的指明代码修改意味着什么。例如，此次软件更新包括12个增强版的业务需求和8个新故障修复，Vane说。“在过去，代码修改是可以按照意愿来进行的。某个业务部门要求更改，我们就照做。我们是优秀的技术人才，但是我们不擅长问代码修改后的影响是什么。”

　　为了准备软件升级，Navy Federal依靠了Serena Software公司的产品，包括Serena Release Manager在内，它能够自动处理推出的新软件并且能够在软件更新之前使用这个工具，Vane和他的团队将亲自管理此次升级软件的发布，并在个Excel电子表格中追踪信息。Vane说，“现在，在拥有一个集中的仓库后，该过程变得更加容易，” Navy Federal也使用了Serena的其他三款产品：Business Manager（用于业务流程自动化），Dimensions CM（用于软件变更和配置管理）和Change Man（用于大型软件发布管理）。

　　策略2：开发一个针对代码修改的业务案例

　　指定软件升级的具体要求和故障修复是新程序的第一步。第二步要求业务经理提出修改应用程序的请求并记录下来要求修改的原因。Vane 说，“如果此次修改成功了，会在业务中产生什么样的影响？如果此次修改未成功，又会有什么样的影响？”，这种提问解释了什么是Vane和他的团队想知道的。业务经理要有快速的执行力。负责Navy Federal入站营销应用的营销经理这样说，“通过对应用程序代码的修改，实施的新业务规则将使我们能够在星期五启动一个新的营销活动。如果你不这样做，我们将损失30万美元，”Vane回忆说，“他知道自己该如何做。”

　　策略3：允许并行开发

　　当Fidelity升级计划启动时，发布经理的团队开始相信F在新的Fidelity软件推出后，暂停修改其他应用程序是有意义的。但他们很快地意识到这并没有商业意义。一个依靠Navy Federal内部应用来管理与用户对话的经理说，“不可能吧，”Vane回忆说，“无论客户需要提供新产品或者新促销，他都需要有做出改变的能力。”Vane举了一个例子。进行一个短期改进，例如一个新的存款单（CD）提供以3%的利率和500美元最低存款，其中涉及要调整应用程序代码来支持此次改进。Vane说，“我们正在做业务决策，”他的团队成员明白这些决策将驱动代码修改。

　　策略4：在试生产环境中做用户验收测试

　　所有发布管理项目都应包括某种形式的试运行。但Vane和他的团队成员对待试运行很认真——完成了从软件升级推广到生产环境试运行的整个过程。他们通过所有“后勤管理成员”，就像是真的运行一样。Vane说，“我们做了电话会议，会议上各抒己见，其中包括产线业务的VP，”这次会议团队拥有70个成员，IT部门和业务部门之间平分秋色。

　　策略5：制定召回计划——并祈祷它不会发生

　　召回计划就是因修改后的代码不稳定收回新版本，它是每个发布经理的噩梦。Vane说，“召回会涉及某些非常措施。你可能已经对数百万的数据库表进行了修改，但是，此时你不得不回到最初的版本。”为了适应这种可能性，你需要想象一下之前是什么样子的，然后将其恢复到原有状态，他说。这是一个不容易完成的任务。“但是我们必须制定召回计划。不断地进行预演。”这看上去是一种疯狂之举，但是我们CIO坚持这样做。