需求從哪裡來？

說到需求，這半年來我觀察到了很有意思的現象。需求分成兩種：

1. 使用者大約知道自己想要什麼功能，即使描述得很零散，但大致上能簡約寫出一個列點式的需求。
2. 需要我們去挖掘出他心裡面真正在想什麼，大部分談的是感覺，談的是願景，如何彌平願景與現實中的巨大鴻溝，對我而言充滿挑戰性。

先來說說前者，通常我會列出幾個大項：

1. 需求描述
2. 解決方案
3. 技術評估
4. 最終結論

需求描述

這部分如果能盡量了解使用者的背景知識，會對於列出解決方案十分有幫助。因為部分使用者會直接提出他認爲最佳的解決方案，但或許是天生好奇心旺盛，當我把我自己帶入使用者的實際生活場景時，如果我自己並不認為對「身為那個使用者的我」的工作流程有改善，我就會去深入了解為什麼使用者會認為這是最佳解。

情境說明：改善某個在流程上保有彈性，又可以隨意選擇流程的 App，因為最初並沒有設定「必須完成」的步驟有哪些，以至於流程管理較為混亂。

第一線使用者的主管：我希望可以在每個步驟都放上簽名流程！

我：為什麼會希望都放上簽名流程呢？這樣對於第一線工程人員並不友善呀。他如果原本只要請客戶簽一次名，變成一張訂單要簽很多次，他會覺得很惱人吧。

第一線使用者的主管：我想確保他每一步都有做到啊！有些人我也不知道他們是不是在摸魚，該做的推銷也不知道有沒有給客戶看，反正這幾個月的狀況都不太好。

我：那你跟我說這幾張類型單子一定要做的事情有哪些，有哪些是選填的，我來幫你想想怎麼改善。

從上述的故事中，我們可以知道，其實主管他並不是一定要工程人員簽名，而是希望知道他設定的日常交辦流程，有沒有正確地被工程人員執行，並讓他們的客戶知道。挖掘到更深入的意見，這時候，就可以來列解決方案了！

解決方案

這時候考慮的面向會是業務上的操作會怎麼執行，由於剛剛在需求描述有做點功課，在列解決方案時，除了可以考慮得更全面外，也可以讓方法更多元，但有時候牽涉的單位非常多，如果這時候有張清單能協助我們檢視利害關係人的話，會減少許多繞彎路的過程。

心中稍微順過了需求，就拉著我們家 UI/UX 來討論怎麼呈現才能讓使用者體驗上更順暢，列出了幾種解決方案後，帶著我們家設計畫給我的 wireframe，再去找客戶開會。

我：這邊我們有兩種建議

1. 我們把這些一定要完成的流程做個設定，如果沒有完成，就沒有辦法進行下一步，畫面上同時也會在側選欄上顯示哪些是已完成，哪些是尚待完成。如果有完成，按鈕會變成可執行的顏色。除此之外，資料庫內也會紀錄工程人員實際完成的項目與時間
2. 先顯示所有必要流程，並且不能隨意跳過這些流程，後面再放上附加的流程，這樣可以嗎？（簡報配圖說明）

第一線使用者的主管：我這邊沒什麼問題。兩種我回去想一下再回覆你。

事情到這裡我以為結束了，結果幾週後接到需要修改的電話，對方的稽核對於這個流程有疑義，於是我們又再次召開了會議，製作了流程影片，模擬了第一線工程人員與客戶互動的過程，才勉勉強強過關。

打到這裡發現有點過長，明天再繼續說明技術評估與最終結論的部分～感謝看到這裡的你們！