PM 溝通術 - 與工程「主管」溝通

溝通佔PM大部分的工作時間。不幸的是，溝通是軟實力，難以像程式工具書一樣有SOP步驟，讓你跟著做跟著學。但是工程背景出生的我，還是想要嘗試，明文化溝通的一些方法，這篇文章先來聊，PM如何與工程主管溝通。

PM 如何與工程師溝通我相信也是許多PM遇到的困難，之後的文章再來提，這篇文章我先來說明，更難的部分。不只是要與工程師溝通，甚至要與工程的主管溝通。

釐清組織權力結構

本篇雖然不說明通用性的溝通準則，但是PM在擬定任何溝通戰術之前，還是要先想清楚整個組織的結構。這裡的釐清不單是看職位的大小，因為一間公司兩個人即便職位是相同的，但是在不同部門，是依據公司注重的程度，才是實質上話語權的大小。

所以當你在與工程主管溝通的時候，你要先知道工程主管與你職位的的大小關係、跨部門的組織關係，以及他在公司的實質話語權。

一般來說，工程主管不會是PM的直屬主管，應該是不同組或是不同部門，屬於平行關係。對於PM職員來說，工程主管應該是平行部門的主管關係。而工程主管通常面對的壓力是公司的技術革新、系統的維護，以及底下工程師的績效。

什麼時候得接觸工程主管

通常一個案子的細節，很少會直接與工程主管溝通，除非是大案子或是工程主管就是負責這個案子的工程師。通常三種情境才會遇到得與工程主管溝通的情況，第一，新案子需要指派負責工程師的時候；第二，工程主管質疑你指派的任務不對的時候；第三，你主動向工程主管反映底下工程師的問題。

新案子需求講解的溝通

先來談第一種新案子分配負責工程師的時候，這裡最常會遇到的問題時，你描述的問題不夠清楚，以至於工程主管無法決定要派任務給誰。這時候工程主管便會覺得PM沒有負起責任。

而描述問題不夠清楚的原因，通常是PM不了解技術細節，因此不知道詳細會使用哪些技術，只能給出使用者需求。但是工程主管會認為PM，如果沒有辦法把用戶需求轉成技術相關的分析，就沒有負起責任。

雖然這通常是分析師應該做的事，但因為台灣普遍沒有分析師的概念，所以多半還是由PM負起責任，但是PM技術肯定沒有工程師好，這時候該怎麼辦呢？

當然你要了解軟體的基本知識，包含前後端協作等概念是最好的。除了硬實力培養，我認為要在需求描述底下，說明細節與邏輯。你不需要講解到程式設計的邏輯，但你要寫得讓理科腦能懂得邏輯。這是對於工程來說「清楚」的意思。

舉例而言，今天客戶會含糊地說，

「我希望使用者能夠使用Google直接登入我們的系統，一進來可以看到我們這個月主打的產品。」

你要如何寫給工程師？

「登入系統串接 Google 第三方登入(細節)，這樣使用者可以點擊兩下就能快速登入，不需要額外輸入帳號密碼(邏輯)」

「後臺管理可新增主打商品，主打商品分別要有大圖片Bannger圖片上傳，以及文字說明(細節)。後臺管理人員，可以人為操作修改主打商品，主打商品要在首頁就顯示讓使用者一目了然(邏輯)」

「前台畫面設計圖如下....，手機板需要佔上半部一半的畫面，電腦版要...(細節)，設計重點，使用者一進入頁面看到的第一個畫面(邏輯)」

你可以不用說明程式怎麼寫，但你需要思考實際的操作行為，有哪些細節，這樣的設計目的為何，即你的邏輯或是使用者心中所想。

有這些初步說明，可以協助工程主管知道，這個案子大概需要幾位工程師介入，分別需要哪些類型的工程師。

如何面對質疑PM指派任務的工程主管

我相信這是許多PM會遇到的困難，好的情況是，工程主管會提供善意的建議，或是提醒你沒注意到的細節，我想這個應該可以斟酌消化。最麻煩的情況是，工程主管認為PM的指派有問題，所以想要介入。

台灣PM常常身兼Project, Product甚至分析師，這樣的情況有時也反映在工程師的心態。我有遇到很優秀的工程主管，也有遇過真的瞧不起PM的工程主管，希望大家不要遇到。但我既然遇到了，就分享如何處理瞧不起PM的工程主管更為妥當？

通常工程主管瞧不起PM的理由，無外乎，覺得PM技術沒我牛。雖然大家可能覺得很荒謬，不同職位，專業性有什麼好比的？但在職場上其實不少人的認知是，技術不好的工程師才會去當PM。在潛意識裡的瞧不起，往往就會變成質疑你的任務分配。

以下是我發生過的真實故事：

我曾經待過一間接案公司，公司的組織是，設計組、工程組與PM組，我當時是PM組底下的一名PM專員。當時我很快就發現，公司組織的分工問題(PM需要對這個部份很敏感)，就是工程組是後端工程師組成，設計組合作上負責前端畫面設計，但認知上以及命名上，他們是負責畫面設計，並不是工程師。

這個問題，果不其然在一項案子爆發。一位客戶的需求是，把他們舊網站作內容更新，但是UI畫面要與舊有畫面相似。但是他們公司沒有舊網站的前端程式碼。這時候其實只要從他們前端畫面(明碼未加密)，把程式碼爬下來，做一些修改即可。那這個工作在剛剛我提的公司組織架構中，應該是哪個部門負責？

工程組認為，這是前端工程師的工作，也就是設計組的工作。設計組認為這是工程師的工作，他們是設計師不是工程師。後來因為設計組人力比工程組少非常多，但幾乎每個案子都需要設計組。因此我協調本案負責的工程師，由他負責爬程式碼。爬下來以後，如果跑版，我也協調了設計部門會幫忙處理。

原本這次的溝通，工程師與設計師都很滿意這樣的分工模式。但是工程主管在周會工程師向他報告後，非常不滿意。便找我討道理，他的原因無外乎是，他們是後端工程師，不是前端工程師。

當時我的職位，難以讓他願意聽我說話，因為潛意識的歧視。雖說是跨部門，不應該有他是我主管的差異，但工程組是全公司最大的組(如同上述，PM要知道組織結構背後的意涵。你就會發現，當然工程主管自己也知道，他的話語權很大)，我只好組織會議找了設計組的組長一起，在這樣的會議上，我才有機會表達想法。

後來，會議結果變成，由設計師爬下來，如果程式碼設計師不會爬，再由工程師協助，然後跑版的話設計師再幫忙調。

講到這裡你會發現，「這個方法跟之前差在哪裡？」最大的差異，就是工程主管認同了！這也是PM需要努力的地方，專案管理不只管專案，有時候需要管人性。這樣的結果與之前的方法差不了多少(以前是工程師爬，設計師修。現在改成設計師爬，但需要工程師協助，再由設計師修)。但是這樣些許的差異，是由工程主管下令。既保全了他的面子又保全你認為正確的解決方案。

第一段故事到這裡，你就會發現PM所需要的一個溝通技巧。

「讓結果順應你，但是表面上由他人決定」

類似的技巧還有很多，例如提供選項

「你覺得要這樣設計？還是這樣設計呢？」

你可能提供了兩個都不錯的選項，或是一個好，一個爛的選項。但是由他選擇以後，感覺會像是他做的決定。即保全他的面子，又能做到你要的結果。

我想大家聽完這個故事，可能會覺得PM有點憋屈，明明是自己的功勞，又得顯得好像是鬧事者的功勞一樣。

所以後面還發生了另一則故事，這次可能我也有點情緒，所以我用了比較激進的方法，大家慎選是否要使用，以下說明故事。

同一間公司，所以公司組織我就不重複說明。

一個客戶的新需求，(詳細的需求我有點忘記了，這裡描述大概)客戶需要錄製監控攝影機的傳輸到電腦畫面。但這台電腦超級舊，然後好像跟政府還是跟某個保密協議有關，這台電腦不能安裝螢幕錄影功能。

所以客戶想要側錄螢幕，並且想要有影像分析，能夠警報螢幕上數字發生異常的情況。

我當時與公司老闆討論，我認為螢幕的解析度太差，影像分析無法分辨出來(當時技術也沒有現在好)，我們不如從監控攝影機另外把主碼流引出來到另一台螢幕。

老闆當時認為主意甚好，請我與工程主管討論。因為先前的經驗，我這次直接在公司大群(有老闆在的群組)，向工程主管提案。這次不出意外的，工程主管又批評PM沒技術，提案非常爛，直接側錄就好，影像分析之後再慢慢優化。

我接著便在相同群組Tag老闆說

「工程主管認為XXX(老闆名字)這個主意不是那麼聰明，那我就不像客戶提議這個點子了嗎？」

群組當然換來一片安靜，隨後是工程主管的解釋，說明這個主意其實沒這麼差，但他認為現在要先拿案.....

這裡的我雖然做事衝動了一點(當時是我第一份工作)，但我這樣做也不是完全的衝動。我會這麼做是因為有兩個把握，第一，老闆是個明事理，講道理的人，而且他也很清楚工程主管有歧視PM的問題。第二，我很確定我沒有提出笨主意(畢竟都跟老闆確認過了)。

我故意在大群講，就是想要全公司注意到，工程主管歧視PM問題已經嚴重到影響工作合作的情況。

如果你今天想要用這個方法，請注意你的老闆是否講道理？以及你提出的點子，一定要有十足把握。

跟工程主管建立合作關係

其實工程主管有一個很困難的地方，就是他的工程師在各自的專案，他不可能了解專案細節。但工程的好壞又與細節有極大關係，他至多只能從Code Review 了解工程師的「技術」，但如何從專案合作上，了解工程師的工作態度，或是除了技術以外的專業能力。PM這時候扮演了工程主管的眼睛。

你可以與工程主管培養一個默契，當工程師表現不好，或是表現優異的時候，你可以在與工程主管開會時，或是私下約開會時向他反映。

當然這裡要小心，沒有人喜歡別人說他底下組員的壞話，保護機制算是每個人的本能機制。你可能會覺得，你沒有要說她們壞話，你只是想反映事實。但稍有不慎，誤解就會從這裡發生。

所以我反映問題的時候，我通常不會指名道姓，會回報案件可能延誤的警訊跟工程主管說，問他建議方法，然後再告知工程師有XX解法。

稍微有責任感的工程主管，便會主動關心這個案子工程師的進度。你不需要指名道姓，只要說案子，工程主管絕對知道這個案子是誰在負責。

長此以往，建立了合作默契，你跟工程師的合作也會變順利。相信我，工程師很聰明，他們絕對會發現，你有「一點能力」會影響到他們的考績。

PM常常會有一個困擾，有管理職責卻沒有獎懲權力。沒有權力，只能靠PM創造影響力。這裡便是一個你可以產生影響力的地方。

後記

大家可能會好奇，上面的故事，後來我為什麼離開公司了。簡單來說，我也不喜歡上班爭鬥，我覺得我已經點出公司問題，是我沒有任何權力的情況下，能為公司做的事，隨後不久我便離職。

因為公司的其他PM與工程師與我關係都不錯，據他們說，我離職不久，老闆便把工程主管開除(或是他主動請辭)，工程主管已經在那間公司有十年以上資歷。

PM是個小CEO，或許我們沒有那麼大的權力，但我認為認清組織問題，並且努力反映組織問題，是好PM應做的事。如果你遇到的是好老闆，你絕對是他重要的助力。

反之，如果你現在是老闆，請多留意，願意幫你發掘組織問題的PM。