請你說明一下，這個功能的時數是怎麼估出來的？ ── RD 與 PM 的攻防戰｜專家論點【林鼎淵】
在上篇文章中，筆者分析了 RD 在面對任務指派時的想法。
PM 雖然被稱之為專案「經理」，但在大多數的公司並沒有管理實權；如果想讓 RD 跟你配合，至少要對技術要有一定程度的了解，並能聽懂對方想表達的內容。
本篇文章會分享一些實用技巧，讓 PM 獲得更精確的資訊來判斷 RD 的估時是否合理，並告訴你遇到不配合的 RD 該如何應對進退；話不多說，讓我們看下去！
▋了解對方的專業真的很重要嗎？
筆者很負責任的跟你說：「超級重要！」
當然這不是要你成為該領域的專家，但至少要具備「溝通、評估」的能力。
以 Web 開發舉例，如果你不具備前端、後端、資料庫的概念，你怎麼評估及分配任務？難道只靠感覺來判斷工程師的估時是否合理？
就拿筆者過去的經驗來說，儘管我有全端開發經驗，但在擔任公司 PM 時，因為缺乏與設計師合作的經驗，導致合作初期無法判斷設計師的估時是否合理。
了解專業是為了評估出「合理時間」，並在遇到不合理的狀況時，能適時提出自己有疑問的觀點。
在此特別強調「不要亂估時」！一但被發現會破壞彼此的信任，也是不尊重自己專業的表現。
▋如果 RD 的估時超出 PM 心中的時程
原則上，PM 都是秉持相信 RD 的態度請他估時的；但有時 RD 估出來的時數，會讓人懷疑自己是不是被糊弄了。
如果專案有時程壓力，PM 會需要更精確的資訊來協助判斷，比如：
- 向 RD 詢問該 Task 的細節：就像標題所述，PM 需要了解這些時間花在哪裡，是否需要拆成多個 Subtask？因為有時一行字的需求，背後可能涉及到資料庫的遷移、後端 API 改寫、前端畫面調整。
- 是否有擅長這個領域的人：有時會有這麼長的估時，是因為指派對象不擅長這部分的技術，或是缺乏相關經驗；如果時程寬鬆，那是一個很好的學習機會，但如果有時程壓力，還是看誰擅長就由誰負責（如果 PM 不清楚每位成員擅長的領域，在 Planning 階段可以請資深工程師 or Tech Lead 從旁建議）。
- 如果是全新領域：RD 在面對陌生的技術時，也只能憑感覺亂估；因此建議開一個「研究新技術」的 Task，讓 RD 先對技術有基礎的認知，在這之後估出來的時間才有參考價值。
- 是否有最小可行性方案：如果不是技術達不到，而是時程根本不夠，那就要考慮縮減非必要功能，或是採用替代方案。比如說有個需求是「使用者列表」，在 API 設計上，工程師會覺得除了「查詢」外，應該還要有「新增、修改、刪除」的功能，但如果客戶沒有這些需求，那或許先階段用 Seeder 把使用者寫入資料庫就可以了。
RD 估時較長，還有一個常見原因，那就是面對「需求變更」時的緩衝時間；理想上需求變更應該要延長專案時程，但實務上專案的截止日期很難調整，因此在估時上多少會預留一點空間來保護自己。
這個部分涉及到組織文化、公司面對客戶的話語權、主管態度等多個方面，如果讀者對這個話題感興趣，筆者會在獨立一篇與大家分享。
▋適當的借勢
如果 PM 初來乍到，而 RD 年資很深，那有可能遇到 PM 叫不動 RD、RD 明顯亂估時的狀況。
在職場上我們盡量與人為善，但假使對方就是很皮，你以禮相待他還是使勁搞破壞；那適時的請主管協調也是有必要的，不過這個方法偶爾為之還行，如果常常使用不但會被 RD 討厭，還會讓主管懷疑你的工作能力。
每間公司的文化不同，但拿人手短、吃人嘴短幾乎是共通的；有時請 RD 喝個下午茶，你會發現大家突然變得很好溝通（每個人的社交方式不同，也歡迎讀者分享自身經驗）。
▋結語
有些 RD 被詢問估時的細節時，會覺得 PM 不尊重專業；但 PM 真的是只是想了解細節，並尋求更好的方案。
筆者認為 PM 與 RD 是平等互助的關係，只是彼此的立場與看事情的角度有些許差異；如果總是刁難對方，其實是在損害自己的 Credit，並讓主管難做人。
「RD 與 PM 的攻防戰」這個議題就先講到這邊，希望有讓大家看到不同角度的思維模式，如果喜歡類似的內容也歡迎留言告訴我～
☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。
瀏覽 16,637 次
