敏捷并不仅仅适用于软件开发。从CIO转为CEO的Ken Accardi认为，它还能应用于CIO的变更管理策略。
创业公司能从企业CIO那里学到一些东西 ——反过来也一样。Ken Accardi在SearchCIO最近的访谈中表达了这样的观点， 他从CIO转为CEO，有创业公司和企业的经验。
作为GE Medical Systems（现在是GE Healthcare）的CIO，Accardi认识到定义良好的流程不仅强大，而且对于医疗公司非常必要。在更小的公司里，像ViryaNet（一家Verisae拥有的提供移动工作流的高效软件的供应商），以及Tele Atlas（TomTom所有的一家数字地图公司），他学习到了Agile软件开发流程适用于各种各样的事情——哪怕是变更管理策略。
Accardi后来获得了MBA学位，并且是他自己拥有的两家公司的CEO —— Ankota和Triple Aim Technologies；他期望通过这两家初创公司重新定义老年人医疗交付系统。这里，他将在GE学习到的知识以及在小型公司的经验融合在一起。他向SearchCIO分享了在流程管理和构建敏捷变更管理策略的深度思考。
你在GE工作了14年——并且担任GE Medical Systems的CIO四年时间。你是怎么达到这个高度的？
我一开始加入了X射线的产品开发团队，当时负责全球X射线机器里的软件开发。我们完成了一个现在听上去有些过时的项目，但是在当时很有革命意义，我们找到了如何通过网络在X射线机器上远程诊断问题的方法。基于这个项目的成功，我被招聘进GE，并且领导服务部门的信息技术。
你离开GE去了ViryaNet，担任业务方案副总裁，然后去了Tele Atlas，担任流程工程副总裁。对你而言，大型企业经验和小型企业经验有何不同？
我注意到的第一件事情是当你在大型企业，比如GE时，会非常关注流程，而当你加入创业公司时，所有的事情是关系和口碑。另一方面，我非常喜欢的是，当在像GE一样的大型企业时，你担任的是完成某个角色的工作，而在小企业里，则会参与到销售，市场和业务的很多领域。我非常喜欢这样广度的体验。为什么流程管理是这么值得学习的概念？
如果你问[William Edmunds]Deming，他会说，简言之，如果将一个好员工放在坏流程里，流程每次都会赢。这是他的研究所证明的……当在小创业公司时，成功取决于人们之间的关系，但是如果想要让公司扩张，就需要有强大的流程，这样人们才能理解各自的工作，达到快速和高效。在GE里很好得理解了如何招聘以及评估人才，如何关注于要求汇款或者要求现金这样的循环里，我学习了六西格码和精益六西格码，以及走出流程使其更快更高效并且更少出错——这些都是很有用的技能，我能够用在小型企业里加速它们的成长和成熟。在小型企业和创业公司里，是否缺乏对流程的重视？
绝对。有一些很好的书，比如Geoffrey Moore的Crossing the Chasm讨论了创业公司的不同阶段——需要关注什么以及需要构建什么流程。因此这里有很多故事，谈论可以和疯狂专注，对他们的想法或者设备或者任何东西非常有激情的人们一起创建一个公司。但是要是真的去运行公司，并且扩张到几亿美元，这就要求很多人一起工作，这时候流程很关键。
当你在GE时，关注于保持内部技术的先进和运行。但是在小型企业和你的创业公司里，关注于为公司客户群构建产品。这样不同的角度是否改变了你的方式？
我一直认为无论设计是为内部还是外部所用，都必须关注于业务的成功，并且必须以用户为中心。从GE出来后，改变最大的事情是现在所有东西都是敏捷开发，我会鼓励大家使用敏捷开发，不管是为外部还是内部客户构建东西。这是最大的变革——改变了关注需求如何管理，产品如何开发，如何重新规划优先级以及如何在进行中评估。向员工介绍敏捷时最困难的是什么？
最困难的部分是，一般公司里更多的资深员工来自于瀑布式开发方式的世界。因此还是会出现这样的情况，在缺少信息时想要指派项目的日期。历史已经证明这样的方法论在软件开发、内容开发和市场的领域，是有缺陷的。如果你构建的是硬件，那么的确需要瀑布式开发，因为所用工具有循环周期，但是当谈论的是软件时，事实证明关注于很小的各个部分，可以把事情完成。
敏捷中最大最重要的部分是，持续重新评估需求。以我的敏捷经验，当启动项目时有100个需求，那么在产品完成时，可能会抛弃其中的30或35个需求，并且添加了另外35或40个新需求。如果在瀑布式里完成，你会首先构建这100个需求，并且再花费六个月或者一年的时间才能发现缺失部分，企业没有经济条件这么去做。我们经常听到变更管理的重要性，及其如何困难。以你在GE和小型企业的经验，是否能给CIO一些建议，关于如何构建成功的变更管理策略？
大多数人认为敏捷是构建软件的方式，但是我认为它也是变更管理的好方法。这里有个古老的比喻：怎么才能吞下大象？答案是：一次一口。当有人反对改变时，可以说，“让我们在一到两件事情上试一个月，完成后再回来看看学到了什么，以及接下来该怎么办。”
我是敏捷的忠实拥护者。在小公司更容易做敏捷，但是也有一些大企业的成功案例，比如EMC或Spotify，这些案例每年规模上都会加倍，并且说明了在它们的世界里是如何推进敏捷的。我认为有很多很多证据证明敏捷也是驱动变更管理的方式。在给人们提供工作前，你是否会评估他是否认同敏捷？
在员工职业生涯早期的时候，能加入一个工作良好的Agile团队是非常好的。对于他们而言，最好的方式就是赶紧加入，学习团队合作，以及在这样的环境里如何产出。如果我还在大型企业，并且尝试改进领导者团队，我会去找那些拥抱持续流程改进和短周期想法的人敏捷——，他们和构建有7000行代码的Grantt chart是不一样的人。
本文转自d1net（转载）
相关资源：七夕情人节表白HTML源码(两款)