如果「初始任務」沒有做好，專案就像是蓋大樓沒有施工圖紙，蓋歪、抗震係數不足、工程 Delay 都是正常發揮。

在上篇文章中，筆者介紹了專案啟動時要做的事。

今天讓我們來了解，在正式開發前有哪些「初始任務」要做，以及每個步驟由誰負責。

▋STEP 1：規劃每個階段的時程

由「PM」將專案的需求拆分成不同的 Phase，這樣工程師比較能集中注意力在特定事物上，每個 Phase 都需要把如下的任務納入考量：

1. 要完成的功能（ex：前端、後端）。
2. 撰寫測試程式的時程（ex：單元測試、壓力測試）。
3. QA 團隊測試的時程。
4. 測試、正式環境部署的時程。

規劃時要保留「緩衝時間」，因為測試一次就過基本上是不可能發生的事情，往往需要預留 10~15% 的時間來修 Bug。

▋STEP 2：撰寫 Ticket 需求規格

由「PM」在專案管理系統上為每項任務建立 Ticket，建議需求規格的內容要包含：

1. Prototype 截圖：讓工程師了解功能具體的位置在哪。
2. 需求描述：說明這個功能是用來做什麼的，它跟哪些功能有相依性。
3. 相關計算規則：如果需求是「計算商品總價」，那就要列出「產品搭配、折價卷、信用卡優惠…」等多種排列組合的計算規則。
4. 使用的邏輯：搜尋欄位可以查詢的欄位有哪些？搜尋的邏輯是 And 還是 Or？
5. 關聯需求：像是後端做完 API 後交付給前端，就需要將兩個 Ticket 關聯。
6. 驗收標準：判斷這個 Ticket 是否可以 Close 的依據。

▋STEP 3：評估每個 Ticket 的時數

不同 Ticket 的難易度不同，這邊會由「Tech Lead」與「工程師團隊」一同評估，確認該 Ticket 由誰負責，並評估需要的時數。

筆者在這裡提醒大家，千萬不要勉強自己估出一個很難完成的時數，不然卡關時，會影響到後續一系列的時程規劃（但也不要估出不合理的時數）。

如果某個 Ticket 預估的時程超過 6 小時，建議要再做拆分，否則很難衡量每天實作的進度。

▋STEP 4：確認能否在截止日前完成

只要是專案就一定有截止日期，「PM、Tech Lead」需要在這個階段將 Ticket 的時數轉化為甘特圖來審視，若發現已經超過截止日期，那勢必要再做一些調整，比如：

1. 簡化部分功能（ex：原本要用 Auto-Complete，現在改用一般的搜尋）。
2. 規劃 MVP 讓客戶使用（ex：原本要經過一系列複雜流程才能建立的資料，先用 Seeder 代替，以此大幅減少工程師的開發時間）。

這邊不建議堅持原計劃完成所有功能，因為快速開發所累積的技術債，於未來要花更多的時間處理。

▋STEP 5：分配 Ticket

由「PM」規劃這個 Sprint 要完成哪些 Tickets，然後在 Sprint Planning 時進行細節分工；假設一個 Sprint 為 2 週，建議每個人身上掛的 Tickets 總時數不要超過 65 小時，因為：

1. 時常會有臨時的會議、需求、Bug…等意外事件，需要保留緩衝時間。
2. 在專案初始階段，我們無法保證是否有遺漏的規劃、邏輯的錯誤，若把時間塞滿就很難有轉圜的餘地。
3. 有時舊專案會有緊急狀況需要優先處理，這個也會吃掉不少時間。

▋小結

專案的「初始任務」非常重要，若忽略其中一個步驟，都等於埋下一顆未爆彈。

相信經過「專案啟動、初始任務」這兩個主題，大家都能體會專案前期規劃、評估的重要性；但如果開發時 PM 與 RD、RD 與 RD 間的溝通不良，專案在執行時也會困難重重。

因此在下一篇文章中，筆者會針對常見的合作情境，分享實用的「溝通格式」，讓專案執行時更為順利！

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 為什麼軟體團隊需要制定工作流程？正式開發前的「初始任務」有 5 個步驟不能忽略！｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。