使用使用者故事對映實現領域建模 - pulse

在構建業務關鍵型軟體時，像領域驅動設計這樣的實踐是把一個重要的焦點放在IT和領域專家協作上。此外許多公司還看到了與客戶更親密的關係，更好地瞭解他們的願望和需求，從而建立更忠誠的客戶群的必要性。這就是服務設計、使用者體驗研究和敏捷概念（如使用者故事）的亮點所在。使用者故事圖能幫助我們設計出既可行又有價值，而且可用的軟體解決方案嗎？

“最好的解決方案來自需要解決問題的人和能夠解決問題的人之間的合作”。-傑夫巴頓

你是在一家為客戶著想的公司嗎？或者說，你正在努力創造一個以使用者需求和願望為中心的解決方案？

也許你甚至試著與客戶和他們的使用者一起構建這些解決方案，通過使用模型、試驗和mvp逐步構建，讓他們參與實際設計？

您可能想知道，在這樣的環境下，您究竟如何設計和構建一個可行的系統組合，以避免將未完成的元件與膠帶、細繩和回形針組合在一起的風險，或者可能最終建立過於複雜的解決方案來滿足任何未來的需要。

有很多關於演進架構的討論，但是我們如何將其與客戶需求聯絡起來呢？

為了建立可持續的系統，我們需要知道早期的原型將把我們帶到哪裡；我們需要能夠看到更遠的未來。簡而言之，在這個高度敏捷的世界裡，有什麼可以幫助我們進行領域建模呢？

使用者故事對映

使用者故事對映是一種從敏捷社群衍生出來的實踐，它是一種將使用者故事結構化的方法，它是您正在構建的應用程式的終端使用者體驗到的，從他們的角度講述故事的一種方式。從這個視覺化工具中獲得的見解，無論是產品發現、領域知識、交付計劃和團隊協作，都將直接連線到這個焦點，即使用者體驗。

在許多敏捷方法中，使用者故事已經成為描述使用者想要什麼的一種常見方式，無論是XP的起源地還是流行的Scrum框架。儘管這從來不是一種新的編寫需求的方式，但許多團隊仍然在處理大量的、非結構化的、一維的產品積壓問題，這些積壓的故事被寫成一個詳細的願望列表，就像過去的需求文件一樣。很難很好地處理這個列表，尤其是以一種好的方式對其進行排序和分解，以便以可持續和一致的方式使結果最大化。

將故事對映到使用者的過程中，以及執行的所有活動和任務，開啟了一個新的維度，在這個維度中，可以更容易地找到需要一起構建的內容，以使應用程式可用，並分成可行的產品增量。然後，設計可以以一種進化的方式完成，每一步都可以潛在地擺在使用者面前，從而縮短基本的反饋迴路。

進行這種對映並從開始到軟體交付的整個過程中使用它的一個微妙而重要的影響是，設計與使用者互動明確地聯絡在一起。人們不能再簡單地從所有相關的涉眾那裡收集一長串的需求。每件事都必須對映到某些使用者活動上，迫使設計者從使用者的角度來看待一切。使用者故事概念開始變得有意義，正如它最初的意圖；它是關於它是如何使用的，而不是它是如何寫的。

故事對映非常適合作為設計過程中所有利益相關者的協作工具，從最初的構想和開始，建立連貫的客戶旅程，通過構建階段，到初始之後產品的持續豐富和維護交貨。

它涵蓋了產品的所有三個“-ilities”：可用、有價值和可行。

它對服務設計師來說很有意義，因為它涵蓋了大部分客戶旅程和體驗（CX 和 UX）；非常適合產品發現，讓產品經理很容易描述產品的意圖和目的；它是技術設計人員進行領域建模、通過彌合問題和解決方案空間之間的差距來建立可行解決方案的好方法。

“當工程師抽象地考慮“客戶”而不是真實的人時，您很少會得到正確的結果”。– Gene Kim

領域建模

儘管使用者故事對映主要是一種產品發現和開發工具，但它也有利於領域建模：因為它以非常清晰和全面的方式描述了問題空間。

在設計技術解決方案時，問題空間的複雜性往往沒有被很好地捕捉到，導致基於現有技術解決方案的幼稚設計或架構師和技術專家對以前經驗的重用。相反，設計應該由對問題空間的深刻理解來驅動，故事地圖是一個很好的工具。

它為設計師提供了必要的由外而內的視角，以使用者對要構建的產品的心理模型為指導。除了故事對映所支援的進化設計之外，這還強制實施了技術設計的進化方法。

領域建模者的故事對映的一些具體要點：

• 檢視哪些資料需要一起顯示和儲存，有助於識別有界上下文。
• 為每個有界上下文識別無處不在的語言，不僅基於領域專家的業務術語，還基於使用者體驗。
• 識別需要事務繫結的資料以及最終可以保持一致的資料。
• 查詢聚合及其資料和不變數。

其他出色的建模和協作技術，例如事件風暴、業務能力建模、領域講故事、業務模型畫布、示例對映、影響對映、Wardley Maps 等等。