导致IT事务失利的12大技术陷阱

　　IT事务惨遭失利的原因何在?通常情况下，到底是哪些做法会被人们讹传为“业界最佳实践”?这些以指南、舵手、红宝书自居的“经典”方案真能为技术人员保驾护航，抑或仅仅是一味害人害己的土法偏方?

　　从建立内部客户到坚持贯彻投资回报率为基准的考核原则，很多建议从“上帝视角”来看似乎都满合理的。然而一旦放下高高在上的身段、加入到实际IT工作中来，大家往往会发现这些指导意见只是一堆毫无意义的空话屁话，甚至会将技术事务直接引向失败。

　　1. 张开怀抱，将每个人当作自己的客户

　　想要一尝败果?很简单，张开怀抱向IT部门之外的家伙们大声示好吧：“你们都是我的客户、我的上帝，我的职责就是满足各位的期望(如果怕不够糟，还可以换成‘让大家开心’)。”

　　IT部门之外的员工根本不是技术团队的客户，他们只是普通同事，与IT成员属于完全平等的协作关系。相信我，只有这种健康的组织架构才能让企业迎来良好的发展态势。

　　由于错误的传统观念，很多企业部门会把IT当成受气包一样的服务性组织，技术人员的职责就是让大家满意、哄业务人员开心——而不管这么做对于企业整体业务是否有所助益。这当然是一派胡言，企业所设立的各个部门都拥有共同的奋斗目标——抓住客户、让自己的产品及服务更有竞争力。因此IT部门的重点是让消费者宾至如归，而不是给搞业务的同事们换尿布。

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

　　想搞点更大的破坏?那就来尝试制定一套服务水平协议吧，劝说自己的“内部客户”签署这份协议，并像对待合约一样严格执行所有条款。

　　想让自己的IT事务一团糟，那就拿出大把时间来制定足以让“内部客户”全身心满意的SLA吧——无论他们提出什么无理要求，照做就是。这倒是一种与同事们建立良好关系的捷径，前提是大家还没被企业高管开除。

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

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

　　这种费力不讨好的事情相信大家都遇到过。每天都会有一帮业务人员一惊一乍地跑来声称“我的屏幕不亮啦”或者“电脑开不开机，咋整?”同学，停电了喂。虽然要向他们解释问题有种“秀才遇上兵”的无力感，但请千万别以戏谑的态度应对一切：打印机不灵?把电源插头翻转一下试试——这种恶搞只会引起反感，无法起到任何积极作用。

　　向毫无基础知识的用户解释一切会严重影响大家的工作效率，但在发现IT人员充当义务讲师时，也请不要表达自己的讥讽情绪。作为企业中的一分子，我们应当对身边的同事表达出充分的敬意。他们也许不了解技术，但他们却拥有大量我们所不熟悉的业务经验。正所谓术业有专攻，请以善意对待每一位合作伙伴。

　　不主动说明，但也不拒绝帮助，相信微笑与耐心能够弥合一切鸿沟。

　　4. 拒付技术费用

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

　　我们可以理解企业对于项目投资的谨慎性考量，也认同“真理越辩越明”的观念。但在技术运营成本面前，希望管理者能够以充满信任的胸怀支持IT团队稳健成长。

　　5. 过分关注投资回报率

　　想让关键性项目无疾而终、毫无建树?那就一门心思关注投资回报率吧。让IT部门拿出一套清晰明确、有理有据、充满经济说服力的投资回报方案，等于变相扼杀了企业的根本创新动力。只有那些过时的、已经被竞争对手玩烂了的技术项目才具备如此详尽的支持资料。真正站在时代前端、能够以全新方式提高业务部门商业执行能力、改善客户满意度的次世代方案根本不可能拥有高度细化的明细清单。但创新与蛮干不同，我们完全可以在实施过程中感受到技术给市场销售结果带来的提升——尽管IT部门无法证明，但其价值是每个人都能切实体会到的。

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

　　想一劳永逸，给业务及IT部门带来持续性的运转阻碍?制定一整套约束规范倒不失为“好”办法。对软件成品设置诸多要求、用大量制度束缚开发者手脚，企业必然会陷入发展缓慢的泥潭之中。

　　约束规范基本上可以视为官僚主义的集中体现。业务人员抱怨技术工具无法切实满足运营需求?住口!这可是完全遵循管理机制所开发出的完美产品。如果这种想当然的工具给业务带来严重损害，责任又该由谁来承担?当然是业务部门的管理者了，他们不是在规范上签字认可过了吗。

　　事实上我们不该太纠结于所谓“管理规范”，让项目按预期效果逐步开展才是正确的选择。企业为什么要投资部署新项目?满足商业执行流程中面临的需求(例如‘提高销售效率’)，而不是过分关注软件层面(例如‘采用Salesforce.com’)。

　　7. 强行指定项目主管

　　我们都知道，一旦项目管理流程缺乏一位强有力的业务主管，其成功前景将蒙上一层阴影。但为项目强行指派主管则会使一切变得乱七八糟、无法挽回。

　　我们需要名符其实的主管，而不是那种只是挂个名、实际对项目内容一无所知的官僚。这类管理者必须具备过人的胆识、与项目同荣辱共存亡的坚定信念，同时乐于承担实施过程中出现的风险。在必要的情况下，他们甚至需要抛开个人得失来维护执行效果与企业的商业利益。指望随便选定的家伙能拥有这种程度的责任心与使命感?我个人不抱任何希望。

　　8. 建立一套云计算战略

　　又是一套将IT引向歧途的好办法——建立一套云计算战略。我并不是说云计算对于提升业务缺乏现实价值，但一味活在幻想与假设中无疑会令企业陷入危险的境地。很多管理者自以为引入云技术是历史趋势，这种本末倒置的出发点往往会喧宾夺主，令原本的手段成为企业发展的目标。

　　无论如何，太过好高骛远绝不是什么明智的选择。别以为具备完善管理机制的技术架构就一定能带来服务水准的改善。大家一定要保持头脑清醒，意识到自己到底需要哪些新增服务，而云技术只是实现这些服务的途径而已。

　　这已经不算什么新理念了，成功的管理者一直在强调：形式必须以功能为基础。服务项目本身才是功能，云计算只是我们用于实现功能的形式之一。别被所谓历史趋势牵着鼻子走，只在有必要的情况下采用云技术，否则大量的准备工作及投入会使企业难以回头。

　　9. 敏捷化还是海外化?别指望一箭双雕

　　敏捷化方案确实能给业务带来积极改观，但转型获得成功的前提之一在于用户必须以全方位方式涉入其中。只有这样，我们才能以频繁而积极的细小变更不断改善业务流程，让开发人员每天都能感受到执行方式的变化，同时始终关注来自用户的反馈及使用体验。

　　业务海外化也不失为企业转型的理想方案，毕竟它在降低劳动力成本方面表现拔群。但在实施海外化的同时，我们无法保证敏捷化成功所必需的用户全方位涉入要素。由于时差、语言障碍、文化差异以及沟通渠道等方面的限制，我们恐怕只能通过网络会议处理企业执行链中的各环节交互工作。而这种笨拙的方式根本无法满足敏捷化推广的需要。

　　想要敏捷化?也想要海外化?鱼与熊掌不可兼得，选择一方优先执行吧。

　　10. 打断打断再打断

　　接下来要聊的IT陷阱完全属于好心办坏事——为每位员工分配多项任务。能够以一人之力应付多项事务，这绝对是企业管理者眼中最美好的场景，对吧?但现实总是残酷的，三心二意意味着生产效率及质量在不断下滑的同时，还给员工带来了巨大的工作压力。认为一心多用很简单?大家不妨亲自试试看。

　　当大家每次想要打断员工手头的工作，让他们转而处理其它任务时，请务必克制住自己——人跟电脑不同，我们没有多线程也没有多核心。他们最佳的工作状态就是专注于当前手里的活，并把它干净漂亮地完成掉。一旦强行遭到打断，员工都需要花费一段时间来调整状态、慢慢适应另一项工作。新任务对集中度与精确性要求越高，整个转换过程就越长，同时员工的心情也会变得越烦躁。

　　让IT事务取得成功?那就别插手，让大家安心把眼前的事处理好，再毫无负担地奔向其它项目。

　　11. 同时处理大量项目

　　IT部门自诞生以来就面临着一大致命问题：我们永远没有足够的人手来解决同事们提出的问题。某些“高智商”管理人才有感而发，决定同时在企业中部署多套管理项目，希望以这种方式彻底挖掘技术人员的工作潜力，进而满足业务团队的实际需求。

　　如果大家真的这么干了，那请务必做好心理准备：我们将面对的是费工费时、效率低下、成本高昂且毫无质量保障可言的悲惨结局。

　　我们每个人都希望自己的IT团队能够拥有良好的口碑与执行能力，为此请谨记一点：只在人员齐备的前提下启动新项目。所谓“人员齐备”，是指整个项目能够随时运作，而不会因为某个人的制度而让团队陷入闲置及等待。

　　做到这一点，大家会在工作中体验到势如破竹的快感——任务目标被一个个攻克，技术人员始终拥有饱满的工作热情。大家玩过“魔兽世界”吗?先控场、再集火，别指望一波AOE就能将敌人打垮。

　　12. 面对请求直接表态

　　最后一条，也是IT人士最常遇到的问题就是在面对请求时直接表态。如果一口回绝，那么我们与同事之间辛苦建立起的合作关系很可能就此报销。如果痛快答应，那么我们就等于是做出了承诺，同时也必须准备对所有将为此付出时间与努力的同伴做出合理的解释。

　　如果希望挽回主动、获得成功，那么正确的回答方式应该是“我们会马上着手，不过您也需要适当配合。”

　　面对请求，我们应该以客观情况为依托，拿出一套公平公开的解决方案。无论是项目方向变更、软件升级或者为本不该拥有笔记本电脑的员工配备一台，这都应该算作技术人员的责任而非义务。天下没有免费的午餐，双方共同努力才能达成理想的效果。

　　别一口回绝，也别满口答应，尝试向申请者解释满足要求所需要的条件。相信通情达理的同事会用平和的心态与大家展开讨论，而不会将其视为“是非问题”而发展成激烈争执。

　　就是这样，12条IT事务经验，12个技术执行陷阱，希望大家能从中获得一点启发。