職場360

2023.05.02 | 8553次觀看

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

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

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

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

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

認知團隊的重要性

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

培養技術知識

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

將客戶需求確認清楚

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

設立界線

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

區分直覺與感覺的不同

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

適時求助

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

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

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

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

清楚事情的優先順序

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

多走動、多互動

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

以問題鼓勵思考

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

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

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

了解個性,欣賞優點

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

關注工期安排與時間風險

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

給予空間並定期追蹤

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

相信,但別盡信

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

沒有人想把事情做不好(與團隊站同一邊)

一個專案 / 產品的成功,不會只有一個人的功勞;同樣的,一個專案 / 產品出現問題,也絕對不會是一個人的問題。
所以,如果一個問題在不同人身上重複發生,那就應該要警覺並思考,是流程出現問題、還是制度出現問題?如果在外面遇到事情,沒有跟團隊站在同一邊,那這樣也沒有人會想一起合作的。

反省自己

有反省才有進步,不能什麼都覺得是別人的問題,不要覺得對方是不是在跟自己作對,而是試著去理解問題與「問題背後的問題」。我偶爾也會有溝通到情緒上來的時候,那時候的口氣可能會比較急,也比較不好,我就會找第三方提出意見,讓自己冷靜,事後再主動跟對方道歉。

設立界線,承擔責任

這攸關心中的一把尺,PM 終究還是要向外對客戶負責、向上對主管負責,所以前面談到的「給予空間與容錯」,還是要有明確的停損點。

啟動檢討會議,將經驗歸納與整理

多鼓勵、多肯定彼此做對的地方,正確區分「重複發生的問題」與「新出現的問題」,並與團隊討論出具體的「解決方案」。將每一次的經驗幻化成能讓下一次更好的養分,讓每一次挫折的發生有正向意義。

節錄自:博碩文化《翻轉職涯!轉職PM的必備工作力×與工程師的協作心法/Rafeni(李星玟) 著 》


更多【專案經理PM】工作機會

沒看到有興趣的職缺嗎?


推薦閱讀:

加入粉專,每天收看職場力最新文章