在流程不明確的狀態下，團隊成員只能憑藉自己的直覺做事；如果彼此對一件事的認知不同就容易造成誤會，甚至爆發不必要的衝突。
由於過去許多工作流程都是口頭制定，沒有明確的文字敘述，因此想透過這篇文章來整理流程，並在日後的實踐中不斷優化與完善。
大綱ㄧ、專案初始二、初始任務
➤ 評估每個階段的時程
➤ 撰寫 Ticket 的需求規格
➤ 估計每個 Ticket 的時數
➤ 確認 Ticket 的總時數是否在專案的截止日期內
➤ Ticket 分配
➤ 專案初始環境建置
➤ Server 建置三、專案進行中
➤ 進度回報
➤ 工程師之間的合作
➤ 工程師與 PM 的合作
➤ 了解為什麼都要由 PM 來開 Ticket
ㄧ、專案初始
STEP 1：由 PM 與客戶討論具體需求。
STEP 2：請 UI/UX 設計師依造需求初步完成 Wireframe。
STEP 3：PM、UI/UX、Tech Lead 一起確認流程、功能的可行性，判斷是否有需要調整的部分。
STEP 4：待客戶認可 Wireframe 後，請 UI/UX 設計師將其升級成 Mockup。
STEP 5：由 Tech Lead 確認 Mockup 上需要注意的細節（ex：哪些欄位適合拿來搜尋、不同權限看到的畫面、有哪些元件可以設計為共用模組）。
STEP 6：在 UI/UX 設計師調整為 Prototype 後，由 PM（或 UI/UX 設計師）向團隊成員說明系統的功能與流程，確保大家理解這個專案要完成的目標。
STEP 7：由 Tech Lead 向工程師團隊說明各功能在設計上要注意的細節（ex：哪些欄位要設計 Auto-Complete、是否有特別的 Validation Rules、某些功能需要提前 Survey 避免卡關）。
良心建議：專案初始的設計盡量從 Wireframe 開始，就算專案規模較小也不要直接畫 Mockup；因為客戶的需求在前期會時常變動，就算突然加大投資，小專案突然變成大專案也是很常見的，若使用 Mockup 會要花更多的時間在調整上面。
二、初始任務
➤ 評估每個階段的時程
由 PM 將專案的需求拆分成不同的 Phase，這樣工程師比較能集中注意力在特定事物上，每個 Phase 都需要把如下的任務納入考量：
- 要完成的功能（ex：前端、後端）
- 撰寫測試程式的時程（ex：單元測試、壓力測試）
- QA 團隊測試的時程
- 測試、正式環境部署的時程
規劃時要保留「緩衝時間」，因為測試一次就過基本上是不可能發生的事情，往往需要預留 15~30% 的時間來修 Bug。
➤ 撰寫 Ticket 的需求規格
由 PM 在專案管理系統上為每項任務建立 Ticket，建議需求規格的內容要包含：
- Prototype 截圖：讓工程師明白功能具體的位置在哪。
- 需求描述：說明這個功能是用來做什麼的，它跟哪些功能有相依性。
- 相關計算規則：以計算商品總價來說，就會有「產品搭配、折價卷、信用卡優惠…」等多種排列組合。
- 使用的邏輯：搜尋欄位可以查詢的欄位有哪些？搜尋的邏輯是 And 還是 Or？
- 關聯需求：像是後端做完 API 後交付給前端，就需要將兩個 Ticket 關聯。
➤ 估計每個 Ticket 的時數
不同 Ticket 的難易度不同，這邊會由 Tech Lead 分別向 Frontend、Backend 工程師確認 Ticket 的估時。
此時工程師千萬不要勉強自己，估出一個很難完成的時數，不然在卡關時，會影響到後續一系列的時程規劃。（但也不要估出不合理的時數）
如果某個 Task 預估的時程超過 6 小時，建議要再做細分，否則很難衡量每天實作的進度。
➤ 確認 Ticket 的總時數是否在專案的截止日期內
只要是專案就一定有截止日期，如果將每個預估的時數加總後，發現已經超過了專案的截止日期，那勢必要做一些調整，比如：
- 簡化部分功能（ex：原本要用 Auto-Complete，現在改用一般的搜尋）。
- 規劃 MVP 先交出去讓客戶使用（ex：原本要經過一系列複雜的流程才能建立的資料，先用 Seeder 代替，以此大幅減少工程師的開發時程）。
這邊不建議堅持原計劃完成所有功能，因為快速開發所累積的技術債，於未來要花更多的時間處理。
➤ Ticket 分配
由 PM 規劃在這個 Sprint 中要完成的 Ticket，然後在 Sprint Planning 時進行細節分工；假設一個 Sprint 為 2 週，建議每個人身上掛的 Task 時數不要超過 60 小時，因為：
- 時常會有臨時的會議、需求、Bug…等意外事件，需要保留緩衝時間。
- 在專案的初始階段，我們無法保證是否由遺漏的規劃、邏輯的錯誤，若把時間塞滿就很難有轉圜的餘地。
- 舊的維護專案，有時會有緊急的狀況需要優先處理，這也會吃掉不少時間。
➤ 專案初始環境建置
由 Tech Lead 或是 Senior Engineer 負責專案初始環境建置，初始化的專案需要在 README.md 中有以下說明：
- 環境需求：Node.js 版本、PHP 版本、MySQL 版本…
- 如何在 Local 端建立：安裝流程、環境變數…
➤ Server 建置
由 Tech Lead 開出專案系統所需的硬體配置（正式機、測試機）、DNS、要安裝的軟體/套件（ex：Ubuntu Server、MySQL、Node.js、PHP…各自的版本），並請 PM 填寫需求單讓 MIS 依照此規格進行建置。
三、專案進行中
➤ 進度回報
如果團隊有使用專案管理系統，為了日後方便追朔與釐清狀況，建議填寫的內容如下：
- 如果實作的方向是討論出來的，請紀錄「與會人員」與「決議結果」。
- 如果使用到特別的演算法、技術、套件，請特別附註。
- 如果該 Ticket 完成後要由其他人接手處理（ex：後端完成 API 後交付給前端），請說明要執行哪些指令（ex：DB Migration、Seeder…），並提供相關的 API 文件。
- 如果發現該 Ticket 完成所花時間與當初的估計有所不同，請與 PM 討論並調整。
➤ 工程師之間的合作
- Ticket 執行順序：一個 Sprint 中，每個工程師都會有很多的 Ticket，但有些 Ticket 會有所謂的「前置條件」，建議在開始作業前要先彼此商議，避免出現等待的空窗期。
- 回報 API Bug：請說明是在「哪個系統」、「哪隻 API」、「什麼參數下」會發生。
- 回報 Web Bug：請說明是在「哪個系統」、「哪個畫面（截圖）」、「什麼操作下」會發生。
- 遇到自己無法解決的問題：請說明是在「哪個系統」、「哪個 Ticket」、「你做過哪些嘗試」、「你認為可能的解決方案」。
➤ 工程師與 PM 的合作
- PM 請工程師完成 Sprint 以外的需求時，請說明「任務優先度」、「為什麼會有這個需求」、「可以先將哪個 Ticket 排後面一點」。
- 如果工程師在開發過程中收到其他團隊的需求，請將對話窗口轉移到 PM。
- 如果工程師要請 PM 協助開 Ticket，需描述：「哪個系統」、「要處理的任務/Bug」、「預計要做的事項」、「預計完成所需時間」。
- 若身上的 Ticket 數量爆炸多、任務分配不均，請及時反應。
如果是同一個專案，我們可以輕鬆的排出任務的優先順序；但如果多個專案同時發起優先度高的任務，工程師在這種狀況下會不知所措，需要由 PM 協助排出優先順序。
➤ 了解為什麼都要由 PM 來開 Ticket
- 如果大家都自己開 Ticket，PM 會無法掌握每個人實際在做的任務，即使有 Tag 到 PM，PM 也未必有辦法看到每一則訊息。
- 工程師心中的任務優先順序可能與 PM 不同，這會造成最後在核對完成的任務時，因為彼此的認知落差產生爭執。
- 每個任務完成所需的時間成本不同，可能有些任務是可以不必做，又或者是能交給其他人去做的，讓 PM 從整體的角度去看較不會出現勞逸不均的狀況。
制定大家願意共同遵守的工作流程，在了解彼此的權利＆義務後，相信團隊的運作會更為順利；文章的流程未必適用於每個團隊，僅為筆者過去經驗的彙整。
工程師血淚史▋ 團隊在系統開發上遇到了哪些問題
▋ 需求不斷變更，到底哪個環節出錯了
▋ 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？
▋ 如果沒有明確的開發流程，團隊將會無所適從(本篇)
▋ 你知道對專案來說，README.md 有多麼重要嗎？▶︎ 如果這篇文章有幫助到你1. 可以點擊下方「Follow」來追蹤我～
2. 可以對文章拍手讓我知道 👏🏻你們的追蹤與鼓勵是我繼續寫作的動力 🙏🏼▶︎ 如果你對工程師的職涯感到迷茫1. 也許我在iT邦幫忙發表的系列文可以給你不一樣的觀點 💡
2. 也歡迎您到書局選購支持，透過豐富的案例來重新檢視自己的職涯
