业务创新取决于支撑企业的软件，像优步和Airbnb这种拥有颠覆性创意的新创企业才得以与历史悠久的大企业和行业展开竞争，所有这一切都要依赖于创意和软件的力量。然而，传统企业的IT部门还在努力按业务发展所需的速度进行交付。很少听到业务部门的领导说：“我们的IT团队响应力极强且非常迅速。” 因为IT部门通常被视为业务创新的瓶颈。在许多企业中，业务部门尽量避免和IT部门打交道，而是创建某种形式的影子IT。
传统的IT治理
DevOps原则和实践让更快交付和更高质量成为可能。然而，最大障碍来源之一却是注重IT项目和项目治理的的传统。
一个项目可能意味着一大笔投资，有限的资源迫使企业负责人谨慎地对“应批准哪些创意和计划”进行排序和规划。但无论是多么周密的打算，这种治理方式也无法满足创意经济时代所需要的速度。
事实上，IT部门运作机能失调，如需求过度、各部分部署脱节和质量问题，往往由传统的投资组合规划和项目管理方式所造成。从用户案例和需求管理角度出发。在由项目驱动的传统世界中，项目是一次性商机，企业往往会在其用户案例中得到一份详尽的“必备”功能清单。
然而，这会从一开始就带来技术债务和更多复杂性，特别是考虑到实际上只有一小部分“必备” 功能会被真正用到。最近一项调查显示，高达45%的软件功能经常是闲置的。从衡量项目是否成功的标准出发，项目团队的评估指标通常包括是否能够按时、按预算交付的能力，和其他各种质量和满意度指标。而最后期限和成本的压力可能会迫使企业作次优选择。
因此，随着进度被压缩，测试往往也会被缩略，以实现按时交付。这经常会导致产品发布时有缺陷——服务台不得不处理烂摊子，最终会降低信任度和团队合作精神。项目完成之后，项目团队往往会依据对具体技能的需求，被重新分配到其它项目上。那么积累的团队知识和智慧则会被丢弃，因为团队已解散，所以也没有进一步的措施来激励自动化投资或进行流程优化。
DevOps转变
DevOps 是一种非常不同的方案，它要求重新思考工作是如何被资助和治理的。从根本上来说，DevOps团队负责快速交付小型且高质量的版本。团队获得快速反馈，以消除瓶颈和浪费，并利用不间断的自动化让任务变得可重复且高效。
鉴于团队每年将交付至少十几个版本，它的奖励方式也不同于传统的“项目”团队。DevOps团队往往在开发、测试和生产过程中就“拥有”应用，并对其价值共同承担责任。团队减少了组员交接和任务耽搁，通过频繁的微小变动来管理业务需求、客户反馈和系统性能。
传统IT治理的困难需要用DevOps来克服。其中一个方式就是转变模式——把上述描述中的项目转为产品。关键是要重视价值和业务成果，以及员工和客户的满意度。关键区别在于：为产品融资是一项长期工作，且产品团队能够提供持续价值及业务改进，企业可依靠这些来满足需求。
我们的客户正在探索如何把传统的项目的概念演进为长期的产品导向。一些企业明确改良了产品，而另一些企业则采取更加优化的方式。无论采用哪种方法，发展融资模式的需求都是显而易见的。
产品治理与项目监管的不同之处在于，产品团队与业务团队合作，会得到长期的融资：一年、半年、或一个季度，具体情况取决于业务需求。随后产品团队会迅速交付业务驱动型创新版本，并根据持续的产品评估反馈来快速更新系统。
由于团队仍然完整，它才能够学习、改进，同时加快交付。此外，因为产品团队能够迅速交付， “可有可无”的功能负载才大大降低。
这并不意味着未来不会有项目团队，但是在大型企业中，将会出现产品和项目团队的组合。事实上，我们有望看到项目转变成一种能在创意经济中，针对业务成功提出、评估、构思新产品的方式。
====================================分割线================================
本文转自d1net（转载）