今天就讓我們來聊聊「專案執行」時，如何讓合作的過程更加順利。

以筆者過去的經驗來說，團隊合作免不了要「溝通」，但每個人的溝通能力落差極大，有些人總覺得對方是自己肚子裡的蛔蟲，因此詢問問題、交付任務都沒說明細節，時常需要你來我往的多次確認。

為了減少彼此的衝突，我們可以針對常見的合作情境設計「格式」與「規範」。

工作記錄（Work Log）

如果團隊有使用專案管理系統，為了日後方便追溯與釐清狀況，建議填寫的內容如下：

• 如果實作的方向是討論出來的，請紀錄「與會人員」與「決議結果」。
• 如果使用到特別的演算法、技術、套件，請特別附註。
• 如果該 Ticket 完成後要由其他人接手處理（ex：後端完成 API 後交付給前端），請說明要執行哪些指令（ex：DB Migration、Seeder…），並提供相關文件。
• 如果發現 Ticket 完成的時間與估計的不同，請與 PM 討論並調整。

工程師之間的合作

律定格式，讓溝通有一定的品質。

• 明定 Ticket 執行順序：一個 Sprint 中，每個工程師手上有很多的 Ticket，但有些 Ticket 會有所謂的「前置條件」，為了減少等待的空窗期，工程師要在「 Sprint Planning 時溝通好」。
• 回報 API Bug：請說明是在「哪個系統」、「哪隻 API」、「什麼參數下」會發生。
• 回報 Web Bug：請說明是在「哪個系統」、「哪個畫面（截圖）」、「如何操作」會發生。
• 遇到自己無法解決的問題：請說明是在「哪個系統」、「哪個 Ticket」、「你做過哪些嘗試」、「你認為可能的解決方案」。

工程師與 PM 的合作

工程師與 PM 合作時，千萬不要惜字如金，大家都要把話講清楚；工程師要求 PM 做到的事，自己也要做到。

• 如果 PM 請工程師完成 Sprint 以外的需求：請說明「任務優先度」、「為什麼會有這個需求」、「可以將哪個 Ticket 排後面一點」。
• 如果工程師在開發過程中收到其他團隊的需求：請將對話窗口轉移到「PM」，由他來統一處理。
• 如果工程師請 PM 開 Ticket：需描述「哪個系統」、「為什麼會有這個需求」、「需求描述」、「估計時數」。
• 若 Loading 太重無法負荷：請說明「原因」，如：掛的 Ticket 數量太多、任務分配不均、某個 Ticket 實作遇到困難。
• 若多個專案同時發起高優先度的任務：有些工程師身上會掛多個專案，若不幸有兩個以上的專案同時發起高優先度的任務，就需要請「PM」協助排出優先順序。

為什麼都要由 PM 來開 Ticket？

有些工程師覺得自己開 Ticket 比較快，資訊多轉一手給 PM 根本是浪費時間，但這個制度是有原因的，如果不這樣做就可能導致：

• PM 對專案的掌握度下降：如果大家都自己開 Ticket，PM 會無法掌握每個人實際在做的任務，即使有 Tag 到 PM，PM 也未必有辦法看到每一則訊息。
• 專案進度偏離原定計畫：很多時候，工程師心中的任務優先順序跟 PM 是不一樣的，這導致最後在核對完成的任務時，會因為彼此的認知落差而產生爭執。
• 勞逸不均：有些工程師發現問題就想解，導致身上背了一堆 Ticket 天天加班，而其他工程師閒閒沒事做。
• 做了徒勞無功的任務：有些功能從專案的角度來看，可能不重要，甚至是不需要的。

為了避免上述的狀況發生，如果有任何想做的需求，請先與 PM 討論，讓 PM 從整體的角度來判斷（ex：如果你的 Loading 太重，PM 就可能將你提出的 Ticket 分配給其他人做）。

結語

筆者透過 3 個主題（專案啟動、初始任務、專案執行），與讀者分享制定工作流程的重要性。

制定工作流程是為了讓團隊運作更為順利，所以其中的規範、格式都要與成員充分討論；在彼此有共識的狀態下，工作流程才有存在的價值，否則會變成一種負擔。

最後再次提醒大家，文章的流程未必適用於每個團隊，但可以做為參考方向。

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

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 間的溝通不良，專案在執行時也會困難重重。

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

以筆者過去的工作經驗來說，如果工作流程只靠口頭制定、團隊默契，在沒有明確的文字規範下，大家真的無所適從，當新人加入時還需要更長的磨合期。

而制定團隊的工作流程，能夠讓成員了解自己在各階段要負責的任務；儘管一開始的工作流程可能很粗糙，但只要有了第一版，流程就能在日後的實踐中不斷優化與完善。

由於「為什麼軟體團隊需要制定工作流程」這個議題的涵蓋範圍較廣，所以筆者會拆分成「專案啟動、初始任務、專案執行」等幾個主題進行分享，今天這篇文章先介紹「專案啟動」時要做的事。

內文以「Web 開發」為範例，不同行業請酌情參考。

STEP 1：需求訪談＆初步規劃

這個階段的目標是「初步確認需求、討論需求可行性、讓客戶認可 Wireframe 流程」。

1. 由「PM」與客戶討論需求，在收集完需求後，將其以心智圖（Mind Map）的方式呈現。
2. 接著請「UI/UX」依造需求設計 Wireframe。
3. 待 Wireframe 完成後，「Tech Lead、PM、UI/UX」一起開個會，初步確認流程以及功能的可行性，並討論是否有需要調整的部分。

有些客戶會提出一些會異想天開 or 奇怪的需求，如果在初步規劃就發現這些問題，在反駁的同時請給予對應的建議，比如：

• 我想要一頁顯示 1000 筆資料方便搜尋：有些人還是習慣用「眼睛」來搜尋，但這樣的效率極差，當資料量大的時候還要翻頁；筆者建議與客戶進一步討論他實務上會搜尋的「欄位」有哪些，也許「篩選」功能更符合期待。
• 我想要把過去一年的出貨訂單匯出至 Excel 來統計數據：客戶過去可能習慣用 Excel 函數來分析數據，但這個功能實際上可以做成系統的「儀表板」。

STEP 2：確認具體需求＆完善規劃

這個階段要將「原本模糊的規格具體化、完成 Prototype 設計」。

1. 在客戶確認完需求及Wireframe 的內容都沒問題後，請「UI/UX」開始設計 Mockup。
2. 由「Tech Lead」確認 Mockup 上的細節是否都有考慮到（ex：哪些欄位適合拿來搜尋、不同權限看到的畫面、有哪些元件可以設計為共用模組）。
3. 待 Mockup 上的功能＆流程都確認沒問題後，請「UI/UX」開始設計 Prototype。

血淚史提醒：

專案初始的設計盡量從 Wireframe 開始，就算專案規模較小也不要直接畫 Mockup；因為在前期客戶的需求會時常變動，就算突然加大投資，小專案變成大專案也是很常見的，若使用 Mockup 會需要花更多的時間在調整上面。

STEP 3：向團隊成員說明

在需求與流程相對穩定後，接下來就要與「團隊成員同步資訊」。

1. 由「PM」向團隊成員說明系統的功能與流程，確保大家理解這個專案要完成的目標（這邊建議先用心智圖說明架構，再用 Prototype 模擬實際流程）。
2. 由「Tech Lead」向工程師團隊提醒各功能在設計上要注意的細節（ex：哪些欄位要設計 Auto-Complete、是否有特別的 Validation Rules、某些功能需要提前 Survey 避免卡關）。

這個階段主要是讓團隊成員對每個 Feature 都有具體認知，然後評估自己感興趣 or 擅長的 Feaure，若發現有沒碰過的技術也能提前研究。

小結

專案啟動時，「Tech Lead、PM、UI/UX」在各階段都要做好把關。

相信有實務經驗的讀者，都很清楚「明確的需求、具體的流程」對工程師來說有多麼重要；如果一切都非常模糊，那後續開發一定會遇到各式各樣的問題。

在團隊成員都了解專案的目標後，為了保證後續開發順利，我們還有一些「初始任務」要做，這部分筆者會在下一篇文章與大家分享。