PM 溝通術 - 與工程師溝通

不得不說，因為技術背景的關係，我一直在與工程師的溝通算是順暢。甚至有遇過技術能力比工程師更好的情況。但是我們不能也不應該強求PM要有多專業的技術能力，所以本文要說明工程師需要什麼？PM怎麼樣培養與工程師的合作默契。

了解工程師的個性

每個人個性大有不同，你要找到必然的區分點，這是不可能的。但是我在工作時，心中的確會為工程師做一些分類，這個分類很含糊，但是卻能有效的決定我的合作戰術。

在我心中，工程師的分類有幾種，精進技術型、產品型、資深型、指令型。這不代表所有工程師分類到這幾種，能夠完全符合，但在某些情況下，可以讓我決定如何與他合作，以下會分別講案例。

精進技術型的工程師

有一類工程師，他「喜歡」寫程式。這裡的喜歡，不是不討厭，而是他們甚至會假日刷Leetcode，或是平日工作完以後，可以回家寫自己的程式當作休閒活動。沒這麼瘋魔的，也可能是會喜歡參加研討會，或看白皮書，了解最新技術。

對於這種類型的工程師，我相信PM較難想像。即便本身技術出身，但我並不喜歡寫程式。可是這類型的工程師是我非常喜歡合作的類型，主要有兩個原因，也是跟他們合作的重點。

多問他們能不能做到？

這類的工程師，不懼於挑戰。PM雖然不是他們的主管，但對小組有管理責任，激發小組成員的潛力是PM的重要職責之一。

在設計產品時，如果有機會與這類工程師合作，我特別喜歡開腦動。我會研究競品的設計，然後改良成我覺得更好的操作。接著我會拿著這個設計與他們討論，通常會有以下的起手式

「我想要做...，別人都是...的設計，但我覺得不好，我不確定是不是技術上做不到，所以想問你...是能實現的嗎？」

這類的工程師，常常可以給你意料之外的答案。告訴你能做，或是改成怎麼樣能做到，甚至跟你說，他能做到更好。

而激發潛能的方法，就是要提出挑戰，讓他思考能不能做到。如果不能做到，是技術上辦不到，還是還需要時間研究。給予他們目標學習，絕對是他們樂見之事。

多聽他們說新技術

PM技術不用好，但邏輯一定要好。程式的技術、寫法我們可以不會，但好險演算法都是很有邏輯的東西。在我的經驗裡，雖然我根本寫不出來，但我可以跟工程師聊邏輯聊得很開心，而他們常常也可以透過我，獲得一些點子。

這類的工程師，通常樂於分享自己獲得的新技術。身為PM不要覺得與自己無關，因為你下一個案子，合作的工程師未必是他。但如果下一個案子工程師跟你說做不到，你有印象與精進技術型工程師聊天過，新技術辦得到，你就有辦法與另一位工程師「討論一下」。

其二，勇於提問。如果你有技術背景，請記得一件事，你的技術一定比工程師差，他們才是專業的。我這邊在談的不是事實，而是心態。你要讓他知道你懂一點技術，但他們才是專業的，而你只是喜歡跟他們聊聊最新技術。

如果你是沒有技術背景的，就更好了，你一定會有正確的心態。有了心態以後，跟精進型工程師聊技術時，當遇到你聽不懂的專有名詞時，記得你的提問，一定是問邏輯。

以下是一個真實故事

有一個案子，是與機器學習相關，為了要降低原始資料的雜訊，我們在研討演算法的設計。

工程師說：「我認為可以透過 XXX Filter ，來過濾原始資料的雜訊」

我說：「為什麼這個XXX Filter 可以過濾掉雜訊？他是如何判斷雜訊的？」

工程師：「他又被稱低頻 Filter，他可以過濾掉異常降下的訊號？」

我說：「可是我們的原始資料，除了異常降下，也會有許多異常高起的訊號。我們是否得套用兩個 Filter，另一個是高頻 Filter呢？」

工程師：「有道理，我試試看」

我說：「另外，他如何判斷異常，判斷的數值是可以調整的嗎？」

工程師：「他是用標準差判斷的，可以根據你拉取區間自動計算標準差，我目前預設取一個標準差。」

我說：「好，記得把標準差設為參數，這樣我們才可以動態調整，我覺得應該需要調整多次，才能找到最佳的過濾數值。」

工程師：「對，感謝提醒！」

以上故事可以看到，我根本不懂什麼低頻高頻Filter，所以我問「邏輯」。得知邏輯是，可以過濾異常下降的資料。那麼我知道異常下降可以被過濾掉了，當然我沒有能力檢證是否真的能過濾掉，所以我選擇相信。但是我就會發現，下降可以過濾，按照「邏輯」上升應該也可以過濾吧？我便會提出我的疑問。果不其然，是可以過濾掉的，而且你也成功提醒工程師。這也會讓工程師知道，你聽得懂他在說什麼，他會覺得跟你討論是有意義的。

接著按照邏輯「異常」一定有某個標準，所以我會提問，異常的標準是什麼？工程師說標準差，我沒有能力檢證，標準差是否是好的標準。但凡學過一點統計，應該可以知道異常要抓幾個標準差，雖然有約定俗成的共識，但是是可以調整的。因此我變會提醒，我需要能調整，因為程式一定需要反覆測試。

與工程師這段的討論，我完全不會寫半行Code。但是我依然可以透過邏輯，與工程師一起討論技術。工程師常常會埋怨PM不懂技術，不想跟PM交流。但其實PM只要清楚，程式背後絕對有邏輯，多與工程師進行邏輯方面的討論。能否做到，你可能沒有能力質疑，可是你可以透過邏輯上，幫他考量是否有遺漏的點。這樣就會讓工程師驚覺，跟你討論竟然可以有所收穫，久而久之，他也會尊重，並喜歡找你討論技術。

產品型工程師

理論上應該把產品願景跟工程團隊說明清楚，但其實不是每個工程師都喜歡聽，等等就會介紹到，不喜歡聽的工程師。

但現在要介紹的這一類，是特別喜歡聽產品願景的工程師。而我個人也很喜歡與這類工程師合作。有產品願景的工程師，有能力在聽完你介紹產品路線，以及你為什麼這樣設計後，有效的提供，他覺得潛在的技術債，會在某一階段導致什麼問題。這些建議可以讓PM提前規劃如何避免，或是估時必須有所調整。

有時候，尤其是前端工程師，常常也會給你UIUX設計上的建議。這樣的建議，不只能激發你的想法，也能讓設計時更有可行性。

但是切記，他們畢竟是工程師，不是PM。難保他們在提供建議的時候，不會有一點私心，選擇比較差的設計，但比較好實現的方法。所以PM不能全盤接受，還是要有主見判斷。當然我的建議是，拿出你的主見跟工程師好好討論一下。

產品型工程師，通常會在工程團隊中擔任Leader的角色。如果你有機會與這類工程師合作，請記得把部分Project Manager的工作可以交給他。有他的技術背景，專案不延誤的部分，他絕對比你專業。

而這類工程師，我會高度與他交流，有任何新消息都會跑去跟他說明。這類工程師通常也會樂於聽到最新有關產品的消息。這些消息也可幫助他，設計程式架構的時候，要如何確保彈性，或是階層關係。

資深型工程師

一間公司裡常常會有待很久的資深工程師，如果他待了很久仍不屬於上面兩者。那麼他有可能的狀態是，很熟悉公司的程式架構以及歷史沿革。但是對於新技術以及其他公司所使用的技術已經缺乏興趣，喜歡目前工作上的穩定性。

與這類工程師合作時，如果你自認與公司其他PM的行為模式，不太一樣。記得讓他知道與你的合作模式，也就是讓他知道你是什麼類型的PM。最好要與他多多討論，讓他也認為你的想法是有價值的。

以下說一個發生的真實故事：

這是一間發展多年且成熟的軟體公司，由於市場是走東南亞市場，以低價且可用的產品策略，作為公司主要營利模式。

但是削價競爭到一定程度，公司開始想要重視軟體產品品質。於是要求PM更著重在產品設計上。當時，我主導的一項專案計畫，我與公司一名資深的工程師合作。他非常了解公司有哪些專案、哪些元件庫，程式碼的歷史沿革。

因為公司過取採快速開發，因此開發與設計稿八成像即可。工程師可以用原有套件，或是比較好刻的方式製作產品。在與我合作時，的確也按照這個模式。但是我會比對設計內容與開發內容是否一致，尤其是操作方式，並請他按照設計內容製作。

合作一次後，接下來這位資深工程師要修改任何設計稿內容前，都會與我討論確認。培養了這次默契，討論的內容也能給我的產品設計有很多啟發與好主意。同時他也認知到這位PM是更在意產品品質的特性，也會更重視產品。

所以，彰顯你對產品的執著與重視，展現妳與眾不同的地方。資深型工程師，絕對比其他工程師能更快發現，你與其他PM不同的地方。如果能善用它擁有的知識庫，將可以讓你更精準估時，知道哪些地方有技術債？怎麼設計可以更快速開發。

指令型工程師

遇到指令型工程師，是我最頭痛的。所謂指令型工程師就是，你告訴他怎麼做，他會做出來。但也不想要多動腦思考其他事情。遇到這類工程師，最辛苦的地方在於兩處，第一，產品開發難以估時。因為他會按照你說的開發，可是PM不是技術專家，一定有很多你無法注意到的細節，甚至是公司技術債。常常等開發好後，你發現根本不能用，但他說他按照你說的開發。第二，投入度難以掌握。指令型工程師，因為本身對於產品興趣缺缺，是否有全力製作，還是每天製作一個適當的進度，你難以衡量。

通常我遇到這類工程師，主要會以兩種方式解決。

賦權

我會在產品開發時，找他一起與會，並請他提供建議。當然他可能會覺得這是PM工作，問他像是丟工作給他。這時候你需要軟性的告訴利弊，跟他說需要他的原因是...這樣可以減少後續反覆修改的成本，因為這部分他是專業，一定比其他人清楚。另外，也要設定目標並給予他權利。你可以要求網站效能要多少？或是必須在什麼時程開發完，盡量設定較難達到的目標，並跟他說，他可以動用什麼資源，或是主動告訴你需要什麼協助。當他有挑戰，且必須自己處理，他就會主動思考，要怎麼達到？包含能不能修剪功能？

當然PM最討厭工程師一直說要修剪功能，但是PM要知道工程師會這樣提。他腦袋必須要思考這個產品，哪些是重要的？哪些不重要？這對指令型工程師太重要了！

每日立會

這裡採用Scrum中的每日立會，快速Standup meeting，講昨天做了什麼？遇到什麼困難？今天要做什麼？

你可以透過發現，昨天目標設定...今天報告沒達成，你就可以追問為什麼？他有沒有找人協助？他要怎麼解決？把可能誤時的因素，都壓縮到一天做校正。

總結

無論哪個工程師，PM要記得工程師是團隊重要夥伴。一定要培養合作默契，設定合作規則。有默契的團隊，才能讓產品快速迭代，並且成為有活力的團隊。