之前在 ruby china 讨论过这个问题，这次也想过来请教一下大家
感觉很多团队的做法，或者说要求，都是 “ PM 把所有事情想好，然后告诉工程师怎么做”
不知道大家对这种做法怎么看？
我觉得，可以考虑这些区别
1. 技术导向 vs. 业务导向
可以考虑这两类产品，应该是工程师主导，还是业务(PM)主导？
- 搜索, excel, hotmail, 论坛, Prisma, 石墨， import.io
- O2O 外卖, 垂直行业（ Keep 健身，简单心理）；蚂蚁金服; 发红包功能，退款功能
当然，不仅是产品，也是功能点，比如
- excel: 作为底层产品全面；另一方面, 用户反馈画出好看的图很难，所以也会加入一些数据可视化 best practice ，让产品简单易用
当然很多时候可能更为复杂，比如
- 数据产品: 一方面希望算法、数据足够准确, 但另一方面也希望对用户简单易用不难学
2. 团队的合作氛围
可以责任分明，你没做好就把你批判一番；也可以在别人犯错、需要帮忙的时候，做力所能及的合作
比如说，做一个红包运营活动功能， PM 因为不擅长做 UML 分析，可能会漏了红包的创建者、创建规则等等，这个时候工程师就可以善意提醒
3. 问题 /vision 驱动 vs. 纠结于具体的实现形式
当工程师 /设计师愿意 take ownership 的时候， PM 可以把希望解决的问题、大概的效果讲清楚，然后让他们来解决问题。而不是 PM 说“我要的就是这个样子，你做就好了”
在做有意思的功能的时候，这样子一方面容易出一些创新性的功能设计，另一方面，团队也不会觉得只是在“遵守命令”，可以做一些更具创造力，发挥自身价值的事情
比如，
- 设计某工具型产品的首页，把关注点落在“怎么简单快速的向用户介绍我们的产品”，而不是“你得按 123 的顺序来设计页面，把页面搞好看点就行了”
- 发微博和人交流很麻烦，这时我们把问题明确，然后工程师设计出了 @用户, #话题#的创新功能
4. 试验 /创新性功能 vs. bug 修复、信息架构
当做创新性功能的时候，想法必然会不完善。这时需要的是 PM 、工程师间的紧密协作，而不是 PM 指责工程师怎么做这么慢，做出来和自己想的不一样；工程师指责 PM 老是变需求，想法不靠谱、漏东西
而只修 Bug ，做简单的信息架构（比如 app 分几个页面， 用户私信在哪里浏览），这个时候不确定性又会小很多
5. 让我心寒的
一种是自负的 PM 。觉得自己脑海里已经完全想到了一个东西怎么做，工程师去实现就好了。把工程师、设计师当作了实现自己目标的工具。毫无团队感与谦逊的态度
另一种是不愿意合作的工程师。当用户为团队的产品苦恼，前来求助时，不愿意和 PM 、设计师一起去解决问题，反而说你们想好怎么实现，然后我再做就好了；对于创新性的功能，碰到了 PM 、设计师没想好的地方，只怪别人没想好，老是变更，而不愿意一起去做 MVP 、快速迭代
Select Language