\

本文要点

\\

• CIO（首席信息官）和IT领导者们必须重新定义他们的IT组织与其他企业之间的关系，只有这样才能利用DevOps带来的敏捷和开发周期的缩短。\\t
• 传统的观点认为，IT部门是“业务”的一个独立承包商，这样的观点阻碍了公司通过敏捷实践来获得收益。\\t
• IT领导者不仅要对企业当前的IT能力集负责，还要对其IT资产的潜在价值负责——公司需要以一种敏捷的方式支持未来的需求。\\t
• 敏捷的IT环境中，在“项目”的粒度上做出投资决策不再有意义；基于项目，不能确定成功或失败，也不能确定当前的状态或进展。\\t
• IT领导者的作用是获取业务的结果，而不是交付给它的需求，而这反过来又要求我们的思考方式进行深刻的改变，重新思考管理、风险、团队结构以及IT部门与企业的其他部分之间的关系。\

在《》一书中，Mark Schwartz诠释了传统的CIO角色是如何与软件开发的敏捷方法相冲突的。他在书中探讨了在敏捷环境中IT领导人应该是什么样的，他建议CIO应该为IT部门设立愿景，并且要对业务成果负责。

InfoQ的读者们可以下载。

InfoQ采访了Mark Schwartz，采访的内容有：Schwartz是如何看待业务和IT的交互方式的，以及该如何改善它；怎样的企业架构能够交付业务价值；一个敏捷的管理模型是怎样的；IT领导者所扮演的角色以及IT领导者该怎样消除障碍；以及Schwartz对于未来CIO的一些建议。

InfoQ：是什么促使你写了这本书呢？

\

Mark Schwartz：当我开始写我的第一本书《 》的时候，我意识到我所写的其中一个话题值得花费更多的笔墨。那本书是关于商业价值的，内容包括商业价值真正的含义是什么，它在IT环境中经常被滥用的现状，以及它是如何指导我们的IT实践的。其中的一章是关于CIO在为IT项目进行定义和解释其业务价值方面所扮演的角色。在我进行写作的时候，我发现在CIO的角色中存在着一些根本性的冲突。

\\

试想：敏捷实践会让开发团队直接与业务代表（产品负责人或者现场客户）进行合作以实现价值。在这种情况下，团队是独立自主的，团队只需专注于满足业务需求。如果是这样的话，谁还会需要IT管理者和领导者呢？业务的利益相关者进行需求的定义，然后由团队本身来实现这些需求。

\\

这个场景存在错误，我想通过写一本关于它的书来探究其中存在的问题。当我对这一问题进行探究的时候，它变得越来越有趣。探究的结果就是这本书：《A Seat at the Table：IT Leadership in the Age of Agility》。

\

InfoQ：这本书的受众有哪些呢？

\

Schwartz：我认为，IT领导者需要重新定义他们与企业其他部门之间的关系，因此，这本书是给他们写的：CIO们以及他们的领导团队。该书为改善IT部门与企业其他部门之间的关系提供了实践指导，并在IT战略的制定中采用了敏捷和DevOps的概念。

\\

第二部分受众是广大的敏捷和DevOps社区。敏捷主义者们不会过多的谈论CIO和高级IT领导者，他们更倾向于关注团队。他们总是在驱动组织进行转换的话题中提到IT领导者，IT领导者通常是导致他们的组织采取敏捷的一个因素。但是，在这之后呢？

\\

由于这是一本关于IT部门和企业其它部分之间关系的书，我认为对于那些想要更好地理解如何与IT部门来进行合作完成业务目标的IT领导和管理者来说，这将是一个非常有趣的话题。

\

InfoQ：在这本书中，你提到了IT部门经常被视为一个被企业所控制的承包商。我们是如何陷入这种困境的呢？

\

Schwartz：当信息技术首次进入商界时，它是令人恐惧的，而且似乎是不可预测的。能够管理这项技术的人看起来有点奇怪（让我们面对现实吧，事实的确如此）。因为商界人士对IT界的起因和影响知之甚少，他们开始认为IT界的人在摆弄那些没有商业价值的东西，就像是在玩一种叫IT的玩具。当他们看到IT项目总是迟于预期并且超出预算的时候，它就更加加强了这一想法：很明显是由于极客们在做那些对项目成功没有贡献的事情，才使得IT项目迟于预期很多。实际上，真正的原因可能是IT工作是在一个高度不确定的环境中完成的，但是原因并不明了。

\\

因此，非IT行业的人觉得他们需要某种方式来“控制”IT项目，并研究了很多方法来实现这一目标。业务部门为IT部门准备了一系列的需求，要求IT部门给出一个定价，然后会以该价格进行交付。这难道不是你和承包商进行交易的流程吗？并且，IT部门应该提供具有良好客户服务——当然，所谓的客户是企业中的非IT人员。之后业务部门建立起一个管理流程，确保IT部门一直在做所谓的正确的事情。我们经常会谈到“IT和业务”，就好像它们是两个分开的、毫不相干的事情一样。所有这一切都与承包商模型一致。退后一步，好好想一想：除了IT部门，企业中还有谁需要巴结自己的同事，就好像同事是自己的顾客一样？除了IT部门，还有谁会被同事给出“需求”，还需要按需求进行交付？

\

InfoQ：是什么使得改变IT部门与业务部门的交互方式变得如此困难呢？

\

Schwartz：有许多事情阻碍了变革。

\\

首先，请注意，这个承包商模型与瀑布模型是完全一致的。业务部门把他们的需求丢到了墙上给IT部门看，IT部门就需要制定一个计划然后坚持执行。因此，当我们试图转型至敏捷时，在某种程度上我们就破坏了已经建立起来的整个结构，一种对IT部门的功能进行完全控制的结构。非IT人员头脑中浮现出的最明显的问题就是：如果没有了gantt图（甘特图），如果需求在不断的变化，我们该如何掌控一个IT项目呢？如果我们不能衡量IT项目是否遵守了计划、保持了预算，我们怎么才能知道它做的是好是坏呢？这些问题是正常的问题吗？还是之前的控制为先的模型中所遗留的问题呢？

\\

第二个问题是，我们还没有完全抛掉那些老套的概念。老观念认为：IT人员都是极客，他们不懂该如何用非技术语言来阐述事情，他们很可能会去用技术解决问题，而不是专注于业务本身；业务人员都是些毫无头绪的人，都是些能说会道的人，他们经常提出一些不可能完成的要求，并且他们经常会设法绕过IT政策。然而根据我的经验，大多数IT人员都对支持业务非常感兴趣，尽管他们喜欢使用某项技术，但他们还是会找到更好的方法来满足业务需求；大多数的业务人员也都是很有技术头脑的。

\\

第三个问题是，我们所建立的刚性流程（unyielding processes）和监督机制（oversight mechanisms ）是基于那些老旧的模型的。但凡是在组织想要进行转型的地方，你都能感受到这种情况的出现。各种组织政策、合规制度、限制政策、IT标准、批示流程以及严格的预算实践。有许多糟粕被放在组织的管理中，放到了那些认为管理IT就是对它进行控制的地方。

\

InfoQ：我们该如何才能将企业架构从阻碍开发的架构转型为能够交付业务价值的架构呢？

\

Schwartz：我的观点是，CIO需要为IT设置一个愿景，阐释清楚IT将如何支持企业实现业务成果。每一个企业的愿景都是不同的。这才是我们真正应该称之为企业架构（EA，Enterprise Architecture）的东西，尽管这个术语在过去已经有了一些不同的含义。当我在这个意义上使用这个词的时候，我会认为如今的EA表示的是企业已经具备的一套技术能力，也包括它的潜在能力——是企业在应对未来的需求时变得敏捷的能力。在任何时间，EA都应该有一个理想的未来状态，它是基于CIO对企业战略目标的理解的。

\\

如果当前的EA是灵活的，并且具备有支持敏捷转型的潜在能力，那么迁移至未来的状态就会变得更加容易，成本也会更低。如果你这样想的话，EA方法的实践就不再是关于约束的了——它是关于启用未来状态的。

\\

我们该如何转型至这种EA实践呢？一种方式就是让EA变成一种亲力亲为的、有创造力的规章。EA的实践者实际上可以从软件工程师和基础架构工程师开始实践，这些工程师和其他工程师是一样的。他们开发的也许是参考架构（reference architectures），也许是可重用的组件。他们所做的也许是重构了其他开发人员的工作，使得该组件更易于重用。我想尝试的一件事是建立EA内部的“开源”社区，大家可以在里面设立一个目标，然后有许多开发者可以为该目标作出贡献。

\

InfoQ：一个敏捷的管理模型是什么样的呢？

\

Schwartz：由于敏捷方法是经验性的，并且它是基于审查和自适应的，敏捷治理也必须是这样的。计划一个大的项目，做大量的假设，给它一个绿灯，然后等待它被完成或者被取消，这样做已经不再有意义了。相反，我们必须在前进的过程中进行学习，并把所有的项目计划、投资承诺和需求看做临时的，在项目开始之后逐渐进行调整。例如，我们基于一个功能会对用户产生价值的假设创建了这个功能，在之后发现事实上并不是这样，我们要做的应该是重新审视我们的计划，审视我们还有哪些没有必要构建的功能，或者用我们所学到的来想出一些新的有价值的功能。

\\

仔细想想，管理总是会与瀑布方法联系在一起。我们为一个项目制定计划，根据该计划作出投资决定，然后试着执行这个计划，因为这是作出投资决定的基础。但是现在在这个环节中出现了脱节，因为我们实际要执行这个项目的方式是敏捷的，它会经常变化。此外，通过使用DevOps，我们可以非常频繁地发布产品，然后从使用记录中获取有用的信息。在传统的管理模型中，这部分信息并不能用于改进投资决策，因为我们的计划早已制定完成。

\

InfoQ：你在书中提到“对于IT系统来说，失败是可以接受的。”你对此有何看法？

\

Schwartz：使得我作出这一评论的原因是，我从业务部门领导那里听到了这样的话：“为什么能容许IT部门引入这些对业务有害的软件错误呢？任何人都可能因为制造了这样的混乱而被解雇。”这个问题让我意识到，我们确实坚持认为，我们的其他部门从IT部门接受了许多他们称之为“错误”的东西：系统宕机、硬件错误、安装后使得系统不正常工作的补丁。IT人员会认为他们的工作做得非常棒，因为他们能够对这些问题进行快速相应，并且展现出了他们高超的调试程序的技巧。但是企业的其他部门可能不是这么认为的。

\\

我不是说我们能够完全改变这种现状，不确定性往往是我们工作中非常大的一个因素，并且意想不到的事情往往会导致出错。但我认为，我们可以从一开始就在头脑里建立起要构建高质量软件的策略，通过编写好的测试和立即解决问题、通过建立冗余来达成这一策略——你可能会说，还要建立良好的卫生习惯。

\

InfoQ：IT领导的角色在敏捷和精益的世界中该如何表现呢？

\

Schwartz： IT领导是负责业务成果的。我们总是这么说，但是同时又把IT部门看做是一个承包商，为“业务”提供产品和服务，然后从中获取业务成果。IT部门总是潜藏于“在我开始做之前，你首先要告诉我需求”或者是“我们只是交付了需求中所要求的产品，所以它不好用不是我们的错”这样的说法背后。这不是真正意义上的关注于成果。

\\

对此产生改变的是，通过使用DevOps、云服务等等，IT领导者可以更容易地参与到同企业其它部门的学习之旅中，尝试做出假设、不断改进想法、度量交付的价值以及贡献创新的业务理念。现在，IT就能够真正的做到为业务成果负责。

\\

但是这并不意味着IT在孵化成果方面扮演着一个通用的角色。就像是CFO带来了金融知识、CMO带来了市场营销的想法一样，CIO们必须要把技术专长以及技术观点带到企业中来。CIO们需要通过深厚的专业技术视角来审视业务战略决策。并且他们需要额外关注于目前所构建的技术架构的长期影响——当前的技术架构能否促进未来的敏捷性或创新呢？

\

InfoQ：IT领导者们能做些什么来消除障碍呢？

\

Schwartz：我注意到有一件事情很有意思：虽然发号施令（command-and-control）的领导方式在敏捷环境中并不那么有效，但是它常常能够很好地消除障碍。我的确是有点在开玩笑，但是事实摆在我们面前，我们需要消除障碍，有时我们需要抓住一切对我们有用的东西。障碍的出现通常是有原因的——它们出现在一些地方的时候，它们能够满足一些需求。为了消除一个障碍，IT领导者必须首先要找出目标（intent）是什么，然后决定这个目标是否仍然有效，如果是它仍然有效，那么就要找出有什么更好的、更精简的方法来实现这个目标。

\\

我看到过各种各样的障碍：限制条款、公司政策、现金流的限制、网络问题、关键的审批人不在办公室、丢失的文件，你能想到的全都会有。一个领导者必须要利用自己的创造力，找出该如何消除这些障碍，这样才能保证团队不会在一个沮丧的情况下继续工作。

\

InfoQ：你对未来的CIO有什么建议吗？

\

Schwartz：最重要的建议就是要有勇气。这听起来可能有些老套，但是我的意思是：IT领导者必要要意识到，我们所做的工作有很大的不确定性，即便是你做出了正确的决定仍然有可能会导致错误的结果。但是不论如何你都要做出正确的决定。为了让你们员工们充分发挥他们的才能，你必须要替他们承担风险。这需要勇气。最后，我的建议是，对于IT领导者来说，与其在桌子边等着不如直接去拿，直接对业务成果进行问责，而不是仅仅为其他业务部门提供良好的客户服务或者是仅仅交付业务部门所要求的“业务需求”。如果有必要，请微笑着把另一把椅子也拉到桌上来。

\

关于作者

Mark Schwartz 目前是Amazon Web Services（AWS）的企业战略家，他与各大企业合作，帮助他们从云计算中获取最大的受益。他上次的CIO角色是作为美国公民及移民服务局（US Citizenship and Immigration Services）的CIO，他领导了一次大规模的变革，向DevOps实践、云计算以及以客户为中心的设计方式进行转型。Schwartz拿到了耶鲁大学计算机科学以及哲学的硕士学位，他还拿到了沃顿商学院的MBA学位。他同时还是《》和的作者。

查看英文原文：