專案在執行時免不了要「溝通」，但每個人溝通表達的能力落差極大；為了減少彼此的衝突，我們可以針對常見的合作情境設計「格式」與「規範」。

在上篇文章中，筆者介紹了正式開發前的初始任務有哪些。

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

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

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

▋工作記錄（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 個主題（專案啟動、初始任務、專案執行），與讀者分享制定工作流程的重要性。

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

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

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

這篇文章 想讓「專案執行」更加順利？工程師與 PM 間的合作要注意這點！｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。