可群里骂的还是我们。运维同事后来跟我说了一句：“你看，锅背好就行，别的不用解释。”
我听完心里很不是滋味。今天就把这套“IT之锅”的真相整理出来，帮你下次想骂人的时候，先停下来想一想。
有数据支持这一点：有分析指出，IT部门作为成本中心，其产出难以量化，不出事就是功劳，一出事就是全部责任。系统崩了你没提前预警，你监控失职；系统安全漏洞被攻击了，你防护不力。而系统全年99.9%正常运行的那部分，没人关心。
真相二：业务方“一句话需求”，落地全是坑
业务领导会上随口说一句“这个应该很快吧，IT实现一下”，产品经理就当需求提过来了。可一问到底要什么、给谁用、什么时间节点，一概不明确。
IT部门按着“一句话”做了，业务方说“不是这个意思，我当初说的你没理解”。改了三版，又说不符合预期。最后项目延期，业务方在老板面前一句话：“IT效率太低，响应太慢。”
这段适合转给那个天天说“这个应该很简单吧”的同事——让他看看“一句话需求”背后的真实成本。
真相三：技术债是前任埋的雷，现任来拆，拆不好全责
研究数据表明，73%的CIO表示技术债是入职后的最大挑战。老旧的基础设施、濒临烂尾的项目、糟糕的客商关系，这些不是新任IT负责人搞出来的，但得他来填坑。
填坑的过程需要花时间、花钱、花领导耐心。你花钱搞新系统，老板问“投了这么多钱，价值在哪？”你不搞，业务天天说系统难用。里外不是人。有CIO甚至调侃，公司的CIO全称是“Career Is Over”（职业生涯结束），因为每隔两年就换一任，成了“职业终点站”。
他不是能力不行。他是全能型数字化人才，却在公司里变成了“电脑坏了找小X”的那个角色。升职加薪与他无关，因为信息部门定位是“辅助部门”。
2、项目失败了别急着甩锅，先看当初谁签的字、谁定的方案。
很多数字化项目本身是业务项目，IT只是工具和落地支撑。业务没想清楚，IT怎么做得对？
3、下次系统崩了，先问“发生了什么”，而不是“谁干的”。
故障处理最怕的不是技术难题，是一边修一边还得应付群里几十条责问。
