在了解 WebScoket 與 Socket.IO 的運作方式後，就......該止癢了吧？接下來就要老老實實規劃專案該有的樣貌了！

規劃的意義

根據專案的規模大小和類型，會有不同的規劃方式，但目的都是：

降低實際成果偏離預期方向的風險

秉持著在前言提到的：「廢也要廢得完整的精神」，小小的 side project 我也認為有規劃的價值，即使是在需要快速試錯的 PoC 階段，也必須明確地描述需求，才不會偏離預期成果太多！

正如先前提到 pseudo code 的概念，動手寫之前沒有先想過一些運作流程的話，很容易寫到懷疑人生、不知道這些功能怎麼進行下去。

使用者故事

使用者故事是以貼近日常口語的概念（自然語言）來描述功能需求。通常會在與客戶、利害關係人的需求訪談中進行一系列的歸納，最後梳理幾項必須要有的核心功能。

我是以做出類似 WooTalk 的網站為目標來進行這個 side project，就不用訪談了吧（偷懶）。

使用者故事大多以這樣的格式撰寫：

{ 角色 } 可以 { 行為 } 達到 { 成果 }

但目前我只是想先盤點大概有哪些功能，就不會寫 成果 部分，印象中大概有這些：

1. 我可以在網站首頁點擊「開始聊天」進行聊天配對
2. 我可以隨時點擊「離開」結束配對
3. 我可以在重新開啟網站後仍能留在同個聊天配對中
4. 我可以在收到新訊息時聽到音效並看到標題變化
5. 我可以在超過一分鐘後由系統自動終止配對
6. 我可以透過密語頻道進行配對
7. 我可以看到系統推薦的話題
8. 我可以點擊「載入」來查看先前的訊息
9. 我可以在對方打字時看到「正在輸入」的提示
10. 我可以看到自己最新訊息旁邊顯示「已送出/已送達」的狀態
11. 我可以看到對方最新訊息是以什麼裝置傳送
12. 我可以張貼尋人啟事
13. 我可以將尋人啟事分享到其他網站
14. 我可以查看使用聲明來了解網路聊天的使用規範
15. 系統可以要求使用者進行人機身份驗證

如果原本描述的範圍太大，我會將內容依「動作」分段，例如 12. 與 13. 本來是寫成 我可以張貼尋人啟事並分享到其他網站，這段文字描述看起來很自然，但其實同時描述了兩個動作（張貼和分享），分段之後會比較容易在流程圖的節點上對照。

功能優先級

正式開發時通常很難將這些使用者故事全數實現，因為：

1. 開發過程遇到較難克服的技術限制
2. 市場變動太快，已經不需要原先的需求
3. 利害關係人不玩了

......等等各種原因，導致原先談好的需求都一一被推翻。所以開發初期要快速試錯、捕捉市場或利害關係人的需求之外，這些功能的開發順序也需要釐清，才能有效率地推出一個可供使用的 MVP。

我通常以「核心」、「次要」、「許願」三種層級來為功能做開發優先度的層級，核心代表沒有這些功能，產品就不成立。

這裡我先列出核心的部分：

1. 我可以在網站首頁點擊「開始聊天」進行聊天配對，以便能快速找到聊天對象開始對話
2. 我可以隨時點擊「離開」結束配對，以便在不想繼續聊天時可以立即退出
3. 我可以在重新開啟網站後仍能留在同個聊天配對中，以便不會因為意外關閉而失去聊天進度
4. 我可以在收到新訊息時聽到音效並看到標題變化，以便即時知道有新訊息到達
5. 我可以在超過一分鐘後由系統自動終止配對，以便不會無限期等待而浪費時間

所以核心一定最先被開發出來，之後才會接著完成「次要」，最後則是評估一些可以附加上去的功能，並不影響核心運作。

這是我在評估大方向的方式～將這些層級分好後，後續開發可以再根據每一項使用者故事，拆分成更細項的任務分配。

本日小結

因為是分析現有的產品，所以算是相對輕鬆的環節 XD

前期規劃的難度跟專案本身的規模有關，越複雜的專案就越需要整合更多的訪談、洞見與分析，才能梳理出相對完整的使用者故事。

隨著後續開發迭代，一定會發現有些東西在前期規劃時遺漏了，或是要推翻，這是正常的，而這也正是開發中需要持續追蹤的地方。只要找到問題，就在下一次迭代中進行改善，而不是強行完成後才提出了一些推翻原本概念的新需求。

參考資料

• WooTalk
  -什麼是使用者故事(User Story)？