“PM 把东西想好，然后工程师实现就行了”，似乎是目前的常态
我觉得这样不太好（我是 PM），所以写了这篇，也不知道对不对，希望大家可以指点一下
适合读者：创业团队，开发效率低，总改需求、出错；合作氛围差，经常撕逼、互相甩锅
1. 被问懵逼的 PM
目前国内常见的做法，是 PM 把所有东西想好，然后告诉工程师怎么做
比如一个双 11 红包活动案例，
- 运营想做个双 11 发红包的活动，于是给 PM 发需求。
- PM 开始想方案 —— 用户在哪里领红包，领了哪里可看到，怎么使用，退款了怎么处理等等
- 然而，PM 只注意了用户流程，忘了红包谁出钱、发放规则谁来制定等方面。
- 于是，在需求评审的时候，PM 被工程师"领到的红包是谁出钱？红包的发放规则，是商户控制还是我们控制？”一连串问题 问懵逼了，运营活动也就没下文了
这里，PM 因为考虑不周全被作者批判了一番，结论是 PM 要把流程中的主体考虑清楚，不要漏东西。
PM 把产品上的东西弄明白，当然是正确的。但这里的做法，我总感觉不太对。。。。
2. 看起来更好看的首页
之前在一家公司实习 PM，碰上首页改版，效果是这样的（左为改版前，右为改版后）
乍一看挺不错，更好看了，但实际效果不会太好。
因为，没有人会一字一句读首页上的功能特性，人们只在乎能帮他们解决什么问题、效果如何。
也就是说，真正的目的应该是快速把产品介绍给用户，而不仅仅是好看。比如美图秀秀，根本不需要说产品特性 123 点 —— P 图前后对比就够了 [1]
也就是说，之前的PM 把目标定错了，导致首页改版没什么效果。
于是，我重新定义了要解决的问题 —— 怎样快速、简单的介绍我们的产品？
这时思路就打开了，再给了些别的产品作例子（比如展示实际案例，产品 UI），设计师的思路也就不会再局限于排版、颜色上，也有更大的发挥空间了，而且设计师本身也很擅长解决这个问题。
也就是说，给出一个好的问题，比直接给出具体的 solution，要更好。另一方面，PM 给的 solution 也未必是好的，就像之前的 PM 给的非常模糊的目标一样。让团队里的专家（设计师）解决专门的问题会更好，得到的结果也不会局限于 PM 的个人能力。
3. 自然而成的 sidebar 插件
另一件事是给 Jupyter Notebook 做sidebar 插件
Jupyter 有个在 Github 上有个插件 repo，里面都是大家写的插件。当时，我觉得应该给一个插件加个新功能。但直接开 Issue 说“你们应该怎么做”, 感觉不太好，人家也不会乐意。
于是，我做了原型，把 gif 效果展示给了大家
大家觉得很棒，也就跟着做了（后来反应也很好）。这里，我没给文档、细节，只是把vision(好处、效果) 讲清楚，大家就明白了、愿意做了。
通常，我们总是要求 PM 把功能/产品的细节想好，然后告诉工程师怎么做。像基本的功能，比如退款、收藏、订阅，运营活动，论坛系统，这是可行的。
但是，做比较新的东西的时候，比如这里的 sidebar, 或者墨刀、Prezi，数据/算法产品（信息流）, bot 再到涉及机器学习、爬虫等等，很难想到具体的细节，通常会涉及到交互/数据/技术等方方面面，是难以一蹴而就的。这个时候依然按传统的“文档 -> 开发”来做，就很难了。
另一方面，让 Data Scientist, 设计师，工程师去考虑这些新的/专门的/他们擅长的问题，不会比全部交给 PM 要更好吗？毕竟他们在这些方面，比 PM 懂多了。
面对未知性较强的开发任务时，把 vision 讲清楚，细节大家共同完善，会不会更好？本质上，其实更接近于“实验”了，是要不断调整、试错的。
4. 更好的方法？
说到这里，我觉得红包运营活动的例子，这样做如何？
- PM 把基本流程梳理好
- 运营、产品、工程师讨论，说说大概想做的东西是怎样的，怎么落实。
- 这时，工程师发现一些问题没考虑到，比如红包的钱谁出、规则谁定，运营也可能想到了其他的点。
- 针对这些问题，大家分别领任务细化落实
团队各个角色一起思考，可以考虑得更完善，也能有效利用各方所长，更有效率。像 PM 漏了红包的创建者、创建规则，其实是因为不会 UML，这个工程师会更擅长，他来就会很全面；运营可能会有新想法、发现漏了东西，可以及时补上；工程师可能对整个流程不了解，这个让 PM 讲故事就好……
退一万步，真的需要把流程完全交给 PM 设计，也可以让工程师把 UML 教给 PM 嘛，哈哈哈
建立 vision/共识 -> 发现问题 -> 解决问题，东西就做出来了，不会有谁被问懵逼，也更有效率
其实就是这种说法 ——
build a shared understanding, not write a perfect documentation [3]
更重要的是，团队合作的氛围也更好了。开头红包的例子里，其实有敌意（工程师责怪 PM 为什么没有考虑周全），但如果大家可以合作解决问题，就不会有这个事了。
5. 总结
“PM 想好所有东西，然后工程师负责实现“适用于常规的开发，但做新的东西、未知性强的东西的时候，不一定合适
(1) 得不到最好的结果
尤其是对于新产品/功能，需要工程师/设计师不断实验的，没办法一开始就想好。
(2) 尊重
这个上面没提，我是觉得没有人喜欢被告诉一天到晚做什么，尤其是听没自己懂的人（PM）瞎比比
(3) 团队合作氛围
彼此之间责任完全分隔，很容易导致没人 contribute to the product, 都只在乎自己的一小块做得好不好。可是，自己的产品，自己都不在乎，还会在乎用户吗？
写了这么多，其实是想老板/PM 们可以更开放一点，让开发团队更多的参与到决策中，而不是闷头自己去“解决问题”
不过，很多时候工程师/设计师又未必乐意、主动给想法，甚至不少 PM 也没那么主动
这就涉及到了另一个问题 —— 产品经理/工程师/设计师，是产品的创作者，还仅仅是老板制作产品的工具？
[1] 不同产品的首页应该是怎样的？
考虑 ReactJS, 微信编辑器，美图秀秀几个产品的首页差别
[2] 不同产品，由不同的人主导
考虑下面这些，分别应该由什么样的人来主导？
- 退款流程，携程，O2O
- 墨刀，Prezi, Canva/创客贴
- 电商
- tower
- 摄影、滤镜 App；流利说英语学习产品
[3] 出自 User Story Mapping
PM 把需求想清楚，把流程设计通畅，把需求描述清晰是本职工作。
工程师把需求理解清楚，把需求转化为技术实现，写出可维护可扩展 bug 少的代码，顺便找到流程中缺失环节反馈给 PM，这是本职工作。
所以，你问工程师只负责实现么，我觉得是。我觉得可以理清需求给出实现就算是合格的工程师。
至于你要问，工程师要不要负责产品设计，要不要负责 UI 设计，要不要负责 QA，要不要会演讲，要不要负责运营，要不要负责管理？我当然觉得会的越多越好，能做的越多越好…但往往这样的人可遇不可求，或者都去自己创业了…
从现实角度，每个人精力有限，写代码真的不是一撮而就的事，耗费大量时间和精力在里面，能做好一件事都很难得。
工程师少，懂产品的工程师更少，我觉得现在流行的分工方式其实才更容易让团队 scale。不需要要求每个人都是所谓的全栈、万能，但每个领域都要有专家，大家取长补短，团队整体才能强大。
ps. 完全赞同楼主说的「给出一个好的问题，比直接给出具体的 solution，要更好」
hooopo
回复
感觉有些东西没写清楚，我再改改
我觉得，是对于具体的任务，需要区分对待的
对于一般的功能，比如收藏啊、退款流程啊等等，比较好梳理清楚，所以 “PM -> 工程师” 这个是可以走通的。
但是，当做比较新的功能、有创新性的东西的时候，就需要比较多的试验、原型的功夫了，"PM <->工程师/设计师"，需要不断的沟通，发现问题解决问题。这个时候，苛求 PM 没把流程理清楚，或者工程师实现速度慢，都不对。
像做 AI, NLP 的产品，我就会完全让位出来给 Data Scientist，因为希望主导方向上（技术），有尽可能多的突破。但很多 PM 还是死死的要把控项目，我觉得就把产品给做小了。
- 在其位谋其政，术业有专攻，要么怎么你是 PM. 别人不是？
- 工程师也要做设计调研测试决策，实现只是其中一个小环节，我理解的实现就是把代码写出来。
- 况且不一定每个 PM 都像你一样想听别人意见的，自负的人多着呢。
- PM 跟工程师固然要沟通，但终要回到各自的领域做具体的事。
gihnius
回复
明白了，我立意没有写好。
仔细想了想，这个标题是我对自己（pm）的提问：工程师只负责实现吗？因为感觉很多 pm 都太自负了，不愿意听其他人的建议
但是你读起来变成了对工程师的质疑…是我措辞没做好，不好意思
我看看怎么改会比较好
很简单：
- 业务主导的开发，PM 权重大于研发
- 技术主导的开发，研发权重大于 PM
两边的出发点不一样，区别还是非常大的。
第一个例子：
就像上周我司开会，要在 App 里集成运营的功能，老板是个聪明人，就一下子指出不光要有 App 运营内容展示的模块，还要有一个发布运营内容的地方。我直接把话接过来，讲到“App 上只是做到运营内容的展现，但运营是公司的业务之一，运营的闭环是产生、发布、展现、回馈，因此这里至少还需要一个用于发布运营内容的平台，才能把这部分做出一个最基本的可用的样子”。
第二个例子：
App 上要做一个 xx 综合指数的数值（姑且称为 INDEX），这个数值由几部分不同维度的数值综合而来（姑且称为 index_a、index_b、index_c...）。那么首先：
- 这个数值是给谁看的？
- 我们给受众展现这个数值，有什么直接作用？比如 360 产品的“电脑开机速度打败 95% 的用户”，比如“本周您的运动步数为 xx，在朋友圈中排名 xx%”，这完全不一样。
- 我们给受众展示这个数值，有什么长期目的？是单纯的增加用户体验，还是为了增加用户活跃度，还是为了配合公司其他产品的活跃度/销售，还是为什么大功能铺路？
- 因此这个数值应当（或理想中）达到怎样的表现？满分是多少，分几个层级，每个层级代表怎样的含义，如何引导用户加高（或减低）该数值，会引导用户进行怎样不同的操作，等等。
- 所以，具体来说，INDEX 与不同维度综合指数的关系是怎样的：线性关系，指数关系，还是更复杂的非线性关系？不同维度所占权重是多少？
- 用户查看这个指数的场景是什么：实时更新，按小时更新，亦或是日报/周报的形式？
以上六个问题，与业务密切相关，PM 本应深入理解业务，那么回答以上六个问题也就是分内的工作，但凡抛一个给工程师，只能说明 PM 失职或者能力不够。
再接下来，如何得到 index_a、index_b、index_c 这几个数值呢？这些参数是不同业务的综合指标，因此，平均值？方差？中位数？写过 abc 三个业务的程序员应该心里有数，PM 当然更应该对业务了如指掌，也应该心里有数。所以这个问题上，达成共识是双方共同的责任。
最后，如何根据场景（周期）计算所有用户的 INDEX、页面展示、小数处理、各个环节之间的依赖与异常处理等，这些都是工程师要做的东西，没话说。
第三个例子
数据产品、人工智能产品（如 Siri、Cortana、小冰）、框架级别的产品（墨刀、Matlab）乃至当年的 OS360，至少以现在的标准看，这些东西都应该自始至终由工程师主导。
以上，请楼主仔细思考。
我能感受到楼主的困惑，但我也觉得楼主把问题想简单了。
高度概括实现一个产品的流程，就三部分：业务设计，（基于业务的）工程设计，工程实现（包括测试）。这三个坑，不论是 PM 还是工程师，不论是怎样的 PM 或者怎样的工程师，敬请对号入座。
PS：我是一名工程师。
cqcn1991
回复
我上面所说的，是我对 PM 和研发的职责划分。我能在一定程度上做好自己职责之内的事，但 PM 那边做不到、又管不了，这是我这边的问题。