問題領域與解決方案領域上篇 | Problem & Solution Domain
客戶與開發者的理解，圖片來源
情境
在最理想的情況下，客戶能夠完美的解釋需求，完美到講出來的話就是他想要的， 但通常會發現確認需求是一段崎嶇的路， 然後確認需求的文件一改再改，從第一版到 final 版本的 final 版本。
版本地獄
客戶解釋中很難避免使用專業術語， 而大量的專業術語，就如同你跟你麻吉才懂得密語。
客戶的解釋就如同複雜的迷宮，第一層迷宮還會通向不同層的迷宮，他講得口若懸河，但你已經迷失在迷宮裡面了，甚至你還不知道你在第幾層。
最後克服重重困難，產品做出來了，但維護跟新增功能呢， 程式碼變成開發者才懂得東西，現在變成開發者對後來維護者一陣輸出， 理解鴻溝在此又出現了，這還是與客戶不一樣的理解鴻溝，這是開發者與後繼維護者的理解鴻溝。
綜合以上所述，問題為以下三點
- 客戶想法與解釋的落差
- 客戶與開發者的理解的鴻溝
- 開發者與維護人員的理解鴻溝
但我相信這些只是冰山一角，但我們必須要更細膩的感知到從需求到產品的問題才能解決。
問題領域 | Problem Domain
“ 問題空間是指包含了你希望你的產品能滿足的所有客戶需求的領域。你不應該將"需求"一詞理解得太狹隘:無論是客戶的痛點、願望、待完成的工作,還是用戶故事,都存在於問題空間中。 ”
只有知道問題長怎麼樣，才能去正確的解決。問題與解決方案如同感覺與語言，只有真確地了解到自己的感覺，才能用適當的語言表達，否則就是胡言亂語、心口不一了。
使用者用這個功能達成甚麼目的，以及功能的細節、使用者的痛點等等上下文...， 而功能的目的與上下文、脈絡被稱為問題領域。
例如在對於【客戶瀏覽電商首頁】這功能本身
- 推薦的廣告與商品要依照什麼指標與訊息來呈現?
- 根據不同國家的法律法規，顯示的內容是否需要做相應調整?
- 網頁響應速度的要求是多少?
又例如【醫療管理系統的預約醫生】這功能本身
- 預約時的個人訊息需要哪些? 是否操作繁瑣?
- 不同科室的預約規則是否相同?
- 就診前是否要提醒，以避免客戶忘記預約時間?
除了功能本身，功能的上下文、脈絡同樣重要，這能更好、更貼近得符合客戶的需求，也是在同類產品中脫穎而出的關鍵。
如何釐清問題領域
不同分析方式用不同的方式去建構它，以下列出不同的分析方式
- 顧客旅程地圖 (Customer Journey Map) 透過步驟、接觸點、行動、思考、心情、現狀與痛點，以圖像化、宏觀的方式查看產品。
- 物件導向分析利用 UML 的類別圖 (Class Diagram) 將與順序圖 (sequence diagram) 或其他建模方式。
- 領域驅動設計 (Domain Design Driven) 利用統一語言 (Ubiquitouse language) 避免了語言的歧異性；與客戶進行事件風暴 (Event Storming) 釐清商業流程。
- 統一過程 (Rational Unified Process) 利用詳解用例條列分析了用戶用例的範圍、用戶目標、主成功場景、特殊需求等等...，使用用例圖確定系統的主要參與者與其他參與者。
無論是哪種方式，只要能了解產品要解決的範圍以及上下文，都是正確的方式，甚至可以組合不同的方式，以不同的方面去察看問題。
獲得了甚麼
因為這是對於問題的釐清，在幫助開發者了解產品以及相關背景的同時，如果有客戶的參與，在建構問題領域時也有可能讓客戶更明白自己想要甚麼。
作者心得
“ Customer collaboration over contract negotiation. ”
在研究這個概念的時候，發現澄清問題領域是非常需要技巧以及客戶的配合。
使用技巧去結構化的分析問題領域，例如上文提到的 : 顧客旅程地圖、物件導向分析等等...，然後由客戶的配合去填充分析結構的內容，就像畫線稿跟塗色或故事大綱與細節填充。
如果用畫線稿跟塗色來比喻，不同領域的產品由不同的色塊組合，而具體需要什麼色塊組合才會讓使用者滿意也是客戶才知道的。
這種商業領域的專業知識，就是一個做為開發者的侷限，因此敏捷宣言才有『 客戶協作，優於契約談判 (Customer collaboration over contract negotiation)。』