“PM 把所有事情想好，然后告诉工程师怎么做”，大家对这种做法怎么看？

[cqcn1991]

之前在 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 、快速迭代

[kokdemo]

pm 这个岗位最大的坑就是职能不明确，

开发强势了， pm 就沦为画图仔
运营强势了， pm 就沦为传声筒

所以还是得在团队里找好定位，这样大家才能都舒心。

[Yourdaye]

做技术的，要多跟用户沟通，听取用户的心声

[leekafai]

我觉得绝大多数 pm 能把需求阐述好就已经很好了……看一个 pm 合不合格，最简单的就是考 ta 登录功能的设计。表单项设计、输入限制、前端验证我觉得就筛掉一部分了，再来就是各类的错误提示设计、异步数据加锁（ loading 动画之类的）状态设计……当然，再多的我觉得不单是产品的责任，而是项目管理的责任，像后端验证，性能上讨论缓存数据在登录上的使用（密码修改后要及时处理缓存，读写分离的话就要留心处理）、用户数据的脱敏缓存。所以，很多时候坑不在产品管理，而在于缺少项目管理（简写也是 pm ……）。或者根本一点，公司没钱请项目管理，那产品经理就要拿头硬 gank 了。

[sammo]

好公司的标准是职责划分清晰
也就是 any employee is replaceable
所以还是 专业人做专业事
不背锅也不甩锅

你让一个实现技术细节的人帮你想着你的运营流程的工作，是不可能的。善意提醒是不可能的，不骂你就不错了（也没有必要骂你：可以直接告诉老板这个 pm 专业度不够，老板会直接 fire 你） 你只能回去自我反省。

[wohenyingyu02]

PM 还懂技术么……

[cqcn1991]

@sammo 想请教一下，你对这篇文章里的说法怎么看？

http://svpg.com/good-product-team-bad-product-team/

我翻译了一下，在这里 https://book.douban.com/review/8421504/

[sammo]

我认为好团队本身有 intrisic features. 这些特点本身是决定了他们可以位于好团队们的行列，比如职责分明 有专业度
我认为业内的顶尖团队们都有相似之处。向好团队们的共性看齐 才可以变成好团队。其他都是锦上添花而已

除此之外 我认为业内的顶尖团队和业内的顶尖团队之间的差别其实很小，即使他们的成立时间不同、做的是不同方向的产品

最后，我很反感 “以 产品的好坏 来评价 产品的制作者” 的视角。推出好产品的团队就一定是好团队吗？ No 好产品是天时地利人和的综合产物，如果吹好产品的制作者 那么会忽略天时地利。我认为如果一个团队有 “好团队们的共性” 那么他们就是好团队。好团队做不出好产品的例子比比皆是，但好团队就是好团队 即使没有那种被大众报道的明星产品（人和在、天时地利不在。而且 有些团队在开发原子弹 根本不会被大众报道）。 —— 如果你身处一个好团队里，你是可以感觉到它的周到之处的

[cqcn1991]

@sammo 之前没看到，非常感谢你的回复~