【直播】PML 产品管理大讲堂第二期:《产品经理和研发管理体系的战争》文字稿

对于产品经理和研发体系的兄弟们之间的相爱相杀的故事已经有了很多的传说,当然,我估计这些传说都是由研发的兄弟们传播出来的,因为产品经理往往在这些传说中扮演的是一个“反派”角色。

其实在一个企业内,大家都是干活拿钱的人,哪有什么正派,反派之说,但为什么会出现这样的情况呢,今天的直播咱们就聊聊这个。

我们先来聊第一个话题:

1、PM都要和哪些研发管理体系的兄弟们打交道?

我不知道大家通常都会和研发体系的哪些兄弟们打交道,我总结了一下我的经历,大家可以看PPT1:

这些团队大家都非常熟悉,我就不一一详细说了啊,只说我认为比较有意思的两个团队:

1、设计师团队:这个呢,我说一点国外的看法,在国外,有些人认为应该把设计师团队放到产品管理体系下,因为他们认为设计师团队是为早期的产品构想提供高保证原型的,其实和产品经理接触更为频繁,而不是研发团队,研发团队应该更聚焦于产品的技术实现上。

当然了,具体如何定位设计师团队的归属,大家可以根据企业的实际情况来考虑,我重点说说一个设计师团队都应该包括哪些角色,大家看PPT2:

大家可能注意到了,我这里说的是角色,而不是职位,什么意思呢,就是告诉各位,其实在很多的公司,并没有如此豪华的设计团队配置,因此,就不得不一个人扮演多个角色,比方说,产品经理很多时候就得扮演快速原型师或者视觉设计师的角色,这也从侧面印证了一个现状,就是为什么好多互联网行业的产品经理都多少得会点原型设计,但是,我们需要清楚的是,你终究是产品经理,是做产品管理工作的,做原型或其它的设计工作,只是在特定的情况下走个穴而已,千万不要舍本逐末,当然,我们最终还是希望公司能够把相关角色配置齐全。

关于设计师团队中这四类角色的详细说明,可以看这篇文章:http://www.chinapm.com.cn/?p=4709

2、QA团队:QA,质量保证,可能有很多朋友理解QA就是确保产品最终质量产出的团队,这个没错,我想说的我们是否分析过是最终产品质量的是否合规都和哪些因素有关系呢?

我们通常能想到的主要是和产品有关的可见的要素,比方说原料质量,工艺设备,操作熟练度等等,但是我觉得其实还有一些软性的要素会影响到产品最终的质量。

比方说流程规范性、工作质量合规性等等,我来举个例子,我以前在一家公司,就有一个叫质量改进小组(好像是这名字啊)的团队,一共四个人,这个团队干什么呢,就是每天审核整个产品小组的每项工作成果,比方说,产品经理写了一个PRD,那么,他们会去审核你写的这个PRD是否符合公司的撰写要求,其中的内容是否清晰明白,是否能够让程序员看懂,如果有问题,就会打回去让你重写。

我觉得这个是有一定积极意义的,因为我们写PRD,通常是按照我们的思维习惯去写的,但是别人不一定能习惯或跟上你的思维和逻辑,因此,就必须有个第三方团队来做这个事,他们不评价和业务有关的任何东西,只评价和流程、规范有关的事务,因为在公司看来,产品的质量好坏与否不能只和生产环节有关,而是在整个流程中,每个环节都会影响到的,不仅包括可见的要素,还包括很多不可见的要素,这些,都应该纳入到QA团队的范畴中。

其实这本来就是ISO所要求的,当然,我不是太了解ISO的各种标准和要求,我只是想说,如果能有这样一个团队的话,那么势必会大大帮助我们更好的把产品做好,因为产品经理最终是要去验收产品的,如果有QA团队能够帮助我们从外围把各个环节的质量确保好,会大大节省我们自己在这上面的时间的,并且人家也专业,是吧。

说到这里,有朋友会说了,不是还有测试吗,关于这个呢,我也曾经在《YES!产品经理I》中说过这个,这里简单总结一下产品测试、产品验收和产品质保三者之间的关系和区别,大家看PPT3:

产品测试,简单来说,就是这个工作是“找问题”的,也就是说,这个工作是保证“技术化结束时产品是可以交付的的” 。

产品质量保证,简单来说,就是这个工作是“保证生产过程是符合相关指标、规范和流程的”,也就是说,这个工作是为了保证产品质量的持续稳定。

产品验收,这个工作是由“验(check)”和“收(accept)”构成的,“验”是条件,“收”是结果,正文中也提到了,这个工作是“确保产品没有问题”,保证可商业化的产品介质是符合PRD规格标准的。

这三者的目的虽然不同,但是却是相互联系的。

首先,它们都是存在于技术化阶段的,测试不用多说,验收呢,是研发管理体系向产品管理体系最终输出成果的一个关口,QA就有点意思了,常见的是把QA放到研发管理体系下的,不过这个我觉的需要再斟酌。

其次,它们都是为产品的商业化奠定基础的。

最后,它们之间也是相互促进的,QA是保障整体质量的一个工作,测试是保障技术化最终成果质量的一个工作,而验收则是技术化通向商品化的最后一道关口。

我们把这些搞清楚了,最现实的好处就是产品经理不再会到处横插一脚,惹其它部门的兄弟们不高兴,该做什么就做什么,该什么时候做就什么时候做。

不过,如果现实一时无法改善,那么,一些纷争就在所难免,我们今天不从什么流程规范了,管理制度了这些方面聊,就聊聊我们都会接触到研发管理体系中哪些类型的兄弟。

2、研发的兄弟们都有哪些类型?

就我经历的情况看,我把研发的兄弟们分为四类,大家看PPT4和PPT5:

那我们该怎么来应对不同类型的程序员呢?

我就以“技术痴狂型”这类程序员为例做个说明。

这是典型的技术人员,这种类型的技术人员天生就是做技术的料,他们对于解决问题所涉及到的技术的痴迷要远远大于项目、产品、市场本身。

他们可以花一个晚上的时间去研究如何解决一个问题,他们喜欢在技术上的挑战,喜欢采用自己在理论证实可行的方法来实践,但是恰恰忽略了他们做的是产品,是要用来为公司盈利的商品,产品只不过是提升他们实力,验证他们技术理论的平台而已。

他们始终追求的是“最好”,而不是“最合适”。

毕竟我们大部分的企业是偏重于RD中的D的,而不是R的,因此,我们的程序员们还是需要按部就班的去按照公司产品计划去执行开发任务。

这类技术人员其实就是没有给自己一个很好的定位和角色调整。

在公司,你就是程序员,就是按照公司计划和安排去做技术工作,在工作之余,你花多少时间去研究新技术,新应用,都是可以的。但是一定要知道角色的转换,每天早上打完卡,你首要考虑的就是“我今天要做PRD中的那个功能?还有多长时间项目结束?”,而不是去用连自己都不确定的思路去做项目。

因此,对于这种类型的技术人员,应该用“借刀杀人”的方式来让他按照时间安排来做。

例如可以这样说:

PM:这是用户提出的要修改的一个地方,你看能做吗?

Looking……

程序员:我觉的这个地方有些问题呀?

PM:哪里有问题?

程序员:你看,这个地方我觉的这样做不合适,应该……

开始讲解他认为最好的方法。

PM:那如果按照你认为的方法做的话,需要多长时间呢?

程序员:我也说不好,这种方法我没用过,不过我可以试一下,这样吧,等做完了,我通知你吧!

PM:这个问题是用户非常急迫要求修改的,我必须知道一个确切的时间,否则无法向用户说明。

程序员沉思中

程序员:好吧,其实有种方法也可以实现,今天下班前我尽力做完,做完了,我通知你。

……

为什么要用“借刀杀人”的策略呢,因为技术痴狂型的程序员之所以敢怼产品经理,其实很大程度上就是欺负好多产品经理们不懂技术,于是就给我们一个让我们无法回怼的场景,但是,这种类型的程序员敢怼我们,但是通常不会去怼客户,因为他们也知道,得罪了客户,尤其是大客户,这就不是向产品经理交待的问题了,而是要向全产品团队,甚至公司交待的问题了,因此,用客户这把“刀”来刺一下他们是能够让他们意识到,你再好的技术也是为市场,客户服务的。

在我发的产品经理的42个原则的第33个原则中,就是在说这个,结束纷争的最佳方式就是让客户来结束,而不是我们自己,当然,前提是你必须有真实和可靠的客户反馈来支撑你的任何观点。

关于其它三种类型的程序员该如何应对,大家可以看这篇文章:http://www.chinapm.com.cn/?p=991

当然,我们都知道,在开发项目中,我们打交道最多的应该就是项目经理了,因为整个开发项目的进度、质量、成本都在他的管理之下,因此,我们要通过和项目经理的协作关系,来确保开发项目是按照我们定的产品计划执行的。

不过,我也知道现在很多产品经理在项目开发中,同时也扮演这项目经理的角色,如果今天有这样的同学,可以歇会,去个厕所,喝个茶,打盘游戏,一会我喊进入到下一个话题的时候再回来啊。

说到产品经理和项目经理的关系,我必须得说说我曾经经历过的一件事,这件事或许会让我终身难忘。

2006年的时候,那是我做产品经理第六个年头,在一家旗帜型的web2.0的公司,当时公司要开发自己的原生产品,以前用的是开源的,所以公司非常重视这个产品,整个团队配置算是比较豪华了,差不多50人了,其中负责开发这块的就是一个搜狐过来的项目经理。

尽管我那个时候已经做产品经理六年了,但是放到当时的环境中,还是属于比较冷的一个职位,因此,在当时的团队中,基本上就是只知道项目经理,不知道产品经理,普遍对产品经理的认知就是设计功能,写文档的。

我记得有一次,有个程序员没按照我的PRD去做,关键是做完了我才知道,就说产品经理再没地位,但这是赤裸裸的打脸啊,于是我就找那个项目经理讨说法,但是,让我没想到的是,这个项目经理只是瞟了我一眼,然后只说了一句话:这个没必要告诉你。

然后就没有然后了。

咱们这是语音聊,要是现场聊的话,我就把当时项目经理那眼神,那语气,那种不屑演给各位看。

我这小脾气哪能受的了这个,于是就告诉了我们产品部的老大,我和他的私交非常好,这位老哥可是个人精,现在是阿里云的高管了。

至于最后怎么处理的,我这里就不说了,反正也是一堆扯皮,扔锅,不过最后还是解决了。

我想和大家说的是,这位老哥在事后告诉我的如何和团队处理关系的一些方式,今天我也和大家分享一下。

1、摸:什么意思呢?就是说如果你刚到一家新公司,人生地不熟的,那么,没事的时候就到各个部门转转,不是瞎转啊,两个目的,第一个目的,把自己推销一下,告诉各色人等,我是公司新来的产品经理,以后的工作就多仰仗大家的支持了,姿态低一点,让人家先对你有个印象,要不,团队成立起来了,好多兄弟开始纳闷了,这货是谁啊;第二个目的,通过和各个部门的人的交流,大致摸清楚哪些人好打交道,哪些人不好打交道,这些人在部门内都是啥情况,是核心员工,还是一般员工,这样做的目的在于,一旦在后续的工作中出现啥情况,你就知道从哪个人身上能够找到突破口,还有就是你可以大致知道,面对不同脾气秉性的团队成员,你如何更好的和他们交流。

2、促:摸的工作完成了,那么,接下来要做的就是如何逐渐的和他们建立起于公于私都需要的良好关系,尤其是私人关系,这里强调一下啊,我说的不是拉帮结派,搞自己的山头,我个人也非常厌恶办公室政治,而是在各个部门结交几个三观相符的兄弟,怎么结交呢,其实也没啥高大上的方式,一起抽抽烟,一起聊聊天,一起聚聚餐,打打游戏,扯扯淡啥的,就算最后不能成为真正的朋友,但是肯定要比只是点头打个招呼要好多了,对吧,其实各位可能不知道,我这人是个内向的人,但是现在各位感觉我就是个话唠,全是这样聊出来的。

简单说,就是在第二步中,我们根本的目的就是促进我们和其它部门兄弟们之间关系的由远到近,由生疏到熟悉,由从制度下的工作到共识下的工作。

3、帮:私交有了,那么,对咱们的工作有啥好处呢?那天老刘在群里提了一个问题,说新产品发布了,但是销售们都不愿意去销售新品,怎么办,我的建议是通过自己在销售部里关系不错的几个哥们,先让他们去销售,然后我们尽力支持,把标杆竖起来后,其它的销售就逐渐有信心了,也就是说,新品销售的从0-0.5,步,还是得靠玩的来的兄弟们帮助咱们。

我以前就是这么干的,经常是新品发布之前,我就会提前和几个不错的销售的兄弟打招呼,新产品来了啊,是哥们我负责的,以后出去销售产品的时候,要多照顾一下新产品啊。

当然,这都是基于私人关系的一种非正式的互助,同时,帮助也是互相的,但前提是绝对不能违反公司的纪律,否则就是越界,大家都会有麻烦的。

以上说的这三点,都没有多么高端,也提升不到什么团队管理,人际关系这样的理论高度,完全是我们这些草根产品经理一点点摸索出来的,只提供给大家做个借鉴,具体方式方法个人把握啊。

有时候我就在想,都说产品经理要成为产品的领袖,而不是领导,那么,领袖和领导的区别在哪里,我觉得是这样的,领导是自上而下的一种权力安排,下面的人不是听你的,而是看在权力的面子上不得不听你的,而领袖呢,则是自下而上的一种权力信任,权力来自于下面的人对你的认可和主动赋予,因为他们相信,跟着你不会有错的。

你怎么让下面的人相信你,信服你,不去走进他们,和他们打成一片是不可能的。

再回到我说的这个和项目经理的案例中,后来我就开始按照老哥告我的去做,慢慢的,我和项目经理的关系就融洽多了,他见了我也有笑容了,没事的时候就一起抽抽烟,聊聊产品的事,毕竟产品经理和项目经理在具体的项目阶段中关注点是不一样的,咱们想的是这个阶段做不好,就会影响下一个阶段,而项目经理想的是,在预算,时间确定的情况下,怎么按时按质按量的把活做出来,他们不会考虑后续商业化、市场化的事的,因此,两个PM有时间的收多交流交流,各自说说自己的难处和想法,是有好处的。

说完了这两个PM,咱们再说一下另外两个PM,是什么呢,就是今天的第四个话题:

4、两个或多个产品经理之间的摩擦如何解决?

看到这个子话题,可能有些朋友觉得产品经理之间怎么可能有摩擦呢,都是一个战壕里的,同吃同住同劳动,就算是有摩擦,顶多了也是私人恩怨上的,我说了,咱们无论是文章、课程或是直播,不会讨论这个方面的,我说的就是工作上的。

我来举个例子啊,还是上面提到的那个案例,当时我们那个产品团队是双产品经理制,我负责产品的后端,还有一个产品经理负责前端,我就以刘指代了,因为当时那个产品比较大,也非常重要,公司怕我们一个产品经理玩不转,于是就有了这样的安排。

尽管有前后端产品经理之分,但是不交流肯定是不行的,毕竟产品是一个整体,要是各干各的,肯定会出问题,一次,刘看了我做的原型,就指着一个地方说,这个地方怎么能这样做呢,不太专业啊,我当时心里就有些不痛快,心想,专业不专业,也轮不到你说啊,但是咱脸面上得过得去,于是就和他聊他的建议是什么。

在经过沟通后,我才明白了,之所以产生这样的分歧,是因为他一直是做C端产品的,而我之前,在互联网产品这块,是做B端的,而C端产品和B端产品在整体设计思想上是有一定差异的,因此才造成了这样的不同见解。

这是一种情况,属于产品经理因为以往经历的不同而才产生的摩擦,没有触及到各自的根本利益,很容易解决的,比较难解决的是第二种情况,就是产品经理之间形成了一种真正的内部竞争,而这种竞争的目的是为了各自的利益。

这是为什么呢,其实这是由产品管理体系的直接目的决定的,这个直接目的是什么呢,是通过一种内部竞争的形式,为企业找出最有市场活力和价值的产品,从而让企业有限的资源得到合理的配置。

那么,既然是产品间的内部竞争,那么,每个产品的负责人,也就是产品经理,自然就会有摩擦了,而这种摩擦就不是第一种情况提到的那种无伤大雅的形式了,而是对企业资源配置上的一种争夺。

说到这里,或许有些朋友就有体会了,没错,就是这样的,比方说,你现在负责的一个产品,而另一个产品经理负责的那个产品因为要赶工期,但是人手不够,于是就要从你的产品团队中临时调几个人过去,那你是愿意还是不愿意呢?肯定是不愿意了,人一调走,你的进度就会受到影响,并且,也不代表着另一个产品就会有效率,因为你的人过去,还得熟悉对方那个产品是什么,我以前在一家公司,就是这样,我的开发团队一共就四个程序员,但是为了当时公司一个要力推的安全产品,就时不时从我这个团队里抽人,但是我这个是翻译类产品,完全类型不一样,于是,我这边的兄弟过去,还得先了解安全产品怎么做,然后才能开始上手,最惨的时候,我这边就剩下一个程序员了,当然,也不能再抽人了,再抽的话,我就可以回家歇着了。

但是,这还不是最糟糕的,糟糕的是,那边的忙帮完了,再回来做一段时间原来的产品,还得先了解进度走到哪里了,因为尽管只剩下一个程序员了,但是进度还在走,于是经过这么几次后,我实在忍不住了,就和那个安全产品的产品经理抱怨,不能再这样了啊,再这样的话,我可要急眼了。

当然,我也知道,别说抱怨了,你就是动手都没用,因为每个产品经理只会站在各自产品的利益角度去想,

我说这些的目的是什么,肯定不是给大家讲故事了,而是想和大家共同探讨一个更为高端一点的话题,就是未来的产品管理体系该走向何处。

我刚才说到的那个情况只是目前产品管理体系中出现的一个问题,就是:

产品经理之间竞争有余而合作不足。

除了这个,还有哪些问题呢?大家看PPT6:

因此,大家现在应该明白我的意思了吧,尽管今天聊的第四个话题是产品经理之间的摩擦,但其实反映出来的是产品管理体系在当下表现出来的一些不足,而这些不足如果没有一个好的策略去解决,无论是企业,或是个人,都会受到极大的影响,在前几年的时候,国外就有一种声音,认为产品管理早已落伍,该退出历史舞台了,但是有些人不这么认为,通过共同的努力,在不断优化和完善产品管理体系,我想,咱们这些中国的产品管理人是不是也应该做些什么,这是我真心希望的。

有危机才有挑战,可能对于我来说,因为是专门做这个的,因此,在产品管理体系如何迎接未来挑战上想的比较多一些,但是我现在也感觉有些吃力,因为毕竟个人的能力和精力就这么多,因此,我才希望大家能一起参与进来,共同来做这个事。

同时呢,我也特别希望大家能够不要只站在产品经理这个职位上来看待我们的工作,最好能够站在产品管理这个体系上来一起探讨如何做的更好,其实,单从一个职位来说,研究头不大,这方面的资料也非常多了,但是,在国内,研究产品管理的,真的太少了。

今天咱们聊的内容比较多,先布置第一个作业,针对以上提到的目前产品管理体系面对的挑战,大家会如何来考虑解决方案呢?

这个作业可能有点大,没事,咱们畅所欲言,我也可以从大家的智慧中吸取更多的养分,先谢谢大家了啊。

最后呢,咱们就讲一下附赠的那个小话题,如何科学的确定竞争对手。

这个就不占用大家太多时间了,直接看PPT7:

这两种方法是比较容易使用的一种定性的方法,其实还有一些定量的方法,比方说通过消费者在一定时间内的品牌转换率的分析来识别竞争层次,这被称为是客户购买行为分析法,这种方法特别适用于C端产品,尤其是竞争非常激烈的市场中。

这种方法思路上很简单,难在哪里呢,难在需要一个非常强大的数据系统以及分析模型的构建,这个有时间了,咱们可以聊聊,不过直播就肯定不行了,我写篇文章大概介绍一个思路。

好,今天的直播咱们就到这里,现在布置第二个作业:

1、在介绍的两种定性的竞争对手确定的方法中,你能否看出有哪些局限性?并提出你的想法。

2、基于你现在负责的产品,选择两个方法中的一个,试着确定一下你的产品的竞争层次是什么样子的。


扫码进入直播间进行回听

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址