PM與RD如何互利共生

文／Vida Lin

最近有社群朋友問了工作上的問題，小女洋洋灑灑寫了一個故事案例、也收到更多Q&A，便順手來Medium整理一下，希望能留下紀錄，也跟其他有緣的開發朋友多交流，有機會激盪出更多好做法。

一、誰適合讀本篇？

1. Junior 產品/專案經理、RD工程師
2. 開發過程常遇到時程控管、溝通困難的人
3. 開發進度常delay但卻不知道原因的PM

二、故事案例

有次因為當期開發sprint大delay，中間工程師也沒有即時說。所以，趁著Retro會議，我（PM）跟工程師說：希望大家以後遇到技術問題、會delay的時候可以提早告知，不要太晚講。
PM雖然很常問需要多久，但不是要工程師馬上做出來的意思，是因為可能下午或隔天就要讓老闆/客戶驗收，這之前，還要經過QA、PO驗收，沒問題才能交付。
所以如果真的來不及，PM得留buffer或想好備案、跟主管討論，避免開天窗。

然後，當場有工程師馬上回說：「可是，妳之前會馬上跑過來當面問我們要多久，也沒有說過原因。」

當下我一臉尷尬，但經過那次會議，也才明白，其實大家都沒有惡意，只是有壓力或緊繃時，可能會表錯意、或用錯方法。但大家都是想把事情做好。

如果，過去溝通前，PM可以先私訊工程師，問他是不是在忙、不想被打擾，這樣真的當面溝通時，他應該會更願意表達。

又如果，PM每次都有讓對方知道：為什麼要做這件事，每個決策對彼此、對團隊來說的利益/風險是什麼，大家也會比較知道要怎麼幫忙（後來團隊有些人真的變滿積極的），而不會讓PM一個人窮焦慮。

後來，團隊也有講好，每天進度有delay、需要幫忙，站立會議都要說，做不完就儘管厚臉皮的請求支援XD

三、開發問題Q&A

寫完上頭案例後，收到另外兩個Q&A

部門近期人員異動，剛好沒有主管，如果規格開好了，但負責的工程師最後產出沒有按規格執行，而是用自己覺得更快的方式，該如何溝通？
前端工程師初期估Spec本來是1天，後來實作變成2週。工程師表示因為估的當下沒想到還有什麼要抓，也沒看過Mockup，所以就花更多時間。
PM想問：前端已經知道要做這件事，也有wireframe給他看，通常還有須要看到最後Mockup ，前端才能估時程嗎？

【不負責任回覆】

1.先假設，沒主管的情境，是比較少發生的。沒人罩還遇到歹咖，只能說快逃（還好他逃了XD），不然就立下篡位目標，自己來當主管。又或者，這個環境是自己喜歡的，只有少數幾人不好合作，那就多跟其他能信任、有智慧的朋友/資深同事討論解法（勿找愛抱怨/八卦的）。

回到他的問題，改Spec這件事，我還是會看有沒有影響到用戶。

• 沒影響、還能更快，也不錯 （有時間的話會請教對方這麼做，未來再串後端、擴充功能有無影響之類的）
• 有影響，會趁對方心情好、或飯後、下班前等比較輕鬆能溝通的時段，去問問原因，例如：「Hi OO! 我發現OOXX這邊的設計，跟Spec不太一樣耶，可以問問你原本的設計考量是什麼嗎~」等他回答之後，PM也要說明User端要達到的目的是什麼，然後兩個人一起找到折衷解法。並再最後平和的說：「為了避免之後會這樣花你時間討論，能否你遇到要改的地方，先群組拋出來說一下，確認User痛點能被解決，工程師再執行」等等。

Ps. 如果擅自改Spec是慣性，溝通無效，那可能要分階段驗收，例如將一個功能拆成3階段，第1階段畫面完成，就先讓PM驗收。

2.不確定其他公司經驗如何，不論一開始估的多準，只要有技術債的地方，就有「工時變數」的可能XD
然後，落差這麼大，照理工程師要在做完半天or一天後，在站立會議時，即時反應讓團隊知道 ，邀請利害關係人協助判斷價值，資源投報率太低的話就改需求，有價值就看要調其他資源幫忙，還是主管要下來幫忙做。

Ps. 趕時間的時候，會請工程師先抓1–2小時研究，跟Tech Lead討論研究結果，再決定要不要往下執行。

最後分享Evonne老師金句──

公司目標比老闆命令還要大

同理，目標應該也比我們每個員工都還重要。大家工作都有自己的價值信念，合作只是來解決問題or賺錢練功的，我們這一輩也很少人會在一間公司做到退休，沒必要互相為難。

如果用點（正直）手段、演個戲也好XD，能讓團隊達到目標，站在旁觀者的角度（畢竟我不是當事人，無法理解其他人遇到問題的全貌），會建議多試試看不同方法~ 盡力後，如果還是呈現耗損資源的趨勢，就準備幫自己換工作、拿更大包的啦！

本文來自 Vida Lin 授權轉載，原文連結

瀏覽 2,385 次