瓶颈总是似乎总是产生自最好的意图，但是它们必须被根除——必须被打破。从治理到手动配置，下面来说说是什么阻碍了你的IT组织提供结果的能力。

现在是时候面对一个冷酷的事实：你的IT部门太慢了。这是好的意图产生的不好的结果，但在业务中，意图并不重要。

IT什么时候会变得很慢?每当业务的任何部分都要等待IT交付货物时，那就是很慢的时候。如今的神奇行话可能是“创造价值的时间”，但真正的指导原则是“超越竞争对手”。如果IT没有做到这个，你可以确信组织的业务主管已经失去了对你的耐心。

想加速你的IT部门吗?首先要摆脱一些使其减速的东西——说白了就是瓶颈。以下十二个地方就是你的着眼点。忽略了你就要承担风险。

IT瓶颈之一：治理

委员会是老式治理方法。由于治理对IT所做的一切起到带头作用，委员会减缓了他们所接触的一切事宜，尽管你尝尽了各种方法，但将委员会作为治理的核心将使IT蜗速前行。

就大小而论。每增加一个委员就会减缓决定;超过五个成员进展就会慢如爬行，因为达成共识的可能性荡然无存了。

如果委员们认为自己不是信息技术领导者，而是选区的代表，不然就不会得到公平的份额，那么情况就会更糟。这种委员会将会一直争论不休，而不是解决共同的问题。

然后还有会议日程安排。速度节拍器为委员会管理的每一个项目树立了榜样。如果一个委员会一个月才开一次会，那么等待决定的任何事情都等待一个月。你正在进行的项目有多少可能会遇到这样的瓶颈?

如何解决这个问题?使文化成为新的治理。将其视为道路上的车道标志，将指导委员会降级为护栏的角色——当所有其它方面都失败时，还有他们来使IT不会陷入深渊，而只有当所有其它方面都失败时不得已而为之。

让文化担起重任。如果每个人都明白什么是最重要的并关注它，那么大多数治理是多余的。

IT瓶颈之二：多任务

员工的多任务处理有一个简单的规则：别这么做!

对于软件开发项目尤其如此，研究表明，每次中断都会造成开发人员的生产力下降15分钟。但是，对于应用程序开发来说为真的，对IT人员必须集中精力的其它所有情况也是如此。

挑战并不在于知道你必须避免多任务;而是如何避免它。答案就在企业项目管理办公室。它应该有一个不可侵犯的规则：所有项目都必须人手充足，否则不能启动。

什么是人手充足的项目?一个从来不必等到某个团队成员可用的项目。将并发项目的数量限制在可以完全配备的人数上，那么团队成员就不必多任务。

结果：每个项目不仅完成得更快，而且整个项目组合将会更快完成。

IT瓶颈之三：项目

传统上，组织通过项目实现新技术。设计越复杂，项目越大。但是随着项目越来越大，当产生实质性延迟的可能性近乎必然时，故障的风险也呈几何级数增加。

考虑将你的努力整理成发布版本。发布版本将离散的功能增强捆绑起来用于回归、压力测试和部署。依靠发布版本而不是项目，你可以利用IT管理的最可靠的启发式方法之一：功能增强成功了，而项目失败了。

顺便说一下，如果你走这条路，你不必把它描述为任何激进的东西。你可以称之为scrum，享受它的一路陪伴。

不要停在那里。将开发工作纳入发布版本仍然会造成延误。典型的scrum冲刺是一个月的时间，这为每个业务变化建立了一个每月速度，不包括必须等待变更咨询委员会(CAB)的会议(另一个治理委员会)。

所以始终贯彻持续整合和部署——一言蔽之即devops。将测试自动化，将每个软件变更进行持续整合，并立即将每一个微小的变更投入生产。有了如此微小的变更，CAB是多余的。

毕竟，一个错置的逗号会导致某物爆炸的时代已经远离我们而去。

IT瓶颈之四：手动配置

开发团队可以在几分钟左右的时间在云中配置完整的环境，或者可以在几个月左右的时间对IT操作进行相同的环境要求。

这不是内在的限制。这是一个选择。分钟比几个月短，由于公共云提供商已经完善了该技术，更好的选择昭然若揭。

启用自动化，并授权开发人员自己处理配置。

IT瓶颈之五：偏爱借口胜过集成

新功能创造新价值。但是在大多数IT工场中，新功能在确保软件更改不会破坏公司的自定义编程的点对点批量接口的蜘蛛网(或毛球)方面处于次要位置。

用精心设计的集成系统清理接口混乱，项目团队加快速度，测试所需的时间更短，部署更加顺利。

然后再进一步：将“信息技术”变成“集成系统”，其工作是通过标准API提供对公司核心应用程序组合的可靠访问，这些API将数据和功能公开为安全，定义明确的服务。

IT瓶颈之六：抑制影子IT

阴影IT——即业务部门部署的系统——会导致问题。尤其是，有了影子IT，建立在破旧基础上的局部自动化是规则，而不是例外。

但影子IT忠实地做着业务需要的事情。而且它不必等IT治理流程开绿灯，所以它可以提供业务现在的需求。

把它看作是外包应用程序团队的一个免费资源，这些团队拥有聪明的业务分析师，但他们是糟糕的架构师。

照亮阴影IT。给它一点支持，而不是试图杜绝它。作为交换，即使在计算使用符合IT隐喻建筑规范的隐喻管道和布线来重构其设计所需的努力之后，您也可以增加带宽。

如果你将IT变成集成系统，你也可以将该API提供给公司的影子IT团队，同时解决局部自动化问题。

IT瓶颈之七：坚持100%的解决方案

IT的本能就是使一切防弹。但是为一个每隔1000次交易就攻击系统的案例编写代码所需的时间和为一天发生几百次的案例编写代码是一样的。

从IT的久远年代汲取的教训是：为主要的案例编程，并将其余作为手工处理的例外。

电脑擅长主要案例。人类善于例外。

IT瓶颈之八：创建数据仓库

选择一个字儿来描述典型的数据仓库项目，它可能会是“晚点”。

好吧，这是两个字儿。告我吧。但数据仓库由于难以设计OLAP数据结构而总是慢一拍，这些数据结构被优化来回答他们现在要问的问题而没有人知道他们会问出这样的问题。

输入NoSQL。使NoSQL有趣的不仅仅是它处理大数据量的能力。更有价值的是它现在可以接受数据的能力，当以后要查询组织形式时，NoSQL还可以让分析师弄清楚其组织形式。

相比之下，让Hadoop疾速实现的正是这种“按需模式”的质量。

IT瓶颈第之九：强调TCO

你的决策者是否忘记成本会带来好处?

瞧，任何一个笨蛋都可以削减成本。诀窍在于削减成本而不损害交付。这就是总体拥有成本(TCO)发挥作用的地方，而且没有发挥好的作用。

除了打消人们对功能的念头，TCO并不关心功能。毕竟，降低成本的最简单的方法是提供和支持功能较弱或不太得力的东西。少用=较低成本。

因为不可侵犯的其中一条指标规则而强调TCO，这是不可避免地会发生的事情：你不会去测量任何你得不到的东西。这包括IT所能创造的价值。

此外，如果每个人的关注点都是降低成本，那么就没有人会专注于加快速度。如果速度不是优先事项——遑论本该有的优先事项——速度根本不会产生。

IT瓶颈之十：迫使创新者进入“高保真”IT架构

企业过去常常坚持与昨天一样的明天。他们要求防弹，永不丢失数据并始终提供正确的答案的“高保真”系统，。

现在，创新与防弹一样重要。这是未来;这就是竞争优势产生的地方?

不要强迫创新者——例如影子IT——进入“高保真”IT架构。当创新者弄清楚事情并使未来发生时，给他们一个属于自己的隔离空间。只要他们成功了就有足够的时间来使他们的创新高保真。

IT瓶颈之十一：允许自满的文化

即使经营良好的IT工场也可能会过时，特别是那些当有人尝试创新事物而未果“对人们问责”而不是恭喜他们承担风险的的公司。

自满的文化放慢了运营，因为没有人认为有必要加快速度。毕竟，这就是我们在这里的惯常做事方式。

如果这就是你所拥有的文化，那就努力改变现状。另一个选择就是无聊至死。

IT瓶颈之十二：建立疏远的业务/ IT关系

你认为哪些可以更快地给出结果：疏远的形式，其中IT“协商”服务水平协议，同时要求其业务“客户”“批准需求和规范”，或以“你试图完成什么，我们怎样才能帮上忙?”开始的非正式对话，

很多专家将正式方法称为“最佳实践”。忽略它们吧。采用超最佳实践。培养强有力的非正式关系，绝不谈判。

为什么呢?因为谈判是针对坐在桌子对面的人。

理论上，IT和其它业务处在同一立场——难道不是吗?

本文转自d1net（转载）