楼主:
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