PM 雖然被稱之為專案「經理」，但在大多數的公司並沒有管理實權；如果想讓 RD 跟你配合，至少要對技術要有一定程度的了解，並能聽懂對方想表達的內容。

本篇文章會分享一些實用技巧，讓 PM 獲得更精確的資訊來判斷 RD 的估時是否合理，並告訴你遇到不配合的 RD 該如何應對進退；話不多說，讓我們看下去！

了解對方的專業真的很重要嗎？

筆者很負責任的跟你說：「超級重要！」

當然這不是要你成為該領域的專家，但至少要具備「溝通、評估」的能力。

以 Web 開發舉例，如果你不具備前端、後端、資料庫的概念，你怎麼評估及分配任務？難道只靠感覺來判斷工程師的估時是否合理？

就拿筆者過去的經驗來說，儘管我有全端開發經驗，但在擔任公司 PM 時，因為缺乏與設計師合作的經驗，導致合作初期無法判斷設計師的估時是否合理。

了解專業是為了評估出「合理時間」，並在遇到不合理的狀況時，能適時提出自己有疑問的觀點。

在此特別強調「不要亂估時」！一但被發現會破壞彼此的信任，也是不尊重自己專業的表現。

如果 RD 的估時超出 PM 心中的時程

原則上，PM 都是秉持相信 RD 的態度請他估時的；但有時 RD 估出來的時數，會讓人懷疑自己是不是被糊弄了。

如果專案有時程壓力，PM 會需要更精確的資訊來協助判斷，比如：

1. 向 RD 詢問該 Task 的細節：就像標題所述，PM 需要了解這些時間花在哪裡，是否需要拆成多個 Subtask？因為有時一行字的需求，背後可能涉及到資料庫的遷移、後端 API 改寫、前端畫面調整。
2. 是否有擅長這個領域的人：有時會有這麼長的估時，是因為指派對象不擅長這部分的技術，或是缺乏相關經驗；如果時程寬鬆，那是一個很好的學習機會，但如果有時程壓力，還是看誰擅長就由誰負責（如果 PM 不清楚每位成員擅長的領域，在 Planning 階段可以請資深工程師 or Tech Lead 從旁建議）。
3. 如果是全新領域：RD 在面對陌生的技術時，也只能憑感覺亂估；因此建議開一個「研究新技術」的 Task，讓 RD 先對技術有基礎的認知，在這之後估出來的時間才有參考價值。
4. 是否有最小可行性方案：如果不是技術達不到，而是時程根本不夠，那就要考慮縮減非必要功能，或是採用替代方案。比如說有個需求是「使用者列表」，在 API 設計上，工程師會覺得除了「查詢」外，應該還要有「新增、修改、刪除」的功能，但如果客戶沒有這些需求，那或許先階段用 Seeder 把使用者寫入資料庫就可以了。

RD 估時較長，還有一個常見原因，那就是面對「需求變更」時的緩衝時間；理想上需求變更應該要延長專案時程，但實務上專案的截止日期很難調整，因此在估時上多少會預留一點空間來保護自己。

這個部分涉及到組織文化、公司面對客戶的話語權、主管態度等多個方面，如果讀者對這個話題感興趣，筆者會在獨立一篇與大家分享。

適當的借勢

如果 PM 初來乍到，而 RD 年資很深，那有可能遇到 PM 叫不動 RD、RD 明顯亂估時的狀況。

在職場上我們盡量與人為善，但假使對方就是很皮，你以禮相待他還是使勁搞破壞；那適時的請主管協調也是有必要的，不過這個方法偶爾為之還行，如果常常使用不但會被 RD 討厭，還會讓主管懷疑你的工作能力。

每間公司的文化不同，但拿人手短、吃人嘴短幾乎是共通的；有時請 RD 喝個下午茶，你會發現大家突然變得很好溝通（每個人的社交方式不同，也歡迎讀者分享自身經驗）。

結語

有些 RD 被詢問估時的細節時，會覺得 PM 不尊重專業；但 PM 真的是只是想了解細節，並尋求更好的方案。

筆者認為 PM 與 RD 是平等互助的關係，只是彼此的立場與看事情的角度有些許差異；如果總是刁難對方，其實是在損害自己的 Credit，並讓主管難做人。

「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 的角度來討論這個話題吧。