通常情况下，到底是哪些做法会被人们讹传为“业界最佳实践”?这些以指南、舵手、红宝书自居的“经典”方案真能为技术人员保驾护航，抑或仅仅是一味害人害己的土法偏方?从建立内部客户到坚持贯彻投资回报率为基准的考核原则，很多建议从“上帝视角”来看似乎都满合理的。然而一旦放下高高在上的身段、加入到实际IT工作中来，大家往往会发现这些指导意见只是一堆毫无意义的空话屁话，甚至会将技术事务直接引向失败。

1.制定服务水平协议(简称SLA)，并像对待合约一样严格执行

想搞点更大的破坏?那就来尝试制定一套服务水平协议吧，劝说自己的“内部客户”签署这份协议，并像对待合约一样严格执行所有条款。想让自己的IT事务一团糟，那就拿出大把时间来制定足以让“内部客户”全身心满意的SLA吧——无论他们提出什么无理要求，照做就是。这倒是一种与同事们建立良好关系的捷径，前提是大家还没被企业高管开除。

但如果想要取得成功，大家就必须记住一点——合作关系的基础在于信任，如果我们不把同事当作真正的伙伴，信任是根本无法存在的。请记住一点，真正的朋友会在问题发生时拉我们一把，这才是“协作”的真正含义。而合约及协议给不了我们合作关系，它们只能划出冷冰冰的框框，指示企业员工在缺乏信任、面对麻烦时该如何为自己洗脱责任、并将其他相关人士拉下水。

2.向毫无基础知识的用户解释一切

每天都会有一帮业务人员一惊一乍地跑来声称“我的屏幕不亮啦”或者“电脑开不开机，咋整?”同学，停电了喂。虽然要向他们解释问题有种“秀才遇上兵”的无力感，但请千万别以戏谑的态度应对一切：打印机不灵?把电源插头翻转一下试试——这种恶搞只会引起反感，无法起到任何积极作用。向毫无基础知识的用户解释一切会严重影响大家的工作效率，但在发现IT人员充当义务讲师时，也请不要表达自己的讥讽情绪。

作为企业中的一分子，我们应当对身边的同事表达出充分的敬意。他们也许不了解技术，但他们却拥有大量我们所不熟悉的业务经验。正所谓术业有专攻，请以善意对待每一位合作伙伴。不主动说明，但也不拒绝帮助，相信微笑与耐心能够弥合一切鸿沟。

3.过分关注投资回报率

想让关键性项目无疾而终、毫无建树?那就一门心思关注投资回报率吧。让IT部门拿出一套清晰明确、有理有据、充满经济说服力的投资回报方案，等于变相扼杀了企业的根本创新动力。只有那些过时的、已经被竞争对手玩烂了的技术项目才具备如此详尽的支持资料。真正站在时代前端、能够以全新方式提高业务部门商业执行能力、改善客户满意度的次世代方案根本不可能拥有高度细化的明细清单。

但创新与蛮干不同，我们完全可以在实施过程中感受到技术给市场销售结果带来的提升——尽管IT部门无法证明，但其价值是每个人都能切实体会到的。

4.为IT项目制定大量约束规范

想一劳永逸，给业务及IT部门带来持续性的运转阻碍?制定一整套约束规范倒不失为“好”办法。对软件成品设置诸多要求、用大量制度束缚开发者手脚，企业必然会陷入发展缓慢的泥潭之中。约束规范基本上可以视为官僚主义的集中体现。业务人员抱怨技术工具无法切实满足运营需求?住口!这可是完全遵循管理机制所开发出的完美产品。如果这种想当然的工具给业务带来严重损害，责任又该由谁来承担?当然是业务部门的管理者了，他们不是在规范上签字认可过了吗。事实上我们不该太纠结于所谓“管理规范”，让项目按预期效果逐步开展才是正确的选择。企业为什么要投资部署新项目?满足商业执行流程中面临的需求(例如‘提高销售效率’)，而不是过分关注软件层面(例如‘采用Salesforce.com’)。

5.强行指定项目主管

我们都知道，一旦项目管理流程缺乏一位强有力的业务主管，其成功前景将蒙上一层阴影。但为项目强行指派主管则会使一切变得乱七八糟、无法挽回。我们需要名符其实的主管，而不是那种只是挂个名、实际对项目内容一无所知的官僚。这类管理者必须具备过人的胆识、与项目同荣辱共存亡的坚定信念，同时乐于承担实施过程中出现的风险。在必要的情况下，他们甚至需要抛开个人得失来维护执行效果与企业的商业利益。指望随便选定的家伙能拥有这种程度的责任心与使命感?

6.拒付技术费用

这又是一项大大阻碍信息技术发挥作用的错误做法：拒付技术费用。与其它成本压缩方案不同，在这里我们需要详细核对每一笔支出所对应的每一张发票，并分类评估其现实价值。从CPU寿命周期到SAN及NAS存储机制、到开发者工作时间、再到帮助咨询服务台处理技术问题，这一切都很难以量化标准核算价值。

另外，为了证明技术费用必要性所投入的时间与精力也构成了另一笔浪费。我们可以理解企业对于项目投资的谨慎性考量，也认同“真理越辩越明”的观念。但在技术运营成本面前，希望管理者能够以充满信任的胸怀支持IT团队稳健成长。