蘇格蘭小說家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并不完全兼容?？窗逍Ч?/div>
抱歉通知你們一個傷心的消息。
首席信息官的自欺#7：我們有客戶服務文化。
聽到過來自幫助(臺)的竊笑嗎?對不起，服務臺?這就是你的服務臺工作人員拿菜鳥故事對罵。這不是客戶服務文化的產物。其中一個將從尊重開始。
這沒關系，因為如果他們有客戶服務文化，他們的首席信息官認為其余的業務是她的客戶。
非常糟糕的想法。它導致不合適的概念，如扣費(系統)——為爭論IT賬單而浪費時間、精力和信任的絕佳機會。
如果不完全清楚為什么“客戶服務文化”是錯誤的想法，請看看當你刪除“客戶”一詞時會發生什么。
首席信息官們應該在IT中培育服務文化。
他們怎么知道他們是否有一個這樣的文化?如果他們仍然聽到菜鳥故事，那他們就沒有。
首席信息官的自欺#8：信息安全很嚴密。
還記得敏捷流(agilefall)和清單二三事嗎?很多時候，當有一個清單時，在框框里打勾成為這一切的重點，而不是作為跟蹤的方式使用的清單。信息安全受到同樣的挑戰，尤其有合規認證時。
PCI，支付卡行業的安全標準躍入腦海，你可能記得塔吉特(Target)公司在2013年虧損了約4000萬個客戶記錄，盡管它符合PCI規定。這遠遠不是已經通過某種形式的信息安全評估的企業可能遭受的唯一數據損失。
如果首席信息官認為信息安全很嚴密，他可能是錯誤的。擔心信息安全可能會有一些漏洞的首席信息官們很可能是狀態良好的。
首席信息官的自欺#9。我們的IT治理流程確保我們只接高業務價值的項目。
讓我們再回到整個業務掛鉤問題。
IT治理應該確保只有最高價值的項目得到資助。然而，無論這個過程如何精心炮制，它仍然是通過同一班人馬來實現的，首先他們自己都沒有彼此“掛鉤”。
因此，除了估計每個項目對業務的價值外，最終決定還涉及討價還價和純粹的惡意。
再加上另一個煩人的細節：具有成本削減的好處的項目將優先于具有收益增加的好處項目。為什么呢?因為成本削減是在業務的控制之內。如果一切按計劃進行，成本都會下降。
但增加收入就要求客戶做你想讓他們做的事情。而他們通常不會去做。你不能對他們指手畫腳。你必須說服他們。
這對于你的日常行政人員來說不算壞習慣，順便說一句，但日常行政人員都不只有一個壞習慣。
想從這里得關乎利害的中心思想嗎?這就是：如果你能確定什么的話——你幾乎肯定是錯的。如果你是首席信息官，并且你確定這九個主題中的任何一個，或者就其任何其它問題，請問自己這個簡單的問題：為什么?
關鍵字：CIO
京公網安備 11010502049343號