【51CTO.com原创稿件】关于 CTO，我的看法是：一个小公司，或者是一个业务明确的公司，或者一个业务单一的公司，核心的工作是技术的把控能力。
如果是一个不断有新业务产生的综合业务型的公司，CTO 应该加强中央式的技术控制。在大型企业中，CTO 更多的是把握公司前进的技术方向，把握公司所有的产品技术架构，并做集中式的管理决策。
技术团队的核心目标是什么?
在搭建技术团队的时候，我的观点是：做技术管理跟做一般的人员管理完全是两码事。如果你不了解这个业务和这个业务本质或产品技术的特点，又没有架构能力，那么你想在这个单点上去完成技术管理是很困难的。
首先，你怎么去分配任务?怎么把工作合理地分配下去?让各个团队的工作量差不多，同时他们又不至于去做无用功?只有具备基本架构能力，你的团队管理才谈得上走上正轨。
有些老板认为只要给出目标，然后不断地去给团队施压，就能把目标给压出来。我很遗憾的告诉大家，技术团队是压不出来了，你如果给大家的分工不明确，或者不合理，就靠给大家一个目标，不断地去问为什么没有完成，结果一定会令你很失望。
其次，目标完成了怎么去分配成果?就是分钱的时候怎么办?如果你不能理解技术上的困难，仅仅以谁的产出多来评价。
而且你本身不了解他们在这种创新过程中遇到的难度和实际做了哪些事情，完全以结果来评价的话，你***会发现，谁干得越多，谁想的越远，谁的评价就越吃亏。
所以，从这两点来看，我认为不存在一个不懂技术架构就能把技术管理好的机会。我们知道亚马逊创始人 Jeff Bezos 说过一句话：“一个***的团队用两个披萨可以喂饱”。
我对这句话深信不疑，但是在今天的技术管理方向上，很多人忘了这一点。
比如说在中国创业公司，技术人员的规模普遍要超过美国同等的创业公司，而且还超过很多，但是不见得它的产出就高。
比如说一些国内互联网巨头的广告团队有多少人?基本都是在三位数，甚至有的超过了四位数。
但真的有必要吗?我觉得大家要好好考虑这个问题。原来我带的一个团队成员，现在在管理公司负责产品，我们也沟通了这件事情，他***的苦恼是这么多产品经理到底让他们干什么。
所以，我觉得讨论技术管理还要回归到事情的本质，你在打造一个技术团队的时候，能不能自己想清楚?
如果你自己想不清楚，没有办法用两个披萨以内的团队把它解决了，那我建议你再想一想。不能说我们还没有想清楚就搞起来，然后不断地加人，***实现的效率却很低。
尤其像重逻辑的商业产品，不客气地说如果你的团队到了 400 人以上，一切东西都是失控的，因为它已经没有办法很灵动地去实现那些创新了。
因此，在打造一个团队之前，作为技术 Leader，这也是所有人都要思考的，你要想清楚你的产品团队在相当长的一个时期之内应该是可以被两个披萨喂饱的。
如果你想不清楚这一点，在团队成长的过程中，你一定会不断地去加人，而且越加越坏。很遗憾，是你自己还不合格。
如何定位核心产品?
商业产品的特点是在本质上要比用户产品好做，因为它重逻辑，重数据。有一本书叫《增长黑客》，里面对用户产品的一个论点是，用数据驱动去优化和打造一个用户产品，我个人并不是完全支持。但是，对于商业产品来说非常的理性，就应该这么做。
理解产品范畴
所有的互联网公司都有商业产品，都有变现、数据和 CRM。在建立团队之前，你要搞清楚产品范畴。
比如说在一般的商业产品中对商业模式的探索，商业模式在哪?怎么把钱挣到?怎么在产品里把它孵化?这是商业产品最最难的任务。但是，在产品范畴里最常见的是流量和数据的变现。
另外，如果你有多项商业产品，例如广告产品、游戏联运、CRM 等，这些产品之间的内在逻辑是什么?怎么样统一建设和运营一个整体的商业产品体系?这些都应该是商业产品负责人在一开始就要有认识的。
如果一开始就没有想过他们的内在联系，总有一天你会碰到很大的麻烦。他们之间的利益冲突和他们之间的有机配合关系要一开始就想清楚。
所以，***步是理解产品范畴。
找到核心产品
无论你的产品范畴多大，总有一个核心的产品要达成。在你的脑海里，只要有一个逻辑的蓝图，就可以一块一块往上拼。对于商业产品体系，核心的产品任务就两个：流量变现和数据变现。
流量变现就是自有流量 RPM 水平的提升。数据变现就是搭建数据体系，用数据去提高流量变现的结果，使得收入在流量的基础上进一步的增加。这是两个基本的任务，你要把它想清楚。想清楚以后，产品就要围绕核心人物展开了。
但是，你的脑子随时要知道一个全貌，让这个全貌能及时的往核心版块上面去拼。在我们把这些问题想清楚以后，会发现商业产品设立的一些基本原则。
商业产品一般是面向商业客户而不是一般用户的产品，最典型的是广告产品。商业产品与用户产品有什么区别呢?
首先，它有隐性的产品存在。用户产品大多数的工作是在做收集需求，写 PRD，设计原型，然后去优化用户体验。
商业产品很大的工作是在做背后看不见的策略，比如说用户的标签应该怎么做?跟别人的数据对接和交换模式是怎么样的?排序应该是怎么样的?直观上看不见的产品会占一大部分。
要把这个任务想清楚了，开始就要有这个认识，否则发力就发错了，因为这是商业产品最核心的东西，它的关键不仅在于前台的用户体验，还要有整体观。
如何利用数据?
在商业产品的运营上强调的是用数据让运营和产品形成闭环，就是指导大家利用数据的策略。
《增长黑客》这本书里有一个例子，是说 Facebook 是怎么用数据优化页面的布局，比如 Facebook 的首页要做一个改版，然后它把新版做上去，通过实验框架切一部分流量出来，比较这两个哪一个结果好。
这个方法论，商业产品里非常成熟，每一件事都是这么做的。但是对用户产品，我个人觉得不对，Facebook 的首页近三年以来一直都没有改动，你觉得这个结果对吗?
我个人觉得不很对，杂志改版，每一次改动一定要达到什么目标。过一段大家熟悉和适应后，它会从理性的数据上达到一定的新高度。
也就是说，用户产品本质服务的是终端用户，这个终端用户选择用户产品的时候是感性的，换句话说他不是一个理性思维的状态。
大家知不知道 Zynga 这家公司?这是前两年很火的做社交游戏的公司，曾经 Facebook 里前五名的游戏都是 Zynga 做的。这家公司的绝活是什么?为什么能比别人做得好?
实际上它就是数据运营做得好，所有的东西都是数据驱动，所有的产品经理不断地做 A/B 测试。结果，突然有一天，这家公司发生了严重的沉沦。原因就是靠数据是发现不了创新和突破的，真正新的模式出来是要靠想象力的。
所以，我个人不同意用户产品的运营要完全盯着数据走，对一个普通的产品经理，这可能是一个正确的策略，我都拿数据给老板看，这个数据不行就不上，每一次决策都是理性的。
但是，对于整个产品的发展来说，它一定会走向一个死胡同，如果你不能跳出这个 Local Optimum，而全部用数据来优化，你是不可能优化出伟大新产品的。
但是，商业产品不一样。拿广告来说，我们的目标千年不变，就是系统的利润。商业产品本身是理性的，跟用户产品有本质的区别，所以你就要抓住这一点，在整个产品体系里面体现出重数据、重策略的状态。
如何建立产品团队?
建立产品团队其实很简单，但是人要找对了。
灵魂
***，它的灵魂是一定要有数据思维的人，而不是有设计感和强用户体验能力的人。
举个例子，Google 的 GA 并不好用，但为什么这么多人在用?很简单，你用它就能挣钱，只要能挣钱，就算再难用别人也会用。所以，数据是优先于用户体验和设计的，你要找到这样的人来塑造你的产品。
当然，商业产品还有一点是***有技术背景的产品经理来做，没有技术背景的话，在深入理解策略的时候会有很大的困难。
比如说我们排序要讲 Second Price，检索的时候点击率模型应该用 Feature，如果对技术完全不能理解，这样的产品很难在商业产品上做好，容易飘着飘着就飘到优化用户体验上去了。只有找到这样的人，产品团队才能快速地建立起来。
具体的产品有两大类，一类是平台型，一类是策略型。平台型的当然是说所有对外接口，包括登录、投放广告、看报表，也有一些像 SDK、API 这种。策略型的是收集和分析数据，并且确定策略的方向。
有很多特别生动的例子，比如像 Facebook 广告平台的 OCPM 功能，这两年做得很成功，这样的策略产品才是真正起到核心驱动作用。
所以只要找到人，对一个中等规模的广告产品来说，两到三个产品经理是完全够用的，多了以后反而更发散了，大家不能聚焦。
开发
第二，开发。广告系统为什么很难做?它基本上是所有互联网应用中并发数***的。
比如创业公司做一个广告平台， DSP 接的流量要接多少?一天一百亿次，这都是起步。但是用户产品什么时候能做到一天一百亿?几乎不太可能。
所以，广告系统看起来很难。但是，实际上我想告诉大家，其实非常的简单。技术团队依然要深入理解问题的本质，才能用比较小的团队，比较低的成本快速地搭建起来。
比如一个广告产品的系统，非常庞大，非常复杂，有很多的模块，涉及大量的算法、检索、数据流转和离线的分布式计算、在线的分布式计算等。
首先，结合任务，在你脑子里要有个全貌，在产品上你要知道你的标尺，在技术上你要把图画得非常清楚，然后再把它分解下去。然后，根据业务去删减，去抓住关键任务，这样整个任务分工和工程进程都会大大地加快。
除了脑子里有全貌，还要知道关键特征，要结合业务了解系统的关键特征是什么，有几个关键的特征必须把它摸清楚。
首先，它的要求是高并发、低延迟，这是很难做的。高并发一天一百亿，延迟也得低，因为每一次广告，100 毫秒，这是硬限制。
比如你的算法很复杂，处理一秒就可以解读出一些东西。比如你在上一个算法的时候，如果这个算法很复杂，那么它带来的效果好也用不上，因为在线计算时间如果超过 100 毫秒，那么，在很多的广告系统中，它是没有用的。
其次，系统中***有挑战的一点是，数据处理的规模极大，广告推荐的是对用户环境和信息三元组上的处理，本质就特别困难。
像搜索，它是一个二元组，SearchKeyword 和 Document 是一个二元组。而这是个三元组，而且用户的维度又特别大，所以你会发现系统的难点和重点是在数据处理，效果提升也靠这个。
意识
第三是必须要有这个意识，数据处理的速度是远远优先于精度的。
比如我建一个模型，精度提高 1%，但是多花了两个小时跑，它值不值呢?对于广告业务来说是不值的，因为我们在对用户的性情做建模，给他投入相关的内容，你快速反馈他的兴趣，快速地用起来。
比如他刚刚搜了一双鞋，那在你的系统里面知道他要买鞋，在分钟级的时间内就能够把这个信息捕捉到，然后用起来。例如我能够非常清楚的算出他要买耐克鞋，但系统明天才让我知道，这时他的鞋都买完了。
产品和技术不分家就是这样，大家要深入到产品的场景中才能在技术上决策。所以，你在广告系统里看到的算法，除了像点击率模型和个别的环节之外，大多数情况下都不复杂。因为要牺牲精度换取速度，速度远远比精度要多一些。
特点
第四，领域的特点。有很多技术容易有一种技术上的道德的优越感，总要做得尽善尽美。这恰恰在我们这个系统里是不行的。
比如广告 1000 次的请求过来，有一次算错了也没有关系，甚至有 10 次算错了都没有太大关系。如果一开始就知道 1000 次你能错一次，你设计出来的就是按照这个一致性来做，会发现成本会降得极低。
我认为技术决策最困难的一点不在于提高性能，而在于控制成本。
就像你的任务本身有特别明确的把握，这个一致性的要求点到底是在哪里?它是千分之一，你绝不要给它做成十万分之一。那用不上，而且你的成本一下就上去了。
再比如说数据日志处理，一万条日志丢个两三条一点关系都没有。在日志处理和建模这样足够大的场景里，大体上对就可以了，它使得吞吐率和成本降得很低很低。
这些充分说明要了解系统的全貌，作为技术的 Leader，你要能画得出来，绝不能跟着 Team 一块学。特别是对强逻辑性的商业产品，如果这样的话，就很难长出一个好的系统。
技术
第五，要充分利用开源的技术。对一个新业务来说，你的价值是什么?你要搞清楚公司存在的价值。公司存在的价值是解决社区里或者市场里的新问题。
对过去已经被别人解决了并且解决得尽善尽美的问题，如果你不能利用社区的现有成果，而是所有的事情都按照自己***的方式去做，那么不管你做得好还是坏，其实都偏离了主战场。
所以，很多人来问我这个问题，就是为什么觉得广告系统几个人就可以了。实际上，真的是几个人就可以了，特别的简单。
当然，用开源软件也有顾虑，因为开源软件确实良莠不齐。我个人认为大型互联网公司和开源公司还是可以信赖的。
比如像 Google、雅虎、Facebook，他们本身首先有 Reputation 的问题，另外你不要指望现在做这个日志传输工具能比 Facebook 的 Scribe 做得好，这是因为你上哪儿去找一个测试环境。
人家对压测的测试，经过每秒 10TB 的数据，你上哪儿找?没有经过那一个测试环境，你说我代码写得好，那根本不可能啊。
我们的原则是什么?只关注核心的业务逻辑。对于广告来说，核心的业务逻辑是检索和排序，就是这点。所有的外围的东西，像我们画的图，基本上都可以用开源的架构搭起来。
这样，你所有的资源只要做投放，一个是数据处理的算法，还有就是投放的地方。我算了一下，再复杂的广告系统，五六个人是完全可以的。当然，前提是彻底拥抱开源，不要犹豫，因为你不是做中间件的公司，你是做业务的、做广告的公司。
还有一点要特别提醒大家，任何以逻辑性和数据性为关键指标的产品，大家都会忘掉实验框架。
实验框架就是怎么样建立一个非常完善的框架，让我可以分流量做测试，这些其实都有成熟的解决方案，通过 Google 的 Paper 大家都能够知道。
在执行过程中，任何一个不太重要或者不紧密的任务，如果***天把它实现了，你会发现在以后所有的时间内这个生产效率都是加倍的。凡是以数据驱动为主的，有经验的Leader，实验框架是最最关键的一个。
***，对于技术团队来讲，相关的产品经验很重要，团队的技术灵魂人物，必须要懂产品，而且深入理解业务。这样的一个架构师，能够把全貌图画出来，对产品特别的清晰，这才是最关键的。
为什么要重视运营?
运营是容易被大家忽视的。运营有两个热度，首先运营对整个全貌的一个决策能力，其次，要把数据漏斗建立起来。
运营最怕什么?如果运营人员看一个整体，看一个收入，和别人比怎么挣五块钱，怎么挣三块钱，天天盯着收入，这就没有意义，那就会不知道哪一个环节有问题。
所以对于商业产品的运营团队，我觉得数据漏斗优化能力是最关键的，当然如果具有产品思维就更好了。如果结论都出来，靠运营商的手段来解决会变得越来越累。
还有 MVP，对商业产品来说，MVP 实际的落地者就是运营人员。有一个策略，没有开发之前怎么办呢?运营会先拿手工的策略来试一试，结果好再去开发。所以，MVP 是一线的实践，非常重要。
***，作为一个技术 Leader，不管是 CTO，还是技术总监，如果开始没有想清楚用两个披萨喂饱一个团队的原则，老想着哪天我的团队变成 300人、500人、2000 人……那绝对是错误的。
团队的管理者必须要想清楚，用两个披萨就能把这事做好了，想清楚了这一点，后面所有的事情就都会顺利了。
刘鹏
360商业产品***架构师
负责 360 商业化变现的产品和技术。曾任微软亚洲研究院研究员、雅虎北京研究院高级科学家 ( 负责全球搜索广告、受众定向广告、个性化内容等项目 ) 、 MediaV ***科学家 ( 负责算法和数据平台 )以及搜狐集团研究院负责人。
以上内容节选自 CTO 训练营出版图书《CTO说》，根据 30 多位CTO训练营导师的课堂分享内容整理、改编，包括乐视网 CTO 杨永强、360 副总裁谭晓生、跟谁学 CTO 李钢江、花虾金融 CEO 段念、极客邦科技总裁池建强等，
更多内容查看：https://item.jd.com/12065279.html
CTO 训练营为 51CTO 推出的面向中高端技术管理者的学习及社交平台，16 年推出以来受到了行业里的中坚技术力量的欢迎，邀请了行业里资深的技术高管、技术类型的投资人以及技术创业者，打造技术管理者的 MBA，帮助中国***潜力的技术管理者成长为未来技术领域的***。CTO 训练营第四季正在招募中，愿意加入我们吗?
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
