如何構建知足用戶需求的雲環境的五個步驟

不管你如何定義，雲就是你的用戶展示其在組織中的價值的另外一個工具。當談論新的範例或者技術（雲是二者兼有）的時候很容易被它的新特性所分心。由一系列無止境的問題引起的對話可以很快的被髮展爲功能願景清單，全部下面的這些都是你可能已經考慮到的：

• 是公有云、私有云仍是混合雲？
• 會使用虛擬機仍是容器，或者是二者？
• 會提供自助服務嗎？
• 從開發到生產是徹底自動的，仍是它將須要手動操做？
• 咱們能以多塊的速度作到？
• 關於某某工具？

這樣的清單還能夠列舉不少。

當開始 IT 現代化，或者數字轉型，不管你是如何稱呼的，一般方法是開始回答更高管理層的一些高層次問題，這種方法的結果是能夠預想到的：失敗。通過大範圍的調研而且花費了數月的時間（若是不是幾年的話）部署了這個最炫的新技術，而這個新的雲技術卻從未被使用過，並且陷入了荒廢，直到它最終被丟棄或者遺忘在數據中心的一角和預算之中。

這是由於不管你交付的是什麼工具，都不是用戶所想要或者須要的。更加糟糕的是，它多是一個單一的工具，而用戶真正須要的是一系列工具 —— 可以隨着時間推移，更換升級爲更新的、更漂亮的工具，以更好地知足其需求。

專一於重要的事情

問題在於關注，傳統上一直是關注於工具。但工具並非要增長到組織價值中的東西；終端用戶利用它作什麼纔是目的。你須要將你的注意力從建立雲（例如技術和工具）轉移到你的人員和用戶身上。

事實上，除了使用工具的用戶（而不是工具自己）是驅動價值的因素以外，聚焦注意力在用戶身上也是有其它緣由的。工具是給用戶使用去解決他們的問題並容許他們創造價值的，因此這就致使了若是那些工具不能知足那些用戶的需求，那麼那些工具將不會被使用。若是你交付給你的用戶的工具並非他們喜歡的，他們將不會使用，這就是人類的人性行爲。

數十年來，IT 產業只爲用戶提供一種解決方案，由於僅有一個或兩個選擇，用戶是沒有權力去改變的。如今狀況已經不一樣了。咱們如今生活在一個技術選擇的世界中。不給用戶一個選擇的機會的狀況將不會被接受的；他們在我的的科技生活中有選擇，同時但願在工做中也有選擇。如今的用戶都是受過教育的而且知道將會有比你所提供的更好選擇。

所以，在物理上的最安全的地點以外，沒有可以阻止他們只作他們本身想要的東西的方法，咱們稱之爲「影子 IT」。若是你的組織有如此嚴格的安全策略和承諾策略而不容許影子 IT，許多員工將會感到灰心喪氣而且會離職去其餘能提供更好機會的公司。

基於以上全部的緣由，你必須牢記要首先和你的最終用戶設計你的昂貴又費時的雲項目。

建立知足用戶需求的雲五個步驟的過程

既然咱們已經知道了爲何，接下來咱們來討論一下怎麼作。你如何去爲終端用戶建立一個雲？你怎樣從新將你的注意力從技術轉移到使用技術的用戶身上？

根據以往的經驗，咱們知道最好的方法中包含兩件重要的事情：從你的用戶中獲得及時的反饋，在建立中和用戶進行更多的互動。

你的雲環境將繼續隨着你的組織不斷髮展。下面的五個步驟將會幫助你建立知足用戶需求的雲環境。

一、識別誰將是你的用戶

在你開始詢問用戶問題以前，你首先必須識別誰將是你的新的雲環境的用戶。他們可能包括將在雲上建立開發應用的開發者；也多是運營、維護或者或者建立該雲的運維團隊；還多是保護你的組織的安全團隊。在第一次迭代時，將你的用戶數量縮小至人數較少的小組防止你被大量的反饋所淹沒，讓你識別的每一個小組指派兩個表明（一個主要的一個輔助的）。這將使你的第一次交付在規模和時間上都很小。

二、和你的用戶面對面的交談來收穫有價值的輸入。

得到反饋的最佳途徑是和用戶直接交談。羣發的郵件會自行挑選出受訪者——若是你能收到回覆的話。小組討論會頗有幫助的，可是當人們有個私密的、專一的對話者時，他們會比較的坦誠。

和你的第一批用戶安排個面對面的我的的會談，而且向他們詢問如下的問題：

• 爲了完成你的任務，你須要什麼？
• 爲了完成你的任務，你想要什麼？
• 你如今最頭疼的技術痛點是什麼？
• 你如今最頭疼的政策或者流程痛點是哪一個？
• 關於解決你的需求、但願或痛點，你有什麼建議？

這些問題只是指導性的，並不必定適合每一個組織。你不該該只詢問這些問題，他們應該導向更深層次的討論。確保告訴用戶他們任何所說的和被問的都被視做反饋，全部的反饋都是有幫助的，不管是消極的仍是積極的。這些對話將會幫助你設置你的開發優先級。

收集這種個性化的反饋是保持初始用戶羣較小的另外一個緣由：這將會花費你大量的時間來和每一個用戶交流，可是咱們已經發現這是至關值得付出的投入。

三、設計並交付你的解決方案的第一個版本

一旦你收到初始用戶的反饋，就是時候開始去設計並交付一部分的功能了。咱們不推薦嘗試一次性交付整個解決方案。設計和交付的時期要短；這能夠避免你花費一年的時間去構建一個你認爲正確的解決方案，而只會讓你的用戶拒絕它，由於對他們來講毫無用處。建立你的雲所須要的工具取決於你的組織和它的特殊需求。只需確保你的解決方案是創建在用戶的反饋的基礎上的，你將功能小塊化的交付而且要常常的去徵求用戶的反饋。

四、詢問用戶對第一個版本的反饋

太棒了，如今你已經設計並向你的用戶交付了你的炫酷的新的雲環境的第一個版本！你並非花費一全年去完成它而是將它處理成小的模塊。爲何將其分爲小的模塊如此重要呢？由於你要回到你的用戶組而且向他們收集關於你的設計和交付的功能。他們喜歡什麼？不喜歡什麼？你正確的處理了他們所關注的嗎？是技術功能上很厲害，但系統進程或者策略方面仍然欠缺嗎？

再重申一次，你要問的問題取決於你的組織；這裏的關鍵是繼續前一個階段的討論。畢竟你正在爲用戶建立雲環境，因此確保它對用戶來講是有用的而且可以有效利用每一個人的時間。

五、回到第一步。

這是一個迭代的過程。你的首次交付應該是快速而小規模的，並且之後的迭代也應該是這樣的。不要期待僅僅按照這個流程完成了一次、兩次甚至是三次就能完成。一旦你持續的迭代，你將會吸引更多的用戶從而可以在這個過程當中獲得更好的回報。你將會從用戶那裏獲得更多的支持。你可以迭代的更迅速而且更可靠。到最後，你將會經過改變你的流程來知足用戶的需求。

用戶是這個過程當中最重要的一部分，但迭代是第二重要的由於它讓你可以回到用戶中進行持續溝通從而獲得更多有用的信息。在每一個階段，記錄哪些是有效的哪些沒有起到應有的效果。要自省，要對本身誠實。咱們所花費的時間提供了最有價值的了嗎？若是不是，在下一個階段嘗試些不一樣的。在每次循環中不要花費太多時間的最重要的部分是，若是某部分在此次不起做用，你可以很容易的在下一次中調整它，直到你找到可以在你組織中起做用的方法。

這僅僅是開始

經過許多客戶約見，從他們那裏收集反饋，以及在這個領域的同行的經驗，咱們一次次的發如今建立雲的時候最重要事就是和你的用戶交談。這彷佛是很明顯的，但很讓人驚訝的是不少組織卻偏離了這個方向去花費數月或者數年的時間去建立，而後最終發現它對終端用戶甚至一點用處都沒有。

如今你已經知道爲何你須要將你的注意力集中到終端用戶身上而且在中心節點和用戶一塊兒的互動建立雲。剩下的是咱們所喜歡的部分，你本身去作的部分。

這篇文章是基於一篇做者在 Red Hat Summit 2018 上發表的文章「[爲終端用戶設計混合雲，要麼失敗]」。