PM都是如何惹怒工程師的？

PM與RD是要一起合作的團隊夥伴，然而PM們很容易因為不知道RD在意的點而不小心踩到地雷🔥，最後導致專案溝通不順利、團隊合作與凝聚力出現問題。

因此這篇文根據自己的經驗以及打聽了RD心聲，統整以下8個會惹怒RD的行為🤯

各位PM們（尤其推薦新手PM）可以檢視一下平常是否無意識的做了這些事，提醒自己不要踩雷了！

（文章裡附RD表情包！）

Table of Contents

｜需求面

🤯1. 資料還沒給完整，就要壓時程

當PM想到一個新需求，總是會很興奮地想要趕快把它做出來看成效，但卻沒有發現資料都還不完整。這時最常聽到RD回一句「東西都有了嗎？」然後PM就會陷入沈默之中、再默默地把這需求移除本期排單。

在和RD提需求前，有幾個checklist項目要檢查：

需求文件：包括目標、預期成效、驗證行為（需求的理想行為與效果有哪些）、功能描述
UI畫面與規格：包括設計圖、UI flow、function flow、spec規格說明
後端資料：和前端RD提需求的時候最容易被遺漏這一塊。
由於PM在缺少技術背景下會不知道做這需求是否會需要後端提供資料，因此很常聽到前端RD問：「後端資料有了嗎？沒有後端要怎麼做？」
👉若這些項目都還沒有完整，最好就先別排進本期單子了吧！這樣會讓RD覺得「你東西都還沒準備好給我，就要我在這期做完？！🔥」
👉如果不知道這個需求是否會需要後端或其他資料，可以在提需求前可以先跟RD確認是否還有缺少什麼，避免在會議上被釘在牆上

🤯2. 需求範圍界定不明確

如果功能沒有訂定明確的範圍，不確定要做到什麼程度，那PM在提需求的時候就很容易無限上綱，等於是無止盡的需求綿延不絕的來！

例如要做一個大功能時，一開始和RD說一、二、三階段分別要做什麼，就應該按照一開始講的階段分別去提需求。

而不是在做第一階段的時候想到更完整的功能，就把原本不在這階段要做的事情又加上去。這樣只會讓RD覺得這功能永遠無法告一段落，PM當初講的和後來實際要做的都不一樣🤯

🤯3. 需求反反覆覆，等RD做了之後又要修改

在變化快速的科技業，每天可能都會接收到針對需求不同的意見，但如果已經提給RD需求且他們在動工了，就盡可能不要修改。如果真的要修改也要說明改的原因、以及帶來的好處。

需求要修改的原因可能有以下幾個，PM可以先注意來避免修改的情況：

提需求時太急促，沒有事先考慮好優缺點與風險
大多時候都是因為PM突然發現之前沒想到的缺點、或沒想清楚影響範圍就下了決定。
👉因此PM應該要確保做的事情都是有明確目標、有意義且可以說服別人的。讓團隊跟你一起檢視這樣的需求是否合理、或者討論達成目標是否還有其他解方。
接收到老闆主管的意見而要修改
最好的情況是在RD動工之前，就和老闆&所有利害關係人（例如客戶、合作部門）都確認好需求規劃。
但若老闆在開發中才提出建議，也有幾個應對的方式：
👉不要把老闆的話照單全收，要自己思考他的提議是否真的有有道理？適合團隊現在的目標嗎？
👉評估老闆的建議是否有顯著的好處。如果沒有的話，可以將老闆的建議安排到下一階段再實作。
RD做到一半發現原本預計的做法行不通要改做法，導致影響到其他RD
需求很緊急需要前端&後端同步動工，這時就會有風險：若後端RD調整作法，前端也會需要跟著調整。
👉理想的開發流程應該是後端要跑在前端前面，這樣才有資料可以串接驗證、也能避免後端做到一半若要修改方法，就會導致前端也要再修改。

🤯4. 講不出需求的合理原因

讓RD知道「為什麼要做這個？」是很重要的一項工作。讓RD知道目標有幾個好處：

RD可以用工程角度來想是否有更簡單也能達成目標的作法
建立團隊目標感，讓團隊更有動力往目標一起前進

反之，如果講不出要做的原因，那可能會讓RD覺得「我做出來沒人用，不就做白工了嗎」

⭐️線上課程推薦
HaHow 《軟體需求溝通─從外商公司學跨部門協作開發》：
從規劃需求方法論、到和RD與設計師溝通需求，都能在這堂課中學到，推薦給想要更熟悉產品開發＆團隊溝通的各位PM～！

📚好書推薦
《矽谷最夯・產品專案管理全書》：這本書最大的價值在於告訴你「好的PM是什麼樣子」，並且釐清PM與每個部門（RD、UI、行銷…）之間的合作關係，幫助你了解和不同職位的人溝通應該要著重的面向、以及該注意的點。
《Google創投認證！SPRINT衝刺計畫》：用簡單易懂的方式瞭解sprint應該要怎麼跑，當你理解專案要如何管理、知道要提供RD、UI怎樣的東西，就大大減少開發中因為交付不完整資料而被釘在牆上的機會！

｜溝通面

🤯5. 有事沒事看到bug就一直找RD

雖然有bug要回報是再正常不過的流程，但回報bug也是要用點技巧，不然可能會讓RD感到不快🔥

1.事先討論好回報方式

在團隊合作前就應該先和RD討論：當有bug發生時，處理流程應該如何進行？而不是一有bug就跑找RD。

原因是RD開發寫程式的時候通常不喜歡被打斷，但如果PM頻繁的因為bug去找RD，那一方面他們的開發過程會一直被打擾，另一方面應該也會很氣餒（畢竟是自己寫出來的程式的問題😢）

2. 找對的人回報bug

PM應該要回報給「能解決問題的RD」，而不是隨意找前/後端RD叫他幫你解決。

這問題很常發生，譬如當發現一個bug時直接請前端RD去修bug，結果前端RD花了一個下午檢查後發現根本是後端的問題，那前端RD一定會大爆走！🔥

因此PM應該先自己判斷是前/後端的問題，再找負責的RD處理。以下提供幾個判斷方法：

若是後端bug，那不管在ios手機/安卓手機/網頁都會遇到同樣的問題；反之，若只有一個平台遇到問題，通常是前端程式碼的bug
如果知道前端是接哪道api、也可以先驗證是否為api問題。如果api response都正確，那可能就是前端串接或顯示上有問題
如果真的無法自己判斷，就先用詢問的方式問RD看要給誰處理吧！別一開始就指派某個RD處理。

🤯6. 會議時間不準時

PM的一天之中總有很多會議，我們也都很習慣臨時召開會議、或配合他人調整會議時間。但這樣的「陋習」不應該帶到與RD的會議中。畢竟有些RD的工作習慣並不喜歡在寫程式的時候被打擾。

因此「讓會議時間準時開始、確立會議目標不冗長進行」是在與RD開會時的重要準則，避免讓他們寫程式時還要感到焦慮與不確定性（表定時間到了卻不知道會議要開始了沒）或是在會議中討論失焦，浪費RD寫程式的時間。

🤯7. 回覆RD問題時總是拖拖拉拉

當RD實作中發現有待釐清的問題就會跑來問PM，但如果PM沒有辦法快速回答，也應該要盡快確認避免拖延RD開發時程。不然最後沒有辦法如期交付功能的人，是RD呀！

而PM也要注意：我們最不應該做的，就是讓事情卡在自己身上。

🤯8. 問RD「這是做得出來的嗎？」

PM在規劃需求的時候，有時無法下決定是否要做，就會問RD「這功能可以做得了嗎？」

這時RD心裡的OS是這樣的：「要做就一定可以做，只是好做跟難做的差別而已」。

開需求給RD的時候，重點不是能否做出來或是簡單複雜，最重要的還是「目的是什麼？這方法真的能幫助解決問題嗎？」

PM只要思考確認好需求的目的與原因，只要是合理且必要的事情，RD基本上都可以接受。而不是依照「這東西做得出來嗎？簡單嗎？」來判斷是否要做

｜心態面

🤯9. 把RD當作碼農

你覺得RD在團隊中是什麼角色呢？

如果你覺得你們之間的合作模式是「我提什麼需求、RD就做什麼事情」那在合作上就會遇到不少的阻礙。

就像前面提到的，讓RD了解需求目的、知道自己為了什麼要做不僅能讓需求更完善，也能增進團隊凝聚力。因此在規劃需求的時候也記得要與RD討論，並尊重他們的專業建議！

結語

PM是需要別人的幫忙才能完成自己目標的工作，因此如果能在團隊中與RD有良好的溝通和互動方式，那一定會大大提升工作的效能與團隊分為！

希望以上分享的「惹怒RD行為」能讓大家借鏡，如果你也有和RD溝通的訣竅也歡迎和大家分享，讓各位PM們在開發中都能更順利輕鬆！

PM都是如何惹怒工程師的？