以客戶理解的方式打造
「必要性是發明的母系。」此說法會擷取人類自然感的可傳遞性，以及我們自然的發明力。 就如牛津英語詞典中所述，「當某樣事物個的需求變得必要時，您會被迫找出取得或達成的方法」。很少人能拒絕承認這些有關發明的普通真相。 不過，如 數位經濟中的創新 一文所述，雲端創新需要在發明與採用之間取得平衡。
如果我們繼續進行類比，創新來自更擴充的系列。 感同身受客戶的需要是創新的源頭。 若要建立可推動創新的客戶同理心解決方案，需要合法的客戶需求，讓他們能夠回到解決重大挑戰。 這些解決方案是以客戶所需的專案為基礎，而不是想要或叫用。 若要尋找客戶真正的需求，請從同理心開始，並深入瞭解客戶體驗。 對許多工程師、產品經理、甚至是企業領導人來說，同理心的敏感性技能尚待開發。 幸運的是，雲端架構師角色的各種互動和快速步調可促進此技能。
如何建置同理心，以及為何客戶同理心如此重要？ 客戶同理心可協助您瞭解並分享客戶體驗。 從第一版的最低可行產品 (MVP) ，到上市市場等級解決方案，客戶同理心可協助您建置更好的解決方案。 更重要的是，同理心更適合讓小組能夠創造鼓勵採用的解決方案。 在數位經濟中，最容易與客戶需求同理心的產品小組，可以使用更聰明的工具來重新定義並引導市場。
定義使用客戶同理心建置的假設
定義假設是規劃的基礎。 您規劃的越多，您就能更清楚地看到假設逐漸進入絕佳想法的基礎。 假設通常是自我同理的產品。 換句話說， 如果我處于這個位置，該怎麼辦？ 當您從建置階段開始時，它會將假設可以影響解決方案的期間降到最低。 這種方法也可加速與真實客戶之間意見反應的來回，並於早期即觸發學習及磨練同理心的機會。
警告
正確定義要研發何種內容可能會很棘手，需要一些實務做法。 如果您建置太快，它可能不會反映客戶需求。 如果花太多時間嘗試了解客戶一開始的需求以及解決方案需求，可能會在您有機會研發任何方案之前，市場上已先有了這類產品。 不論是哪種情況，學習的機會都會大幅延遲或降低。 有時候，資料甚至可能已損毀。
從過往看起來，最創新的解決方案都來自於直覺的想法。 這種直覺的感覺來自於既有的專業知識和第一手觀察。 從建置階段開始，因為它可讓您快速測試您的直覺。 您可以從該處培養更深入的瞭解和更清楚的同理心程度。 每一次的反覆運作或發行解決方案時，都能從研發展現對客戶同理心的 MVP，取得平衡。
為了穩定此平衡動作，下列兩節說明如何使用同理心建置及定義 MVP 的概念。
定義以客戶為主的假設
當您以同理心建置時，這表示您會根據定義的假設來建立解決方案，以說明特定客戶需求。 下列步驟制定假設，鼓勵使用同理心進行建置。
- 當您抱持著同理心進行研發時，客戶一定會是焦點。 這種意圖可能需要許多體現。 您可以參考客戶原型、特定的角色，甚至是在您想要解決之問題的過程中提供客戶的圖片。 請記住，客戶可能是內部人員 (員工或合作夥伴) 或外部 (消費者或業務往來客戶)。 此定義是您要測試的第一個假設：我們是否可以協助此特定客戶？
- 了解客戶體驗。 抱持著同理心進行研發，意味著您感同身受客戶的體驗，並了解客戶所面臨的挑戰。 這種思維方式指出了下一個要測試的假設：我們是否能以這種可管理的挑戰來協助此特定客戶？
- 定義單一挑戰的清楚解決方案。 如果您依賴跨人員、程式和主題專家的專業知識，可能會導致潛在的解決方案。 然後，要測試的完整假設是：我們是否可以透過建議的解決方案，協助此特定客戶解決此可管理的挑戰？
- 達成價值陳述。 您希望為這些客戶提供哪些長期性價值？ 這個問題的答案會產生出完整的假設：使用提議的解決方案解決這項可管理的挑戰，對於這些客戶的生活改善如何？
最後一個步驟是因為同理客戶而提出假設的終點。 它會定義對象、問題、解決方案，以及要改進的評量，而這一切皆以客戶為中心。 在量值和學習階段期間，您應該測試每個假設。 預期客戶、問題聲明或解決方案中的變更，因為小組為可定址的客戶群開發更大的同理心。
警告
其目標是要運用對客戶的同理心進行研發，而不是利用它進行規劃。 為了要達到最完美的客戶同理心陳述，很容易就會深陷在無止盡的規劃和想方法調整的循環之中。 在嘗試開發這類陳述之前，請先參閱下列各節，了解如何定義及研發 MVP。
在您證明核心假設之後，後續的反復專案除了同理心測試之外，還會著重于成長測試。 建置、測試及驗證同理心之後，您就可以開始瞭解大規模的可定址市場。 您可以展開先前所述的標準假設公式，以更深入地瞭解可定址的市場。 然後，根據可用的資料，估計 (潛在客戶數目) 的總市場大小。
從該處，估計遇到類似挑戰的總市場百分比，因此可能會對解決方案感興趣。 您接著會有可定址的市場。 下一個要測試的假設是：如何使用建議的解決方案來改善 客戶生活百分比 ，以解決這項可管理的挑戰？ 客戶的小型取樣會顯示前置指標，其建議對參與客戶的集區產生百分比影響。
定義測試假設的解決方案
反覆進行研發、評量及取得意見反應的循環期間，要嘗試依據 MVP 所定義的共識，進行研發。
在建立足以向客戶學習的解決方案時，需要的最小工作單位 (發明、工程、應用程式開發或資料結構) 即為 MVP。 每項 MVP 的目標，是要測試部分或所有先前的假設，並直接從客戶收到意見反應。 輸出不是一個美觀的應用程式，其中包含變更您的產業所需的所有功能。 每項反覆運作所希望的產出，是有機會更深入測試假設的學習機會。
箱型時間是確保產品精簡的標準方法。 例如，確認您的開發小組認為解決方案可以在單一反復專案中建立，以允許快速測試。 若要進一步瞭解如何使用速度、反復專案和版本來定義最小的意義，請參閱 規劃速度、反復專案、發行和反復專案路徑。
降低複雜度並延遲技術預研
創新方法中所述的發明專業領域會探索提供成熟創新或大規模 MVP 解決方案所需的功能。 請使用這些專業領域作為納入功能的長期性指南。 同樣地，也可以在客戶價值與解決方案中同理心的早期測試過程中，使用它們做為警告性指南。
功能廣度和發明的不同專業領域，無法在單一反覆運作中建立。 MVP 解決方案可能會有數個版本，以納入多重專業領域的複雜度。 視開發投資的大小，在不同的專業領域內可能會有多個小組平行進行，以測試多項假設。 雖然維護這些小組之間的架構一致性是相當聰明的，但您不想要嘗試建置複雜的整合式解決方案，直到您可以驗證價值假設為止。
您偵測到技術 尖峰頻率或數量的最佳複雜度。 技術預研是為了建立無法輕易請客戶測試的技術解決方案時，所花費的精力。 當客戶價值和客戶同理心未經測試時，技術尖峰代表創新的風險，而且應該最小化。 針對移轉作業中所發現的測試成熟之解決方案，在採用期間進行技術預研很普遍。 但它們會延遲對創新工作的假設進行測試，您應該盡可能延遲。
無止止的簡化方法可協助任何 MVP 定義。 這種方法表示您移除了任何無法協助您驗證假設的能力的專案。 若要將複雜度降至最低，請減少測試假設所需的整合與功能數目。
研發 MVP
在每個反覆運作中，MVP 解決方案會有許多不同的面向。 常見的需求是只有輸出可進行假設的評量與測試。 這個簡單的需求會起始科學程式，並讓小組以同理心建置。 為提供此客戶優先的重點，MVP 一開始可能只會仰賴其中一個發明專業領域。
在某些情況下，最快的創新路徑表示暫時避免這些專業領域，直到雲端採用小組確信假設已正確驗證為止。 從 Microsoft 之類的技術公司，本指導方針可能很直覺。 但強調客戶需求，而不是特定技術決策，是 MVP 解決方案中最高的優先順序。
一般而言，MVP 解決方案是由應用程式或資料解決方案所組成，具有最少的功能和有限的波蘭文。 對於具有專業開發專長的組織來說，此路徑通常是學習及反覆運作最快的途徑。 下列清單包含小組研發 MVP 時，可能採取的數種其他方法：
- 一個預測演算法，此演算法 99% 錯誤，但可示範特定的預期結果。
- IoT 裝置，不會在生產規模安全地通訊，但會示範進程內近乎即時資料的價值。
- 公民開發者所建置的應用程式，其用來測試假設或能符合較小規模的需求。
- 手動程序，其會重新建立應用程式遵循之好處。
- 詳細程度足以讓客戶互動的線框或視訊。
開發 MVP 應不需要大量的開發投資。 最好是盡可能限制投資，以將一次測試的假設數目降到最低。 然後，在每個反復專案和每個版本中，您都會刻意改善解決方案，以達成代表多個發明專業領域的大規模解決方案。
加速 MVP 開發
上市時間對於所有創新的成功都很重要。 發行速度更快可加快學習速度。 而學習速度更快則能讓調整產品的速度變快。 傳統的應用程式開發週期，有時候可能會拖慢此程序。 創新更常是受限於有限的專業知識。 預算、員工人數和員工可用性都可以建立小組可處理的新創新數目限制。
人員配置限制和想要以同理心建置，為公民開發人員產生快速成長的趨勢。 這些開發人員會降低風險，並能在組織的專業開發小組內提供擴縮性。 公民開發人員是客戶體驗的主題專家，但不是以工程師身分訓練。 這些個人使用原型工具或較輕量型的開發工具，專業的開發人員可能並不見得同意這些開發者。 這些尋求解決商務問題的開發人員，會建立 MVP 解決方案並測試理論。 一致時，此程式會建立生產解決方案，以提供價值，但未通過足夠有效的刻度假設。 Teams 也可以在開始調整工作之前，使用解決方案來驗證原型。
在任何創新計劃中，雲端採用小組應將其組合多樣化，納入公民開發者的努力。 藉由調整開發工作，您可以透過降低投資來形成及測試更多假設。 當您驗證假設並識別可定址的市場時，專業開發人員就可以使用新式開發工具來強化和調整解決方案。
最終的研發關卡：客戶難題
同理客戶的程度強時，應能很容易找出顯然存在的問題。 客戶的難題應該很明顯。 在建置期間，雲端採用小組正致力於根據客戶難題來測試假設的解決方案。 如果假設已妥善定義，但沒有問題點，則解決方案不會真正以客戶同理心為基礎。 在此案例中，組建不是正確的起點。 相反地，應先投資在營造同理心，並從真實客戶學習。 建置同理心和驗證痛的最佳方法很簡單：聆聽您的客戶。 花點時間與客戶會面並觀察客戶，直到您能找出經常發生的難題為止。 在您充分瞭解客戶痛點之後，即可測試假設的解決方案來解決該難題。
不應用此方法的時機
有許多法律、合規性和產業需求可能需要採取替代方法。 如果開發解決方案的公開版本，此方法可能不適合：
- 建立專利時間、智慧財產權保護或客戶資料外泄的風險
- 違反已建立的合規性需求
當這些認知到的風險存在時，請先洽詢法務顧問，再採用任何引導式發行管理方法。
參考資料
本文中的一些概念是以 Eric Ries 所 The Lean Startup 討論的概念為基礎。
後續步驟
研發 MVP 解決方案之後，可以評量出同理心價值與規模價值。 了解如何評量客戶所受影響。