【PM夥伴攻略】番外篇：工程師雷區幹話大全
這篇是《【PM夥伴攻略】如何跟工程師合作？》的番外篇。
▍雷區翻譯官
一開始（現在可能還是）跟工程師合作時，常會沒拿捏好分寸而踩了雷，這篇就讓我來分享那些年我被罵過的經典對話原音重現！
一、你當我會通靈喔？
使用情境當產品經理的需求提的不清不楚，要工程師自己花心思猜測或設計時。
優化方向找工程師討論或實作之前，先將目標、需求、BUG 的重現方式寫清楚。
詳情請見《【PM夥伴攻略】如何跟工程師合作？》第一、二點。
二、你這不叫敏捷開發，叫做隕石開發。
你這個 request 很急嗎？當我許願池、你有投錢嗎？
使用情境沒有規劃清楚 Product Roadmap 和優先級，常有插件產生。
優化方向
新需求或需求更改在所難免，但盡量避免讓團隊將 A 功能開發到一半時，突然又要換去做 B 功能。可以在 Sprint 銜接中間再來處理小插件。
三、又要改，還是我直接幫你開一個 bitbucket 帳號？
使用情境產品經理沒想清楚就行動，導致同個功能來來回回改動多次。
或是小文案的改動，實際修正很快，但特別開 task 來做的時間成本並不低。
優化方向
需求統整好再一次開，避免多次來回修改，若真的臨時有小需求要改，請懷抱著感恩與謙卑的心面對辛苦的工程師大大。
四、沒有做不做得到，只有做不做得完。
使用情境產品經理帶著一個初步的想法去問工程師「這做得到嗎？」對工程師來說，以他高超的能力，沒有做不到的功能，只有做不完的需求。
優化方向
產品經理帶著想法去問工程師時，可以先將目標、幾種不同類型的解法建議、時間與資源限制都列下後，再詢問實作的複雜度、可擴充性等等，同時也可以多問一些開放式問題，別用「這做得到嗎？」打天下。
五、什麼叫做這個應該很簡單，那你來教我！
不然你來寫啊！你要不要先去上 Ruby 101，我幫你付學費。
使用情境產品經理帶著一個需求並脫口而出「這個應該改很快吧！」、「這明天可以給我嗎？」或是在工程師卡關絞盡腦汁思考的時候，堅持要給工程師技術建議，希望能幫助他們更快完成工作。（醒醒吧，你幫不上忙的！）
優化方向
提出一個新的需求時，給工程師足夠的時間「實作」外，也要給工程師足夠的時間思考他需要多少時間來實作。
詳情請見《【PM夥伴攻略】如何跟工程師合作？》第五點。
六、你有聽懂嗎？那你講一次給我聽。
很好，那你去解釋給 XXPM 聽，因為他聽不懂。
使用情境
工程師對產品經理說明為什麼某個 BUG 會產生、某個解法不可行、某個實作很複雜，要先理解技術才能繼續規劃功能時。
優化方向
請工程師有耐心的說明，也請產品經理自己先做功課。我過去合作的工程師會先貼一些網路文章（技術說明、實作案例）給我看，叫我看完再回去找他討論，節省雙方時間。記得做筆記，好話不說第二遍。
七、我這邊測是正常，還是不 work 嗎？你有清 cache 嗎？
你用無痕看看。我剛有改，你有 deploy 最新版本到 staging 嗎？
昨天我測還好好的啊，為什麼你試就不行？你很強欸你要不要轉去做 QA？
使用情境產品經理發現問題回報給工程師後，工程師測不出來。
優化方向
測到問題時，將重現步驟、截圖清楚地提供給工程師，他們才能夠按圖索驥的 debug 和測試。
有的時候是不同新功能彼此有 dependencies 或邏輯不一致，上線前沒注意就全部 merge 在一起造成整合測試時才發現問題，這時可能就要拉回去修改。
八、所以這是 bug 還是 feature？
你當初開需求給我的時候就是這樣啊！啊客戶怎麼會覺得是 bug？
使用情境文件寫得不夠清楚、使用者回報一個沒遇過的問題，當產品經理拿著一個你覺得是 bug、他覺得是 feature 的使用狀況來質問時。
優化方向
產品經理要將文件細節、特殊使用情境想清楚，工程師實作時遇到不確定的狀況也可以主動找產品經理溝通。不過到底是 bug 還是 feature，最後還是使用者說了算😂
▍結語
寫完這篇心都累了～工程師請用心的教育與灌溉你的產品經理。產品經理們，讓我們繼續結伴用一顆感恩的心踩地雷吧❤
謝謝你的閱讀！如果有任何疑問、建議的主題也歡迎留言給我 📒如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多團隊合作的文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我們知道 👏🏻未來也會分享跟團隊內其他角色的合作方式，敬請期待！
想要持續追蹤我們的最新文章，請追蹤產品三眼怪實驗室 (◉◉◉)
