（Photo by Andrea Piacquadio on Pexels）

工程師最討厭 PM 的三件事：

• 搞不清楚狀況，只會亂壓時程（或在沒經過團隊討論下，就亂先對外給承諾）
• 無法解決問題，只當傳聲筒。
• 把客人或老闆給的壓力（比如：時程）直接往團隊身上丟（比如：叫大家加班趕工）

然後，不知道自己在幹嘛，就只會整天叫團隊開會報告進度。（工程師 o.s.：我們都很清楚我們在幹嘛，就你不清楚...這到底是誰的問題？）

其實，近年來愈來愈多非本業 PM 遇到這些問題，然後感到非常挫折。

之前有一位企管相關科系畢業不到兩年的新鮮同學，目前在一個集團裡擔任 PM，專案產品是「資訊系統」，而團隊是一群「軟體工程師」。

她問我：「老師，以前我選文法商類組時，就聽人家說，如果怕賺不到錢，可以往 PM 發展，畢業後，我很努力找 PM 的工作，現在我也是做 PM 的工作，為何還是覺得賺不到錢，而且心好累？」

休旦幾咧......是不是誤會了什麼？

其實不管是哪個領域都有許多專案在進行，文法商類組也有許多行銷、展店、研發新商品、商業活動......等專案，的確也非常需要優秀的 PM 人才。

我其實非常鼓勵工作人要把握舉手爭取擔任 PM 做專案的機會，並且還要想辦法把這些專案做出一些漂亮的成果，別半途而廢，因為這些都會累積成你下一份 offer 的重要籌碼。但並不代表我支持在毫無專業的條件下，以為懂幾個紙上談兵的管理知識，就能做好 PM 的工作。

在我認為，一個優秀的 PM 需要三種專業：

1. 專案管理專業：搞定人、搞定事、永遠保有目標意識和 Plan b 的準備、理解整個專案架構的邏輯、當中間發生各種變化時，做全面性的評估和處理、提早預防變壞的風險，甚至能夠得心應手的使用一些有效率工具來協助管理。

2. 專案產品技術專業：直接舉例：如果你的產品是系統軟體，你不必是團隊裡最會寫 code 的那個人，但你至少得懂軟體工程、得懂軟體的極限、知道什麼是 schema、能聽懂工程師在說什麼。

比如：當你聽到客人要求在 Web 前端上要同時出現 4,000 筆資料，每筆資料必需有 8 個欄位物件可以即時維護，又不願意分頁時，第一時間就要瞪大你的眼睛，拿出你的專業，告訴客人這樣玩不下去。

而不是因為缺乏專業無法判斷，唯唯諾諾地說：「好的，這個需求我回去會找我們工程團隊討論，盡可能會在 deadline 前交付。」

工程師耐著性子告訴你：「這樣會有效能的問題...」

你也沒搞清楚原委，直接傳聲給客人：「我們工程師說不行，這樣會有效能的問題。」

客人問：「為何會有效能的問題？我不懂。」

你說：「嗯，這個部份我再請工程師來跟你說明。」

客人心想：X！我到底要這個 PM 幹嘛？

工程師想：X！我到底要這個 PM 幹嘛？

然後，你會發現盡管團隊沒直接發作出來，大家也會把你當好笑的空氣，最好眼不見為淨。

當大家都抱著：嗯，這個 PM 不行，我們只要應付應付他就好的心態，你就離團隊的真實更遠了。

然後你的不安全感就會一直叫團隊來開會，工程師心想，我們已經忙得快死，應付你那些莫名其妙亂答應客人接進來的需求，還要浪費我時間來開會？煩死。

工程師們覺得反正講了你也聽不懂，開會也只要表面上應付你一下，所以你自然更無法了解專案的狀況，自此整群人開始進入惡性循環。

3. 專案市場領域專業：你的客人是半導體領域、是餐飲領域、是金融領域、是土木工程領域......你對這個領域也要有一定程度的涉略。

但這個部份有一個關鍵，就是你的團隊配置狀態。

比如說，我之前有一個專案就是土木工程領域的系統軟體，必須要在系統中計算「流量率定曲線」這個我完全門外漢的專業東東，但團隊中配置了一位專家，他可以將所有複雜的計算萃湅出明確的公式，我們只需要轉換成 code，並且直接置入系統中即可。

所以，我們可以把更多時間更投入在拆解客人的事務流程、整合客人的商務需求裡頭。

最後來說說結論：

以上的三項專業，

1. 「專案管理專業」能讓你能整合好 2 和 3 的東東，完成交付

2. 「產品技術專業」能讓你搞懂團隊在幹什麼

3. 「市場領域專業」能讓你弄懂客人在說什麼（或忘記、沒說什麼）

如果以上任何一項你都沒有，那麼我建議你先別當什麼 PM，不如進到團隊裡紮實地磨個一兩年，免得把自己的問題變成整個團隊的問題，甚至變成整個公司的災難。

還老覺得自己很無力、推不動、沒人理你、老被唬弄......別說賺不到錢，遲早你還是會摘掉這個角色的帽子（自己受不了、或老闆受不了），因為你可能連專案管理裡最低門檻的文書工作都做不好。

但若以上三項，你至少有其中兩項，或許還有機會可以做得不錯。

要能持續進階，也沒有什麼訣竅，就是「學」，而且要趕快學。

趕快補上自己的短板，大家或許可以接受你 3 個月不懂，可是無法接受你做了 3 年還是不懂。

你說你不是軟體本科系，不會寫程式，那麼就去學，沒什麼好說的，不論是去報名上課、去閱讀、去各大相關社群裡面看看大家都在討論什麼？大神們都在說些什麼？有機會的話，從中拜師學個藝也很香。

記得，你不用成為骨灰級的厲害工程師，但你至少要搞懂團隊可能會有什麼困難？每個製程裡可能發生哪些問題？為什麼改這個時程需要比較久？動了什麼東西會出事？能用客戶懂的語言說明，為什麼只是把一個資料欄位加大，團隊要大動干戈改 15 天？

某個恐怖的需求根本不用問工程師，就知道應該要先擋下來和客戶展開討論。

再來，在你學習的這段時間裡，請你務必要先做好團隊的守護者，技術先交給他們，但是他們討厭的、脆弱的那些對外協商、跨部門協作、喬時間、談判、吵架......等工作，就好好地盡全力擋在他們前面，盡可能守護一個讓團隊專注工作的環境，然後，跟他們站在一起吧！

最後，也真心奉勸能夠看到這裡，且在公司裡有權力指派並且決定 PM 的老闆主管們，至少先確認他們具有其中二項的專業或實務經驗，並且能夠給他們一些培訓的管道或機會，再讓他們上。

不然，除非你就是故意要弄走他，但同時願意付出把團隊（及客人）搞得雞飛狗跳的代價；或者你需要的單純只是一個任務的 tracker + 聯絡的窗口，而不是 PM。

若是如此，那就直接把他的角色和職責講清楚，別輕易把 PM 的頭銜掛在他頭上，結果最後害人害己啊！

其實工程師們很期待有 PM 的協作；他們只是討厭那些幫不上忙、不求進步還只會添亂的假 PM。

本文轉貼自：李君婷老師臉書