作者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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1550977457.A.B92.html
※ 编辑: annedoo (27.242.71.126), 02/24/2019 11:05:57
1F：推 bboy81905: 好文 02/24 11:21
2F：推 iamhandsome: 安毒推推 02/24 11:22
3F：→ MOONY135: 这应该很简单吧 是大忌 02/24 11:26
4F：推 hwChang: 推推 02/24 11:31
5F：推 AnAnNiHow: 推 02/24 11:36
6F：推 Chris926926: 我最近常常听到，不就复制贴上就好了吗？应该很简单 02/24 12:45
7F：→ Chris926926: 吧？真的理智快断线，又一直被压时程 02/24 12:45
8F：推 anandydy529: 别人家的PM和QA都不会让我失望 02/24 12:46
9F：→ alan3100: 最後一点怎麽会是使用者说的算? 02/24 12:56
10F：推 knme: 推 02/24 13:05
11F：推 alloha: 哈哈哈哈哈赞！推推 02/24 13:24
12F：推 yenru: 大家是要一起合作把事情做好，而不是互相扯後腿 02/24 13:47
13F：推 paint: 哈哈哈哈哈哈哈 推 02/24 14:17
14F：→ annedoo: 真的很感谢我们工程师在我说了一些很瞎的话之後还愿意跟 02/24 14:37
15F：→ annedoo: 我讨论，告诉我下次不可以再这样哈哈哈哈哈！ 02/24 14:37
16F：推 adern9: 还以为是电虾板主 02/24 15:07
17F：推 ripple0129: 线上产品某功能你认为行为上是有bug，使用者已经用习 02/24 15:08
18F：→ ripple0129: 惯了，你突然把他改了他还会叫你改回来，因为用习惯了 02/24 15:08
19F：→ ripple0129: ，这种就是使用者说的算的feature。 02/24 15:08
20F：推 chiang1: 原PO聪明正妹PM 推推 02/24 15:28
21F：推 even810911: 好文推推！ 02/24 16:49
22F：→ diejudas: 优化好刺眼 02/24 19:02
23F：推 jeffrey0401: 我想把这篇给公的全部人看了 XD 02/25 01:09
24F：推 bakedgrass: 楼上没有认识母的人吗？ 02/25 08:15
25F：推 Dnight: 不是功能差不多吗？复杂贴上改一改就好了怎麽那麽久 02/25 09:13
26F：推 ESRI99: 怎麽文字有声音?..疑? 02/25 09:22
27F：推 deray: bug还是feature?这我真的没听过XD 02/25 09:40
28F：→ mirae: 最後一个应该反过来,通常是你觉得是feature, PM全部回bug 02/25 10:27
29F：→ annedoo: 回楼上，的确有时候我（PM）觉得是 bug 工程师觉得是 fea 02/25 11:26
30F：→ annedoo: ture，所以其实不是工程师开发错而是一开始没沟通清楚QQ 02/25 11:26
31F：→ annedoo: 阿主受词混乱因为这篇是从PM角度写给PM看哈哈 02/25 11:28
32F：推 orech2002: 我遇过....只寄一张图然後写说请帮忙确认问题 02/25 11:28
33F：→ orech2002: WTF? 02/25 11:28
34F：→ alan3100: 理论上应该是重新设计符合使用者的习惯而不是rollback 02/25 13:16
35F：→ alan3100: 工程师觉得是bug换另一个工程师来看还是bug 02/25 13:18
36F：→ alan3100: 放着就是技术债,系统如果持续复杂就看客服还工程师先崩 02/25 13:22
37F：推 cobrasgo: 我最赌烂5 02/25 19:40
38F：推 dollar1019: 写的很棒，有在思考沟通起来是很快的 02/26 03:58
39F：推 RedDracula: 其实工程师要的很简单，就是一个体贴的正妹 02/26 20:02
40F：推 boo1024555: 乾 根本是在说我 02/27 23:38
41F：推 Eide: 推 07/06 22:30