作者:
annedoo (蕭安)
2019-02-24 11:04:02哈囉～我是在軟體業工作的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，最後還是使用者說了算
以上～～～
作者: bboy81905 (莊家) 2019-02-24 11:21:00
好文
作者:
hwChang (聰明是天賦 善良是選擇)
2019-02-24 11:31:00推推
作者: Chris926926 (Jan Egeland) 2019-02-24 12:45:00
我最近常常聽到，不就複製貼上就好了嗎？應該很簡單吧？真的理智快斷線，又一直被壓時程
作者:
knme (knem)
2019-02-24 13:05:00推
作者:
alloha (lindachiou32)
2019-02-24 13:24:00哈哈哈哈哈讚！推推
作者:
yenru (戴菲娜)
2019-02-24 13:47:00大家是要一起合作把事情做好，而不是互相扯後腿
作者:
paint (有斑紋的馬)
2019-02-24 14:17:00哈哈哈哈哈哈哈 推
作者:
annedoo (蕭安)
2019-02-24 14:37:00真的很感謝我們工程師在我說了一些很瞎的話之後還願意跟我討論，告訴我下次不可以再這樣哈哈哈哈哈！
作者:
adern9 (adern9)
2019-02-24 15:07:00還以為是電蝦板主
線上產品某功能你認為行為上是有bug，使用者已經用習慣了，你突然把他改了他還會叫你改回來，因為用習慣了，這種就是使用者說的算的feature。
作者:
chiang1 (歐噴羌ㄙ)
2019-02-24 15:28:00原PO聰明正妹PM 推推
作者: even810911 (even) 2019-02-24 16:49:00
好文推推！
作者:
Dnight (暗夜)
2019-02-25 09:13:00不是功能差不多嗎？複雜貼上改一改就好了怎麼那麼久
作者: ESRI99 (炎涼) 2019-02-25 09:22:00
怎麼文字有聲音?..疑?
作者:
deray (Deray)
2019-02-25 09:40:00bug還是feature?這我真的沒聽過XD
作者: mirae (國境之南) 2019-02-25 10:27:00
最後一個應該反過來,通常是你覺得是feature, PM全部回bug
作者:
annedoo (蕭安)
2019-02-25 11:26:00回樓上，的確有時候我（PM）覺得是 bug 工程師覺得是 feature，所以其實不是工程師開發錯而是一開始沒溝通清楚QQ阿主受詞混亂因為這篇是從PM角度寫給PM看哈哈
我遇過....只寄一張圖然後寫說請幫忙確認問題WTF?
理論上應該是重新設計符合使用者的習慣而不是rollback工程師覺得是bug換另一個工程師來看還是bug放著就是技術債,系統如果持續複雜就看客服還工程師先崩
作者:
cobrasgo (人魚線變成鮪魚線，超帥)
2019-02-25 19:40:00我最賭爛5