[[417354]]

對于企業(yè)領導者來說，很多技術決策由于考慮不充分或由于時間太短而出錯。他們希望做出明智的選擇，并且不會受到一些不利因素的影響。

當出現(xiàn)新技術時，企業(yè)領導者是否會嘗試每一項技術創(chuàng)新?企業(yè)領導者如何在沒有充分分析和盡職調(diào)查的情況下選擇技術供應商?或者由于采購經(jīng)理、項目管理者或業(yè)務利益相關者通過詳盡的研究做出技術決策，以至于企業(yè)在采用創(chuàng)新技術之后卻陷入了遺留平臺的困境?

這些決定技術購買的角色存在于許多企業(yè)中，這可能會削弱技術領導者做出明智和及時的技術選擇的能力。隨意的技術選擇會導致企業(yè)浪費精力并出現(xiàn)技術債務，而過于有條不紊的方法會減緩創(chuàng)新的步伐，并阻礙明智的冒險和敏捷文化。

這些角色可能以各種方式影響企業(yè)領導者的技術決策過程，其中包括阻礙企業(yè)的技術評估過程到影響何時投資技術以及考慮哪些產(chǎn)品或服務的決策。以下是企業(yè)領導者可能做出糟糕技術決策的12種情況。如果企業(yè)領導想做出明智的技術決策，不要執(zhí)行以下操作：

1.接受行政部門的意見作為最終決定

當企業(yè)的首席執(zhí)行官或其他有影響力的高管要求技術團隊購買和實施特定的技術解決方案時，了解其基本原理至關重要。企業(yè)領導者試圖解決什么問題?其解決方案滿足預期的程度如何?團隊領導者通常會聽從企業(yè)高管的命令，而不是采取措施使方法合理化或提出替代方案。

一種解決方案是制定和呈現(xiàn)愿景陳述的規(guī)則，重點關注問題、機會、價值主張。而精心設計的愿景陳述將定義目標，但并未規(guī)定采用哪些解決方案或實施方案。即使技術團隊代表企業(yè)高管填寫這些內(nèi)容，也經(jīng)常會引發(fā)對多種解決方案的討論。

2.未能征求或考慮客戶的意見

作為技術人員，有時會犯與企業(yè)高管相同的錯誤。他們通常會看到問題，并采用解決方案實施修復。不幸的是，企業(yè)領導者在決策過程中并沒有考慮客戶的意見，或者不了解對客戶有什么好處，或者提供不符合要求的功能。

當通過定義角色來開發(fā)最終用戶的應用程序時可能會更容易。但是，在考慮后端功能(包括基礎設施、安全功能、中間件、庫或Web服務)時，尋找客戶角色可能更具挑戰(zhàn)性。但技術人員也是業(yè)務的一部分。在實施后端技術時，架構師、業(yè)務分析師或技術主管可以充當客戶角色的代理，可以提供需求，確定驗收標準，做出權衡決策，并評價他們對實施的解決方案的滿意度。

3.忽略現(xiàn)有的標準和技術

從歷史上看，技術部門一直在努力創(chuàng)建和維護文檔以及溝通和管理標準。因此，當出現(xiàn)緊急請求或最高需求時，他們更有可能尋求新的解決方案，而不是調(diào)查和重用現(xiàn)有功能。

這種方法通常會導致冗余能力、半開發(fā)的解決方案和激增的技術債務。在研究新解決方案之前或作為其一部分添加“研究內(nèi)部解決方案”步驟是一個可以增加重用性的簡單原則。當推薦新技術時，創(chuàng)建一個流程來評估對傳統(tǒng)平臺的升級或整合具有類似功能的技術。

4.培育某種供應商和某種方法的技術文化

很多企業(yè)通常會強調(diào)“我們是一家X店”，以此來減少對其他供應商或技術的任何研究、審查和考慮。擁有首選供應商是一回事，而對第三方一無所知并阻礙采用替代方案是另一回事。

采用強大平臺的少數(shù)聲音淹沒在任何探索和實驗中可能會導致代價高昂的錯誤。技術領導者應該解決這種文化反模式，特別是當它妨礙人們提出問題或挑戰(zhàn)現(xiàn)狀的時候。

5.假設構建或購買是唯一的選擇

使用自定義代碼構建解決方案與購買SaaS或其他提供開箱即用功能的技術之間存在很大的灰色地帶。介于兩者之間的是高度可配置的低代碼和無代碼平臺、商業(yè)合作伙伴關系以及利用開源技術的機會。

因此，在構建或購買之間選擇是一種簡單化的做法。更好的選擇是所需的功能是否有助于區(qū)分業(yè)務，以及從長遠來看哪些類型的解決方案可以提供更多的創(chuàng)新和靈活性。

6.假設API滿足集成需求

大多數(shù)現(xiàn)代SaaS甚至許多企業(yè)系統(tǒng)都提供API和其他集成選項。但是編目集成應該只是調(diào)查它們是否滿足業(yè)務需求的開始。API公開了哪些數(shù)據(jù)?是否支持所需的視圖和事務?企業(yè)能否輕松連接數(shù)據(jù)可視化和機器學習工具?API的性能是否足夠，是否存在需要考慮的潛在使用成本?

加速集成功能審查的方法包括這三種驗證API和利用低代碼集成平臺的方法。

7.未能履行社會盡職調(diào)查

當人們面臨很多解決方案時，可信賴的信息源可以幫助企業(yè)縮小競爭范圍。而閱讀博客、白皮書、評論和研究報告，以及觀看網(wǎng)絡研討會、主題演講和在線教程都是關鍵的學習步驟。但經(jīng)常被遺漏的一種方法是利用社交網(wǎng)絡向專家咨詢。

8.跳過概念驗證(PoC)

企業(yè)選擇技術的藝術和科學涉及設計和執(zhí)行概念驗證解決方案(PoC)，以驗證假設并測試關鍵戰(zhàn)略要求。在驗證新興技術或評估SaaS平臺時，概念驗證尤其重要，但即使使用敏捷峰值來審查第三方技術組件，也有助于加快制定決策，并避免代價高昂的錯誤。

最大的錯誤可能是跳過概念驗證(PoC)，或者是因為企業(yè)只信任供應商，或者面臨時間壓力。而從概念驗證(PoC)中學到的知識可以幫助企業(yè)將優(yōu)先級導向可行的實施方案。

9.沒有制定詳細的決策矩陣

當許多人參與審查和評估新工具和技術時，幫助推動數(shù)據(jù)驅動決策的一種常見方法是創(chuàng)建決策矩陣電子表格。特性和功能按重要性加權，然后由審查委員會進行評級，并采用電子表格計算總分。

不幸的是，當涉及太多人員、選擇太多功能或分配任意權重時，這些工具很快就會失控。電子表格最終會優(yōu)先考慮編制者的偏好，而人們通常查看一些無用的東西而忽略了需要戰(zhàn)略性評估的內(nèi)容。

企業(yè)領導者在開始采用決策矩陣之前，考慮將解決方案的特征提煉為業(yè)務問題的本質，而不是要求由太多審核者評估眾多的特性。

10.忽略長期架構、生命周期和支持方面的考慮事項

企業(yè)領導者需要通過基于易用性和價值實現(xiàn)時間來評估技術，但這并不意味著長期架構、維護和支持不重要或不需要評估。

關鍵是決定何時對它們進行評估、關鍵考慮因素是什么、誰將參與審查，以及在評估中投入多長時間。這樣做的一個很好的方法是將技術團隊在評估開始時應該考慮的控制問題與應作為決策過程輸入的長期因素分開。

11.忽略SLA、數(shù)據(jù)保護和安全審查

時間壓力或盲目信任選擇的技術是瀏覽服務等級協(xié)議(SLA)審查和評估供應商安全和數(shù)據(jù)保護實踐的糟糕借口。做好這些審查的關鍵需要具備必要的專業(yè)知識、談判技巧、工具和有效的評估流程，只有這樣，技術人員和業(yè)務贊助商才不會將審查視為瓶頸。

在內(nèi)部執(zhí)行服務等級協(xié)議(SLA)、數(shù)據(jù)保護和安全審查的大型企業(yè)必須高效，并集中精力將評估與最高風險保持一致。專業(yè)知識不足的是小公司應該尋求在解決方案領域具有專業(yè)知識的外部人員的幫助。

12.延遲財務和法律審查

最后但同樣重要的是一個是進行財務和法律審查，很多企業(yè)并沒有這些領域的專家。

考慮到許多SaaS產(chǎn)品、API服務和云原生技術都有基于消費的定價模型，運營成本可能無法滿足預算或財務限制的要求。法律審查對于受監(jiān)管行業(yè)的企業(yè)或在全球范圍運營的企業(yè)尤為重要，在這兩種情況下審查合規(guī)因素可能特別耗時。對于財務和法律審查的延遲，企業(yè)可能會付出高昂的代價。

不要等到技術審查過程結束才引入財務和法律專業(yè)知識人才。在此提出的建議是，在一開始就讓他們參與進來，并在企業(yè)領導者做出任何技術決策之前權衡需要盡早審查的內(nèi)容。此外，不要因為一次性進行太多評估，而使財務和法律人員的工作負擔過重。

對許多企業(yè)來說，試圖兼顧多項技術評估是不現(xiàn)實的，企業(yè)領導者應該優(yōu)先考慮他們的采購工作。如果這樣做的話，開展智能、全面和高效的技術審查是可能的。