項目問題
1.在軟件中堆砌新功能，然而用戶不用：原因是開發人員將工程方法當成設計工具。
2.設計的核心概念在開發實現中會容易被抹殺，就像做手術，按照規定走完所有的手術流程，病人死在了手術臺上：原因是開發和設計相關人等沒有達成一致意見作出承諾，關注點沒有集中放在用戶身上，而是流程步驟。
解決方案：用戶故事地圖（有效溝通）
1.便籤、膠帶在牆上討論畫出軟件系統地圖。
1.1 就像一個網站導航和頁面，還包括每個交互對象（比如按列表）動作的前後臺邏輯。
1.2 紅色便籤用來標註用戶（用戶模型，畫用戶），黃色標籤用來描述用戶行爲（故事）。
1.3 第一行是用戶便籤（分散一點）
1.4 第二行是各個用戶主要的行爲便籤，按照用戶與用戶之間交互操作流程順序貼出。
1.5 第三行開始在每個主要操作行爲便籤下面，分解各個行爲，單位是3個工作日內能開發完成的工作量（細化行爲便籤）
1.6 與高層開始討論分幾期開發，第一期需要抓住哪些用戶，需要首先支持這些用戶的哪些基本行爲。
1.7 產生最小可發佈集：與特定用戶溝通（建立特定目標用戶羣），進一步細化行爲，將細化的行爲劃分成必做和不做功能，移動細化行爲標籤上下順序，以調整優先級。
1.8 根據第一期的發佈集使用Axure畫出demo原型頁面（用來驗證假設的行爲是否可用可行），打印出頁面，貼在對應行爲標籤下面，與用戶溝通調整demo（多輪用戶測試和打磨）。
1.9 與開發人員溝通，關注細化行爲便籤,將對應行爲的前後端業務邏輯貼在demo頁面打印頁上。
1.10 將要未掌握的技術架構知識使用綠色便籤貼在行爲便籤上（風險便籤），在風險便籤上貼出風險燃盡圖。劃分2個階段，第一階段成果是編寫無技術障礙的基礎功能，發MVP（最小發布框架試驗品）基礎功能已經具備，用戶可以試用；第二階段是掃除有技術障礙的功能和優勢功能，發佈第一期所有功能給用戶羣試用。
1.11 可以直接在行爲標籤上簽名開發和測試，文檔人員記錄待辦列表，畫出燃盡圖開始開發和寫測試案例測試。
1.12 第二期重複1.5到1.11的步驟。