導致IT部門身陷失敗的原因是什么？最常見的情況，就是那些本應深入剖析再行操作的所謂“行業(yè)最佳實踐”，被人們無腦執(zhí)行并毫不反思，導致本非份內的工作從天而降、成為沉重的負擔。

從建立內部客戶到成本追溯、再到堅持投資回報率，這些策略從宏觀角度看似乎都有其合理性。但在實際落地的過程中，我們往往發(fā)現(xiàn)種種所謂有助于IT成功的秘訣卻往往通向無路可走的死胡同。

把所有人都劃為自己的客戶

想沒事找倒霉嗎？那就在公司之內大聲宣布吧，除技術部門之外、所有員工都是我們的客戶，我們的工作就是超越你的一切期望。（當然，還有更作死的表述，就是「讓你滿意 」。）

IT部門之外的員工不全是客戶，他們就是普通同事而已。大家應該以更穩(wěn)定的心態(tài)跟他們平等合作，共同推動業(yè)務進步。

隨著“數字化”成為主流，信息技術如今已無處不在，幾乎嵌入到企業(yè)內的每個角落。正因為如此，精明的商業(yè)領袖才不愿再把所有內部員工都稱為自己的客戶。他們發(fā)現(xiàn)，IT部門已經成為企業(yè)中不可或缺的組成部分，正如信息技術已經成為產品和服務體系中不可或缺的組成部分一樣。別刻意強調什么，做好該做的就已經很難了。

建立SLA并把它當成合同般嚴格對待

想給自己找別扭嗎？那就整理一份嚴格的服務水平協(xié)議吧，要求“內部客戶”簽字確認，并像對待合同一樣加以執(zhí)行。

這樣一來，那幫“內部客戶”（這個詞又出現(xiàn)了）就會帶著種種IT職責之外的東西來爭取支持，你不同意就拿SLA威脅。沒錯哦，你都把人家當客戶了，哪還有平等協(xié)商的余地？

更進一步想想，如果IT部門沒能達成SLA，那“內部客戶”們會如何反應？起訴你？

請大家務必記住，成功的要訣是固定的信任關系。而除非把同事們看作一個個真實的人，否則信任根本無從談起。只有讓他們喜歡你，他們才會跟你一道解決任何問題。而合同在這方面幫不上什么忙，畢竟它的意義并不是定義關系，而是闡明在信任缺失并發(fā)生了嚴重問題時，雙方該如何處理。

順帶一提，在新冠疫情之后，相當一部分勞動力轉為遠程辦公，這意味著大量工作人員開始依賴商業(yè)/消費級ISP來獲取網絡基礎設施。

也就是說，IT部門定下的SLA已經不只作用于內部環(huán)境，你根本就不控制不了整個系統(tǒng)。

總想明確追溯成本

這又是另一個阻止信息技術普及的好辦法：追溯成本。具體實施方法有二：其一就是明確列出每個成本中心所產生的各種成本類型，包括CPU周期、SAN/NAS存儲、開發(fā)者的工作時長，還有以10分鐘為增量單位的服務器呼叫計費。

吵吧，成本追溯劃分得越細，各方之間就永遠會有吵不完的架。畢竟沒人愿意把賬單上那些模棱兩可的支出劃到自己頭上。

至于第二種實施方法，就是把公司的IT總支出按人均分攤給全體員工。這倒是沒啥可爭論的，但同時也失去了現(xiàn)實意義。

堅持追求投資回報率

沒錯，要是能在項目規(guī)劃期間就明確積極的財務回報，那當然是最好的事。但隨著IT的普遍部署和全面滲透，它已經成為企業(yè)一切運作步驟中的組成部分。這時候再強調投資回報，就相當于顛覆了傳統(tǒng)IT決策的基本思路：信息技術不再以用例為基礎進行具體批準，而只能看作一種普遍性成本要素。

只有手動操作才需要按用例審批，自動化體系是不會挨個征求意見的。

讓業(yè)務牽著IT項目的鼻子走

想要徹底解決業(yè)務/IT之間的對立關系？那就單純以軟件交付為訴求做項目規(guī)劃吧，這樣IT部門的工作內容就只有一個：按照需求和規(guī)范開發(fā)軟件，別的一概不問。

如此一來，當業(yè)務部門抱怨軟件滿足不了的他們的需求時，IT部門就永遠有話可說。因為項目開發(fā)完全是按照“業(yè)務”需求來做的，既符合規(guī)范、又符合當時的要求，有啥問題？

這里再次強調：如今的IT元素已經無處不在。這不只是說每個人都在使用IT產品，更意味著每位IT使用者都在思考要如何利用它提高自身所處業(yè)務環(huán)節(jié)的運作效率。有追求的IT部門應當以終為始、結果為先，而不能總讓業(yè)務牽著鼻子走。

給項目找“背鍋俠”

學過項目管理的朋友都知道，每個技術項目都需要有業(yè)務方面的支持者存在，否則就很難成功。但一旦把支持者理解成“背鍋俠”，那項目就幾乎完蛋了。

這里一定要把支持者跟“背鍋俠”區(qū)分開來。真正的支持者在內心深處希望項目能取得成功，并在必要時愿意承擔風險、推動項目成功，甚至不惜以自己的名聲為賭注。這，才是真正符合商業(yè)利益的IT探索。但那些被動拉來的“背鍋俠”能有這個覺悟嗎？不可能，他們一早就知道自己要背鍋，所以隨時都可能抽身跑路。

硬上云計算

云計算本身并不是策略。它只代表一種合理的假設，即每個應用程序都應該在云端運行——請千萬別把它當成技術架構中的決策前提。

明確定義的技術架構應該從服務的角度進行定義，用以切實滿足需求。當然，云計算也許就是正確的答案，但無腦上云有沒有必要？也許有、也許沒有，而且沒有的幾率明顯更大。

老話說的好：手段是為目的服務的。交付IT服務就是這個目的，而云計算只是達成目的的多種可能手段之一。

敏捷加離岸：一套致命組合

敏捷方法確實有不少好處，但其成功的先決條件之一就是有高水平且深入了解業(yè)務情況的用戶參與，這樣才能經常做小規(guī)模的路線修正。開發(fā)人員每天都能看到最新進展，并隨時通過用戶驗收測試調整前進方向。

離岸外包也有自己的長處：每小時勞動力成本更低，但卻缺乏敏捷方法所強調的高水平、深入了解業(yè)務情況的用戶的參與。考慮到全球12個時區(qū)間的巨大差異、語音障礙、文化鴻溝以及無法面對面交流的客觀局限，離岸加敏捷的組合往往會帶來災難性后果。

當然，也不是說二者組合就一定不行，但風險確實很高，也絕對不適合剛剛踏上敏捷轉型的新手IT部門。

敏捷，還是離岸？暫時請保證二中選一。

用打斷來打斷打斷

確保IT失敗的下一步，就是強行要求每個人同時處理多項任務。一心多用，這聽著多牛啊，得把運作效率提升到什么高度啊，對吧？

當然不對！同時處理多項任務的必然后果，就是降低生產力和產出質量，同時大大增加員工們的工作壓力。

每當我們要求某人停下手頭的工作、轉去處理其他事務時，請千萬牢記一點：人類不善于在多項任務間頻繁切換。我們最熟悉的是先做完一件事、再做另一件事。如若不然，大家就會在場景和心態(tài)切換上浪費大量精力。而且一項任務越是需要注意力集中，在切換之后浪費掉的時間和精力就越多。

所以想讓IT部門取得成功嗎？很簡單，留出時間讓他們先把手頭的事做完，然后再轉去處理別的工作。

兼顧多個項目

IT部門的人手永遠也不夠用，總有工作面處于排隊狀態(tài)。于是就有大聰明認為，在不同項目之間靈活調動員工能夠充分利用人力、加快成果交付速度。

真的嗎？扯淡！這樣做的唯一后果，就是所有項目都被拖得更久、浪費更多成功并拉低產出結果的質量。

想讓你的IT部門建立起良好聲譽，請制定這樣一條規(guī)則：每個開始運作的項目都應配備充足的人員，所謂“充足”是指不用等待他人加入即可保持運作、持續(xù)推進。

相信我，這樣每個項目的交付時間都會早于大雜燴式的項目切換。

消除“影子IT”

毫無疑問，當業(yè)務部門自己部署IT方案時，肯定會帶來某些隱患、至少是不可控的因素，所以IT團隊應當盡可能阻止這種情況的發(fā)生。但這只是整個故事的三分之一，另外三分之一是：業(yè)務部門之所以會選擇DIY，是因為IT部門沒有足夠的人手幫他們解決影子IT所處理的這部分業(yè)務問題。這就讓IT部門陷入了尷尬的境地——即使市面上明明有更好的替代方案，但業(yè)務部門還是被迫在用Excel處理所有工作。

至于故事的最后三分之一？那就是大家可以親自試試，看消除影子IT有沒有那么容易。首先，基于云端的應用程序就很難被發(fā)現(xiàn)。這類技術方案不僅行跡隱密，而且蔓延速度極快，往往不等IT部門“剿滅”就已經傳播到了更多項目當中。

面對任何要求，只用“是”或“否”來回應

導致IT失敗的最后、也是最致命的一種方式，就是面對任何要求都只用“是”或“否”來回應。表示拒絕，你會破壞自己跟業(yè)務部門之間的良好關系。表示接受，則是做出了無法兌現(xiàn)的承諾，而且是拉著整個IT團隊共同為你的草率承諾買單。

想要IT成功，正確的答案是“我們能做到，但前提條件是……”

這就是平等協(xié)商中的一條鐵律：無論提請項目范圍變更、軟件增強，還是在業(yè)務環(huán)境中普及平板電腦，一切決策都有相應的代價。

所以別輕易拒絕、也別什么都接受。解釋要有怎樣的條件才能滿足需求，這樣接下來雙方就能共商細節(jié)、攜手共進，而不是在毫無意義的是非之間爭個面紅耳赤。

前一種，才是解決問題之道。