【 產品經理與工程師溝通的技巧 】

Tina Lin
✍ TinaLin
Published in
5 min readApr 23, 2023

小孩子才做選擇,我全都要?咦?

前言

在出社會工作後,就是一直擔任 PM 的角色,但一開始是擔任產品經理助理的角色,屬於 support 產品經理的學習階段,比較沒有自己去獨立 hold 一個功能開發進度或是與工程師直接協調的經驗,基本上都是提出想法後,最後都會由較資深的產品經理去 hold 整個開發流程。

在這方面其實當時也對成為這個角色還沒有太大的把握,一方面是發現自己對於當時的產業好像沒有太大的動力,或是說 To B 和 To C 的產品也會影響自己投入的熱忱,因此對於職業和產業的雙重不確定下,當時自己對於 PM 這個角色還沒有太多的投入和想法。

時光快轉到現在,換了產業後,也已經成為可以獨立設計功能、跟著團隊跑 Scrum 的 PM了,也發現產業真的會影響自己的熱忱!目前在這個工作中,讓我大大的提升自信和決策力,雖然一開始是挺痛苦的 XD ( 之後可以再寫一篇文章分享ya )

接下來就來分享,自己是如何抓到與工程師和睦相處的方式,還有他們最難以接受的地雷吧!

😎 與工程師和睦相處的方式:

1. 在規劃新功能、優化功能時,需要注意這個功能是否有開發的必要性?

:「 這張 issue 是用來幹嘛的?」

:「這個功能很不錯啊!大家一定會用的!」

:「誰?有誰會用?」

:「ㄜ…就是可能會對他們有幫助吧?」

工程師最不喜歡開發出來的程式最後沒有人在用,或是自己辛辛苦苦寫出來的 Code,最後打掉重頭開始!

身為 PM 最最最重要的就是要確認自己設計規劃出來的功能,是否有打中使用者的需求,還是只是自己的一廂情願?覺得這個功能很棒?毫無根據的認為是為對方好?結果對方根本不需要?

好像是什麼情緒勒索的方式XDDD

這時候前期的規劃和調研就要非常仔細,為了就是不讓任何資源浪費,還有讓做出來的功能都能妥善發揮。

記得適時的稱讚和給予鼓勵吧!

在工程師開發這一樣功能的時候,也適時地讓他們了解,這個功能對使用者的幫助有多大?

讓他們知道自己有多麽偉大 ✨ ✨ ✨

2. 開發功能的時辰要抓好,雙向溝通很重要!

:「 這個功能我下週就要!」

:「 蛤?啊我這邊還有東西欸!怎麼可能下週?」

:「 還好吧?這個有很難嗎?」

:「 ……. 」

剛開始開發功能的時候,我發現之前看一些關於 PM 的文章,大家都說要跟工程師理性溝通,來回去理解對方的難處,但還沒有實際運用到職場中,所以也不太曉得怎麼抓時間。

但現在完全可以體會到一些情境,當個不要亂壓時辰的 PM。

預估工程師可以完成的時間

也可以找工程師討論這個功能整體開發會需要多久?

像是新的 sprint 要開發新功能時,對他們來說,有時候會需要將「 研究功能 」這樣的行動列成一張 issue,我們會開一張 study 單子,讓他們有足夠的時間去研究如何開發這項功能。

入職時間的長短也會影響開發時辰的進度,像是前陣子有一些新進的工程師,在我們跑 Scrum 的週期中,同事和我就會稍微將 RD 的進度稍為調整下,因為同時也會考慮到原本在公司的工程師需要花時間教育訓練新進人員,新進人員在一兩個月後,也開始跟進度時,會需要時間 study 他們接下來要開發的新功能,這時候我們也會開幾張「Study — Fuction」的單子,讓他們有足夠的時間去吸收消化。

要相信大家都想把功能做好!

當工程師提到這個東西會需要非常久的時間時,不能單方面的就說需求方很急想要在什麼時候完成,而是要去理解為什麼會很久?開發這個功能會涉及到什麼系統嗎?還是說目前他手上的任務沒有餘裕去完成這個功能?

理解對方的處境、系統的邏輯脈絡

上週有工程師跟我提到原本要繼續開發的系統可能要下一個 sprint 才可以一起完成,我們就在會議室討論為什麼會這樣,原來是因為這項系統開發會卡到另一個工程師目前在開發的項目,也理解這個系統會用到哪些 table?這些table 的組成順序?

結論是上版的先後順序需要調整,那留下一個sprint 的空檔,我們可以將一些未來要一起調整的項目先陸續開發,這樣讓上版的時間綽綽有餘!

3. 幫助工程師省時間,預先想到各個功能未來的優先順序

:「 我這邊有插件喔!」

:「 這個有很急嗎?下次再安排 ok 嗎?」

其實要當個幫工程師擋需求的 PM 也是需要有強大的判斷能力的,除非是急件,否則當我們接到需求時,要如何將這個需求加入到 sprint 中?有哪些功能是必須的?哪些功能調整是可以在這次上版一起完成的?

通常我們的判定標準:

  1. 急件:在這次 sprint一起上版
  2. 一般 ( 涉及到跟這次上版有關的系統 ):只要是牽連到這一次需要上版的系統或是產品,就會一起連帶開發上版
  3. 一般 ( 未涉及到跟這次上版有關的系統 ):只要是沒有牽連到這一次需要上版的系統或是產品,就會找接下來這個系統在哪一次會有上版的排程?並且將他歸納在一起!

這麼多需要改善的功能

不要跟工程師說我全都要XD

我相信工程師一定都知道我們被夾擊在中間的處境,在我們理解他們的同時,他們一定也會知道我們的不易 (應該ㄅ XD),所以清楚的和他們溝通需求的輕重緩急,他們一定會理解的!

結語

在擔任 PM 這條路上,也還有好多功課要學習,不過我發現自己也越來越享受這個職位需要挑戰的課題!每次遇到難題真的會越來越勇於面對,並且更加無懼的面對陌生問題!

所有的積累都是成長的養分

慢慢發現自己有在成為自己理想中的模樣,或是說理想中的模樣是什麼也說的不是很清楚,只知道現在去上班是開心是快樂的!這個標準應該就足夠了!最後最後,也是蠻重要的一點!

讚美的力量非常的強大

當功能開發出來後,適時的回饋給工程師們,使用者目前對於功能上的體驗,並且將這些回饋分享給工程師們,我想,這對他們來說也是莫大的鼓勵吧!

【大家大家 ~~~ 快去註冊Medium吧 !】

若想讓我的三分鐘熱度持續下去
可以「拍手」給我支持:

1. 喜歡我的文章:請給我 1~10 個拍手;
2. 有所收穫:請給我 11~20 個拍手;
3. 給我撐下去! 想繼續看接下來的文章!!:21~50 拍隨便你拍!

--

--