因收到Google相关通知,网站将会择期关闭。相关通知内容

12 技术、产品、业务三方关系?谁水平高听谁的

极客时间:我发现技术人和业务人思考问题的重点常常是不一样的,比如 CEO (更多指非技术出身的CEO)或者是销售、运营同学经常会觉得业务起不来,技术再好也没用。而工程师会觉得,不管业务怎么样,我技术要去做好。为什么会有这么大差别呢?

汤峥嵘:公司里面不同部门都有不同的看问题视角。每个人站在自己的位置上,就会无限放大跟自己相关的东西,因为他要实现自己的目标,这就是主观性。就比如你情绪好的时候,你看到的天就特别蓝,心情不好的时候,就觉得今天好像哪里都不怎么样。

具体来讲,业务人关注的就是业务量,因为他看不出你的技术到底能给他的业务带来什么价值。技术人呢,他们会说:没有技术拿什么支撑业务?当然应该把技术做好了。这种视角上的差异很正常。

极客时间:这两种不同的思维一定会导致二者的沟通合作出现一些问题,具体可以怎么协调呢?

汤峥嵘:关键是找到一个第三方作为“桥梁”,把这两端打通。我觉得这是 CTO 的一个很重要的职责。我们要花很多精力去跟业务人明确问题,然后协调解决问题。在快速变化的公司里,能力强的技术人员是有能力把业务上的一些问题先整理好的。不过现在的互联网公司里,这部分责任往往会跑到产品经理身上。

极客时间:业务、技术,再加上产品经理,这就成了三方协作的问题了。

汤峥嵘:对,因为产品经理恰恰是业务和技术中间的一个特别重要的桥梁。产品、业务、技术就是三角关系,一个常见的说法是“三角形是最稳定的结构”,其实对应着这三方,这个结论是不成立的。也就是说,产品、业务、技术这三方并不是在所有情况下都能形成一个良性的制衡关系的。

那实际情况是啥样的呢?我们就把这三方具像化成三个人吧。我认为,这三个人谁水平高,另外那两个人就听他的就这么简单。

比如说,如果三方关系里有一个大牛级的产品经理,那什么也不用说了,另外两个人肯定都听他的。业务人会说:你太厉害了,你做出什么产品,我就卖什么东西。就像乔布斯做出 iPhone,产品好绝不愁卖。技术这一方也是,产品经理说什么需求,他就做什么需求。这样,技术人和业务人就都能做好自己的事情,这三方保持稳定状态。

但是,如果产品经理很弱,那业务人和技术人肯定就会吵架。业务人会觉得技术不行,技术人会说产品讲不清楚。这种情况下,我们就没有一个稳定的平衡点。所以你看,产品经理这个位置挺关键的,但优秀的产品人确实特别少。相对地,优秀的销售(泛指业务方)和优秀的技术人很多,因为这两个相对来说能力要求比较单一。

极客时间:看来在业务、技术、产品这三角里,产品经理起的是很关键的支撑作用,对这个结构的稳定性影响很大。也正是因为这样,这个三角很容易不稳定?

汤峥嵘:对,因为优秀的产品经理很难找,所以,我在途牛和 VIPABC 当 CTO 的时候,都坚持要把产品经理放在我们 CTO 的管理线上来,相当于让产品听我的。因为我认为自己是一个能够打通技术和业务两边的人。

如果分成三个部门,产品肯定有他们自己的分法。最后就变成什么样呢?这个三角结构在更高层的管理上更要打架了,因为相当于有三个强势的人都在指挥。

我在途牛和 VIPABC 当 CTO 的时候把产品放到我这,就是为了减少三方带来的不稳定因素。但是我们的组织结构也要求 CTO 得有产品能力。

我的做法是,把技术团队统一归成产品加开发。这样,我下面的技术 Leader 有可能是个技术经理,也有可能是产品经理。因为产品技术关系更近,产品和开发,都是“做东西”的人。它就是要做出个东西来,让业务方拿去用。

打个比方,我们做出一个杯子来,业务方拿去卖。做杯子,从设计到开发,再到生产,这都是一系列的技术。我觉得它们本质是一样的,区别无非就是我们“杯子”的设计是产品经理做出来的,具体的“制作”是技术团队写代码写出来的。

极客时间:除了你说的这种把产品和开发放一起管理的模式,是不是也有把产品放在业务那儿管的情况?

汤峥嵘:我知道很多公司是这样的模式。业务人是老大,下面有一个产品、一个技术向他汇报,这时候就变成业务为主了。如果这个业务老大对技术是很有感觉的,这样绝对就 OK。

淘宝为什么后来发展得那么好?我认为和陆兆禧做了淘宝 CEO有很大的关系。一方面他自己做过销售,很懂业务,另一方面他对技术的人是非常喜欢的,他就不停地提拔技术人出来做业务负责人。三丰(姜鹏)、行癫,一开始都是技术人,都是后来成了业务负责人的。三丰后来变成了淘宝的 CEO,行癫变成了淘宝的 COO。

行癫负责淘宝的业务对淘宝的快速增长影响很大。我觉得,主要还是因为行癫确实是对整个淘宝的架构特别熟,而且淘宝的业务他从很早就了解甚至参与了。等他全面负责淘宝、天猫、聚划算之后,就很清楚应该做什么事,以及在哪些方面可以重点投入。这就是业务是三方中的老大,可以驱动产品和技术的情况,我认为这种状态是最良性的。

因为产品和技术都觉得,我们老大还挺靠谱的,给我提的需求也好做,做完了马上就有效果,肯定就跟着他做。但如果是一个完全不懂技术的人当业务老大,提了一大堆需求,其他两方做不完,产品和技术的人这时候可能变成一伙了,合起来去跟业务人对抗。

极客时间:这个例子很好理解。我的理解是,这种情况下就要求业务负责人的综合能力是比较高的。那在你待过的组织里,技术人会向业务方汇报吗?那产品经理呢?

汤峥嵘:是这样的,我的组织里技术人是会向业务汇报的,产品经理呢,就放在我的技术团队里。比如说做跟团游,技术领导人可能是个产品经理,也可能是个技术经理,他下面有产品和技术(我每个团队下面都是有产品和技术的),这个人就相当于跟团游的 “CTO”了。跟团游的业务方完全不负责产品,有需求就找产品经理。所以产品经理就是要负责天天去跟业务沟通。

我不建议把业务、产品、技术作为三个独立的团队。我也在这样的组织中经历过,觉得这三方特别容易吵架。我一直认为,在一个快速发展过程的公司里,不适合搭出一个四平八稳的架构。你的架构可以是有缺陷的,但是它也得有个长处,来支持你快速增长。最后你想快速发展,就是大家(三方)一起拼命奔跑,谁在跑的过程中领先了,跑的姿势还好看,他就突出出来了。到最后你会发现这个人真的很关键,他一个人的能力高低会影响一大半人。

极客时间:前面我们聊了技术、业务、产品这三方的关系和组织划分。看来不管怎么划分,都是为了跑得快,公司能发展更好。

汤峥嵘:我们的体系要做的是去给员工赋能,而不是束缚我们的员工。我觉得很多做技术的人特别喜欢定规则,他们自认为规则很好,但是这些规则常常反过来变成束缚了。

就比如说写文档这个事儿吧。通常的规则是这样的:每做一个产品,大家开个会,从 PSD(产品详细说明文档),再到更细的功能需求,再到开发,再到测试,是要写一系列文档的。在公司里我就跟大家说,尽可能少写文档。你说你辛辛苦苦写了个一千页的产品需求,就算你不累,看的人累不累?有这时间,就把产品、开发、测试的三个经理关在一个房间里讨论,讨论到三个人都同意了才放出来,这个事儿就成了。讨论过程中,开发人员知道怎么开发了,测试人员也知道怎么测试了。你们觉得该补的一些核心文档,后面补一补就行了。因为市场变化太快了,等文档都写好了再讨论,肯定后面又得调整。

我自己特别不喜欢看需求文档,而且大家应该都觉得看文档挺累的。国内的情况跟国外还不一样,外国人就是觉得写个文档出来很清晰。但是我觉得国内大部分人都没经过这么好的训练,还是习惯直接沟通。

还有一个关键点是,有时候最核心的东西业务同学自己也没想清楚,辛辛苦苦做了这么久的文档,业务明天就推翻了重新来一遍,这不是浪费吗?我觉得比较合适的方式是,快速做出一个东西来,然后就拿上去试一试,不行就放弃。就是要快速试错、快速迭代,东西粗糙不要紧,关键是能让公司快速跑起来。

极客时间:快速跑的模式下是不是出问题的概率也大?

汤峥嵘:只要做东西就容易出 Bug,所以必须得在效率和错误率之间找到平衡。我那时候会实时盯着大家的这些 Bug。一个产品刚上线的时候流量不大,出点问题就出点吧,业务可能觉得影响不大,速度快可能比这个 Bug 率更重要。但是如果Bug会影响业务,刚上线就出了一大堆 问题,那肯定会被被业务投诉。所以这些都是需要技术和业务两方提前商量好、说清楚的。

这里有个前提,就是技术团队修复Bug的能力要强。这个能力其实对技术要求挺高的。比如需要实时监控的能力。我经常讲,优秀的技术团队要能比用户先知道系统问题。我们用真实的一小批用户试错,等到大规模用户来临前,我已经把Bug修好了。

我们技术人容易踩一个坑,就是沉浸在技术当中,又想做得快,又想做一个很好的东西,这确实成本很高,很难达到。但是用这个视角看问题,就很容易不清楚业务的需求。技术跟业务的关系是啥样的呢?用打游戏来打比方的话,业务和技术是打配合的。业务人员说今天要把刀,技术人就得今天扔个刀给他。技术人先不要想做一把多厉害杀伤力多强的刀,业务的人可能也不 Care 这个,他们就是想要把能用的刀,能大概砍几下就行了。

那厉害的产品经理牛在哪儿呢?他跟业务的人聊完之后,就能明白在这种场景下业务真正的需求是什么样的。比如飞镖有时候就比刀的效率高,可能一个飞镖一下就能杀死十个人,产品经理就能说服业务方,其实飞镖更适合你。这时候业务的人才恍然大悟:还有这个玩意,挺好,我们要的就是这个。厉害的产品经理就是这样,需求看得很准。

所以,业务、技术、产品确实相爱相杀,在一个快速发展的组织中如果有哪一方很牛,能纵观全局,带着另外两方向前跑,结果还不错的话,我觉得这就是比较好的协作模式。

互动时间

你目前是在业务、技术、产品哪个团队?欢迎你聊一聊和协作团队相爱相杀的故事。