哈囉～我是在软件业工作的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，最后还是使用者说了算
以上～～～