如果阿基里斯(Achilles)成为首席信息官，那么自欺就是他的脚跟(致命弱点)。他会确定业务—IT的挂钩、信息安全防范以及所有项目都准时到达。首席信息官们通过自我愚弄为灾难铺平了道路。

　　苏格兰小说家Walter Scott解释说：“噢，一旦我们练习欺骗的时候，我们就编织了一个错综复杂的网。”

　　但是，当目标是别人时，无论网路如何错综复杂，当我们愚弄自己的时候，没有什么比发生混乱更糟糕了。

　　我们愚弄自己——不是因为我们故意设定错误的优先事项，做出错误的决定，追求错误的目标，而是因为痴心妄想比通过玻璃眼镜来看待世界要容易得多。

　　以下是首席信息官们说谎的9个常见情况，不是对整个业务的IT员工或同事，正是对他们自己。

　　首席信息官的自欺#1：我们与业务挂钩。

　　“将IT与业务挂钩”听起来非常美好，很多首席信息官都会提供精心设计的IT治理流程，以确保这会发生。

　　只有很少的企业，无论规模大小，能与自己保持一致，这太糟糕了。与其说他们像《朱门恩怨》里的Ewings家族(Dallas’Ewings)，不如说像《舞台情愿》里的Partridge家族(the Partridges)。与业务挂钩通常意味着要么抚慰玩弄权术者，要么建立扣费系统。

　　扣费(系统)?没错，是扣费(系统)。此谓IT即勤杂工：只要你为项目提供资金，我们就会给你你想要的任何东西。

　　有了扣费(系统)，IT可能与业务不挂钩，但它与业务预算挂钩。如果这与业务挂钩，这一切都很好，如果不挂钩，那就是别人的问题。

　　首席信息官的自欺#2：升级软件的唯一原因是新版本提供重要的业务价值。

　　这听起来不仅很有说服力，而且很有执行力。提出这一点的首席信息官明确地将重点放在业务上(并与之相一致)，不能因为“为了技术而技术的支出”而受到指责。

　　甚至更好的是，IT预算可以缩减，因为它不必支付保持现状的成本。

　　但是，提出这一点的首席信息官，要么从来没有经历过“一败涂地的跳过几代技术的升级”，要么已经成功地将混乱的责任推卸给别人了。

　　软件升级是预防性维护。你要么现在付款，要么以后付款。越往后数字越庞大。

　　首席信息官的自欺#3：落后于计划的大型任务关键型项目?我们将在下一个阶段赶上并及时交付。

　　这是平常的进展：

　　业务案例：这不能令人信服。所以不管这个正在萌芽的灾难是谁的脑力劳动产物，它做了管理者自电子表格被发明之前所做的事情：他们瞎折腾直到投资回报率超过最低预期回报率，他们说服自己他们修改的假设仍然合理，即便不完全合理，至少有了运气和强大的推动力还是可行的。

　　需求和规格：估计需求和规格阶段是一件麻烦的事情。项目越大，潜伏的未知谎言就越多;每一个人都会使事情进一步复杂化。需求和规格阶段总是一种多头，但是没关系。每个人都知道你的设计越透彻，你所需的编码和测试时间就越少。我们到时候就可以弥补。

　　规划：与业务及其它挂了钩的IT，规划是从右到左进行的，从交付日期开始，回溯到任何可以做到这个的时间表。这一次轮到陷入绝望的项目经理瞎折腾直到时间表看起来合理为止，只要没有人盯得太紧。

　　他们不会这么做，因为这把他们想听到的东西告诉了他们。

　　黄色：这是项目状态，也称为无药可救的晚点，但在拒绝仍然取代现实的最后期限之前还有足够的时间。当项目达到这个阶段时，机灵的项目经理采取两项行动。首先他们挤压测试。这使得项目和团队的形势变成绿色。

　　第二，在项目毁掉他们的声誉之前他们开始找工作。

　　一级测试：这包括重新定义好“恰到好处”的尊贵地位。有了足够宽松的标准和足够的政治影响力，即使是最糟糕的代码也可能被投入生产。

　　二级测试：也称为PROD。你总是测试来测试去。唯一的问题是在软件投入生产之前或之后是否进行彻底的测试。

　　脱离轨道：新的首席信息官阻止了车毁人亡。他的前任指责项目经理。项目经理参加PMI会议就像嗜酒的人去戒酒所(AA，Alcoholic Anonymous)一样。

　　首席信息官的自欺#4：我们在做ITIL。

　　这可能看起来像语义上的吹毛求疵，但确实没有“做”ITIL这回事。ITIL是一个框架，诚如其支持者耐心地向任何愿意倾听的人解释的那样(通常是不包括我们的自欺的首席信息官的一小撮了无兴趣的受众)。

　　ITIL列出了IT必须擅长的事情。它没有规定怎么个擅长法，这也无妨，因为在所有情况下，ITIL的列表中没有任何一种方法可以一招通杀。(不要相信我，试想如果你在一个小型广告代理机构工作，你会如何经营IT，现在考虑一下如何在一个专门从事网络安全的大型政府承包商中经营它。)

　　除此之外，还有很多首席信息官将“做ITIL”等同于一个运行正常的服务台(或者至少重命名他们的帮助台，以便可以看到“服务台”)，也可能设立一个处于应用程序开发和IT运营之间的变更咨询委员会(change advisory board，CAB)，以便他们都可以怒视CAB而不是彼此瞪眼。

　　首席信息官的自欺#5。我们正在做敏捷

　　已经有IT工场从瀑布式(瀑布流)应用开发技术转移到一个或多个敏捷变体的，或者正在这样做。

　　对于每一个实际采用敏捷的人来说，大概有十几个或者更多的人是依赖某种形式的“敏捷流”，他们严格遵循Scrum的每一个形式主义而完全忽略敏捷转型的精神。

　　正如很多其它的业务和IT实践的情况一样，在列表上打勾和正确地执行复选框所记录的工作之间有一个区别。

　　而我猜想，避开了敏捷流陷阱的那一半的IT工场已经沿着另一个方向转弯：他们不是在践行敏捷开发(Agila)。他们往往在一个瀑布式开发者(waterfaller)的吩咐下已经实行了危险开发(Haphazard)，在整个工作开始之前，他们就确定敏捷注定要失败，他们尽力确保他们的预言是自我实现的。

　　首席信息官的自欺#6。我们正在做devops

　　不，你没有。你甚至没有做到敏捷。你不识字吗?

　　好吧好吧。如果你一定要知道，尽管关于devops的呼声不绝于耳，但它的支持者没有发明协作。是敏捷——而不是敏捷流——才是真材实料的东西——在devops到来之前就早早地提倡协作，尽管公允的说，IT运营不是开发人员普遍合作的对象。

　　这是devops给敏捷组合增加的东西：

　　首先，开发团队包括IT运维，出于纯粹自私的原因：他们不想等待环境被构建，他们不想等待CAB部署软件变更。二是无处不在的自动化是一个真正好的主意。不得不通过他们的步伐来手动修改软件变更简直是愚蠢的。

　　第三是，随着devops而不是最敏捷的变体，当然更不是瀑布式，软件总是处于可部署状态。不，不，不，不，不，不是可悲(的部署状态)。在大多数敏捷工场的很多令人尴尬的实施中，这意味着devops和Scrum并不完全兼容。看板效果更好

　　抱歉通知你们一个伤心的消息。

　　首席信息官的自欺#7：我们有客户服务文化。

　　听到过来自帮助(台)的窃笑吗?对不起，服务台?这就是你的服务台工作人员拿菜鸟故事对骂。这不是客户服务文化的产物。其中一个将从尊重开始。

　　这没关系，因为如果他们有客户服务文化，他们的首席信息官认为其余的业务是她的客户。

　　非常糟糕的想法。它导致不合适的概念，如扣费(系统)——为争论IT账单而浪费时间、精力和信任的绝佳机会。

　　如果不完全清楚为什么“客户服务文化”是错误的想法，请看看当你删除“客户”一词时会发生什么。

　　首席信息官们应该在IT中培育服务文化。

　　他们怎么知道他们是否有一个这样的文化?如果他们仍然听到菜鸟故事，那他们就没有。

　　首席信息官的自欺#8：信息安全很严密。

　　还记得敏捷流(agilefall)和清单二三事吗?很多时候，当有一个清单时，在框框里打勾成为这一切的重点，而不是作为跟踪的方式使用的清单。信息安全受到同样的挑战，尤其有合规认证时。

　　PCI，支付卡行业的安全标准跃入脑海，你可能记得塔吉特(Target)公司在2013年亏损了约4000万个客户记录，尽管它符合PCI规定。这远远不是已经通过某种形式的信息安全评估的企业可能遭受的唯一数据损失。

　　如果首席信息官认为信息安全很严密，他可能是错误的。担心信息安全可能会有一些漏洞的首席信息官们很可能是状态良好的。

　　首席信息官的自欺#9。我们的IT治理流程确保我们只接高业务价值的项目。

　　让我们再回到整个业务挂钩问题。

　　IT治理应该确保只有最高价值的项目得到资助。然而，无论这个过程如何精心炮制，它仍然是通过同一班人马来实现的，首先他们自己都没有彼此“挂钩”。

　　因此，除了估计每个项目对业务的价值外，最终决定还涉及讨价还价和纯粹的恶意。

　　再加上另一个烦人的细节：具有成本削减的好处的项目将优先于具有收益增加的好处项目。为什么呢?因为成本削减是在业务的控制之内。如果一切按计划进行，成本都会下降。

　　但增加收入就要求客户做你想让他们做的事情。而他们通常不会去做。你不能对他们指手画脚。你必须说服他们。

　　这对于你的日常行政人员来说不算坏习惯，顺便说一句，但日常行政人员都不只有一个坏习惯。

　　想从这里得关乎利害的中心思想吗?这就是：如果你能确定什么的话——你几乎肯定是错的。如果你是首席信息官，并且你确定这九个主题中的任何一个，或者就其任何其它问题，请问自己这个简单的问题：为什么?

　　责任编辑：DJ编辑