IT運維工具設(shè)計分析

1、 IT運維工具設(shè)計分析目 錄 TOC o 1-3 h z u HYPERLINK l _Toc533534361 一、話題的背景 PAGEREF _Toc533534361 h 3 HYPERLINK l _Toc533534362 二、聊聊運維開發(fā)團隊 PAGEREF _Toc533534362 h 3 HYPERLINK l _Toc533534363 三、一些方法 PAGEREF _Toc533534363 h 7 HYPERLINK l _Toc533534364 四、結(jié)語 PAGEREF _Toc533534364 h 30本文的主題是“運維工具的設(shè)計思路”，會嘗試探討在甲方的運維開

2、發(fā)團隊如何獲得乙方的資源傾斜，為企業(yè)創(chuàng)造更高的價值。一、話題的背景這個話題的產(chǎn)生來源于上個月初與朋友的一次關(guān)于產(chǎn)品經(jīng)理的聊天，朋友跟我聊起了他們在產(chǎn)品設(shè)計過程中總結(jié)并落地的一條產(chǎn)品開發(fā)套路，很有啟發(fā)。結(jié)束聊天后，重新梳理中間一些抽象方法，其實在我日常工作過程中也有應(yīng)用，但零散不成套路，遂決定嘗試做一個小研究：金融企業(yè)中甲方運維開發(fā)團隊的產(chǎn)品設(shè)計思路，本篇為這個小研究開個頭。在本篇中，我嘗試將目前工作中與產(chǎn)品設(shè)計有關(guān)的步驟抽了出來，再串起來一個主線作了一個片子（文末有分享的片子鏈接）。二、聊聊運維開發(fā)團隊自Google sre 50%開發(fā)的布道，以及互聯(lián)網(wǎng)公司、dbaplus社群等技術(shù)社區(qū)的推動

3、，很多運維團隊都建立了運維開發(fā)團隊，金融企業(yè)也認(rèn)同這種新的思路，在人員招聘，組織團隊等方面都有改變。我在上半年做了一個金融行業(yè)運維的調(diào)研（調(diào)研了幾家銀行，幾家券商，幾家保險），其中在運維開發(fā)團隊的運作模式方面，主要如下：基于開源平臺或工具模塊，以自主研發(fā)為主；使用外部產(chǎn)品，整合在己有運維工具體系中；購買外包開發(fā)資源，支持運維開發(fā)；基于廠商的產(chǎn)品或平臺，進(jìn)行合作開發(fā)（實際上多是以廠商出技術(shù)平臺與開發(fā)資源，甲方出idea）；在實際的實踐過程中，由于一些行業(yè)特點，比如系統(tǒng)異構(gòu)、標(biāo)準(zhǔn)化程度不夠、精細(xì)化管理程度、監(jiān)管要求、企業(yè)里流程復(fù)雜度等，通常金融業(yè)里的運維開發(fā)團隊面臨的開發(fā)難題更為復(fù)雜，開發(fā)效率會低

4、于互聯(lián)網(wǎng)公司不少，所以互聯(lián)網(wǎng)公司說他們20人可以支持企業(yè)所有運維開發(fā)工具的需求，但在金融行業(yè)里并不一定能實現(xiàn)（另外大部份同業(yè)的運維開發(fā)團隊不超過6個正式員工）。同時，從投入產(chǎn)出看，在運維這個非企業(yè)核心技術(shù)線的團隊中，20人的運維開發(fā)團隊所需要的人力成本，相比帶來的效益及見效期的期望，往往不如基于成熟產(chǎn)品的合作開發(fā)模式。從調(diào)研結(jié)果看，第4種“基于廠商的產(chǎn)品或平臺，進(jìn)行合作開發(fā)”的模式在同業(yè)中的運作效果更好。所以，本篇思路的基礎(chǔ)是：金融企業(yè)甲方里的“運維開發(fā)”不等于“完全的自主研發(fā)”，探討在“合作開發(fā)”的運維開發(fā)模式下，如何創(chuàng)造更高的價值。1、甲方乙方說到合作開發(fā)，通常會有甲方與乙方，所以需要分析

5、一下雙方的優(yōu)劣勢，才能看看如何取長補短，實現(xiàn)雙贏。具體的分析則是如何從甲方角度讓乙方將資源向我們傾斜，畢竟好的乙方人力資源通常是比較緊張的。首先看看甲方：甲方的運維開發(fā)團隊，成員很多是從運維一線出身，對特定運維場景下的需求理解更深，更貼近真實的用戶，對痛點或價值的把握更好；其次，甲方角色很容易得到市場中成熟的商業(yè)解決方案，并更容易理解并獲取同業(yè)中真實解決方案及方案的應(yīng)用狀況。有優(yōu)勢，劣勢也明顯，比如甲方實施人力資源少，且有大量的工作量分配在流程的消耗上，甲方的運維開發(fā)團隊沒有生存壓力，在成本與效能的管控能力上比較弱等?？赐昙追剑賮砜纯匆曳剑阂曳降膬?yōu)勢在于，一個好的乙方通常見識面更廣，他們見過

6、行業(yè)及行業(yè)外各種客戶需要，踩過各種坑，掌握行業(yè)更通用的需求與更完備的技術(shù)解決方案；同時，乙方有一個完整的研發(fā)團隊，所以可以支持產(chǎn)品設(shè)計、開發(fā)、測試等人力與技術(shù)的支持；另外，乙方有生存壓力，所以他們對成本與效能的管控更好，且實施效率快。當(dāng)然，乙方同樣存在劣勢，他們對特定的需求理解不夠或他們需要放棄一些特定的需求，他們與真實用戶的距離比較遠(yuǎn)，如何獲得真實且正確的客戶需求是一個難點；另外，好的乙方人力資源很緊張。2、差距分析有了上面甲乙雙方優(yōu)劣勢分析，可以明顯的看到將甲方和乙方的優(yōu)勢結(jié)合是一個很明智的選擇方向。不過，從經(jīng)驗看，在這個過程中甲方要解決一個難題：“如何讓乙方將資源向我們傾斜”。如果你是行

7、業(yè)TOP5，或在一個大的區(qū)域范圍內(nèi)的TOP3，很好，乙方可能會基于戰(zhàn)略考慮，給你更多資源；如果你給足夠多的錢，項目夠大，乙方也會給你更多的資源。也就是說如果你所在企業(yè)名氣大或給的錢多，乙方的資源傾斜問題不大。但，如果你的項目預(yù)算不算多，企業(yè)的名氣又不能支持乙方的戰(zhàn)略銷售方向，我們應(yīng)該如何獲得乙方資源支持呢？就這一點，我和不少廠商的朋友聊起，得到了這樣一個回答：這個甲方可以作為產(chǎn)品孵化場所，甲方的團隊對產(chǎn)品或場景的理解更有前瞻性、更深入。想想看，如果有一個甲方能分析乙方現(xiàn)有的產(chǎn)品能力，有針對性的梳理出優(yōu)化的方向，或提出一種全新的模式，對于乙方來說是得到了一個更懂用戶的產(chǎn)品經(jīng)理或需求分析人員，將是

8、一個很美好的事。上面的觀點很重要，將是我們甲方在合作開發(fā)中的一個切入點。不過在現(xiàn)實中，我們很多運維開發(fā)人員或以技術(shù)導(dǎo)向進(jìn)行工具開發(fā)與設(shè)計，或主要承擔(dān)項目經(jīng)理或?qū)嵤┙?jīng)理，對產(chǎn)品設(shè)計及后期運營支持比較少，這個背景不利于乙方對產(chǎn)品功能完善的訴求。所以在合作開發(fā)的模式下，我們甲方要充分發(fā)揮我們的優(yōu)勢，要去掌握一些產(chǎn)品設(shè)計的思想與方法，以下進(jìn)一步介紹一些方法。三、一些方法由于缺少一個成熟方法論的支撐，這里抽象出來的方法目前看可能比較分散，各位可以有側(cè)重的閱讀。1、先講項目背景因為后面的方法介紹中需要舉到一些例子，所以先把例子涉及的項目背景簡要說一下。我們是以“監(jiān)、管、控、析”為主線的運維工具體系建設(shè)，分

9、別對應(yīng)監(jiān)控工具集、流程管控及IT服務(wù)工具體、生產(chǎn)操作自動化、運維數(shù)據(jù)分析。這個工具體系思路是以領(lǐng)域驅(qū)動的設(shè)計思路，將運維工具體系中不同領(lǐng)域的工具進(jìn)行分解，重點是領(lǐng)域深度上的擴展性。雖然在擴展性方面解決了我們的工具建設(shè)問題，但在實際的工具使用過程中我們?nèi)匀粫龅綆讉€問題：由于一項工作場景通常需要使用到“監(jiān)、管、控、析”多個工具，用戶需要在多個工具中來回切換，工作方式仍以經(jīng)驗導(dǎo)向，缺少一個經(jīng)驗沉淀或最佳實踐的落地；有重復(fù)建設(shè)的問題，互聯(lián)互通程度不夠的問題；大部份工具是面向與生產(chǎn)環(huán)境交互的自動化，但是對于日常運維管理及事務(wù)性的工作，線下程度高； 為了解決上述問題我們提出了場景可視化項目。項目在工具體

10、系層面上是在“監(jiān)、管、控、析”之上建立一個信息整合層：上圖的場景可視化層的核心目標(biāo)是：結(jié)合團隊背景，以“場景”的思想，以可視化為主要手段，構(gòu)建管理及事務(wù)性工作自動化，整合”監(jiān)管控析”工具集的工具調(diào)用與數(shù)據(jù)的互聯(lián)互通，落地運維專家的最佳實踐。為了支撐上述目標(biāo)重點要進(jìn)行以下三個手段：統(tǒng)一可視化；自助式與關(guān)鍵場景構(gòu)建；管理及事務(wù)性工作自動化。項目以“場景”作為核心思路，即“特定的時間+特定的環(huán)境+特定的人+特定的事件+特定的連接方式”，場景思想作作為后續(xù)所有的場景設(shè)計的指導(dǎo)思路，以提高擴展性。以下嘗試用一個故事來介紹一下項目：2、方法關(guān)于產(chǎn)品設(shè)計的方法套路根據(jù)不同的行業(yè)，不同的角色會有不同，從甲方角

11、度考慮產(chǎn)品設(shè)計相對更簡單一些，我們通常重點要關(guān)注設(shè)計出的運維工具有足夠的粘性，不需要考慮商業(yè)論證。不過，我平時在設(shè)計一個工具時也會考慮商業(yè)價值，原因有兩個：一是我希望乙方也能在這個項目的產(chǎn)品設(shè)計過程中獲益，你多為乙方想，乙方也會多為你著想，這樣能建立更為長期的合作關(guān)系；二是如果乙方的項目產(chǎn)品設(shè)計更為通用，后續(xù)的升級也能應(yīng)用在我們的項目中，也是雙贏的目標(biāo)。這里從簡單考慮，不考慮商業(yè)論證的環(huán)節(jié)，包括發(fā)起、價值主張、技術(shù)方案、設(shè)計與選型、運營5個環(huán)節(jié)：1）啟動一個項目通常來說，我們啟動項目有兩個思路，一是技術(shù)推動，二是需求拉動。技術(shù)推動是從技術(shù)角度出發(fā)推動項目的發(fā)起，比如“應(yīng)用XX技術(shù)，實現(xiàn)XX”，

12、像我們金融行業(yè)里講AIOps很可能是這種類型，或為了參加比賽，或提高技術(shù)儲備，或為了工具體系的完整性與擴展性來進(jìn)行這類項目，從這個角度看，我們也可以認(rèn)為立足長遠(yuǎn)。需求拉動是從用戶痛點或需求拉動的角度出發(fā)接動項目的發(fā)起，比如“解決XX問題，實現(xiàn)XX價值”，像我們說的解決手工在多臺服務(wù)部署程序，解決監(jiān)控事件分散的問題等。需要聲明的是，上述兩個思路都有存在的價值，關(guān)注這個點是希望項目的發(fā)起要清楚項目發(fā)起的源頭，不要舍本求末，抓住關(guān)鍵。這里我舉個例子來說明關(guān)注啟動項目的思路重要性。我曾經(jīng)做過一個集中監(jiān)控優(yōu)化項目，當(dāng)時項目目標(biāo)是解決集中監(jiān)控的性能問題，降低監(jiān)控事件報警誤報率，提高事件處理及時率。在拿到這

13、個項目后，我們剛開始制定了以下解決方案：將原來單節(jié)點的MySQL數(shù)據(jù)庫架構(gòu)進(jìn)行改造，以基于MyCat的分布式數(shù)據(jù)庫中間件，擴展為17個數(shù)據(jù)庫節(jié)點，對大表進(jìn)行分片，對數(shù)據(jù)庫進(jìn)行讀寫分離；建立動態(tài)基線，解決節(jié)假日與夜間的監(jiān)控誤報情況；對監(jiān)控可視化進(jìn)行改造，建立事件集中、豐富、處理等全流的可視化策略，實現(xiàn)事件與ITSM關(guān)聯(lián)。在第1、2兩個方案中雖然在技術(shù)上是亮點，但做的過程很痛苦的：比如基于MyCat的分布式數(shù)據(jù)庫中間件的應(yīng)用上雖然最終也解決了數(shù)據(jù)庫性能問題，但由于剛開始對表的分片沒有設(shè)計好，實施過程中發(fā)現(xiàn)跨表訪問的速度反而下降，另外后期的維護(hù)成本也變高。再比如第2個動態(tài)基線的方案，由于算法選擇問題

14、反而帶來了另外一些誤報。事實上，我們后來評估，第1個性能問題解決只要使用讀寫分離，并進(jìn)行大表數(shù)據(jù)遷移就能解決問題，第2個誤報情況主要原因是由于閥值策略不合理、監(jiān)控事件級別設(shè)計不好、變更維護(hù)過程中沒有設(shè)置維護(hù)期導(dǎo)致，所以我們在對閥值策略、事件級別分類、變更維護(hù)期與變更部署系統(tǒng)聯(lián)動后，報警數(shù)量收斂明顯。總結(jié)下來，其實在一開始的選擇方案中就出現(xiàn)問題，因為這個項目是為了解決實際的痛點，應(yīng)該就痛點來選擇技術(shù)方案，而不是選用一個更先進(jìn)的技術(shù)架構(gòu)方案來解決問題，技術(shù)架構(gòu)原則上應(yīng)該是演變過來才合理。反過來，如果這個項目是一個創(chuàng)新性的項目，那么應(yīng)用分布式數(shù)據(jù)庫中間件、基于算法的動態(tài)基線則是合理的。最后，再強調(diào)一

15、下，兩個項目發(fā)起都沒有誰對誰錯，存在即合理，關(guān)鍵是做項目的人要清楚是技術(shù)推動，還是業(yè)務(wù)拉動。2）價值主張價值主張有一個成熟的思路方案，關(guān)于價值主張詳細(xì)的說明，可以參考以下這本書：書中以一種圖文并茂的方式介紹了價值主張設(shè)計在產(chǎn)品設(shè)計過程中的實踐，主要圍繞以下這張價值主張畫布：我是上個月底看到這本書，在此之前沒聽過價值主張這四個字，實際上到目前為止我也只是粗看了一遍。所以接下來，我主要講講在價值主張這個環(huán)節(jié)中，我原來會做的一些事以及用到的一些工具，與價值主張原有意義可能會有些不同。在這個過程中，我們進(jìn)行價值主張的方法來實現(xiàn)以下目的：確定最準(zhǔn)確的用戶群與用戶需求；找到最迫切、最重要的工作目標(biāo)，獲得清

16、晰明了的重點工作；使團隊行動協(xié)調(diào)一致；避免無效或低效工作的開展，舍本求末，降低失敗風(fēng)險。在這個環(huán)節(jié)中，我通常會使用四個方法：用思維導(dǎo)圖梳理思路，討論明確邏輯關(guān)系，確定大的方向，并與廠商達(dá)成共識；借鑒別人經(jīng)驗，我通常會去做些同業(yè)調(diào)研，廠商交流，也會跨界去看看2C方面的軟件，有時候跨界能產(chǎn)生更棒的效果，因為好的生活軟件實際上己培養(yǎng)了用戶習(xí)慣，你只要參考這種方式設(shè)計就能更好的運營落地；用原型圖與廠商或用戶達(dá)成共享，通常用粗細(xì)條是為了與廠商達(dá)成共享，用低保真或高保真的圖是為了與用戶達(dá)成共享，大部份時間里低保真的圖也夠，高保真的圖通常是為了更好的傳遞設(shè)計思想或與重要用戶的交互；講故事特別有用，尤其是要在

17、短時間內(nèi)給方案審批方講解時，比如給領(lǐng)導(dǎo)匯報工作時就特別有用，在用戶故事中還會結(jié)合原型圖的方式講故事。Ok，以下進(jìn)入這一環(huán)節(jié)的具體介紹，首先我以運維場景可視化的統(tǒng)一IT服務(wù)場景的設(shè)計作為例子。在統(tǒng)一的IT服務(wù)的設(shè)計中，希望設(shè)計一個場景能實現(xiàn)IT團隊從被動受理IT需求向主動進(jìn)行IT服務(wù)供應(yīng)轉(zhuǎn)型，即建立一個類似一站式IT服務(wù)搜索的技術(shù)方案，運維人員可以將服務(wù)供應(yīng)能力發(fā)布在上面，服務(wù)的申請方只要根據(jù)關(guān)鍵字快速就能獲得IT服務(wù)，最終的方案如下：為了實現(xiàn)上述的場景設(shè)計，應(yīng)用以下的方法及工具。（1）思維導(dǎo)圖思維導(dǎo)圖在整理思路、思維擴展等方面都很有用。通常是將一個問題或目標(biāo)，通過某種結(jié)構(gòu)拆解為多個部份，每個拆

18、解的部份又可以進(jìn)一步往下拆解，使用思維導(dǎo)圖還有助于培養(yǎng)結(jié)構(gòu)化思維，在處理問題上更有邏輯性。我在很多場景中都會用到思維導(dǎo)圖，比如工作中的寫方案大綱、需求收集、功能設(shè)計、臨時性的討論等場合，以及工作以外的，梳理一篇好文章的內(nèi)容時，也很有用。思維導(dǎo)圖主要是分解，在應(yīng)用過程中可以提前形成一些套路：比如技術(shù)方案大綱可以這樣分解：背景（痛點或需求，解決思路）、技術(shù)方案（方案概述、方案分解及介紹、投入產(chǎn)出分析、實施路線）、展望；再比如運維工具功能設(shè)計時通常會采用：概覽（可量化的重要指標(biāo)）、用戶角色、用戶提出的需注、實際的技術(shù)方案、主要前端功能（通常抽象幾個大的功能點，再對功能點進(jìn)行擴散）、后臺功能（同上）。

19、下圖是我在場景可視化項目中的某個需求分析階段，集中幾天梳理的功能設(shè)計并梳理的思維導(dǎo)圖：（2）借鑒上述的思維導(dǎo)圖不僅有助于設(shè)計人員不斷的拆散對功能實現(xiàn)的理解，在與用戶收集或確認(rèn)需求、與廠商溝通技術(shù)方案時都很有用。在進(jìn)入工具或功能設(shè)計后，我首先會去借鑒別的系統(tǒng)設(shè)計思想（我們設(shè)計工具目標(biāo)是在內(nèi)部讓大家用起來，什么設(shè)計容易推廣與運營是我們選擇方案的重點，如果是創(chuàng)新則可能有另一種方式），在這方面的選擇有很多，可以是領(lǐng)域領(lǐng)軍企業(yè)的系統(tǒng)設(shè)計，也可以跨界2C的設(shè)計思路。以IT統(tǒng)一服務(wù)場景為例，我有借鑒servicenow的服務(wù)前端設(shè)計（事實上IBM的服務(wù)支持中心也是類似的設(shè)計）：除了同業(yè)的設(shè)計思路，一些日常2

20、C的功能設(shè)計也可以借鑒，比如百度、Google極簡的搜索方式己培養(yǎng)了很多用戶習(xí)慣，我們只要按這個方向去設(shè)計，在推廣運營過程會更加容易。同理在移動端的設(shè)計上，也可以借鑒手機上的一站式搜索，以下是華為手機的一站式搜索，可以對手機及云上的多個渠道進(jìn)行一站式搜索。（3）原型圖原型圖也是一個特別好用的工具，它是思維導(dǎo)圖分解思想及借鑒的案例在結(jié)合己有需求后的直觀落地形式，是達(dá)成共識，減少后期改動，促進(jìn)開發(fā)效率的辦法。通常我會用到粗細(xì)條、低保真、高保真的圖，從可視化效果看越來越好，但投入成本也會越來越高。由于我自己不會畫高保真的圖，所以通常只有要與重要用戶（比如領(lǐng)導(dǎo)或項目初期的統(tǒng)一思想）時會用到高保真的圖來

21、輔助溝通。在與廠商開發(fā)人員溝通時采用精細(xì)條、低保真也能達(dá)到溝通交流目的。粗線條可以在白板、觸控電視機，也可以紙上畫，比如下面幾張圖就是粗細(xì)條的原型圖，我們通常在討論時快速畫的圖：上面的精線條圖主要是要將需求體現(xiàn)在原型上面，但在實際設(shè)計過程中還要考慮一些部局、簡單的交互，需要細(xì)化設(shè)計的內(nèi)容，指引開發(fā)人員的開發(fā)，這時就需要使用低保真的圖。低保真的圖還會用來與用戶需求提出方進(jìn)行交流，并在這個圖的基礎(chǔ)上讓用戶提優(yōu)化需求與建議，我們使用Axure來畫低保真的原型圖，還有一個在線的工具叫墨刀也可以試試（modao.cc）。比如下面這兩張圖：高保真的原型圖就是前面發(fā)出的兩張圖：（4）講故事講故事是一個特別好

22、的方法，故事能把一些零散的需求串起來，要講一個好的故事并不容易，所以如果條件允許通常我會在故事中加上高保真的原型圖，通常高保真的原型圖是讓廠商畫出來的，因為我們沒有這方面的資源。關(guān)于講故事可以參考前面講項目背景時的故事方式，主要是什么時間，什么人，做工具做了什么事，得到什么效益，比如：固定收益部新員工小明，面臨申請電腦、移動設(shè)備、電話、用戶等一系列工作，但是小明的導(dǎo)師也沒有一個完整的新員工申請清單。10點10分，小明在統(tǒng)一IT服務(wù)場景中打上“我是新員工”，統(tǒng)一IT服務(wù)通過NLP分詞發(fā)現(xiàn)關(guān)鍵字是“新員工”，并到ITSM、文檔管理、工具工廠中查找到涉及“新員工”的IT服務(wù)，統(tǒng)一IT服務(wù)為小明提供以

23、下信息：在文檔管理系統(tǒng)中找到“新員工入職指引”，在工具工廠中找到“服務(wù)臺工具”，在ITSM中找到“用戶申請、電話申請、網(wǎng)絡(luò)申請、設(shè)備申請”幾個IT服務(wù)。11點，小明根據(jù)指引，在ITSM中發(fā)起服務(wù)申請。16點，IT運維人員根據(jù)服務(wù)申請單，支持相關(guān)申請。次日10時，小明在統(tǒng)一IT服務(wù)場景中可以看到申請的進(jìn)度，并可以根據(jù)SLA情況進(jìn)行催辦，服務(wù)臺人員可以幫助進(jìn)行催辦。在完成相關(guān)申請后，IT團隊中負(fù)責(zé)互聯(lián)網(wǎng)VPN的同事發(fā)現(xiàn)他的申請仍為郵件方式，所以他在ITSM中上架一個VPN用戶申請的服務(wù)，在統(tǒng)一IT服務(wù)的服務(wù)目錄中就可以找到這個服務(wù)。如在上面的故事中，要有側(cè)重的將產(chǎn)品的統(tǒng)一搜索、NLP、多渠道的信息

24、整合、服務(wù)處理軌跡可視化、服務(wù)上架、催辦等主要功能呈現(xiàn)出來，以更為生動和貼近用戶的方式介紹功能。3）技術(shù)方案完成前面的價值主張后，我們和項目相關(guān)方之間就“重心是什么，要做什么，做得怎么樣”達(dá)成共識，接下來就要開始評估如何實現(xiàn)，即技術(shù)方案。我會關(guān)注四個視角的架構(gòu)：用戶視角：準(zhǔn)確來講這個視角不屬于架構(gòu)，只是下面的視角會與用戶相關(guān)，所以暫時放在這里。用戶視角是要對工具的用戶進(jìn)行梳理，了解這些用戶的特點，重點關(guān)注重要用戶及大部份用戶的通用訴求。功能視角：針對功能級別的分類與不斷分解，通常我會以一個工具套路，比如至少要有一個面向不同用戶的總覽，有一個配置后臺，再針對不同的工具設(shè)計不同的查詢、操作類功能；

25、技術(shù)棧視角：以分層的方式梳理好使用的技術(shù)，需要重點關(guān)注技術(shù)選擇與項目的發(fā)起有關(guān)系；數(shù)據(jù)視角：需評估數(shù)據(jù)來源、數(shù)據(jù)存儲方式、數(shù)據(jù)整合方式、數(shù)據(jù)模型。4）設(shè)計與選型制定上述的技術(shù)架構(gòu)后，需要評估自研還是廠商合作，如果選擇廠商合作還要關(guān)注以下問題：找一家什么樣的廠商：是找一家產(chǎn)品成熟的廠商，還是找一家愿意與你一起打磨的廠商，對于需要客戶化的工具的選型，我通常會找后者，不過前提是我們要有足夠的建設(shè)思路來支撐這個客戶化，否則建議找前者；廠商的技術(shù)特點的分析：如果選定一個愿意客戶化的廠商，需要考慮廠商的基因，有些廠商以集成為主，這種廠商的實施能力強，但缺少核心技術(shù)；有些廠商掌握技術(shù)平臺的能力，擴展空間大會

26、大一些，建議找后者；廠商對業(yè)務(wù)的理解：還要關(guān)注你選的廠商對你的需求的理解能力，有些廠商只能理解你的需求的50分，有些能理解到80分，甚至110分給你帶來驚喜；找一家思路統(tǒng)一的廠商很重要。再具體到設(shè)計階段，則要關(guān)注更多的事情，比如在場景可視化項目中會關(guān)注：設(shè)計過程中融入項目的思想。比如這個項目的核心思想是“場景”，特定的時間+特定的環(huán)境+特定的人+特定的事件+特定的連接方式，在具體的場景設(shè)計中就要關(guān)注這幾個特定的元素是否關(guān)注到位；定義主要功能的設(shè)計策略。比如這個項目的大功能是大場景與小場景，大場景要集中力量去做通用的場景，沉淀最佳實踐，小場景則賦能給用戶自定義，所見即所得，兩者的基礎(chǔ)支撐是有區(qū)別的，前者是個性化方案，后者是通用方案；制定一些設(shè)計標(biāo)準(zhǔn)。比如這個項目的可視化色彩的應(yīng)用，白與白的相近色為底色，藍(lán)