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

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

這樣的清單還可以列舉很多。

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

這是因為無論你交付的是什麼工具，都不是使用者所想要或者需要的。更加糟糕的是，它可能是一個單一的工具，而使用者真正需要的是一系列工具 —— 能夠隨著時間推移，更換升級為更新的、更漂亮的工具，以更好地滿足其需求。

專注於重要的事情

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

事實上，除了使用工具的使用者（而不是工具本身）是驅動價值的因素之外，聚焦注意力在使用者身上也是有其它原因的。工具是給使用者使用去解決他們的問題並允許他們創造價值的，所以這就導致瞭如果那些工具不能滿足那些使用者的需求，那麼那些工具將不會被使用。如果你交付給你的使用者的工具並不是他們喜歡的，他們將不會使用，這就是人類的人性行為。

數十年來，IT 產業只為使用者提供一種解決方案，因為僅有一個或兩個選擇，使用者是沒有權力去改變的。現在情況已經不同了。我們現在生活在一個技術選擇的世界中。不給使用者一個選擇的機會的情況將不會被接受的；他們在個人的科技生活中有選擇，同時希望在工作中也有選擇。現在的使用者都是受過教育的並且知道將會有比你所提供的更好選擇。

因此，在物理上的最安全的地點之外，沒有能夠阻止他們只做他們自己想要的東西的方法，我們稱之為“影子 IT”。如果你的組織有如此嚴格的安全策略和承諾策略而不允許影子 IT，許多員工將會感到灰心喪氣並且會離職去其他能提供更好機會的公司。

基於以上所有的原因，你必須牢記要首先和你的終端使用者設計你的昂貴又費時的雲專案。

建立滿足使用者需求的雲五個步驟的過程

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

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

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

1、識別誰將是你的使用者

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

2、和你的使用者面對面的交談來收穫有價值的輸入。

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

和你的第一批使用者安排個面對面的個人的會談，並且向他們詢問以下的問題：

• 為了完成你的任務，你需要什麼？
• 為了完成你的任務，你想要什麼？
• 你現在最頭疼的技術痛點是什麼？
• 你現在最頭疼的政策或者流程痛點是哪個？
• 關於解決你的需求、希望或痛點，你有什麼建議？

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

收集這種個性化的反饋是保持初始使用者群較小的另一個原因：這將會花費你大量的時間來和每個使用者交流，但是我們已經發現這是相當值得付出的投入。

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

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

4、詢問使用者對第一個版本的反饋

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

再重申一次，你要問的問題取決於你的組織；這裡的關鍵是繼續前一個階段的討論。畢竟你正在為使用者建立雲環境，所以確保它對使用者來說是有用的並且能夠有效利用每個人的時間。

5、回到第一步。

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

使用者是這個過程中最重要的一部分，但迭代是第二重要的因為它讓你能夠回到使用者中進行持續溝通從而得到更多有用的資訊。在每個階段，記錄哪些是有效的哪些沒有起到應有的效果。要自省，要對自己誠實。我們所花費的時間提供了最有價值的了嗎？如果不是，在下一個階段嘗試些不同的。在每次迴圈中不要花費太多時間的最重要的部分是，如果某部分在這次不起作用，你能夠很容易的在下一次中調整它，直到你找到能夠在你組織中起作用的方法。

這僅僅是開始

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

現在你已經知道為什麼你需要將你的注意力集中到終端使用者身上並且在中心節點和使用者一起的互動建立雲。剩下的是我們所喜歡的部分，你自己去做的部分。

這篇文章是基於一篇作者在 Red Hat Summit 2018 上發表的文章“[為終端使用者設計混合雲，要麼失敗]”。