【投稿】親愛的工程師|PM 與工程師相處的12個眉角

這篇想分享, PM 如何與一群比自己厲害數百倍的軟體工程師合作?看似不同立場的雙方如何溝通與共處?

這篇想分享, 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

文章出處:親愛的工程師|PM 與工程師相處的12個眉角

主圖來源:unsplash.com

若有轉貼需求,請來信(service@pmtone.com)討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。 覺得這篇文章好嗎? 請分享給您的朋友吧~

分享在 facebook
Facebook
分享在 twitter
Twitter
分享在 linkedin
LinkedIn
分享在 email
Email
分享在 print
列印

延伸閱讀