老是惹怒工程師？PM與工程師協作的12個眉角

江湖傳言PM 與工程師的摩擦最容易出現在「估工期之時、開始開發與測試之後」，有些 PM 可能會在未與工程師溝通前，向客戶或老闆承諾不合理的時間，或需求不明確等，讓工程師覺得 PM沒有站在他的立場思考。本文分享身為PM該有的心理建設，以及和工程師協作的12個眉角，順利找到彼此的交集。

擔任 PM 的心理建設與課前準備

了解自己的職責與主管的期待

通常我會相信在職場上，老闆與主管的安排一定有他的考量，所以通常我會問自己，上級將我安排這個職位，是要我幫他解決什麼問題？在這樣的公司文化與體制裡，我「實際」上有哪些職責與權力？這些不一定一開始就會被告知清楚，但我們必須主動與老闆或主管確認，直到明確雙方期待並凝聚共識，才能確保自己能做出符合期待的產出，心裡也會更清楚為何而做。

認知團隊的重要性

一間軟體公司即使有再好的業務銷售、再好的設計或行銷團隊，如果沒有工程師把想法／創意變成產品，那一切都是空談。而如果整個團隊只有工程師卻沒有其他部門，工程師會無法專心寫程式碼，也需要親身體驗被需求追殺的感覺了 XD。我其實很喜歡這種缺一不可的感覺，這說明每一個人的參與都很重要，我相信沒有完美的個人，只有適合的團隊！

培養技術知識

PM 最重要的工作任務是透過溝通與資源調度等方法，將專案成果如期如質的交付給客戶。而為了有效完成上述的任務，就至少要懂流程、對技術有概念，才能做出相對適當的安排，並加快事情的推動。

將客戶需求確認清楚

專案／產品可以分階段或迭代式開發，但如果要避免重工（並想讓自己在工程師面前說話可信、有份量）。
在確認客戶的需求時，該做的事情、該用的工具都不能少，多使用流程圖與線框圖，儘量圖文並茂，以文字描述（留存紀錄）後，要再與對方通電話，以確認雙方是否達到同一頻率與認知。同樣一句話、一張圖，每個人看到的 / 會在意的重點都不太一樣。確認需求不貪快，完成的時間會更快。

設立界線

我不奢求能在短時間內改變一個人的價值觀，但我們能清楚表達公司在意什麼，透過以身作則的方式帶頭示範，做我們該做的，剩下的就是緣份了。依個人最低的判斷標準是，不將私人情緒與好惡帶到工作之中，即是對彼此的界線與尊重。

區分直覺與感覺的不同

每天要做的事情很多，所以不是每種情緒與感覺都要被正視或處理。然而，如果有覺得哪裡說不上來、但「怪怪的」地方，這有時候是一種直覺，不能就這麼過了（因為客戶也不會就這樣放過你的），不過這時也不能空口只說一句：「我覺得怪怪的」，就要工程師信服或處理，所以一定要想辦法先多方詢問，用數據或資訊釐清與佐證，直到雙方都沒有疑慮（我們的確曾因為這份直覺，躲過很多問題）。

適時求助

一般來說，我儘量不會問 Google 關鍵字第一頁就能搜尋到的答案，但如果自己真的多方搜尋與驗證過後有疑問，還是要主動問，因為不懂裝懂而做出錯誤的決策，會付出更高的成本。

PM 與工程師相處的 12 個眉角

定義清楚的目標與明確的任務說明

這裡談到的目標，還包括職員的個人目標，每個人來到職場工作，一定有所求，不論是求溫飽、求挑戰、求新鮮還是為興趣，都是一個人來到這裡的目標與動機。能夠了解每個人的目標的好處是「知道他為何而戰」，那就可以用他在意的主題去鼓舞他或找到共鳴，使他自己管理自己，而非只能透過外力強硬管制（這邊先假設薪資水準有讓他滿意 XDD）。
關於任務部分，很關鍵的是如果每個人都不清楚自己負責什麼項目，應該在什麼時間有什麼樣的產出，並必須通過什麼樣的檢驗標準，那如何期待對方能產出令人滿意的成果呢？

清楚事情的優先順序

這跟經驗相關，也無時無刻存在每一個決策與應變之中。

多走動、多互動

如果有問題想討論或有新的任務要交辦，不要只是留在位置傳LINE 或撥打分機，而是儘量走到對方旁邊仔細說明。這是之前上國際產品經理證照 NPDP 課程時，向夏松明老師請益而來的：）

以問題鼓勵思考

雖然我不會寫程式，但我還是願意傾聽並用討論的方式找答案，如果工程師或設計師卡關了，我們會去聊：他原本想完成哪一項功能？過程中遇到哪些問題卡住了？他覺得可能是哪些原因造成這些問題？那現在可以怎麼處理？有時候會再回退一些，客戶會怎麼操作？當初為什麼我們會設計這樣的功能 / 體驗 / 機制？使用者故事很好用。

有時候，透過這樣的對談，可以激盪出不同的解法（但同樣的，這也包含了解個性與情境判斷，有些人特別願意表達自己、觸類旁通，也有些人需要比較多的時間進入狀況，在緊急時需要指令，而非無限發散的討論等）。

在每個專案都落實這點，會有一個好處是，因為本身同時管理多個專案的關係，所以偶爾也能提供不同的觀點，例如：在別的專案是否也遇過類似問題，後來如何處理，並知道可能可以找哪一位工程師來協助等。

了解個性，欣賞優點

溝通要用對方能理解的語言；而在這之前，得先理解個性與立場，才能找到同樣的頻道和語言。
畢竟，沒有人是完美的！多看優點，缺點可以透過團隊互補。
或許這也是小型團隊編制的好處，可以把人看成人，而不是機器，只要彼此尊重，能夠順利完成任務，那多一點理解與對優點的欣賞，可以少掉很多不必要的衝突。

關注工期安排與時間風險

在排定專案期程前，一般都需要先與工程師確認完成某件事的規格、工時、技術／時間風險以及其他需要注意的地方。
而每位工程師的回答可能不太一樣，有些工程師會過度樂觀，有些工程師老實回答，還有些工程師會給自己充裕的緩衝時間。
所以當我們在收到工程師回覆時，也需要退一步，以綜觀的角度看整個專案的安排，將（工程師回覆的工期 × 過往經驗的守時風險）+ 自己預抓可能的緊急狀況 = 預估工期，當然也要確認最後出來的結果對客戶來說是合理的，再回報給客戶，並做後續相對應的管理。

給予空間並定期追蹤

接下來，很重要的就是「相信對方」，並給對方適當的「實作」時間與「容錯」空間（相信沒有一步到位的程式碼或產品，所以才需要團隊協力合作與層層把關）。
如果真的有未達目標之處，請語氣和緩並清楚告訴對方：具體來說，哪裡需要調整，希望對方在什麼時間點之前調整到什麼程度。
定期追蹤可以視為適當的提醒，適時關心對方有沒有遇到問題，才能做出相對應的資源調度。

相信，但別盡信

這呼應前面提到的「相信直覺」，有時候是每個人經驗與思考角度的不同，也許對方會回你：「這做不到，如果要做會有多麻煩多麻煩等。」這時候，我腦袋都會閃過跑馬燈。我會先思考：現在這個專案的時間是否緊迫？這個問題是否與驗收相關或是客戶在意的核心問題？對方這樣的回覆合不合理？我是否有在其他專案或產品看過同樣的功能，有滿足需求或使用體驗？以上這些問題都能幫助我們做出更好的決策。