親愛的工程師｜PM 與工程師相處的 12 個眉角
4. 了解個性，欣賞優點
溝通，要用對方能理解的語言；而理解個性才能找到同樣的頻道和語言。
畢竟～沒有人是完美的啦！或許這也是小型團隊編制的好處，把人看成人，而不是機器～只要彼此尊重、能夠順利完成任務，那多一點理解與對優點的欣賞，可以少掉很多不必要的衝突。
5. 多走動，以問題鼓勵思考
雖然我不會寫程式，但我還是願意傾聽並多用討論的方式找答案，如果工程師或設計師卡關了，我們會去聊：
他原本想完成哪一項功能？過程中遇到哪些問題卡住了？他覺得可能是哪些原因造成這些問題？那現在可以怎麼處理？有時候會再回退一些，客戶會怎麼操作、當初為甚麼我們會設計這樣的功能/體驗/機制？（User story 很好用！）
有時候，透過這樣的對談，可以激盪出不同的解法～（但同樣的，這也包含了解個性與情境判斷，有些人特別願意表達自己、觸類旁通、也有些人需要比較多時間進入狀況、在緊急時後需要指令而非無限發散的討論等。）
在每個專案都落實這點有一個好處是，因為本身同時管理多個專案的關係，所以偶爾也能提供不同的觀點是，在別的專案是否也遇過類似問題、後來如何處理並知道可能可以找哪一位工程師來協助等。
6. 關注工期安排與時間風險
在排定專案期程前，一般都需要先與工程師確認完成某件事的規格、工時、技術 / 時間風險、與其他需要注意的地方。
而每位工程師的回答可能不太一樣，有些工程師會過度樂觀，有些工程師老實回答，還有些工程師會給自己充裕的緩衝時間。
所以當我們在收到工程師回覆時，也需要退一步，以綜觀的角度看整個專案的安排：
將(工程師回覆的工期*過往經驗的守時風險)+自己預抓可能的緊急狀況=預估工期，當然也要確認最後出來的結果對客戶來說是合理的，再回報給客戶與做後續相對應的管理。
7. 給予空間並定期追蹤
接下來很重要的，就是相信對方、並給對方適當的「實作」時間與「容錯」空間。（相信沒有一步到位的程式碼或產品，所以才需要團隊協力合作與層層把關。）
如果真的有未達目標之處，請語氣和緩並清楚的告訴對方，具體來說，哪裡需要調整、希望對方在甚麼時間點之前調整到甚麼程度？
定期追蹤可以視為適當的提醒、適時的關心對方有沒有遇到問題，才能做出相對應的資源調度。
8. 相信，但別盡信???
這呼應前面提到的「相信直覺」，有時候是每個人經驗與思考角度的不同，也許對方會回你：「這做不到，如果要做會有多麻煩多麻煩等。」
這時候我腦袋都會閃過跑馬燈哈哈哈，我會先思考，現在這個專案的時間是否緊迫？這個問題是否為與驗收相關或客戶在意的核心問題？
對方這樣的回覆合不合理？我是否有在其他專案或產品看過同樣的功能有滿足需求或使用體驗？
這些問題都能幫助我們做更好的決策。
9. 沒有人想把事情做不好（與團隊站同一邊）
一個專案/產品的成功，不會只有一個人的功勞，同樣的，一個專案/產品出現問題，也絕對不會是一個人的問題。
所以如果一個問題在不同人身上重複發生，那就應該要警覺並思考，是流程出現問題、還是制度出現問題？如果在外面遇到事情，沒有跟團隊站在同一邊，那這樣也沒有人會想一起合作的！
10. 反省自己
有反省才有進步，不能什麼都覺得是別人的問題，不要覺得對方是不是在跟自己作對，而是試著去理解問題與「問題背後的問題」。我偶爾也會有溝通到情緒上來的時候，那時候的口氣可能會比較急也比較不好，我就會找第三方提出意見、冷靜自己，事後再主動跟對方道歉?
11. 設立界線，承擔責任
這攸關心中的一把尺，PM 終究，還是要往外對客戶負責、往上對主管負責，所以前面談到的給予空間與容錯，都還是要有明確的停損點。
12. 啟動檢討會議，將經驗歸納與整理
多鼓勵、多肯定彼此做對的地方，正確區分「重複發生的問題」與「新出現的問題」，並與團隊討論出具體的「解決方案」。將每一次經驗幻化成能讓下一次更好的養分，讓每一次挫折的發生有正向意義❤️
以上～其實還有很多小眉角我也還在學習，同時感謝一路走來有各路人士的支持與指點。謝謝看完的你們，也希望這篇文章能讓還在找尋與工程師相處平衡的新手 PM 、或對此話題感興趣的人感覺有一些幫助：）
瀏覽 2,538 次
