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

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

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

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

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

▋工作記錄（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 間的合作要注意這點！｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

RD 與 PM 如果有默契，那會是一個很好的組合；但如果彼此水火不容，專案絕對會各種出包。

標題的火藥味有點濃，但 RD 與新手 PM 溝通時，真的很常出現類似的對話。

RD 與 PM 如果有默契，那會是一個很好的組合；但如果彼此水火不容，專案絕對會各種出包。

▋為什麼會出現標題的對話？

有些公司請 PM 更像是在找秘書，基本上不太管專業背景、從業經驗，只是找一個會紀錄需求，安排時程的人。

在這樣前提下找到的 PM，說實話 RD 真的心很累，大家都是出來打工的，憑什麼要我成為你增加經驗的工具人。

因為沒有專業背景，所以 PM 問的問題通常沒有什麼 Sense，甚至類似的問題還會重複問；而這個狀況除非 PM 有自知之明去學習相關知識，否則未必會隨時間改善。

大部分 RD 會服從有專業能力的人，然後看不起那些什麼都不懂，只會一直塞工作給他們的人。
有些比較情緒化的 RD 在不爽的時候，就算看到專案規劃有問題，也不會出言提醒（不過這樣做也會害到自己，筆者建議要保持工程師的專業素養）。

▋面對專業的 PM

當然業界也有很多專業的 PM，實務經驗豐富的他們對時程尤其敏感。

通常 PM 在收到需求後，會先請 RD 評估需要的工時；如果 RD 評估的工時超過 PM 心中的時程，那 PM 接下來就會詢問為什麼要花這麼多時間？

這裡我們先分析 RD 估時較長的幾種原因：

1. 之前沒有使用過這項技術，在未知的狀態下，會先拋出一個較長的時程。
2. 即使遇到需求變更，專案的截止日期也不會改變，所以先給自己預留一份緩衝時間。
3. 前段時間工作 Loading 太重，想在淡季為自己爭取一點喘息空間。

關於第 1、2 點，我們放到下一個 PM 篇再來討論；今天這篇文章先來聊聊 RD 如何用好的理由實現第 3 點。

▋RD 如何用好的理由為自己爭取喘息空間

有經驗的 PM 會適時地讓 RD 有喘息空間，但 RD 也要給 PM 一些好的理由，讓他可以跟老闆交代，這就是筆者說的「默契」，比如說：

• 重構程式：快速開發容易累積技術債，可以趁淡季的時候進行重構，以維護專案程式碼的品質；而多少程式需要重構，每個功能重構所需的時間都是很有彈性的。
• 研究新技術：評估未來專案可能會用到的技術、套件，並提前研究，避免日後專案執行時卡關。
• 整理技術文件：在有時程壓力的狀況下，常常 API 文件、部署文件、使用說明文件的內容不齊全，可以趁這個時機點更新到最新版。

筆者只是舉出 3 個常見例子，歡迎讀者留言補充自己是如何爭取「喘息空間」的。

▋結語

「專業」為自己贏得尊重，彼此的「默契」讓合作更加順利。

撰寫需求規格時，PM 很難把每個面向都考慮得很完整，因此開發時，需要 RD 適時地與 PM 溝通，或是用自己的經驗補齊不足之處；但具體做到哪個程度，也要參考到專案的時程。

下篇文章，就讓我們改由 PM 的角度來討論這個話題吧。

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

這篇文章 講這麼多次了你還問？聽不懂就不要問！── RD 與 PM 的攻防戰｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。