| 摘要：企业软件项目可能会砸了你的饭碗，所以IT负责人规划和安排好项目，以便能够及早发现和纠正问题，或者及早叫停项目，这很重要。软件项目失控后经常上演的一幕是，最高层的IT官员疲于同时应付太多的项目，因而等到弄明白情况变得非常糟糕时，已经为时太晚。因而，要做的第一件事就是，确保你将时间花在了正确的项目上。 |
如果是风险最高的项目，项目主管和技术主管都直接向我报告，而不是向那么副总裁报告。这么做的目的是，至少有三个人能够独立地了解项目开展得如何。(传统的体系结构是项目主管和技术主管向负责项目的官员报告，但这会导致信息被负责官员过滤掉。)
项目主管在这种体系结构中很重要。若是大型项目，通常会有众多项目主管向另外几个负责官员报告。把项目计划协调起来，要求项目团队制作准确的状况报告，以及评估哪些方面遇到了麻烦，这是一项艰巨的任务。让项目主管直接向我报告为这个人提供了对信息提出质疑的默认权力。
测试软件是引入独立视角、降低风险的另一个机会。几年前，我将应用副总裁岗位改成了测试副总裁岗位，并组建了一个独立的测试部门。我的意图是，将测试放在与开发同等的地位上，改进关键软件的质量，并且让我可以听到关于项目的另一个声音。测试副总裁也直接向我报告。
规划和安排好项目以便降低技术风险同样很重要。桥梁工程师并不负责桥梁的设计和制造，而是负责桥梁测试：开着卡车通过桥梁，看看会不会垮掉。同样，还没有找出所有技术风险、解决问题，就不要构建或安装软件。
七八年前在联邦快递公司构建一个名为Customer Fusion的集成数据库时，我们遇到了好多的技术问题;只有先解决了这些问题，才可以安全地开始进行开发工作。其中的首要问题是：消息层平台能否以所需的交易处理速度来运行?
技术主管在找出问题、设计测试执行方案、监管测试执行情况以及分析结果方面发挥了重要作用。针对Fusion，我们在硬件供应商的实验室，采用实际数据构建了测试环境。安排的计划是让消息层达到所需的性能，故意让一些处理器出现故障以测试故障切换，以及模拟其他场景。没想到那家供应商的产品出了故障，花了好几个星期才解决故障。不过，一旦解决了那些性能问题，项目就按计划顺利进行，技术和业务方面都取得了成功。
要是每一个企业软件项目方面的技术风险都事先全面考虑到该有多好。近15年前，在智傲物流有限公司(GeoLogistics)进行业务整合期间，我们需要把三个应付账款系统换成一个新系统。我的业务同事想要甲骨文系统，技术专家们则想要IBM——AIX平台上的DB2数据库，那是我们公司的标准。甲骨文公司坚称，其AP软件在DB2和甲骨文数据库上都能顺利运行;但我们的承包商告诉我，据他所知，没有人把甲骨文AP放在DB2数据库上。可是我把他的提醒当成了耳边风。
我只晓得，甲骨文和DB2数据库处理读写锁定的方式存在重大差异;却不晓得甲骨文编程员不知道这种差异。我们开始安装甲骨文AP时，由于严重的编译错误，一些模块楞是加载不上去。这个技术难题迫使我们只好编写程序，以解决甲骨文AP问题;但要是我采用了上面概述的设计、测试和构建模型，原本是可以避免这些问题的。
遏制、切换和应急方法
我从这件事当中明白了调节、转换和应急方法在尽量降低项目实施风险方面具有的重要性。
调节方法控制新流程或新产品的实施，从一个软件转移到功能几乎一样的另一个软件时，特别有用。比如说，一家公司更新定价系统时，它需要精心设计一项向上扩展的计划，以便在实时运行条件下，将新旧系统的结果作一对比。我多次用过这种方法，我们每一回都能发现新旧软件存在的错误。
转换方法是指启用和停用某个流程或产品，常常与调节方法结合使用。在上面这个定价系统例子中，新的定价逻辑会有转换机制来启用和停用定价系统。有几次我看到新系统投入运行，结果却立即被撤出市场。如果营销失误搞砸了成千上万客户的发货清单，这绝对成了一个IT问题;IT人员得花好几个星期的时间才能编写好代码，恢复如实。
我要求在每一个企业软件项目计划中都要有应急方法。应用软件开发团队总是抱怨，调节、转换和应急方法大大增加了成本和时间。大多数应用开发团队更偏爱“在失败中前进”——匆忙中解决问题。但有时候迫使开发团队考虑这些风险管理方法，可以让他们设计出更好的软件。与其他以构建和安装软件系统为业的人一样，我也遇到过棘手和失败的项目。但是没一个项目造成惨重的后果。关键就是规划和安排好企业软件项目，消除所有的已知风险，然后设计好团队结构，从尽可能多的人获得独立视角，然后倾听他们的意见。
责任编辑：Honey
评论表单加载中...
