瞎扯淡 工程师只负责实现吗?

cqcn1991 · 2017年03月11日 · 最后由 a0nqm 回复于 2017年03月12日 · 2384 次阅读

“PM 把东西想好,然后工程师实现就行了”,似乎是目前的常态

我觉得这样不太好(我是 PM),所以写了这篇,也不知道对不对,希望大家可以指点一下


适合读者:创业团队,开发效率低,总改需求、出错;合作氛围差,经常撕逼、互相甩锅

1. 被问懵逼的 PM

目前国内常见的做法,是 PM 把所有东西想好,然后告诉工程师怎么做

比如一个双 11 红包活动案例

  1. 运营想做个双 11 发红包的活动,于是给 PM 发需求。
  2. PM 开始想方案 —— 用户在哪里领红包,领了哪里可看到,怎么使用,退款了怎么处理等等
  3. 然而,PM 只注意了用户流程,忘了红包谁出钱、发放规则谁来制定等方面。
  4. 于是,在需求评审的时候,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. 更好的方法?

说到这里,我觉得红包运营活动的例子,这样做如何?

  1. PM 把基本流程梳理好
  2. 运营、产品、工程师讨论,说说大概想做的东西是怎样的,怎么落实。
  3. 这时,工程师发现一些问题没考虑到,比如红包的钱谁出、规则谁定,运营也可能想到了其他的点。
  4. 针对这些问题,大家分别领任务细化落实

团队各个角色一起思考,可以考虑得更完善,也能有效利用各方所长,更有效率。像 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,要更好」

个人觉得产品流程上的决策需要由 PM 来负责梳理并描述清楚,工程师需要搞定的是功能实现的过程中技术上的决策。

hooopo 回复

感觉有些东西没写清楚,我再改改

我觉得,是对于具体的任务,需要区分对待的

对于一般的功能,比如收藏啊、退款流程啊等等,比较好梳理清楚,所以 “PM -> 工程师” 这个是可以走通的。

但是,当做比较新的功能、有创新性的东西的时候,就需要比较多的试验、原型的功夫了,"PM <->工程师/设计师",需要不断的沟通,发现问题解决问题。这个时候,苛求 PM 没把流程理清楚,或者工程师实现速度慢,都不对。

像做 AI, NLP 的产品,我就会完全让位出来给 Data Scientist,因为希望主导方向上(技术),有尽可能多的突破。但很多 PM 还是死死的要把控项目,我觉得就把产品给做小了。

到底是 pm 还是 pd 啊。。。

lihuazhang 回复

啥意思?我算 pm,product manager, 产品经理

cqcn1991 回复

哦 我理解的 pm 是 project manager。 pd 是 product designer。

  • 在其位谋其政,术业有专攻,要么怎么你是 PM. 别人不是?
  • 工程师也要做设计调研测试决策,实现只是其中一个小环节,我理解的实现就是把代码写出来。
  • 况且不一定每个 PM 都像你一样想听别人意见的,自负的人多着呢。
  • PM 跟工程师固然要沟通,但终要回到各自的领域做具体的事。
8楼 已删除
gihnius 回复

明白了,我立意没有写好。

仔细想了想,这个标题是我对自己(pm)的提问:工程师只负责实现吗?因为感觉很多 pm 都太自负了,不愿意听其他人的建议

但是你读起来变成了对工程师的质疑…是我措辞没做好,不好意思

我看看怎么改会比较好

很简单:

  • 业务主导的开发,PM 权重大于研发
  • 技术主导的开发,研发权重大于 PM

两边的出发点不一样,区别还是非常大的。

第一个例子:

就像上周我司开会,要在 App 里集成运营的功能,老板是个聪明人,就一下子指出不光要有 App 运营内容展示的模块,还要有一个发布运营内容的地方。我直接把话接过来,讲到 “App 上只是做到运营内容的展现,但运营是公司的业务之一,运营的闭环是产生、发布、展现、回馈,因此这里至少还需要一个用于发布运营内容的平台,才能把这部分做出一个最基本的可用的样子”。

第二个例子:

App 上要做一个 xx 综合指数的数值(姑且称为 INDEX),这个数值由几部分不同维度的数值综合而来(姑且称为 index_a、index_b、index_c...)。那么首先:

  1. 这个数值是给谁看的?
  2. 我们给受众展现这个数值,有什么直接作用?比如 360 产品的 “电脑开机速度打败 95% 的用户”,比如 “本周您的运动步数为 xx,在朋友圈中排名 xx%”,这完全不一样。
  3. 我们给受众展示这个数值,有什么长期目的?是单纯的增加用户体验,还是为了增加用户活跃度,还是为了配合公司其他产品的活跃度/销售,还是为什么大功能铺路?
  4. 因此这个数值应当(或理想中)达到怎样的表现?满分是多少,分几个层级,每个层级代表怎样的含义,如何引导用户加高(或减低)该数值,会引导用户进行怎样不同的操作,等等。
  5. 所以,具体来说,INDEX 与不同维度综合指数的关系是怎样的:线性关系,指数关系,还是更复杂的非线性关系?不同维度所占权重是多少?
  6. 用户查看这个指数的场景是什么:实时更新,按小时更新,亦或是日报/周报的形式?

以上六个问题,与业务密切相关,PM 本应深入理解业务,那么回答以上六个问题也就是分内的工作,但凡抛一个给工程师,只能说明 PM 失职或者能力不够。

再接下来,如何得到 index_a、index_b、index_c 这几个数值呢?这些参数是不同业务的综合指标,因此,平均值?方差?中位数?写过 abc 三个业务的程序员应该心里有数,PM 当然更应该对业务了如指掌,也应该心里有数。所以这个问题上,达成共识是双方共同的责任。

最后,如何根据场景(周期)计算所有用户的 INDEX、页面展示、小数处理、各个环节之间的依赖与异常处理等,这些都是工程师要做的东西,没话说。

第三个例子

数据产品、人工智能产品(如 Siri、Cortana、小冰)、框架级别的产品(墨刀、Matlab)乃至当年的 OS360,至少以现在的标准看,这些东西都应该自始至终由工程师主导。


以上,请楼主仔细思考。

我能感受到楼主的困惑,但我也觉得楼主把问题想简单了。

高度概括实现一个产品的流程,就三部分:业务设计,(基于业务的)工程设计,工程实现(包括测试)。这三个坑,不论是 PM 还是工程师,不论是怎样的 PM 或者怎样的工程师,敬请对号入座。

PS:我是一名工程师。

a0nqm 回复

受教!这个其实就是我想表达的

a0nqm 回复

其实就是碰到了技术主导型的产品,pm 喜欢管太多,又或者是工程师不愿意管…

cqcn1991 回复

这套思路是我最近理清楚的,还没来得及推行。要让整个团队都认同这个观点,大概会比较难。

a0nqm 回复

哈哈哈,所以其实你们也有这样的问题咯?

cqcn1991 回复

我上面所说的,是我对 PM 和研发的职责划分。我能在一定程度上做好自己职责之内的事,但 PM 那边做不到、又管不了,这是我这边的问题。

cqcn1991 理想的团队应该是怎样的? 中提及了此贴 03月17日 11:58
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册