一加手机龚银：中型创业公司的技术管理之痛

编者按

“大牛V课堂”是Geekbang核心栏目，通过邀约专业领域内的互联网顶级大牛分享专业知识和见解，让你了解专业领域内含金量最高的知识。关注geekbang01公众号，遇见下一位大牛。

本文根据一加手机技术总监龚银在ArchSummit深圳2015大会的演讲整理而成，略有修改，感兴趣的读者可以关注10月份QCon上海2015大会的精彩内容。

去创业公司里做CTO？

今年3月份的时候有一个很久不见的朋友有一天突然打电话给我，说最近有一家很有背景的公司要创立一个互联网公司，希望邀请他去负责整个研发，去做CTO，他很向往这个职位，但他有很多顾虑，我们聊了很久，关于这个行业的背景、关于这个类型的创业公司我曾经碰到哪些困难，有哪些感受，和他交流了很多内容。

上个月中的时候又有一个朋友找到我，也是一个类似的P2P公司希望他去负责技术团队，能够去做一些事情，但他有非常多的顾虑，因为他一直在互联网行业和公司，他很担心这些传统公司面临互联网的挑战。我们行业内一个著名的公司做电商，CEO两年换了四个，CTO也在不停的换，大家都会有这样的顾虑。特别这两个月我也有一些迷惑和不解，也会和行业的团队负责人、老板沟通交流，大家有一个很一致的感受就是创业是非常孤独的，作为一个技术管理者特别是作为创业团队的技术管理者有时候也是非常孤独的，这也是我站在这里做一些分享的目的，希望把我个人的感受和经验和大家做探讨交流。前面几位讲师讲的都是干货，我的主题可能比较湿，是个人的感受或碰到的问题给大家做一些探讨。

怎么界定中型创业公司

首先我们看一下什么叫中型创业公司，大概分了一个类，创业公司、中型创业公司、成熟公司。最近创业公司非常多，各种行业、各种创业公司、各种类型的创业浪潮，这种公司的特点是十几个人，目标很坚定，没有太多的组织结构，大家往一个目标去奔，不停的做一些事情出来；成熟公司就不用说了，比如华为、腾讯，它们的体系是非常健全的，比如腾讯的研发管理平台从06年做到现在，花费了大量的人力和物力去搭建和完善内部的研发体系和研发平台，包括整个组织结构都是非常成熟的，个人在里面更多是追寻业务目标能够把KPI做好，这是成熟公司的一些例子；

什么叫中型创业公司？最近两年在行业第一个趋势是传统行业逐步往互联网行业转型，纷纷成立类似的互联网公司，它的资金和背景很雄厚，可能一成立一下团队就扩张的非常大，还有一些硬件行业互联网化，他们也有很强的背景和资源，大家都在抢时间窗口，都希望在这个短的时间和机会窗口中把目标和业务顺势扩张起来，这种创业公司的团队的扩张会非常快，这是我理解的中型创业公司的特点，就比如现在很多P2P和O2O性质的创业公司，还有硬件软件结合的一些公司，大都是这样的特点。

一加从无到有快速扩张带来的问题和挑战

1、组织的快速扩张带来的技术管理挑战

自我介绍，我是12年的从业经历，基本是在互联网这个行业里打拼，以前在金蝶，后来在比格邦，后来在天猫，也做过双11大流量的事情，现在是在一加，是传统和互联网结合的公司，主打产品是硬件，手机，我们现在定位也是全球性的企业，用户范围会覆盖到四十多个国家和地区，个人经历从事过传统IT、做过硬件、短暂创业、玩过互联网，现在是在软硬结合的公司里奋斗。

首先从一加的故事开始。我们从2013年底正式成立，2013年12月份左右正式宣布我们要去做一加，最初用户和消费群体是在中国，不到一年的时间里我们覆盖到四十多个国家和地区，包括欧盟、北美、印度和亚太等国家地区，现在用户范围大概是四十多个国家，带来的后果是业务发展太快了，实际上是会对我们的内部和公司技术体系带来了很大的挑战。再就是我们的办公地点，刚刚韩老师说他们是跨地区的模式，里面很多内容和我们现在实践的是比较类似的，我们也是一个跨地区、跨不同国家协作开发的模式，我们最早有一个办公地点是在深圳，现在办公地点有十个左右，台湾、北美、印度那边都有。沟通成本和网络成本包括其它成本是非常大的。再就是人员，人员从2013年底十几个人成立这家公司，现在有900人左右，一年的时间组织规模扩充了90倍，这是非常恐怖的，带来的严重后果是因为大家来自不同国家、不同背景、不同习惯，里面会有很多工作上的摩擦，沟通上也存在各种各样的问题。系统在2013年底从无到有，从0到1，现在大概有三十个以上的系统，还在不断扩充，我们跟其它的公司或互联网公司不一样，我们是垂直公司的电商模式，我们又是做硬件的，这个挑战会更大，从供应链、生产、制造、仓库到电商是面向所有消费者，还有其它的各种系统，收支平台也好，都是从无到有建立起来的，对技术平台和研发方面的挑战是非常大的。

这是我们简单的图表，比如部门人数，我们从十几个人的规模到接近一百号人，利用内部研发的应用大概是从十几个到最高峰的时候八十几个，后面我们又做了缩减合并，应用的数量是往下降的，系统的整个数量也是往上膨胀的，到现在大概是三十个以上的系统，包括客服的系统、CRM、仓库管理系统等等，还包括我们的核心电商系统，包括云平台，都是从无到有开发出来的。

2、大公司的技术架构、研发流程和体系在创业公司水土不服

这个是我们现在使用到的部分技术和开源组建，包括一些运维的体系，研发体系也借用大量的开源工具使用，包括ZABBIX、GITLAB，这是正在用或即将用的系统，包括Docker，现在尝试Docker，希望把整个运维体系做到容器化。

这个是我昨天刚过来，我们团队内在讨论一个问题的照片，我们在讨论一个产品的细节，需求一周之内变了五次，这个问题昨天讨论大家都有不同的意见，大家不停的争吵，我们花了两个小时时间还没有拿出一个结论，现在我们开发模式跟这个比较类似，需求不断在变，会有各种各样的突发性的问题出现，对我们研发体系的挑战也是非常大的。这是我们的现状和我们走过来大概是什么样子。后面重点讲讲我在中间学到的经验和感受特别深的事情。

我们是技术架构师的峰会，首先还是讲技术，技术架构简单胜于复杂，量体裁衣。为什么有这么深的感受呢？一加这个团队我接手之后发现有一些很奇怪的问题，整个技术架构是非常复杂的，怎么样复杂法？最早的一波员工可能是从不同的公司或互联网公司过来，就把公司现成的架构带过来了，这个架构好不好，可能非常好，适应大部分平台的企业，服务化做得非常好，文化做的非常好，分了很多应用和服务，这到底适不适合创业公司或适不适合一加的现状，这个现状是有问题的。比如说左边这个图，这只是一个小系统，电商的子模块，模块里面有18个以上的应用，所有应用之间分的很细，子系统做的非常好，然后每个应用之间的调用关系是一个网状。

我们最初的时候开发人员就十几个，每个人负责好几个应用系统，这有什么好处呢？对我们的架构带来很大的挑战性，一下子五六十个应用系统，部署非常复杂。出现问题之后要去找问题，后面我们做了一个事情就是把应用架构简单化，进行整合，把内部五六十个应用做了大量整合，全部合并在一起做了简单应用，然后我们引入了服务和调用框架，把服务管控做起来，把层次划分清楚，比如说怎么去做协调、怎么管控，我们把它简单化、程序化、层次化出来。这样带来的好处是效率高了，现在的业务模式有时候也会涉及到抢购，合并之后应用效能包括效率也高了很多，包括调问题或做什么事情都好了很多。现在互联网比较发达，大家可以在网上找到各种互联网公司的案例，但这些方案真的适合公司吗，团队受制于哪一点，团队能不能做这些事情，每一个架构都有原因，比如说像淘宝的架构也是发展了好多年才发展到这个阶段，如果创业公司一上来就用很复杂的架构，这对整个团队或业务带来非常大的影响，这是体会比较深的。

再一个就是关于混合语言开发的例子，最早我们的架构是从其它公司带出来的，带出来的是什么模式呢？底下有DB，中间有一层JAVA，JAVA是做后面的服务，上面还有一层是PHP，PHP是做Web页面，可能有些缓存，最早看到这个架构的时候也有一点诧异，这样带来的影响是什么？其实架构无所谓好坏，这种模式好多场景下也可以适用，但是在创业团队里，是初次组建的团队，这个模式带来很大的问题，第一个问题就是我做任何事情，比如做一个小小的功能需要进来一个JAVA人员和PHP的人员，可能还需要页面或测试的人员，一个小功能可能要十个人，这对资源是极大的浪费。后面我们改进，把它删减掉，不要垂直的模式，现在团队的现状就是JAVA和PHP都有，从前到后一个模块、一个系统搞定，模块与模块、系统与系统之间语言的交付统一通过服务中心或管控方式管理起来，这样带来最大的好处就是十个开发人员可以同时做十个项目，整个项目迭代是非常快的，这对我们现状来说是非常重要的一点。当然这里面也不会探讨哪个语言好、哪个语言坏，后天上午好像有一个PHP是不是最好语言的讨论，其实没有好与坏，只有适应场景，他是不是能去做这个事情。

再就是整个研发体系和流程的搭建，对于创业公司来说，对小公司来说还好，十几号人大家形成简单的讨论或达成一致应该怎么样去做，可以很快的沟通交流，但是对于像我们这样的团队不大不小，大家做项目是非常需要统一和协调的，没有规范，如果开发者的能力都非常好、沟通非常顺畅、意见很一致的情况下都没有问题，但是当你的团队扩大的时候团队可能会有不同的方式，这里面就会存在很多争论争吵或者矛盾、冲突，导致研发效率严重下降，我们有过惨痛的经历，所以进来以后把研发体系和流程做了搭建，可能不像腾讯有一个完整的体系，简单的会用开源的工具和平台把研发体系和辅助体系相关的东西理顺，最终研发体系是为开发人员服务的，不应该限制它，但是让大家有一致的思想。后面我们也会用一些技术，比如说Docker，把我们的运维体系做的更完善。在团队急剧扩大的过程中大家一定要重视研发体系的搭建，大家有一致的研发方式和理解，使效率推进更快。

这是大概的总结，总结只有四个字，因为我觉得技术架构没有好坏，不同的技术架构在某些情况下都是可以去用的，当然要量体裁衣，你现在团队的规模是什么程度，业务是什么样的业务，开发人员的能力在哪里，预算大概是什么样的，采取你自己合适的架构。尽量简单清晰、效率优先，能够一个人解决的事情绝对不要安排两个人，我觉得在公司沟通成本是最大的，如果大家沟通稍微有些不一样或者理解不一致的情况下会导致很大的团队的抱怨，所以能够一个人解决的让他去做，给他更大的空间，不要让两个人进去。再就是尽量利用开源或成熟产品，不要重复发明轮子，因为我们也是全球业务，我们也搭建机房，直接用海外AWS的产品，帮助我们迅速开展业务。架构观念，聚焦业务，随时调整轻重缓急。

3、业务做不完，效率低，人员跟不上

在我们公司每天碰到三个问题：第一个，我们想做的事情太多了，我们的产品计划已经排到明年下半年了，各种基础设施要做，因为我们也是在一个竞争非常激烈的行业，大家都知道手机行业竞争激烈，大家都在抢时间窗口，我们从无到有，要做的事情非常非常多。第二，我们没有那么多的资源，虽然公司发展比较快，但是也没有达到土豪的阶段或者一下子招很多非常优秀的人才进来，资源永远是有限的，不管投多少人进来，你发现还是很多事情没有人去做。第三就是没有时间，我们每天都在跟时间赛跑，希望把我们的产品和系统，内部的、外部的都能够做的很好，能够支撑业务的发展或者让我们的业务跑的更快，这是每天思考的问题。

这里面最大的一个矛盾就是现在业务永远做不完，因为我们是整个公司的技术部门，对应的业务线有十几条，公关、市场、营销、制造，每个业务线都会提很多关于系统方面的要求，比如说海外一个国家地区，在这个国家地区做很多定制化的东西，做市场推广活动和运营活动，包括做全球客服系统等，每个业务部门都有很多事情要做，全都推到我们这边来的时候事情像山一样压过来，这样的情况下怎么办？我们发现很多内部基础建设的很多问题，人员素质、人员能力一直得不到很好的提高，大家效率很低，我们一直想办法解决掉，当业务过来的时候我们完全没有时间做这些事情。比如我们现在运维体系做的不好需要改善，但是没有人、没有资源去做，我们要做内部的生产工具服务开发人员，比如我们一直计划在做配置中心，参数配置规划了很久，规划的很好但没有时间去做，业务排不过来。这也是我们现在一直思考的问题，怎么样衡量这些东西，怎么样去做。

走了这么久也慢慢摸索出经验，第一个，在创业公司核心的还是业务优先，不管怎么跑，要先跑起来，可能跑的很烂，可能这个路修的不是很好，让业务线跑起来，不能先修一条柏油大路，先修三个月，修完了在上面跑吧，那没用，对我们来说没有时间。但是一定要区分哪些是核心业务，这里面有一个重要的观点就是重要性的四象限，哪些是核心的业务，一定要聚焦，比如这个月有十几个系统需要开发，在这样的情况下同时铺十条线业务会做的怎么样，为什么不集中力量把最核心的业务做掉，少即是多，这是学习到的很深刻的一课。再就是重视规划和系统思维的作用，我们可能比较被动不停的支撑业务，来一个业务做一个，可能业务有他的规划，他不知道下一步做什么，不停的调整，后面发现这个模式非常被动，整个技术团队也在疲于奔命的去做。后面我们做了整合系统的规划和思考，帮助业务理清楚今年到底做哪些事情，什么阶段做什么事情，把这些系统跟业务部门不停的沟通，强迫他们系统化的思考，最后发现达到一致，所有业务部门都可以去理解这个阶段为什么做这事情，这个事情为什么不能现在去做，这样对开发节奏的掌控是非常重要的。

每个业务线在不同的时间和阶段业务需求都会过来，怎么办？告诉他做不了，他就会说这会影响到我们的口碑，后面我们做了什么事情？我们把部门定期一个月让所有部门按照标准把这个月的规划做出来，强迫所有业务部门做好规划和计划，做好之后合并在一起，把所有业务部门的头抓过来一起开会，明确在这边做这件事情，自己做优先级，确定好，大家定下来我们就按照这个方式去走，这个效果非常好，也是印象比较深刻的一点。所以在这种企业里一定要聚焦，区分你核心的业务在哪里，你的团队大概有多少资源做这个事情。再就是系统思维，永远不要指望业务理解技术，这是我从业十二年的感受，可能业务说这里改一点嘛，就两天完成的事情，他们体会不到后面的技术架构怎么做，具体有什么样的困难，他们是体会不到的，所以不要指望业务理解技术这个事情，也不要让技术反推业务，利用一些方法和技巧来实现比较正向的反馈。

4、技术管理者精力需要往管理上转

再一个感受比较深的经验是技术和管理的比重随时要调整和平衡。大部分的技术管理者都是技术出身的，大部分的技术人员对技术都是非常狂热的，当发现新的技术的时候或不好解决的技术问题，这时候非常兴奋，希望做很多事情，我在这方面也犯过错，我刚到公司的时候发现很多技术上的问题、架构上的问题，我会自己投进去，满腔热血做很多事情，问题就是如果你是一个小团队没问题，但如果你的团队足够大，比如说几十号人上百号人规模的时候，一定要控制参与度或者你对具体事情的参与度，把更多精力放在团队的管理上或者是文化的管理上。这个比例具体怎么分，没有绝对的比例，看你公司的情况和环境，有些公司文化做的特别好，但有些公司全部聚焦在业务，这样就需要技术管理者花费更多的时间在团队上、人员管理上或其它的非技术方面的事务方面，这也是我印象比较深刻或走了一些弯路的地方。

5、创业公司招人难

再一个感受比较深的是招人，招人要慢，辞退要快。我今年核心的工作就是找人，找到合适的人，是非常非常难的事情，特别是这两年创业氛围太难了，找不到非常好的技术人员，包括这边很多朋友经常跟我说的一句话是什么都有了，就缺一个技术人员，你帮我找一下吧，我觉得找人很难。在这个过程中我们有很多的方法，通过传统的招聘渠道，也通过一些新兴的招聘工具，包括猎聘我们都尝试过，效果都不是很好。总结下来最好的效果还是内部推荐，从员工的角度大家去推荐，这个效果感觉还不错，进来的素质包括他对公司文化的理解非常到位。我觉得作为创业公司的技术负责人自己一定要花更多的精力和时间在找人上面，找到一个人真的可以去给你解决很多问题。今年上半年我大概有三分之一的时间找人，不停的找人、了解、沟通。

还有在招聘的过程中，除了专业能力还有文化和创业坚守是非常重要的，特别是对于创业公司来说，这点我体会不是很深，最早我要求专业能力非常过硬，来了之后就能用，但是我发现除了专业能力之外，特别是像我们公司文化是比较混合的情况，因为办公室里来自不同国家、不同文化的人，有些同学进来之后会把他已有的习惯或以前工作的方式带进来，每个人的工作方式都不一样，他不理解创业公司为什么要这样，他并没有深刻的认识，创业公司可能最初追求业务，他可能不理解，他可能看到这么多问题，后勤没有做好，加班的零食可能少了一点，有各种各样的抱怨，后面发现在招聘的时候文化和他个人创业精神的理解上一定要去重点把关的，一定要匹配你公司的文化。

再就是辞退要非常迅速，特别是最早期的时候团队扩张太快，招聘上可能没有做的很好，没有把关的很好，导致辞退一些同事，不一定是能力不行，是他跟公司的匹配度和做事方式调整不过来。有一个生动的例子，其实我对辞退员工这件事情是比较抵抗的，从业这么久从来没有辞退过员工。有一次有一个员工给了他三四次机会做一个事情，但是所有周边的人埋怨非常大，后面给他指导过一个月，但是没有用，后来痛下决心把他劝退了，我以为会对团队有影响，但是当他劝退以后周边所有跟他配合的同事大叹一口气“终于走了”，我感触蛮深的，确实不合格的要把他辞掉，因为不仅仅影响到他自己的工作，会影响到他身边的人、他工作同事的状态，会有一些蔓延的后果。如果他持续犯一个错误，我们给他一个月时间指导改正，如果还改不过来，只能是离开，对公司和个人都是好事，这也是我在一加学到的很重要的一点。

6、因人员背景差异带来的分歧，对沟通和团队激励提出了更高的要求

再一个感受就是永远不要忽视沟通的作用和力量。像以前带团队，大家的综合素质比较高，体系比较成熟，大家把事情做好，一个小团队去奋斗、去拼搏就好了。从传统行业到互联网公司，大家在模式上、对新兴事物的认识上有很大的落差和不同，有一个比较典型的例子，有一次我跟一个同事，他也是从比较传统的行业过来，我就跟他聊加班文化，你怎么看待创业公司确实加班很多，他说“不应该多加班吗？研发哪有不加班的。”这个观点有时我也不能认同，但是我认同他说加班是正常的，但是一定是在有效率的加班，而不只是为了加班就坐在那里做一些表现。比如说沟通上业务方有一些想法，他有很多的需求，可能大家在做事情的过程中理解不一样，做完之后有问题，又用另外的方式去做，这会导致不必要的冲突和矛盾，所以沟通这一块是非常重要的技巧，要跟上司沟通、跟老板沟通，跟下面所有的兄弟沟通我们有哪些问题，应该怎么去做，和业务找到一种很好的渠道。沟通只是第一步，一定要形成固定的机制。

最后一点是正确的激励导向，使团队快乐，这个也是蛮有感受的。我们以前也讨论过，创业公司大家的时间和精力都放在业务上，我们要不要做KPI，怎么激励和鼓励员工，去年我们犯了一些错误，公司体制也不健全，很多事情也没有做的很好，这方面引导员工告诉他应该怎么样才能得到更多的激励，这方面可能也做的不是很好，我们现在也在探索，比如说要不要KPI，员工还是要有一个清晰的目标，如果他做的好确实要有激励和奖励措施给他，可以是实质上的奖励，也可以是精神上的奖励，这个是非常重要的事情，这个事情我们也犯了很多错误。再一个是使团队快乐，创业公司压力非常大，也很辛苦，要有各种各样的活动和团建，让大家更Happy，成员之间的感情要很好，大家更有劲。

创业公司的管理者需要具备哪些素质？

在一个公司作为管理者，需要的素质有五个：一是指得了路；二是扛得了枪，公司每天都有很多问题或技术难题，你作为技术负责人自己要深入进去，带动大家解决问题，或者给大家提供建议让大家做事；三是吃得了苦，相信在创业公司待过的都能有一些体会；四是卖得了萌，你带一个技术团队或者是兄弟，需要在团队文化建设或团队氛围做很多事情，活跃你所有的成员，做很多团结方面的事情，跟大家打成一片；五是受得了委屈，很多时候你做了很多决策、想法或事情，可能下面的兄弟不理解你，另外一种方式做可能更简单，可能你比他们看的更远，可是大家不理解你，或者大家的要求你没有满足，大家指责你，可能有这样的冲突或争吵，我觉得这是基本素质，技术负责人要能够受得了委屈，想办法解决，如果你是对的没关系笑一笑就好了，如果你是错的那想想怎么改善。

个人几点有效实践，第一条是锻炼身体，保持良好的体力和心态；第二是每天写管理日志，如实记录，定期反思；三是保持学习，每天至少预留30分钟时间思考，30分钟时间学习；四是定期的一对一会谈。

核心观点，不同公司不同阶段有不同的关注点和解决方法，没有标准答案，需要每一个技术管理者包括CTO去思考，从你的团队到能力、从你公司的业务和业务发展方向去思考到底采取什么样的方法，就去思考、去想，找到你最合适的才是最好的。

前段时间看了一本书《THEHARD THING ABOUT THE HARD THINGS》，作者说了这样一句话，担任CEO的八年时间里，只有三天顺境，其它的时间全部举步维艰。这本书大家可以看一看，可以体会里面的一些方法和实践，包括对创业公司的理解，我的感受来看是非常吻合的。还有一句话是成功的价值就是失败失败失败，不停的去尝试，但是每一次失败都是提供一个机会去学习。我们也应该是这样的心态，敢于尝试，但是要思考，思考哪里做的好或不好，到一定阶段以后每一个架构师或技术管理者都能够形成自己有效的管理理论。

Always On The Road！永远在路上，我们永远都是在路上。