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

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

“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

共收到 15 条回复

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
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册