這篇想分享， PM 如何與一群比自己厲害數百倍的軟體工程師合作？看似不同立場的雙方如何溝通與共處？
為甚麼寫這篇文章
希望這樣的分享能幫助還找尋平衡的新手PM ，也想寫一篇文章記錄與感謝我們家的工程師如此好相處 XD
這篇文章會談到甚麼內容
一、簡述
二、擔任 PM 的心理建設與課前準備
三、與工程師的溝通「眉角」
一、簡述
每間公司的文化與制度不太一樣，這篇分享的是個人經驗、不一定適用於每一個人。
我一開始負責的工作內容是前端切版和與 UX 規劃，後來才開始 PM 之路。目前身上有1個大專案、3個小專案 / 產品同時在跑，不管是對外的客戶，還是對內的規劃、管理、測試、會議，每天平均花 70% 以上的時間在溝通。
［補充說明］
1.這篇文章討論的 PM 為 Project Manager，而非 Product Manager 。
2.根據PMP（國際專案管理師）認證之定義，專案管理兩大要素為五大流程與十大知識領域；這篇文章會比較偏重其中的溝通管理應用筆記與心態～
二、擔任 PM 的心理建設與課前準備
1.了解自己的職責與主管的期待
在職場上，老闆與主管的安排一定有他的考量，所以通常我會問自己，上級將我安排這個職位，是要我幫他解決什麼問題？在這樣的公司文化與體制裡，我｢實際」上有哪些職責與權力？這些不一定一開始就會被告知清楚，但我們必須想辦法理解分明，才能確保自己能做出符合期待的產出。
2.認知團隊的重要性
一間軟體公司，即使有再好的業務銷售、再好的設計或行銷團隊，如果沒有工程師把想法 / 創意變成產品，那一切都是空談。而如果整個團隊只有工程師卻沒有其他部門，工程師會無法專心寫 code、也需要親身體驗被需求追殺的感覺了XD
我其實很喜歡這種缺一不可的感覺，這說明每一個人的參與都很重要，我相信沒有完美的個人～只有適合的團隊！
3.培養技術知識
PM 最重要的工作任務是透過溝通與資源調度等方法、將專案成果如期如質的交付予客戶。而為了有效完成上述任務，就至少要懂流程、對技術有概念，才能做出相對適當的安排並加快事情的推動。
4.將客戶需求確認清楚
專案 / 產品可以分階段、或迭代式開發，但如果要避免重工（並想讓自己在工程師面前說話可信、有份量..）
在確認客戶的需求時，該做的事情、該用的工具都不能少，多使用流程圖與 Wireframe，盡量圖文並茂，以文字描述（留存紀錄）後，要再與對方通電話以確認雙方是否達到同一頻率與認知。
同樣一句話、一張圖，每個人看到的/會在意的重點都不太一樣。確認需求不貪快，完成的時間會更快～！
5.設立界線
個人的判斷標準是，不將私人情緒與好惡帶到工作之中，即是對彼此的界線與尊重。
6.區分直覺與感覺的不同
每天要做的事情很多，所以不是每種情緒與感覺都要被正視或處理。然而，如果有覺得哪裡說不上來但「怪怪的」地方，這有時候是一種直覺，不能就這麼過了（因為客戶也不會就這樣放過你的☺️）不過這時也不能空口只說一句我覺得怪怪的就要工程師信服或處理～
所以一定要想辦法先多方詢問、用數據或資訊釐清與佐證，直到雙方都沒有疑慮。（我們的確曾因為這份直覺，躲過很多問題！）
7.適時求助
一般來說，我盡量不會問 Google 關鍵字第一頁就能搜尋到的答案，但如果自己真的有多方搜尋與驗證過還是有疑問，還是要主動問！因為不懂裝懂而做出錯誤的決策，會付出更高的成本……。
三、PM與工程師相處的12個眉角
1.定義清楚的目標與明確的任務說明
這裡談到的目標，還包括職員的個人目標，每個人來到職場工作，一定有所求；不論是求溫飽、求挑戰、求新鮮還是為興趣，那都是一個人來到這裡目標與動機～如果能夠了解每個人目標的好處是：知道他為何而戰，那就可以用他在意的主題去鼓舞他或找到共鳴，讓他自己管理自己，而非只能透過外力強硬管制。（這邊先假設薪資水準有讓他滿意XDD）
關於任務部分，很關鍵的是，如果每個人都不清楚自己負責甚麼項目、應該在甚麼時間有什麼樣的產出、並必須通過甚麼樣的檢驗標準，那如何期待對方能產出令人滿意的成果呢？
2.清楚的事情的優先順序
這跟經驗相關，也無時無刻存在每一個決策與應變之中。
3.多走動
如果有問題想討論或有新的任務要交辦，不要只是留在位置傳 LINE 或撥打分機，而是盡量走道對方旁邊仔細說明。這是之前上 NPDP 課程向夏老師請益而來的：）
4.了解個性，欣賞優點
溝通，要用對方能理解的語言；而理解個性才能找到同樣的頻道和語言。
畢竟～沒有人是完美的啦！或許這也是小型團隊編制的好處，把人看成人，而不是機器～只要彼此尊重、能夠順利完成任務，那多一點理解與對優點的欣賞，可以少掉很多不必要的衝突。
5.多走動，以問題鼓勵思考
雖然我不會寫程式，但我還是願意傾聽並多用討論的方式找答案，如果工程師或設計師卡關了，我們會去聊：
他原本想完成哪一項功能？過程中遇到哪些問題卡住了？他覺得可能是哪些原因造成這些問題？那現在可以怎麼處理？有時候會再回退一些，客戶會怎麼操作、當初為甚麼我們會設計這樣的功能/體驗/機制？（User story 很好用！）
有時候，透過這樣的對談，可以激盪出不同的解法～（但同樣的，這也包含了解個性與情境判斷，有些人特別願意表達自己、觸類旁通、也有些人需要比較多時間進入狀況、在緊急時後需要指令而非無限發散的討論等。）
在每個專案都落實這點有一個好處是，因為本身同時管理多個專案的關係，所以偶爾也能提供不同的觀點是，在別的專案是否也遇過類似問題、後來如何處理並知道可能可以找哪一位工程師來協助等。
6.關注工期安排與時間風險
在排定專案期程前，一般都需要先與工程師確認完成某件事的規格、工時、技術 / 時間風險、與其他需要注意的地方。
而每位工程師的回答可能不太一樣，有些工程師會過度樂觀，有些工程師老實回答，還有些工程師會給自己充裕的緩衝時間。
所以當我們在收到工程師回覆時，也需要退一步，以綜觀的角度看整個專案的安排：
將(工程師回覆的工期*過往經驗的守時風險)+自己預抓可能的緊急狀況=預估工期，當然也要確認最後出來的結果對客戶來說是合理的，再回報給客戶與做後續相對應的管理。
7.給予空間並定期追蹤
接下來很重要的，就是相信對方、並給對方適當的「實作」時間與「容錯」空間。（相信沒有一步到位的程式碼或產品，所以才需要團隊協力合作與層層把關。）
如果真的有未達目標之處，請語氣和緩並清楚的告訴對方，具體來說，哪裡需要調整、希望對方在甚麼時間點之前調整到甚麼程度？
定期追蹤可以視為適當的提醒、適時的關心對方有沒有遇到問題，才能做出相對應的資源調度。
8.相信，但別盡信🤣🤣🤣
這呼應前面提到的「相信直覺」，有時候是每個人經驗與思考角度的不同，也許對方會回你：「這做不到，如果要做會有多麻煩多麻煩等。」
這時候我腦袋都會閃過跑馬燈哈哈哈，我會先思考，現在這個專案的時間是否緊迫？這個問題是否為與驗收相關或客戶在意的核心問題？
對方這樣的回覆合不合理？我是否有在其他專案或產品看過同樣的功能有滿足需求或使用體驗？
這些問題都能幫助我們做更好的決策。
9.沒有人想把事情做不好（與團隊站同一邊）
一個專案/產品的成功，不會只有一個人的功勞，同樣的，一個專案/產品出現問題，也絕對不會是一個人的問題。
所以如果一個問題在不同人身上重複發生，那就應該要警覺並思考，是流程出現問題、還是制度出現問題？如果在外面遇到事情，沒有跟團隊站在同一邊，那這樣也沒有人會想一起合作的！
10.反省自己
有反省才有進步，不能什麼都覺得是別人的問題，不要覺得對方是不是在跟自己作對，而是試著去理解問題與「問題背後的問題」。我偶爾也會有溝通到情緒上來的時候，那時候的口氣可能會比較急也比較不好，我就會找第三方提出意見、冷靜自己，事後再主動跟對方道歉😭
11.設立界線，承擔責任
這攸關心中的一把尺，PM 終究，還是要往外對客戶負責、往上對主管負責，所以前面談到的給予空間與容錯，都還是要有明確的停損點。
12.啟動檢討會議，將經驗歸納與整理
多鼓勵、多肯定彼此做對的地方，正確區分「重複發生的問題」與「新出現的問題」，並與團隊討論出具體的「解決方案」。將每一次經驗幻化成能讓下一次更好的養分，讓每一次挫折的發生有正向意義❤️
以上～其實還有很多小眉角我也還在學習，同時感謝一路走來有各路人士的支持與指點。謝謝看完的你們，也希望這篇文章能讓還在找尋與工程師相處平衡的新手 PM 、或對此話題感興趣的人感覺有一些幫助：）
本文作者：rafeni lee
主圖來源：unsplash.com
若有轉貼需求，請來信（service@pmtone.com）討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用，並且必須註明原文標題、連結、及作者訊息。 覺得這篇文章好嗎？ 請分享給您的朋友吧~
