建站
咨詢
售后
建站咨詢
新聞中心
背景
在最近的項目上，我有機會和團隊完成了幾次重要的工具選型。它們分別是在讓在建的SaaS 系統(tǒng)具備表單能力;讓該SaaS 系統(tǒng)能夠為接線員用戶提供軟電話能力;讓用戶的不同角色能夠看到和自己相關(guān)的報表。在這幾次選型過程中，有些是在商業(yè)軟件和商業(yè)軟件之間做出選擇，有些是在商業(yè)軟件和開源軟件間做出選擇。回頭看來，每次選擇的過程都不盡相同，但大致可以總結(jié)為以下幾個過程。
創(chuàng)新互聯(lián)主要從事網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務石阡,十載網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18982081108
為了方便讀者理解后面的例子，簡單介紹一下項目背景。CD公司是一家為中小型家政服務公司提供ERP軟件的公司，在行業(yè)內(nèi)已經(jīng)積累了20多年。目前該公司正在將其老舊的基于C/S 架構(gòu)的傳統(tǒng)ERP軟件0改造為云上SaaS 平臺來持續(xù)為客戶創(chuàng)造價值，并通過其20年積累的行業(yè)最佳實踐來吸引新的客戶群體。
清晰定義問題
在考慮其他因素之前，最重要的是清晰地理解問題本身。而且當涉及到工具選型這類重大決策時，干系人都期望所采用的方案能解決的不僅是當前的問題，還需要能解決將來可能會遇到的問題。那么如何確定需求的優(yōu)先級的同時兼顧系統(tǒng)的業(yè)務愿景就特別重要。畢竟有人說過 “A Problem Well-Defined is a Problem Half-Solved”。這一步不是本文的重點，但是會直接影響到選型結(jié)果的正確性。在前面提到的報表的例子中。團隊在和客戶進行了多輪訪談并對競爭對手產(chǎn)品中報表功能的分析后，最終獲得了理解一致的需求 —— “客戶希望根據(jù)行業(yè)最佳實踐為最終用戶提供預定義的報表功能，并能隨著客戶反饋提供簡單的自定義功能，讓用戶可以在預設(shè)的數(shù)據(jù)集內(nèi)通過不同的維度從其業(yè)務數(shù)據(jù)中獲得洞見?！?/p>
確定候選技術(shù)
接下來你需要想方設(shè)法獲得一個備選方案的工具清單，那么清單能從哪來呢?
(1) 從客戶那里來
客戶通常會有一些備選方案，可能是已經(jīng)在其組織內(nèi)部被采用的技術(shù)，或者是客戶方的技術(shù)人員所了解的技術(shù)。這時你只需要詢問客戶即可，你很可能還可以獲得一些商用軟件的官方支持，這將為后面的調(diào)研工作提供便利。
(2) 從競爭對手那里來
可能你有機會可以窺探到競爭對手在該領(lǐng)域所使用的技術(shù)。那么不妨將該技術(shù)也放入列表中，特別是在當前領(lǐng)域處于DDD中的通用域時。(在DDD中我們了解到，通用域是那些不需要具備競爭優(yōu)勢的領(lǐng)域，那么和競爭對手打個平手也是可以接受的)
(3) 日常的積累
如果你曾經(jīng)解決過(或參與解決過)類似問題，那么可能會了解一些相關(guān)技術(shù)。如果沒有，也不用急，類似的技術(shù)選型活動將會是積累相關(guān)技術(shù)的絕佳機會。
如果你正開始嘗試解決方案架構(gòu)師，那么可以使用5W1H 在日常工作中不斷積累各類工具和技術(shù)，這里我將1H strikethrough，是因為成為架構(gòu)師需要快速擴寬自己的知識范圍，將未知的未知問題轉(zhuǎn)換為已知的未知問題，來豐富自己的工具箱。等到需要的時候再進一步深入了解。
相信綜合這些選項你已經(jīng)獲得了可以進入到下一步的工具清單。如果到這里你都還沒有一個足夠你開始調(diào)研的清單，那么很可能該領(lǐng)域的解決方案匱乏，團隊可能最終會需要自己造輪子。
在我們報表工具的例子中，客戶組織內(nèi)部使用了Tableau作為內(nèi)部的BI工具;團隊之前接觸過Jasperreport;項目的云供應商AWS 上的QuickSight 提供了類似的BI 能力;通過詢問，我們了解到了Redash;通過搜索，我們了解到了Superset和 Metabase。
這個時候可能你已經(jīng)準備好了各種緯度表，然后摩拳擦掌，準備開始針對候選產(chǎn)品進行深度調(diào)研和對比了。
做出選擇
通常完成一個工具選型需要考慮的因素很多，但大致可以分為：
- 滿足功能性需求
- 滿足跨功能性需求
- 滿足成本預算
- 對齊技術(shù)愿景
雖然只包含著四個部分，但是想要通過分析快速做出決策并不簡單，就單單從跨功能性需求而言，在《演進式架構(gòu)》中作者就列舉了74項，并還向其中增加了Evolvability (可演進性)。綜合這些考量本身就是一個復雜的過程。
從敏捷項目管理中，我們學到遇到問題時要首先將其分解，再想方法排個優(yōu)先級，問題通常就能變得清晰。在我們的例子中，架構(gòu)師將整理出的跨功能需求按照其影響程度或架構(gòu)的關(guān)注程度進行了優(yōu)先級排序，其中處于較高優(yōu)先級的有：多租戶，安全合規(guī)，功能性需求，互操作性(集成復雜度)，伸縮性，可維護性，技術(shù)愿景，收費模式，成本。接著我們再通過信息獲取和分析的難易程度進行了簡單的排列，例如，有些信息只需要閱讀少量文檔或者通過問詢便可得到，有些信息需要閱讀大量文檔并進行分析才能判斷候選工具間的優(yōu)劣。這樣就能讓調(diào)研工作縮小到一定范圍，同時可以觀察到調(diào)研活動會分布到下圖的四個象限中。
那么針對不同象限中的因素遍可以采取對應的策略進行調(diào)研了。按照從易到難的順序完成調(diào)研工作可以更有效地篩選備選方案。
開源許可協(xié)議 在進行報表工具選型的過程中，由于忽略了JasperReport Server的開源許可協(xié)議，導致了在選型過程中的反復和團隊精力上的浪費。而開源許可類型是非常容易獲得的信息，并且不需要過多的分析就能就可以獲得結(jié)果，它處于Fast Fail象限。如果可以準確的識別出處于該象限中的因素將極大增加選型的效率。
結(jié)合技術(shù)愿景
在作出工具選型時需要結(jié)合組織的技術(shù)愿景，例如，如果我們希望系統(tǒng)可以具有高度的移植性，可以不被鎖定到某個云廠商，那么在技術(shù)選型時應該考慮是否由于選擇某項技術(shù)而增加對云廠商的依賴，在我們的例子中，最終我們選擇了Amazon Connect 作為客服電話集成方案，但是并沒有采用QuickSight作為報表/BI 方案。同是Amazon所提供的服務，但是BI工具作為數(shù)據(jù)的下游，可能會導致在存儲和數(shù)據(jù)管道技術(shù)上大量依賴于AWS提供的其他服務，使將來可能的遷移更加困難，最終鎖定到供應商。而電話系統(tǒng)作為客戶觸點，則更容易通過API的方式和后臺系統(tǒng)解耦而獨立存在，供應商鎖定的風險更小。
關(guān)于成本
關(guān)于成本這里不想展開太多，但是當涉及到商業(yè)軟件的成本的估算是通常需要客戶方的大量介入。團隊則需要根據(jù)目前大致方案給出實施，集成和上線所需要的資源配置和時間。工具的提供方則會提供實際價格及后續(xù)的維護和支持的報價。如果是自建系統(tǒng)，則需要為建設(shè)所需的軟硬件和人力資源成本以及后續(xù)的維護及支持的成本給出大致的估算來為最終的選型提供依據(jù)。
寫在最后
工具選型是一個復雜的過程，需要綜合很多信息才能做出合適的選擇。我們知道任何技術(shù)決策都是權(quán)衡利弊的結(jié)果。將決策上下文和最終選擇的Cons & Pros記錄下來，即便將來發(fā)現(xiàn)這個選擇不再合適的時候，也能清楚的追溯到先前決策的細節(jié)，會為下一步?jīng)Q策提供更加充分的依據(jù)。希望本文能幫助到你，也希望天下沒有錯誤的工具選型。
文章標題：如何合理地選型工具
轉(zhuǎn)載來源：http://m.jiaoqi3.com/article/cddpcgs.html
