个人网站开发的现状,湖南建设银行官网网站首页,html5电影网站模板,网站 功能需求\本文要点\\CIO#xff08;首席信息官#xff09;和IT领导者们必须重新定义他们的IT组织与其他企业之间的关系#xff0c;只有这样才能利用DevOps带来的敏捷和开发周期的缩短。\\t传统的观点认为#xff0c;IT部门是“业务”的一个独立承包商#xff0c;这样的观点阻碍了公…\本文要点\\CIO首席信息官和IT领导者们必须重新定义他们的IT组织与其他企业之间的关系只有这样才能利用DevOps带来的敏捷和开发周期的缩短。\\t传统的观点认为IT部门是“业务”的一个独立承包商这样的观点阻碍了公司通过敏捷实践来获得收益。\\tIT领导者不仅要对企业当前的IT能力集负责还要对其IT资产的潜在价值负责——公司需要以一种敏捷的方式支持未来的需求。\\t敏捷的IT环境中在“项目”的粒度上做出投资决策不再有意义基于项目不能确定成功或失败也不能确定当前的状态或进展。\\tIT领导者的作用是获取业务的结果而不是交付给它的需求而这反过来又要求我们的思考方式进行深刻的改变重新思考管理、风险、团队结构以及IT部门与企业的其他部分之间的关系。\\\在《A Seat at the Table》一书中Mark Schwartz诠释了传统的CIO角色是如何与软件开发的敏捷方法相冲突的。他在书中探讨了在敏捷环境中IT领导人应该是什么样的他建议CIO应该为IT部门设立愿景并且要对业务成果负责。\\InfoQ的读者们可以下载《A Seat at the Table》一书的书摘。\\InfoQ采访了Mark Schwartz采访的内容有Schwartz是如何看待业务和IT的交互方式的以及该如何改善它怎样的企业架构能够交付业务价值一个敏捷的管理模型是怎样的IT领导者所扮演的角色以及IT领导者该怎样消除障碍以及Schwartz对于未来CIO的一些建议。\\InfoQ是什么促使你写了这本书呢\\\Mark Schwartz当我开始写我的第一本书《 The Art of Business Value》的时候我意识到我所写的其中一个话题值得花费更多的笔墨。那本书是关于商业价值的内容包括商业价值真正的含义是什么它在IT环境中经常被滥用的现状以及它是如何指导我们的IT实践的。其中的一章是关于CIO在为IT项目进行定义和解释其业务价值方面所扮演的角色。在我进行写作的时候我发现在CIO的角色中存在着一些根本性的冲突。\\试想敏捷实践会让开发团队直接与业务代表产品负责人或者现场客户进行合作以实现价值。在这种情况下团队是独立自主的团队只需专注于满足业务需求。如果是这样的话谁还会需要IT管理者和领导者呢业务的利益相关者进行需求的定义然后由团队本身来实现这些需求。\\这个场景存在错误我想通过写一本关于它的书来探究其中存在的问题。当我对这一问题进行探究的时候它变得越来越有趣。探究的结果就是这本书《A Seat at the TableIT 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将如何支持企业实现业务成果。每一个企业的愿景都是不同的。这才是我们真正应该称之为企业架构EAEnterprise Architecture的东西尽管这个术语在过去已经有了一些不同的含义。当我在这个意义上使用这个词的时候我会认为如今的EA表示的是企业已经具备的一套技术能力也包括它的潜在能力——是企业在应对未来的需求时变得敏捷的能力。在任何时间EA都应该有一个理想的未来状态它是基于CIO对企业战略目标的理解的。\\如果当前的EA是灵活的并且具备有支持敏捷转型的潜在能力那么迁移至未来的状态就会变得更加容易成本也会更低。如果你这样想的话EA方法的实践就不再是关于约束的了——它是关于启用未来状态的。\\我们该如何转型至这种EA实践呢一种方式就是让EA变成一种亲力亲为的、有创造力的规章。EA的实践者实际上可以从软件工程师和基础架构工程师开始实践这些工程师和其他工程师是一样的。他们开发的也许是参考架构reference architectures也许是可重用的组件。他们所做的也许是重构了其他开发人员的工作使得该组件更易于重用。我想尝试的一件事是建立EA内部的“开源”社区大家可以在里面设立一个目标然后有许多开发者可以为该目标作出贡献。\\\InfoQ一个敏捷的管理模型是什么样的呢\\\Schwartz由于敏捷方法是经验性的并且它是基于审查和自适应的敏捷治理也必须是这样的。计划一个大的项目做大量的假设给它一个绿灯然后等待它被完成或者被取消这样做已经不再有意义了。相反我们必须在前进的过程中进行学习并把所有的项目计划、投资承诺和需求看做临时的在项目开始之后逐渐进行调整。例如我们基于一个功能会对用户产生价值的假设创建了这个功能在之后发现事实上并不是这样我们要做的应该是重新审视我们的计划审视我们还有哪些没有必要构建的功能或者用我们所学到的来想出一些新的有价值的功能。\\仔细想想管理总是会与瀑布方法联系在一起。我们为一个项目制定计划根据该计划作出投资决定然后试着执行这个计划因为这是作出投资决定的基础。但是现在在这个环节中出现了脱节因为我们实际要执行这个项目的方式是敏捷的它会经常变化。此外通过使用DevOps我们可以非常频繁地发布产品然后从使用记录中获取有用的信息。在传统的管理模型中这部分信息并不能用于改进投资决策因为我们的计划早已制定完成。\\\InfoQ你在书中提到“对于IT系统来说失败是可以接受的。”你对此有何看法\\\Schwartz使得我作出这一评论的原因是我从业务部门领导那里听到了这样的话“为什么能容许IT部门引入这些对业务有害的软件错误呢任何人都可能因为制造了这样的混乱而被解雇。”这个问题让我意识到我们确实坚持认为我们的其他部门从IT部门接受了许多他们称之为“错误”的东西系统宕机、硬件错误、安装后使得系统不正常工作的补丁。IT人员会认为他们的工作做得非常棒因为他们能够对这些问题进行快速相应并且展现出了他们高超的调试程序的技巧。但是企业的其他部门可能不是这么认为的。\\我不是说我们能够完全改变这种现状不确定性往往是我们工作中非常大的一个因素并且意想不到的事情往往会导致出错。但我认为我们可以从一开始就在头脑里建立起要构建高质量软件的策略通过编写好的测试和立即解决问题、通过建立冗余来达成这一策略——你可能会说还要建立良好的卫生习惯。\\\InfoQIT领导的角色在敏捷和精益的世界中该如何表现呢\\\Schwartz IT领导是负责业务成果的。我们总是这么说但是同时又把IT部门看做是一个承包商为“业务”提供产品和服务然后从中获取业务成果。IT部门总是潜藏于“在我开始做之前你首先要告诉我需求”或者是“我们只是交付了需求中所要求的产品所以它不好用不是我们的错”这样的说法背后。这不是真正意义上的关注于成果。\\对此产生改变的是通过使用DevOps、云服务等等IT领导者可以更容易地参与到同企业其它部门的学习之旅中尝试做出假设、不断改进想法、度量交付的价值以及贡献创新的业务理念。现在IT就能够真正的做到为业务成果负责。\\但是这并不意味着IT在孵化成果方面扮演着一个通用的角色。就像是CFO带来了金融知识、CMO带来了市场营销的想法一样CIO们必须要把技术专长以及技术观点带到企业中来。CIO们需要通过深厚的专业技术视角来审视业务战略决策。并且他们需要额外关注于目前所构建的技术架构的长期影响——当前的技术架构能否促进未来的敏捷性或创新呢\\\InfoQIT领导者们能做些什么来消除障碍呢\\\Schwartz我注意到有一件事情很有意思虽然发号施令command-and-control的领导方式在敏捷环境中并不那么有效但是它常常能够很好地消除障碍。我的确是有点在开玩笑但是事实摆在我们面前我们需要消除障碍有时我们需要抓住一切对我们有用的东西。障碍的出现通常是有原因的——它们出现在一些地方的时候它们能够满足一些需求。为了消除一个障碍IT领导者必须首先要找出目标intent是什么然后决定这个目标是否仍然有效如果是它仍然有效那么就要找出有什么更好的、更精简的方法来实现这个目标。\\我看到过各种各样的障碍限制条款、公司政策、现金流的限制、网络问题、关键的审批人不在办公室、丢失的文件你能想到的全都会有。一个领导者必须要利用自己的创造力找出该如何消除这些障碍这样才能保证团队不会在一个沮丧的情况下继续工作。\\\InfoQ你对未来的CIO有什么建议吗\\\Schwartz最重要的建议就是要有勇气。这听起来可能有些老套但是我的意思是IT领导者必要要意识到我们所做的工作有很大的不确定性即便是你做出了正确的决定仍然有可能会导致错误的结果。但是不论如何你都要做出正确的决定。为了让你们员工们充分发挥他们的才能你必须要替他们承担风险。这需要勇气。最后我的建议是对于IT领导者来说与其在桌子边等着不如直接去拿直接对业务成果进行问责而不是仅仅为其他业务部门提供良好的客户服务或者是仅仅交付业务部门所要求的“业务需求”。如果有必要请微笑着把另一把椅子也拉到桌上来。\\\关于作者\\Mark Schwartz 目前是Amazon Web ServicesAWS的企业战略家他与各大企业合作帮助他们从云计算中获取最大的受益。他上次的CIO角色是作为美国公民及移民服务局US Citizenship and Immigration Services的CIO他领导了一次大规模的变革向DevOps实践、云计算以及以客户为中心的设计方式进行转型。Schwartz拿到了耶鲁大学计算机科学以及哲学的硕士学位他还拿到了沃顿商学院的MBA学位。他同时还是《The Art of Business Value》和A Seat at the Table: IT Leadership in the Age of Agility的作者。\\查看英文原文Q\u0026amp;A on the Book \A Seat at the Table\
