IT部门必须尽一切代价避免的12大“最佳实践

导致IT部门身陷失败的原因是什么？最常见的情况，就是那些本应深入剖析再行操作的所谓“行业最佳实践”，被人们无脑执行并毫不反思，导致本非份内的工作从天而降、成为沉重的负担。

从建立内部客户到成本追溯、再到坚持投资回报率，这些策略从宏观角度看似乎都有其合理性。但在实际落地的过程中，我们往往发现种种所谓有助于IT成功的秘诀却往往通向无路可走的死胡同。

把所有人都划为自己的客户

想没事找倒霉吗？那就在公司之内大声宣布吧，除技术部门之外、所有员工都是我们的客户，我们的工作就是超越你的一切期望。（当然，还有更作死的表述，就是「让你满意 」。）

IT部门之外的员工不全是客户，他们就是普通同事而已。大家应该以更稳定的心态跟他们平等合作，共同推动业务进步。

随着“数字化”成为主流，信息技术如今已无处不在，几乎嵌入到企业内的每个角落。正因为如此，精明的商业领袖才不愿再把所有内部员工都称为自己的客户。他们发现，IT部门已经成为企业中不可或缺的组成部分，正如信息技术已经成为产品和服务体系中不可或缺的组成部分一样。别刻意强调什么，做好该做的就已经很难了。

建立SLA并把它当成合同般严格对待

想给自己找别扭吗？那就整理一份严格的服务水平协议吧，要求“内部客户”签字确认，并像对待合同一样加以执行。

这样一来，那帮“内部客户”（这个词又出现了）就会带着种种IT职责之外的东西来争取支持，你不同意就拿SLA威胁。没错哦，你都把人家当客户了，哪还有平等协商的余地？

更进一步想想，如果IT部门没能达成SLA，那“内部客户”们会如何反应？起诉你？

请大家务必记住，成功的要诀是固定的信任关系。而除非把同事们看作一个个真实的人，否则信任根本无从谈起。只有让他们喜欢你，他们才会跟你一道解决任何问题。而合同在这方面帮不上什么忙，毕竟它的意义并不是定义关系，而是阐明在信任缺失并发生了严重问题时，双方该如何处理。

顺带一提，在新冠疫情之后，相当一部分劳动力转为远程办公，这意味着大量工作人员开始依赖商业/消费级ISP来获取网络基础设施。

也就是说，IT部门定下的SLA已经不只作用于内部环境，你根本就不控制不了整个系统。

总想明确追溯成本

这又是另一个阻止信息技术普及的好办法：追溯成本。具体实施方法有二：其一就是明确列出每个成本中心所产生的各种成本类型，包括CPU周期、SAN/NAS存储、开发者的工作时长，还有以10分钟为增量单位的服务器呼叫计费。

吵吧，成本追溯划分得越细，各方之间就永远会有吵不完的架。毕竟没人愿意把账单上那些模棱两可的支出划到自己头上。

至于第二种实施方法，就是把公司的IT总支出按人均分摊给全体员工。这倒是没啥可争论的，但同时也失去了现实意义。

坚持追求投资回报率

没错，要是能在项目规划期间就明确积极的财务回报，那当然是最好的事。但随着IT的普遍部署和全面渗透，它已经成为企业一切运作步骤中的组成部分。这时候再强调投资回报，就相当于颠覆了传统IT决策的基本思路：信息技术不再以用例为基础进行具体批准，而只能看作一种普遍性成本要素。

只有手动操作才需要按用例审批，自动化体系是不会挨个征求意见的。

让业务牵着IT项目的鼻子走

想要彻底解决业务/IT之间的对立关系？那就单纯以软件交付为诉求做项目规划吧，这样IT部门的工作内容就只有一个：按照需求和规范开发软件，别的一概不问。

如此一来，当业务部门抱怨软件满足不了的他们的需求时，IT部门就永远有话可说。因为项目开发完全是按照“业务”需求来做的，既符合规范、又符合当时的要求，有啥问题？

这里再次强调：如今的IT元素已经无处不在。这不只是说每个人都在使用IT产品，更意味着每位IT使用者都在思考要如何利用它提高自身所处业务环节的运作效率。有追求的IT部门应当以终为始、结果为先，而不能总让业务牵着鼻子走。

给项目找“背锅侠”

学过项目管理的朋友都知道，每个技术项目都需要有业务方面的支持者存在，否则就很难成功。但一旦把支持者理解成“背锅侠”，那项目就几乎完蛋了。

这里一定要把支持者跟“背锅侠”区分开来。真正的支持者在内心深处希望项目能取得成功，并在必要时愿意承担风险、推动项目成功，甚至不惜以自己的名声为赌注。这，才是真正符合商业利益的IT探索。但那些被动拉来的“背锅侠”能有这个觉悟吗？不可能，他们一早就知道自己要背锅，所以随时都可能抽身跑路。

硬上云计算

云计算本身并不是策略。它只代表一种合理的假设，即每个应用程序都应该在云端运行——请千万别把它当成技术架构中的决策前提。

明确定义的技术架构应该从服务的角度进行定义，用以切实满足需求。当然，云计算也许就是正确的答案，但无脑上云有没有必要？也许有、也许没有，而且没有的几率明显更大。

老话说的好：手段是为目的服务的。交付IT服务就是这个目的，而云计算只是达成目的的多种可能手段之一。

敏捷加离岸：一套致命组合

敏捷方法确实有不少好处，但其成功的先决条件之一就是有高水平且深入了解业务情况的用户参与，这样才能经常做小规模的路线修正。开发人员每天都能看到最新进展，并随时通过用户验收测试调整前进方向。

离岸外包也有自己的长处：每小时劳动力成本更低，但却缺乏敏捷方法所强调的高水平、深入了解业务情况的用户的参与。考虑到全球12个时区间的巨大差异、语音障碍、文化鸿沟以及无法面对面交流的客观局限，离岸加敏捷的组合往往会带来灾难性后果。

当然，也不是说二者组合就一定不行，但风险确实很高，也绝对不适合刚刚踏上敏捷转型的新手IT部门。

敏捷，还是离岸？暂时请保证二中选一。

用打断来打断打断

确保IT失败的下一步，就是强行要求每个人同时处理多项任务。一心多用，这听着多牛啊，得把运作效率提升到什么高度啊，对吧？

当然不对！同时处理多项任务的必然后果，就是降低生产力和产出质量，同时大大增加员工们的工作压力。

每当我们要求某人停下手头的工作、转去处理其他事务时，请千万牢记一点：人类不善于在多项任务间频繁切换。我们最熟悉的是先做完一件事、再做另一件事。如若不然，大家就会在场景和心态切换上浪费大量精力。而且一项任务越是需要注意力集中，在切换之后浪费掉的时间和精力就越多。

所以想让IT部门取得成功吗？很简单，留出时间让他们先把手头的事做完，然后再转去处理别的工作。

兼顾多个项目

IT部门的人手永远也不够用，总有工作面处于排队状态。于是就有大聪明认为，在不同项目之间灵活调动员工能够充分利用人力、加快成果交付速度。

真的吗？扯淡！这样做的唯一后果，就是所有项目都被拖得更久、浪费更多成功并拉低产出结果的质量。

想让你的IT部门建立起良好声誉，请制定这样一条规则：每个开始运作的项目都应配备充足的人员，所谓“充足”是指不用等待他人加入即可保持运作、持续推进。

相信我，这样每个项目的交付时间都会早于大杂烩式的项目切换。

消除“影子IT”

毫无疑问，当业务部门自己部署IT方案时，肯定会带来某些隐患、至少是不可控的因素，所以IT团队应当尽可能阻止这种情况的发生。但这只是整个故事的三分之一，另外三分之一是：业务部门之所以会选择DIY，是因为IT部门没有足够的人手帮他们解决影子IT所处理的这部分业务问题。这就让IT部门陷入了尴尬的境地——即使市面上明明有更好的替代方案，但业务部门还是被迫在用Excel处理所有工作。

至于故事的最后三分之一？那就是大家可以亲自试试，看消除影子IT有没有那么容易。首先，基于云端的应用程序就很难被发现。这类技术方案不仅行迹隐密，而且蔓延速度极快，往往不等IT部门“剿灭”就已经传播到了更多项目当中。

面对任何要求，只用“是”或“否”来回应

导致IT失败的最后、也是最致命的一种方式，就是面对任何要求都只用“是”或“否”来回应。表示拒绝，你会破坏自己跟业务部门之间的良好关系。表示接受，则是做出了无法兑现的承诺，而且是拉着整个IT团队共同为你的草率承诺买单。

想要IT成功，正确的答案是“我们能做到，但前提条件是……”

这就是平等协商中的一条铁律：无论提请项目范围变更、软件增强，还是在业务环境中普及平板电脑，一切决策都有相应的代价。

所以别轻易拒绝、也别什么都接受。解释要有怎样的条件才能满足需求，这样接下来双方就能共商细节、携手共进，而不是在毫无意义的是非之间争个面红耳赤。

前一种，才是解决问题之道。