业务和商业才是技术的驱动力
黄鑫，EGO会员，极光推送CTO兼首席科学家，曾就职于汽车之家、飞信、豆瓣等多家互联网公司，参与多个产品的开发和算法设计。目前负责极光推送产品和研发的工作。
EGO会员群里的各位作为公司产品和技术的最高管理者，我相信大家都是从最初的程序员一路走到今天，我们热爱技术，敬畏技术，相信技术可以改变世界。更是出于职责原因，我们最喜欢谈的词是技术驱动，技术创新。每次在看过分享后，我都在想我们是否应该构建一个这样的乌托邦呢？
在最近一次罗辑思维中，主题是非理性思维，在里面提到了行为经济学，那么管理这个面向人的科学中，我们自然不能太过于理想化，而必须要把管理学自然地变成行为管理学，把人的狭隘，自私必须要考虑在内，这就是我这次分享内容的一个核心出发点。
在开始之前，我先介绍下自己的工作经历。我09年开始工作，第一份工作是在汽车之家做Web开发，当时的汽车之家只有几十人，技术只有六七个人，任何一个项目都需要自己从前端做到数据库，在那里给我最大的感触是如何做产品和用户体验，至今我仍然认为李想是我见过最优秀的产品经理。从汽车之家离职后去了飞信，当时的飞信已经是个两千人的大公司了，在那里学到了成熟的组织和架构到底是什么样的。
然后就是豆瓣近三年的时间，在豆瓣给我的技术层面得到了飞速的成长，Geek的同事，良好的技术氛围，技术驱动的公司，优秀的企业文化，真的是一个技术人的乌托邦。在珍爱做了短暂的停留后，我加入了极光，至今约1年半的时间。
这几年时间，我从程序员到Tech Leader，到部门总监，再到如今企业中的最高技术决策和管理者，每天闲暇时，每晚入眠前，除了对技术和产品发展的思考外，占据我最多时间的就是回顾自己的职业生涯，再看身边企业的发展，思考自己到底在企业中的定位是什么，既然在其位谋其政，那么我应该为企业产生怎样的价值。我的这些思考也是在这次希望和大家分享的话题。
关于CTO的职责是什么？我觉得写的最好的就是caoz的那篇文章《CTO那点事》，在这里我也在caoz那篇文章的基础上补充几点我对CTO职责的思考。另外，这里指的CTO都是数百人团队规模，如BAT一样近万人的技术产品团队我还没有那么高瞻远瞩。
1、绝不是技术专家。因为CTO的职责所限，需要关注的不局限在某个技术领域，甚至不局限在技术上，加之管理职责的分担，所以无论你多天赋异禀，还是多拼命努力，说句让人悲伤的话，也许都不太可能在某个技术领域有着超人的成就了。例如在我们公司的团队中，有后台部门的首席架构师，有运维部门的运维总监，有移动开发的专家。论专业能力，我相信自己远不及他们。自负地让自己的能力成为公司的上限，是最可怕的事情。如果任何业务都需要自己来敲定架构，独断地干涉技术评审，或者太过于自负，或者是招人太失败。
2、跨部门的沟通者。无论我们是否承认，公司大了就需要划分部门，划分部门就需要有部门管理者，每个管理者一定会为自己的部门争取最大的利益，这个利益不仅仅是金钱层面的利益，还包括可控性、风险性等等。
举例来说，假设我们需要做一个需要多方配合项目，移动端会说我们负责的就是把数据传到后端，各种逻辑转换应该后端来做。后端会说我们负责的就是维持后端架构的稳定性，具体的业务逻辑你们来搞。数据会说你们能不能把数据清理好再传给我，这样我集群压力小。当然，三方都有自己的理由，大家都讨厌业务复杂度，保证技术架构的纯净。很多技术人员避免和其他部门产生过多的联调。这时，能站在中立角度去评估分工合理性的只有『CTO』。
要做到这一点，那么自然牵引出了两个必备的素质：<1> 全面的技术能力，不求多深，但是可以听懂不同部门的诉求和技术方案，了解不同方案的技术难度。 <2> 优秀的沟通能力和说服能力，这一点无需多言。
3、让自己负责一块业务。骑驴不知赶驴苦，饱汉不知饿汉饥。我见过好多CTO把自己作为纯粹的管理者，每天的工作就是坐在办公室里批批邮件，听听汇报，出席下对外的演讲场合，所有对公司技术的了解都是从各个部门的负责人听来，这是事必躬亲型CTO的另外一个极端。久而久之，脱离了一线太久，无法沉下心来去思考技术和业务本身。
我在公司会自己去Lead数据部门，当然如第一点所说，我的数据能力并不会比公司的很多数据同事更好，所以我也一样会让他们做最终的决策，但是我同样会参与数据的清洗流程规划，数据挖掘的算法设计，Hadoop集群的监控体系等等，某天抽空还能写几行代码。并不是我不信任同事，而是因为只有让自己抽身在一线工作，才能更加了解和规划公司技术和业务。
4、做CEO的“反对者”。对于大部分互联网公司而言，产品和技术无疑是公司生存的根本，无论是架构组织、市场策略、销售战略都需要围绕着产品本身服务，CTO作为公司内部最了解产品技术的人，自然需要承担起协助发展战略的作用，考虑到大多数CEO并不了解产品技术，想象力也天马行空，所以CTO最重要的作用之一就是做CEO的反对者。我回顾自己和老板的谈话，关键词大概包括这么几点：我要做什么，你应该做什么，你不应该做什么。我会经常和朋友开玩笑说，如果我明天就被我老板开掉了，你一定别惊讶，因为说不准哪天就吵翻了。
我们先定义下什么叫做技术创新，引用洪教授的一段话：“任何工程师希望引入一个新技术，除非看到明显的问题，都会鼓励工程师进行尝试，用数据和效果来证明新技术的价值。一旦证明新技术可用切有效，就会进行全面的技术升级”。
我们再来看看现在技术的发展速度，以流数据处理引擎为例，从Storm到Spark Streaming，到Flink再到如今的Beam，每个技术产生都说自己的性能更好，有各种优点，一个对新技术保持认同和追寻的工程师团队当然恨不得都跟进一遍，然后呢？我们真的要鼓励工程师进行尝试，然后证明他们的效率确实更好，于是进行全面的技术升级么？如果这样，那我相信这个团队可以一直折腾下去了。
曾经和某同事聊天，他说的一句话我觉得很有道理：无外乎团队分两种吧，一种是让工程师开心的，一种是让投资人开心的，做为Team Leader应该是平衡两者之间的关系。作为CTO，我觉得在天平的两端应该是更偏向投资人一方的。在说观点之前，我们先举个例子吧。
哑口无言的同时，我承认当时我满脑子觉得都是你真是不可理喻。但是等我到了今天想到这段对话，不得不承认他的思考方式是一位优秀的CTO(技术VP)所具有的。
在我刚刚加入极光时，Hadoop集群只有五台机器，但是足以支撑所有的业务。这时，我开始着手引入应用分析，地理位置分析等数据业务，尝试开辟新的商业模式。集群开始逐渐变得压力越来越大，团队开始将集群从几台扩展到十台、百台，完成了整体的ETL流程，完成了基本的统计业务。在集群的成本从十几万变成千万级别过程中，团队开始意识到我们不能这样盲目地扩充下去，我们需要精细化集群资源，大家开始考虑做数据压缩，大家开始考虑做冷热备份。再后来，我们开始引入DSP业务，由于需要在大规模的数据集上跑大量的数据模型，每个任务跑上一整天，每次数据更新需要一周我们不再能接受，我们开始引入Spark。由于让新人同时写Spark和Storm的学习成本太高，为了降低学习和培训成本，我们进而开始引入Spark Steaming。
在这个过程中，我没有去刻意推动任何的技术改造，也没有做过任何说服工作。团队也没有人提出我们为什么要这样做，因为大家都知道，这是我们业务所必须要做的事情。通过这个例子，作为CTO最重要的职责到底是什么？我总结了如下四步。
1、找到新的产品增长点，找到新的商业点。通过上面的案例大家可以发现，我们的技术在进步，但是我做的并不是去推动引入新技术，而是通过推动产品发展，推动商业化进程自然而然地去驱动技术向前发展。
2、 打造一个解决问题的团队。很多产品型团队找到了增长点后，却让技术成为了产品增长的瓶颈，例如技术只能支撑100万的并发访问，Feed流没办法做成实时推荐等等。这个时候就衍生了大家反复提及的概念，但是这里我做一个改变，我们不是要打造一个『Geek』的团队，因为Geek这个词在中国被太过滥用了，喜欢造轮子是Geek，喜欢钻研新技术是Geek，无法忍受脏代码看到不爽的就想重构是Geek，而这些在我看来不是优点甚至都是公司人力成本的重大消耗，我们需要打造的是一个能够解决问题的团队，遇到问题能够想到办法，无论是用新技术，还是造轮子，还是对已有技术做二次开发，总之不择手段用最高效的方法去解决问题的团队。
3、做新技术的第一个“反对者”。当然我们在上一点说的是非常理想的情况，我们这里做一点基本确凿的假设，人都是有私心的，很多『Geek』都希望尝试新技术，第一觉得新鲜，满足自己的好奇心；第二觉得自己用得多学得多未来可以找到好工作。
我曾经有过一个同事自己脱离公司的框架自己造了一套大轮子，别人问其原因时他说“否则公司的千万并发和我何干”，这在我看来是管理者的重大失责。我们必须清醒地意识到，大部分人的公司都属于业务复杂性而非技术复杂性，没有几个公司需要学习Google，Facebook，没有几个公司有BAT的体量，所以你遇到的问题别人都遇到过，很少有问题是需要不得不用冷门技术才能解决的，更少有问题是需要通过造轮子才能解决的。
所以作为CTO，我觉得在大多数时候不但不应该做推动新技术的第一人，反而应该成为新技术的第一个『反对者』，因为你永远需要做一个假设，公司里你是唯一一个以公司发展为己任的技术人员。
4、产品未来和商业大势的最敏锐预见者。这一点看上去与第一点相类似，其实完全不一样。在前面的三点中，我一直都在强调的是我们不要搞新技术，我们要保守，那么这个CTO的意义到底在哪儿？就是拒绝么？那这个CTO做的太简单了，作为CTO最难的一步是需要能够把握产品的未来，知道自己当前的技术瓶颈在哪里，而不能当需要做产品时才去解决技术问题；需要能够把握商业大势，如caoz文中所说，Android和iOS都已经如火如荼了，作为CTO还天天想着研究塞班那简直就是公司的大灾难。
当我们沿着这条思路去做的时候会发现很多困扰我们的事情都水到渠成了，还记得若干年前和一个上级讨论管理问题时，他告诉我说，大多数公司的管理问题只可能在两种情况下产生，太忙和太闲。所以作为CTO，将自己的思考重心从技术上更多地迁移到产品和商业上，将技术创新作为实现结果的方式，而并非把技术创新作为我们的目标更为合适。
我先举一个我经历过的例子，这个例子虽然不是一个技术相关的例子，但是我认为很有代表性。我曾经为某互联网公司做过产品技术和管理咨询，他们作为百人左右初创公司，当时最重要的指标自然是用户拉新，广告投放的总负责人是他们当时的运营总监，其中有一个部门负责渠道运营；他们同时有个产品总监，负责用户运营团队。我参与了两次他们的管理会议，运营总监一直在汇报他们从哪些哪些渠道获取用户，有一些渠道是连我都知道的和他们风马牛不相关的垃圾渠道。产品团队就一直在汇报我们做了哪些产品改进，新做了哪些产品功能。而没有人去汇报，他们到底新增了多少忠实用户。
让我们来复盘这个问题。反对KPI的人一定会说，这就是KPI文化啊，每个总监只负责自己的KPI，而不管公司整体利益。支持KPI的人一定会说，这说明KPI制定不合理啊，只要制定一个活跃用户的KPI就好了。其实两者说的都对，通过这个例子我来说明我的两个观点：
1、部门的划分要以KPI为基础。我见过很多奇葩的部门划分，产品和技术相分离，产品抱怨技术不给力，技术说产品乱提需求；推广和运营相分离，市场推广说我们用户给你你留不住，运营说你给我的都是什么垃圾用户；内容审核和审核系统相分离，审核人员说你们做的垃圾系统这么难用要累死我么，审核系统说你们不会用还怪我喽？所有的这些跨部门沟通只有一个人能解决，就是全公司最忙的CEO，结果可想而知。
那什么是合理的组织划分？我列一个最简单的指标，每个部门都有一个明确的KPI。产品和技术他们的KPI就是共同交付优秀的产品；推广和运营他们共同的KPI就是保证活跃用户；审核编辑和审核系统的技术人员共同的KPI就是最小化垃圾内容。最小化跨部门沟通，最小化跨部门沟通，最小化跨部门沟通，重要的事情说三遍。但是我相信无论如何划分，都会出现两个部门的KPI交叉问题，这时就引入了下一个观点。
2、高管不应该背KPI，执行人员要背KPI。对于大部分公司来说，高管的利益是与公司紧密绑定的，大家指望公司盈利分红，指望公司上市分钱。这时我们必须做一个前提假设，少数的这么五六个人以公司『赚钱』为己任，不需要用『背KPI』来约束他们的行为。
如果这样行不通可能需要反思两方面的问题：1. 是否招错了人 2. 是否高管人数太多造成意见太多。但是为什么说高管不要背KPI，执行人员要背KPI呢？同样两个原因，1. 你不要指望人人都觉得公司是我自己的，无论你如何激励，我要的都是现在完成KPI，拿年终拿提成 2. 一个和尚挑水喝三个和尚没水喝，当风险分摊后每个人的行为都自然会发生变化这是我们否定不了的事实，这也是为何我在强调要限制高管数量的原因。当公司太大而导致高管数量无法控制时怎么办？很简单，拆分事业部让各个高管工作交叉几乎为零即可。
我们回想下自己的企业是不是也有同样的问题，如果您是一位CEO，您回顾下你们的产品和技术是否被割裂开了？如果您是一个CTO，您也想一下自己是不是只背技术的KPI而忽略了产品。技术和产品相辅相成，用更优秀的产品驱动技术创新，用未来的技术趋势去驱动新的产品形态，这才是作为一个CTO应起的作用。
作为技术出身的CTO，我们听过了太多Google技术创新的神话故事，可是我们再回头想想，我们的企业真的需要那么复杂的技术么？我们再想想，我们努力打造一个Geek团队，每个人都想着技术创新，这个时候作为CTO的你依然在想着创新，这到底是一件多可怕的事情。
相反，作为CTO的我们，是不是更多时候应该放下“技术至上论”，放下“技术创新”的目标，把更多的经历放到业务和商业上，而让业务和商业驱动技术向前发展，这样才是扛起一个企业向前发展最该做的事情呢？
最后以一句我引用了无数次的例子作为『Geek文化』的结尾吧：『无论任何理由，我真的都无法理解一个企业选用Clojure作为开发语言到底是有多想不开』。