业务和商业才是技术的驱动力

CTO的职责绝不是技术

关于CTO的职责是什么？我觉得写的最好的就是caoz的那篇文章《CTO那点事》，我将这篇文章一直收藏在微信收藏夹里，时时提醒自己该做什么，反思自己什么没做好。那么这里我也在caoz那篇文章的基础上补充几点我对CTO职责的思考。另外，先说一句，这里指的CTO都是数百人团队规模，如BAT一样近万人的技术产品团队我还没有那么高瞻远瞩。

A. 绝不是技术专家。因为CTO的职责所限，需要关注的不局限在某个技术领域，甚至不局限在技术上，加之管理职责的分担，所以无论你多天赋异禀，还是多拼命努力，说句让人悲伤的话，也许都不太可能在某个技术领域有着超人的成就了。例如在我们公司的团队中，有后台部门的首席架构师，有运维部门的运维总监，有移动开发的专家。论专业能力，我相信自己远不及他们。自负地让自己的能力成为公司的上限，是最可怕的事情。如果任何业务都需要自己来敲定架构，独断地干涉技术评审，或者太过于自负，或者是招人太失败。

B. 跨部门的沟通者。无论我们是否承认，公司大了就需要划分部门，划分部门就需要有部门管理者，每个管理者一定会为自己的部门争取最大的利益，这个利益不仅仅是金钱层面的利益，还包括可控性、风险性等等。举例来说，假设我们需要做一个需要多方配合项目，移动端会说我们负责的就是把数据传到后端，各种逻辑转换应该后端来做。后端会说我们负责的就是维持后端架构的稳定性，具体的业务逻辑你们来搞。数据会说你们能不能把数据清理好再传给我，这样我集群压力小。当然，三方都有自己的理由，大家都讨厌业务复杂度，保证技术架构的纯净。很多技术人员避免和其他部门产生过多的联调。这时，能站在中立角度去评估分工合理性的只有『CTO』。要做到这一点，那么自然牵引出了两个必备的素质：<1> 全面的技术能力，不求多深，但是可以听懂不同部门的诉求和技术方案，了解不同方案的技术难度。 <2> 优秀的沟通能力和说服能力，这一点无需多言。

C. 我见过好多CTO把自己作为纯粹的管理者，每天的工作就是坐在办公室里批批邮件，听听汇报，出席下对外的演讲场合，所有对公司技术的了解都是从各个部门的负责人听来，这是事必躬亲型CTO的另外一个极端。久而久之，脱离了一线太久，无法沉下心来去思考技术和业务本身。我在公司会自己去Lead数据部门，当然如第一点所说，我的数据能力并不会比公司的很多数据同事更好，所以我也一样会让他们做最终的决策，但是我同样会参与数据的清洗流程规划，数据挖掘的算法设计，Hadoop集群的监控体系等等，某天抽空还能写几行代码。并不是我不信任同事，而是因为只有让自己抽身在一线工作，才能更加了解和规划公司技术和业务。

D. 做CEO的『反对者』。对于大部分互联网公司而言，产品和技术无疑是公司生存的根本，无论是架构组织，市场策略，销售战略都需要围绕着产品本身服务，CTO作为公司内部最了解产品技术的人，自然需要承担起『协助发展战略』的作用，考虑到大多数CEO并不了解产品技术，想象力也天马行空，所以CTO最重要的作用之一就是做CEO的反对者。我回顾自己和老板的谈话，关键词大概包括这么几点：『我要做什么』，『你应该做什么』，『你不应该做什么』。我会经常和朋友开玩笑说，如果我明天就被我老板开掉了，你一定别惊讶，因为说不准哪天就吵翻了。

这个话题实在太大，时间原因就不再继续说下去了，希望以后有机会可以另开一篇专门去谈这个话题。但是从上面的文字里，大家可以看到，我没有提到一句『技术创新』，不是因为我觉得技术创新不重要，而是在我的观念里，技术创新是结果，而不是我们可以追求的目标。那么我们开始下一个话题，来聊一下一个公司为什么需要『技术创新』。

不要妄谈技术创新

我们先定义下什么叫做技术创新吧，我先引用洪教授分享稿里的一段话：『任何工程师希望引入一个新技术，除非看到明显的问题，都会鼓励工程师进行尝试，用数据和效果来证明新技术的价值。一旦证明新技术可用切有效，就会进行全面的技术升级』。我们来看看现在技术的发展速度吧，以流数据处理引擎来说吧，从Storm，到Spark Streaming，到Flink再到如今的Beam，每个技术产生都说自己性能更好，有这样那样的优点，一个对新技术保持认同和追寻的工程师团队当然恨不得都跟进一遍，然后呢？我们真的要鼓励工程师进行尝试，然后证明他们的效率确实更好，于是进行全面的技术升级么？那我相信这个团队可以一直折腾下去了。

曾经和某同事聊天，他说的一句话我觉得很有道理：『无外乎团队分两种吧，一种是让工程师开心的，一种是让投资人开心的，做为Team Leader应该是平衡两者之间的关系』。那么作为CTO我觉得在天平的两端应该是更偏向投资人一方的。在说观点之前，我们先举个例子吧。

在之前的某个公司里，我和我的Boss发生过一次激烈的争吵，原因是我希望把Hadoop平台去换成Spark平台，他问我换成这个平台的好处是什么呢？我说第一可以节省代码量，第二可以提高计算效率，现在一个小时的任务可能几分钟就能跑完了。他说了至今让我难忘的话，他说现在的同事因为多出的代码量降低了多少工作效率；提高计算效率后省出的那些时间你打算去干吗？代码放后台跑时间再长又能怎样呢？哑口无言的同时，我承认当时我满脑子骂的都是你真是不可理喻。但是等我到了今天想到这段对话，不得不承认他的思考方式是一位优秀的CTO(技术VP)。

在我刚刚加入极光时，Hadoop集群只有五台机器，但是足以支撑所有的业务。这时，我开始着手引入应用分析，地理位置分析等数据业务，尝试开辟新的商业模式。集群开始逐渐变得压力越来越大，团队开始将集群从几台扩展到十台，百台，完成了整体的ETL流程，完成了基本的统计业务。在集群的成本从十几万变成千万级别过程中，团队开始意识到我们不能这样盲目地扩充下去，我们需要精细化集群资源，大家开始考虑做数据压缩，大家开始考虑做冷热备份。再后来，我们开始引入DSP业务，由于需要在大规模的数据集上跑大量的数据模型，每个任务跑上一整天，每次数据更新需要一周我们不再能接受，我们开始引入Spark。由于让新人同时写Spark和Storm的学习成本太高，为了降低学习和培训成本，我们进而开始引入Spark Steaming。

在这个过程中，我没有去刻意推动任何的技术改造，也没有做过任何说服工作。团队也没有人提出我们为什么要这样做，因为大家都知道，这是我们业务所必须要做的事情。所以再回归到主题，通过这个例子，作为CTO最重要的职责到底是什么？我总结了如下四步。

A. 找到新的产品增长点，找到新的商业点。通过上面的案例大家可以发现，我们的技术在进步，但是我做的并不是去推动引入新技术，而是通过推动产品发展，推动商业化进程自然而然地去驱动技术向前发展。

B. 打造一个『解决问题』的团队。很多产品型团队找到了增长点后，却让技术成为了产品增长的瓶颈，例如技术只能支撑100万的并发访问，Feed流没办法做成实时推荐等等。这个时候就衍生了大家反复提及的概念，但是这里我做一个改变，我们不是要打造一个『Geek』的团队，因为Geek这个词在中国被太过滥用了，喜欢造轮子是Geek，喜欢钻研新技术是Geek，无法忍受脏代码看到不爽的就想重构是Geek，而这些在我看来不是优点甚至都是公司人力成本的重大消耗，我们需要打造的是一个能够解决问题的团队，遇到问题能够想到办法，无论是用新技术，还是造轮子，还是对已有技术做二次开发，总之不择手段用最高效的方法去解决问题的团队。

C. 做新技术的第一个『反对者』。当然我们在上一点说的是非常理想的情况，我们这里做一点基本确凿的假设，人都是有私心的，很多『Geek』都希望尝试新技术，第一觉得新鲜，满足自己的好奇心；第二觉得自己用得多学得多未来可以找到好工作；我曾经有过一个同事自己脱离公司的框架自己造了一套大轮子，别人问其原因时他说『否则公司的千万并发和我何干』，这在我看来是管理者的重大失责。我们必须清醒地意识到，大部分人的公司都属于业务复杂性而非技术复杂性，没有几个公司需要学习Google，Facebook，没有几个公司有BAT的体量，所以你遇到的问题别人都遇到过，很少有问题是需要不得不用冷门技术才能解决的，更少有问题是需要通过造轮子才能解决的。所以作为CTO，我觉得在大多数时候不但不应该做推动新技术的第一人，反而应该成为新技术的第一个『反对者』，因为你永远需要做一个假设，公司里你是唯一一个以公司发展为己任的『技术人员』。

D. 产品未来和商业大势的最敏锐预见者。这一点看上去与第一点相类似，其实完全不一样。在前面的三点中，我一直都在强调的是我们不要搞新技术，我们要保守，那么这个CTO的意义到底在哪儿？就是拒绝么？那这个CTO做的太简单了，作为CTO最难的一步是需要能够把握产品的未来，知道自己当前的技术瓶颈在哪里，而不能当需要做产品时才去解决技术问题；需要能够把握商业大势，如caoz文中所说，Android和iOS都已经如火如荼了，作为CTO还天天想着研究塞班那简直就是公司的大灾难。

当我们沿着这条思路去做的时候会发现很多困扰我们的事情都水到渠成了，还记得若干年前和一个上级讨论管理问题时，他告诉我说，大多数公司的管理问题只可能在两种情况下产生，太忙和太闲。所以作为CTO，将自己的思考重心从技术上更多地迁移到产品和商业上，将技术创新作为实现结果的方式，而并非把技术创新作为我们的目标更为合适。但是用这个逻辑走下去的同时，产生了新的问题，如果我们作为CTO，如果满脑子都在想着商业化，会不会出现近期争议不断的某搜索引擎为了商业却违背伦理道德或者损伤公司的行为呢？那么就引出了下一个问题，我们如何看待KPI，被无数人抨击的KPI文化真的不好么？到底如何合理地使用KPI文化。

KPI文化真的不好么

我不喜欢在管理学上引入太多的名词，所以我在这里不和大家区分KPI还是OKR，这两者其实从操作上差别不大。我先举一个我经历过的例子，这个例子虽然不是一个技术相关的例子，但是我认为很有代表性。我曾经为某互联网公司做过产品技术和管理咨询，他们作为百人左右初创公司，当时最重要的指标自然是用户拉新，广告投放的总负责人是他们当时的运营总监，其中有一个部门负责渠道运营；他们同时有个产品总监，负责用户运营团队。我参与了两次他们的管理会议，运营总监一直在汇报他们从哪些哪些渠道获取用户，有一些渠道是连我都知道的和他们风马牛不相关的垃圾渠道。产品团队就一直在汇报我们做了哪些产品改进，新做了哪些产品功能。而没有人去汇报，他们到底新增了多少『忠实用户』。

让我们来复盘这个问题。反对KPI的人一定会说，这就是KPI文化啊，每个总监只负责自己的KPI，而不管公司整体利益。支持KPI的人一定会说，这说明KPI制定不合理啊，只要制定一个活跃用户的KPI就好了。其实两者说的都对，通过这个例子我来说明我的两个观点：

A. 部门的划分要以KPI为基础。我见过很多奇葩的部门划分，产品和技术相分离，产品抱怨技术不给力，技术说产品乱提需求；推广和运营相分离，市场推广说我们用户给你你留不住，运营说你给我的都是什么垃圾用户；内容审核和审核系统相分离，审核人员说你们做的垃圾系统这么难用要累死我么，审核系统说你们不会用还怪我喽？所有的这些跨部门沟通只有一个人能解决，就是全公司最忙的CEO，结果可想而知。那么什么是合理的组织划分？我列一个最简单的指标，每个部门都有一个明确的KPI。产品和技术他们的KPI就是共同交付优秀的产品；推广和运营他们共同的KPI就是保证活跃用户；审核编辑和审核系统的技术人员共同的KPI就是最小化垃圾内容。最小化跨部门沟通，最小化跨部门沟通，最小化跨部门沟通，重要的事情说三遍。但是我相信无论如何划分，都会出现两个部门的KPI交叉问题，这时就引入了下一个观点。

B. 高管不应该背KPI，执行人员要背KPI。对于大部分公司来说，高管的利益是与公司紧密绑定的，大家指望公司盈利分红，指望公司上市分钱。这时我们必须做一个前提假设，少数的这么五六个人以公司『赚钱』为己任，不需要用『背KPI』来约束他们的行为。如果这样行不通可能需要反思两方面的问题：1. 是否招错了人 2. 是否高管人数太多造成意见太多。但是既然说高管不要背KPI，执行人员要背KPI呢？同样两个原因，1. 你不要指望人人都觉得公司是我自己的，无论你如何激励，我要的都是现在完成KPI，拿年终拿提成 2. 一个和尚挑水喝三个和尚没水喝，当风险分摊后每个人的行为都自然会发生变化这是我们否定不了的事实，这也是为何我在强调要限制高管数量的原因。顺路多说一句，当公司太大而导致高管数量无法控制时怎么办？很简单，拆分事业部让各个高管工作交叉几乎为零即可。

我们回想下自己的企业是不是也有同样的问题，如果您是一位CEO，您回顾下你们的产品和技术是否被割裂开了？如果您是一个CTO，您也想一下自己是不是只背技术的KPI而忽略了产品。技术和产品相辅相成，用更优秀的产品驱动技术创新，用未来的技术趋势去驱动新的产品形态，这才是作为一个CTO应起的作用。

总结我们对以上所有观点做个总结吧，作为技术出身的CTO，我们听过了太多Google技术创新的神话故事，可是我们再回头想想，我们的企业真的需要那么复杂的技术么？我们再想想，我们努力打造一个Geek团队每个人都想着技术创新，这个时候作为CTO的你依然在想着创新，这到底是一件多可怕的事情。

相反，作为CTO的我们，是不是更多时候应该放下『技术至上论』，放下『技术创新』的目标，把更多的经历放到业务和商业上，而让业务和商业驱动技术向前发展，这样才是扛起一个企业向前发展最该做的事情呢？

最后以一句我引用了无数次的例子作为『Geek文化』的结尾吧：『无论任何理由，我真的都无法理解一个企业选用Clojure作为开发语言到底是有多想不开』。

FAQ

问题1：各部门协调一直是长久以来无法完全解决的问题，当CTO站在管理角度去思考的时候，除了在技术上能够有良性的技术沟通优势以外，如何保证在其他部门的良好协调呢？

回答：沟通的技巧被无数的书所提及了，其实无论在技术部门之间，还是技术与非技术部门之间，永远分两种：1. 自己权力所能及，那就摆事实讲道理，这个其实要求是最高的，因为你要说服各个部门这样子对公司的利益是最好的，然后往往还都需要为其提供出合适的技术方案。 2. 自己权力不能及，这个往往是和销售部门、运营部门等等，这个我往往是把自己放在一个支持者的心态上，满足对方需求同时提出更合适的解决方案，但是这个相对容易是因为如我在前面所说，高管是不需要背KPI的，大家的目标一致，只是做法不同而已，只要提出最终的目标，往往大家都可以接受。

问题2：架构/技术的前瞻性和业务驱动架构/技术的前进往往有冲突，纪要考虑架构的可演进，又要考虑当前的适用性，如何平衡和把握？

几个原因：1. 产品和技术相分离，产品拼着命想往前跑完全不顾技术，技术拼着命做重构不管产品发展，那么这个是组织架构的问题，我往往会在做每个功能的同时视情况将功能重构，例如最近我们涉及到某一位大客户的需求，我的做法是第一步做一个非常临时的方案(文件系统)满足需求，但是同时我会抽象出方案，对我们的历史Redis集群做出升级方案。 2. 技术前瞻性还是略微欠缺。从理想情况而言，技术应该是先行业务一步的，也举个同样的例子，我们在业务上很重要的一块是数据上报来保证用户可以查询到最实时的信息，过去的时候我们的上报频率最高只能在300/s，突然有一周因为业务原因需要提高到500/s，集群就撑不住了，调优了一周才上线，我和这块业务的技术负责人谈话时是这么说的，我认为这是我们的失责，虽然当时300就可以满足需求了，但是你在同时应该去测试到底我们这个可以撑到多少。在某本关于高性能网站的书(我不记得名字了)上曾经有段理论很对，我们在做架构设计时应该做5倍的设计，留出2倍的余量(大概是这样的意思)。如果即便这样你还发现永远都没精力做去架构的重构和改进，那么真的要考虑是不是组织结构的不合理，或者人手不够了。这些道理其实听上去非常虚，但是我觉得是非常值得去思考的，我每晚睡前都会去翻看自己的wunderlist去看自己最近一个月出了哪些问题，未来一个月需要做哪些规划，去反复的复盘，因为只有这样才能让自己不成为企业发展的瓶颈。