作者annedoo (安安)
看板Soft_Job
標題[心得] PM如何與工程師工作、工程師雷區幹話大全
時間Sun Feb 24 11:04:02 2019
哈囉~我是在軟體業工作的PM,
最近跟朋友寫了一些文章分享從PM角度如何跟工程師、資料團隊合作,
以及我剛開始當PM的時候踩過的雷,分享給新手PM參考~
(雖然不知道這個版PM多不多啦!站出來!)
也請各位工程師大大鞭小力點,歡迎在 Medium 或站內信交流~
如何跟資料科學家合作?
https://pse.is/F893Y
如何跟工程師合作?
https://pse.is/F5J57
工程師雷區幹話大全
https://pse.is/FKDGG
一、你當我會通靈喔?
使用情境
當產品經理的需求提的不清不楚,要工程師自己花心思猜測或設計時。
優化方向
找工程師討論或實作之前,先將目標、需求、BUG 的重現方式寫清楚。
二、你這不叫敏捷開發,叫做隕石開發。
使用情境
沒有規劃清楚 Product Roadmap 和優先級,常有插件產生。
優化方向
新需求或需求更改在所難免,但盡量避免讓團隊將 A 功能開發到一半時,突然又要換去做 B 功能。可以在 Sprint 銜接中間再來處理小插件。
三、又要改,還是我直接幫你開一個 bitbucket 帳號?
使用情境
產品經理沒想清楚就行動,導致同個功能來來回回改動多次。
或是小文案的改動,實際修正很快,但特別開 task 來做的時間成本並不低。
優化方向
需求統整好再一次開,避免多次來回修改,若真的臨時有小需求要改,請懷抱著感恩與謙卑的心面對辛苦的工程師大大。
四、沒有做不做得到,只有做不做得完。
使用情境
產品經理帶著一個初步的想法去問工程師「這做得到嗎?」對工程師來說,以他高超的能力,沒有做不到的功能,只有做不完的需求。
優化方向
產品經理帶著想法去問工程師時,可以先將目標、幾種不同類型的解法建議、時間與資源限制都列下後,再詢問實作的複雜度、可擴充性等等,同時也可以多問一些開放式問題,別用「這做得到嗎?」打天下。
五、什麼叫做這個應該很簡單,那你來教我!
使用情境
產品經理帶著一個需求並脫口而出「這個應該改很快吧!」、「這明天可以給我嗎?」或是在工程師卡關絞盡腦汁思考的時候,堅持要給工程師技術建議,希望能幫助他們更快完成工作。(醒醒吧,你幫不上忙的!)
優化方向
提出一個新的需求時,給工程師足夠的時間「實作」外,也要給工程師足夠的時間思考他需要多少時間來實作。
六、你有聽懂嗎?那你講一次給我聽。
- 很好,那你去解釋給 XXPM 聽,因為他聽不懂。
使用情境
工程師對產品經理說明為什麼某個 BUG 會產生、某個解法不可行、某個實作很複雜,要先理解技術才能繼續規劃功能時。
優化方向
請工程師有耐心的說明,也請產品經理自己先做功課。我過去合作的工程師會先貼一些網路文章(技術說明、實作案例)給我看,叫我看完再回去找他討論,節省雙方時間。記得做筆記,好事不說第二遍。
七、我這邊測是正常,還是不 work 嗎?你有清 cache 嗎?
- 你用無痕看看。我剛有改,你有 deploy 最新版本到 staging 嗎?
- 昨天我測還好好的啊,為什麼你試就不行?你很強欸你要不要轉去做 QA?
使用情境
產品經理發現問題回報給工程師後,工程師測不出來。
優化方向
測到問題時,將重現步驟、截圖清楚地提供給工程師,他們才能夠按圖索驥的 debug 和測試。
有的時候是不同新功能彼此有 dependencies 或邏輯不一致,上線前沒注意就全部 merge 在一起造成整合測試時才發現問題,這時可能就要拉回去修改。
八、所以這是 bug 還是 feature?
使用情境
文件寫得不夠清楚、使用者回報一個沒遇過的問題,當產品經理拿著一個你覺得是 bug、他覺得是 feature 的使用狀況來質問時。
優化方向
產品經理要將文件細節、特殊使用情境想清楚,工程師實作時遇到不確定的狀況也可以主動找產品經理溝通。不過到底是 bug 還是 feature,最後還是使用者說了算
以上~~~
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.71.126
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1550977457.A.B92.html
※ 編輯: annedoo (27.242.71.126), 02/24/2019 11:05:57
推 bboy81905: 好文 02/24 11:21
推 iamhandsome: 安毒推推 02/24 11:22
→ MOONY135: 這應該很簡單吧 是大忌 02/24 11:26
推 hwChang: 推推 02/24 11:31
推 AnAnNiHow: 推 02/24 11:36
推 Chris926926: 我最近常常聽到,不就複製貼上就好了嗎?應該很簡單 02/24 12:45
→ Chris926926: 吧?真的理智快斷線,又一直被壓時程 02/24 12:45
推 anandydy529: 別人家的PM和QA都不會讓我失望 02/24 12:46
→ alan3100: 最後一點怎麼會是使用者說的算? 02/24 12:56
推 knme: 推 02/24 13:05
推 alloha: 哈哈哈哈哈讚!推推 02/24 13:24
推 yenru: 大家是要一起合作把事情做好,而不是互相扯後腿 02/24 13:47
推 paint: 哈哈哈哈哈哈哈 推 02/24 14:17
→ annedoo: 真的很感謝我們工程師在我說了一些很瞎的話之後還願意跟 02/24 14:37
→ annedoo: 我討論,告訴我下次不可以再這樣哈哈哈哈哈! 02/24 14:37
推 adern9: 還以為是電蝦板主 02/24 15:07
推 ripple0129: 線上產品某功能你認為行為上是有bug,使用者已經用習 02/24 15:08
→ ripple0129: 慣了,你突然把他改了他還會叫你改回來,因為用習慣了 02/24 15:08
→ ripple0129: ,這種就是使用者說的算的feature。 02/24 15:08
推 chiang1: 原PO聰明正妹PM 推推 02/24 15:28
推 even810911: 好文推推! 02/24 16:49
→ diejudas: 優化好刺眼 02/24 19:02
推 jeffrey0401: 我想把這篇給公的全部人看了 XD 02/25 01:09
推 bakedgrass: 樓上沒有認識母的人嗎? 02/25 08:15
推 Dnight: 不是功能差不多嗎?複雜貼上改一改就好了怎麼那麼久 02/25 09:13
推 ESRI99: 怎麼文字有聲音?..疑? 02/25 09:22
推 deray: bug還是feature?這我真的沒聽過XD 02/25 09:40
→ mirae: 最後一個應該反過來,通常是你覺得是feature, PM全部回bug 02/25 10:27
→ annedoo: 回樓上,的確有時候我(PM)覺得是 bug 工程師覺得是 fea 02/25 11:26
→ annedoo: ture,所以其實不是工程師開發錯而是一開始沒溝通清楚QQ 02/25 11:26
→ annedoo: 阿主受詞混亂因為這篇是從PM角度寫給PM看哈哈 02/25 11:28
推 orech2002: 我遇過....只寄一張圖然後寫說請幫忙確認問題 02/25 11:28
→ orech2002: WTF? 02/25 11:28
→ alan3100: 理論上應該是重新設計符合使用者的習慣而不是rollback 02/25 13:16
→ alan3100: 工程師覺得是bug換另一個工程師來看還是bug 02/25 13:18
→ alan3100: 放著就是技術債,系統如果持續複雜就看客服還工程師先崩 02/25 13:22
推 cobrasgo: 我最賭爛5 02/25 19:40
推 dollar1019: 寫的很棒,有在思考溝通起來是很快的 02/26 03:58
推 RedDracula: 其實工程師要的很簡單,就是一個體貼的正妹 02/26 20:02
推 boo1024555: 乾 根本是在說我 02/27 23:38
推 Eide: 推 07/06 22:30