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 这个，他们就是想要把能用的刀，能大概砍几下就行了。

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

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

互动时间

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

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e8%b6%85%e7%ba%a7%e8%ae%bf%e8%b0%88%ef%bc%9a%e5%af%b9%e8%af%9d%e6%b1%a4%e5%b3%a5%e5%b5%98/12%20%e6%8a%80%e6%9c%af%e3%80%81%e4%ba%a7%e5%93%81%e3%80%81%e4%b8%9a%e5%8a%a1%e4%b8%89%e6%96%b9%e5%85%b3%e7%b3%bb%ef%bc%9f%e8%b0%81%e6%b0%b4%e5%b9%b3%e9%ab%98%e5%90%ac%e8%b0%81%e7%9a%84.md