IT项目惨遭失利的原因何在?
通常情况下，到底是哪些做法会被人们讹传为“业界最佳实践”?这些以指南、舵手、红宝书自居的“经典”方案真能为技术人员保驾护航，抑或仅仅是一味害人害己的土法偏方?从建立内部客户到坚持贯彻投资回报率为基准的考核原则，很多建议从“上帝视角”来看似乎都满合理的。然而一旦放下高高在上的身段、加入到实际IT工作中来，大家往往会发现这些指导意见只是一堆毫无意义的空话屁话，甚至会将技术事务直接引向失败。
1.制定服务水平协议(简称SLA)，并像对待合约一样严格执行
想搞点更大的破坏?那就来尝试制定一套服务水平协议吧，劝说自己的“内部客户”签署这份协议，并像对待合约一样严格执行所有条款。想让自己的IT事务一团糟，那就拿出大把时间来制定足以让“内部客户”全身心满意的SLA吧——无论他们提出什么无理要求，照做就是。这倒是一种与同事们建立良好关系的捷径，前提是大家还没被企业高管开除。
但如果想要取得成功，大家就必须记住一点——合作关系的基础在于信任，如果我们不把同事当作真正的伙伴，信任是根本无法存在的。请记住一点，真正的朋友会在问题发生时拉我们一把，这才是“协作”的真正含义。而合约及协议给不了我们合作关系，它们只能划出冷冰冰的框框，指示企业员工在缺乏信任、面对麻烦时该如何为自己洗脱责任、并将其他相关人士拉下水。
2.向毫无基础知识的用户解释一切
每天都会有一帮业务人员一惊一乍地跑来声称“我的屏幕不亮啦”或者“电脑开不开机，咋整?”同学，停电了喂。虽然要向他们解释问题有种“秀才遇上兵”的无力感，但请千万别以戏谑的态度应对一切：打印机不灵?把电源插头翻转一下试试——这种恶搞只会引起反感，无法起到任何积极作用。向毫无基础知识的用户解释一切会严重影响大家的工作效率，但在发现IT人员充当义务讲师时，也请不要表达自己的讥讽情绪。
作为企业中的一分子，我们应当对身边的同事表达出充分的敬意。他们也许不了解技术，但他们却拥有大量我们所不熟悉的业务经验。正所谓术业有专攻，请以善意对待每一位合作伙伴。不主动说明，但也不拒绝帮助，相信微笑与耐心能够弥合一切鸿沟。
3.过分关注投资回报率
想让关键性项目无疾而终、毫无建树?那就一门心思关注投资回报率吧。让IT部门拿出一套清晰明确、有理有据、充满经济说服力的投资回报方案，等于变相扼杀了企业的根本创新动力。只有那些过时的、已经被竞争对手玩烂了的技术项目才具备如此详尽的支持资料。真正站在时代前端、能够以全新方式提高业务部门商业执行能力、改善客户满意度的次世代方案根本不可能拥有高度细化的明细清单。
但创新与蛮干不同，我们完全可以在实施过程中感受到技术给市场销售结果带来的提升——尽管IT部门无法证明，但其价值是每个人都能切实体会到的。
4.为IT项目制定大量约束规范
想一劳永逸，给业务及IT部门带来持续性的运转阻碍?制定一整套约束规范倒不失为“好”办法。对软件成品设置诸多要求、用大量制度束缚开发者手脚，企业必然会陷入发展缓慢的泥潭之中。约束规范基本上可以视为官僚主义的集中体现。业务人员抱怨技术工具无法切实满足运营需求?住口!这可是完全遵循管理机制所开发出的完美产品。如果这种想当然的工具给业务带来严重损害，责任又该由谁来承担?当然是业务部门的管理者了，他们不是在规范上签字认可过了吗。事实上我们不该太纠结于所谓“管理规范”，让项目按预期效果逐步开展才是正确的选择。企业为什么要投资部署新项目?满足商业执行流程中面临的需