从“天使轮”到“D 轮”，不同阶段 CTO 的职责！

会员服务 ·

从“天使轮”到“D 轮”，不同阶段 CTO 的职责！

2017 年 7 月 22 日 51CTO博客 王栋

雪球目前处于 C 轮融资，员工总共有 120 多人，其中工程师占一半以上；网站注册用户在千万量级，日活跃用户在百万量级。我以公司团队的发展为线索，针对已经经历过的阶段和未来即将经历的阶段，描述我所认为的不同阶段技术团队和CTO的主要职责。

从“天使轮”到“D 轮”，不同阶段 CTO 的职责

天使轮

天使阶段是验证创业者想法的阶段，这时没有完备的技术团队，事情比较多，没有太多技术含量。

比如我们当时有个论坛是基于 discuz 建立的，有个官方网站是外包团队做的，后来雪球的雏形也是外包的，总团队不到 10 个人，这都是很正常的。

利用一切可以利用的外部资源，使用外包、开源产品等，只要能验证想法就好了。

A 轮

这个阶段要确保规划的产品能够按照预想发布，重复地验证想法。此时要解决的是有没有的问题，而不是好不好的问题。资源少的时候，需要聚焦在最核心的功能上,不要贪多贪大。

对技术团队来说，肯定还是尽量拿开源的框架、开源的产品去搭建架构，确保不会花大量时间去开发复杂的底层基础架构或者框架。

为了提高效率，可以多使用一些新技术，一般来说新技术都是为了避免上一代技术的某些缺点并提高效率而出现的。

我们在这个阶段就开始使用 Node.JS 了，要知道 2011 年，很多人可能还不知道 Node.JS 是什么，雪球就把这个技术应用在生产环境了。

这个技术给我们带来的好处是前后端分离，两端的效率都大幅提升，前后端都独立迭代，只要保证 API 兼容。这对我们当时的产品开发迅速验证产品功能具有决定性的意义。

这种思路也一直延续，包括后来我们引入 Scala、SpringBoot、Docker 等技术都是基于类似的思考。

B 轮

在 B 轮这个阶段，雪球已经分成了三个业务团队。这个阶段没有专职的运维和测试团队，所以运维的工作由开发来做，测试的工作由产品来做，另外，在这个阶段我们重点关注项目管理。

因为产品功能和用户的增长，这个阶段人员的扩张不可避免。突然有一天，你发现开站会的每个同学说几句话，这个会议时间就要开半小时。

于是我们开始拆分团队，把按职能划分的团队重新按照功能来划分，以前是前端团队、移动端团队、后端团队、设计团队、运营团队。

现在是社区团队、行情团队、组合团队，每个业务团队都有完整的前后端、设计、运营的同学，所有的产品迭代都是由业务团队来驱动的。

在这种情况下，我们的项目管理方式是这样的：各个功能团队都基本遵循 SCRUM 的迭代方式，每两周做一次开发测试迭代，产品功能和设计提前一步迭代进行，每周进行产品演示确保产品符合所有人的预期。

功能团队内部每天会有站会，每周会有对各自项目的周报，周报会说明项目进度，如果有延期用红色突出标记提示风险和原因。

对于需要跨功能的管理，特别是 APP 需要发布版本，我们采用了版本列车的方法，也就是规定每个版本的提交日期，然后每个团队根据自己的计划选择搭乘哪一个版本，各团队负责人每周进行 1-2 次沟通。

通报各自团队的项目进展，相互了解产品特性，确保相互依赖的部分按照预期实现。这些方法简单有效且一直沿用至今。

C 轮

在 C 轮阶段，公司经过了两三年不间断的功能开发，终于迎来了业务量的大爆发，业务团队也发展到了 5 个，并且为了更好地分工，我们引入了专业的 SRE 团队、测试团队、平台团队。

比如运维团队负责基础设施的建设维护，平台团队负责各种基础框架、类库、中间件的建设维护，业务团队抽出专门的时间进行系统改造上线。

其实更多时候是业务团队和几个支持团队一起在往前推进，这样的组织结构可以充分发挥各个团队的优势，比较清晰地进行任务分配。

令我喜忧参半的是，我们的系统开始经常性地发生各种问题：程序负载高、数据库查询慢、缓存慢等等，一开始没有线索，在逐步增加数据收集后，发现高峰时期的请求量是过去的 10 倍以上。

这个阶段非常关键，尤其在数据、性能、架构方面投入了非常多的精力，做了很多稳定性的工作。

加强数据收集是尽可能地收集所有的数据，然后展现为图表，再根据数据的突变做报警设置，以前是因为量小，所以不管你怎么去实现，在现在的服务器配置下可能都没有太大问题。

即便程序本身没有 Bug，数据量大了瓶颈就有可能出现在任何地方，所以要通过尽可能多地收集数据了解所有系统的细节，为系统重构和扩容做好准备。

性能方面，我大概介绍一下几个主要的应对措施。另外一个要注意的是时刻要保持警惕，在收集数据的基础上多观察总结。

我们不怕出问题，也不可能避免出问题，主要怕出了问题还不知道，以及不知道为什么会出问题。监控报警能够预知未来和实时提醒，可以把危险消除在用户感知之前。

系统重构的主要着眼点就是把以前的一个单一的项目拆分成微服务，并且把对应的各种资源如缓存数据库也进行拆分，因为以前都是混在一起的。

我们对架构最大的一个改造就是把一个单一的项目拆分成了微服务，这涉及架构选择、标准化推行、资源拆分、代码重构、API 兼容测试、灰度上线、数据监控分析等一系列复杂的步骤。

这些都需要非凡的细心和耐心，我们差不多经历了一年多的时间才把所有的服务都完全迁移到新的架构上。

D 轮

虽然我们现在还没有进入 D 轮阶段，但是我们已经开始做大部分相关的事情了。我们有更多的业务团队，有更多的工程师，所以会更加关注流程、规范和运维、测试提供的服务化工具。

随着参与项目成员的增加，之前描述的开发流程本身变化不大，但是随着新人的加入，如何互相传递信息成为一个问题。

所以我们花了一些时间把以前做过的最佳实践，分门别类做了整理，包括项目管理过程、角色定义、阶段性产出、产品文档规范、技术系统设计规范、代码审查规范、灰度和上线规范等等，基本覆盖了从需求到上线的大部分场景。

这部分的归纳可以让所有参与项目开发的同学在对同一件事的认知上处于同一个水平，以便更容易理解和参与。

在运维和测试的基础设施建设上，在现阶段我们也逐渐把以前手工的、半自动脚本式的工具开始系统化、服务化，把最佳实践固化在工具当中，只提供有限的灵活度。

这样做的好处是运维和测试的同学能够完全从零散的需求驱动转化为服务提供方。几乎大部分开发同学的运维、测试需求都可以通过自助的 Web 化工具来完成。

比如，我们自己开发的基于 Docker 的上线和编排系统，开发同学通过这个工具点几个按钮，就能把 Git 里的代码发布到各种开发测试灰度线上环境中，日志自动收集到数据中心、监控系统和报警系统。

监控报警系统预先设置了很多选项，如果需要，开发同学可以完全自定义各种图表、各种报警项。

测试同学提供的持续集成环境、静态分析、API 自动化测试回归工具、UI 自动化测试工具等很容易被开发同学使用，测试同学提供的更多是对工具的支持，以及对如何写好自动化测试代码的支持。

综上所述，我们并不需要非常庞大的运维、测试团队，就可以支持更多的开发团队自主解决业务问题，毕竟业务团队才是最了解自己业务的。

技术团队建设之路

技术团队建设之人才选拔

每个团队都会有自己的风格和处事原则，一般会符合公司创始人的某种特质和风格，在团队选拔人才上，我们采用了两种不同的方式：

证明你不行的方式。听起来很奇怪。这个方法是说通过了我们招聘环节的同学，我们都倾向认为是一个好同学，所以会最大程度的去信任，入职第一天就开通全部的权限、参加所有讨论、第一周就可以上线代码，团队的支持是无条件的。
除非结果很差，比如不积极、不主动、代码质量差。这样也没问题，毕竟他们不熟悉！我们还会一起总结再给他工作调整的机会，甚至调换团队，如果最后所有的措施经过试验都不行，那就证明了他不行，只好劝退了。
证明你行的方式。这个也挺有意思的，是说任何项目或者方案，如果有人可以提出来说我可以搞，那么只要你能给出当前方案存在的问题、解决的思路、方案设计、如何上线、如何测试，假如大家都觉得没问题了，那这个项目就是你的了。
这样的同学最后手里会有很多重要的项目。他很快就能成为团队的核心，靠的就是积极主动、先人一步、能承担责任的品质，这是我们尤其鼓励的。

对一些同学的能力或者行为有质疑的时候，如果不能很快地下决心解决，最终会给自己、给团队带来非常大的痛苦。这又分两种情况：

有同学能力确实跟不上团队发展了，但是一直任劳任怨，你不忍心开掉，拖得时间一长，严重影响团队效率。
能力比较强的同学，但是过于个性化，自行其事无法很好的和团队一起配合，恰逢相关的岗位又一直无法补充合适的人选就那样凑合着，虽然一再沟通交流但是这种情况根本无法改变。回过头来看，还是应该长痛不如短痛！

技术团队建设之不可或缺的“一对一沟通”

日常的一对一沟通，是团队建设里最不可缺少的一个环节。最开始的时候每过一段时间，我都会和所有工程师进行一对一的沟通。

除了了解想法、传递信息之外，我觉得这个过程非常重要的一点是：如果有什么问题，要直接的指出，让对方很清晰地了解问题是什么，并且如何去改进。

如果不够直接、不够清晰很可能会让对方陷入到误解中。产生了误解对于解决问题就没有任何帮助，所以不要难为情，不要怕伤害对方，大家都是成年人，客观清晰地表述是对对方最大的尊重，也是上级对下级的责任。

如果公司的业务发展的好，特别是高速发展的时候，什么问题都不是特别大的问题，但是需要清醒的认识到随时可能都有危机存在，对于重点要保护的人要保护到位，任何的沟通不到位或者是激励不足，都可能会对业务造成比较大的影响。

技术团队建设之招聘的两个渠道

招聘渠道千万条，其中两个渠道是最好的：用户和内推。

如果一个用户对现在这个产品感兴趣甚至是资深用户，那么沟通成本会小很多，入职以后通常会更加的积极主动。我们现在有不少工程师都是用户转化，他们进入之后无论投入程度、对业务的参与程度、对公司的认同感、服务的时间上都是非常突出的。

有些同学甚至可以降职降薪，当然现在他们的职位和薪资早已超过以前了。内推是另外一个重要渠道，内推的时候，现在的同事就已经帮忙主动过滤了一遍了，通常都是非常匹配的，并且内推奖励一定远比猎头费划算。

候选人是否合适，我们认为最重要的不是经验，不是学校，不是资历，而是价值观。雪球希望工程师具有的价值观有哪些呢？

积极主动、客观、勇敢、对效率要有追求、对技术要有追求、对结果要有追求，至于其他方面，是男生还是女生、是什么学校毕业、发型是什么样的，我们不是很在意。

最后，我们在面试过程中一定要做到真诚，特别是在争取候选人来的过程中，要站在对方的角度去沟通。现在比较好的同学手里有 3-5个 Offer 太正常了，怎么沟通呢？

我通常都会希望他把其他公司或者职位一起聊一下，我会帮助他分析利弊，根据他的情况帮他去想如何选择。我并不会把其他 Offer 说的一文不值，我会很客观的去评价。

这样做的好处是，我们清楚了在招聘这个市场上其他竞争对手的优势是什么，并且即便后来他没有选择我们，我们还可以成为好朋友，会在 QQ、微信上经常沟通，当他遇到不顺的时候，会第一时间想到我们。

当时非常真诚地邀请过，后来通过这种方式来的同学也不在少数。

另外，沟通的过程中，一定要知道，说出来的承诺最后必须兑现，如果无法兑现的事情千万不要说，否则是自己给自己挖个大坑，最后一定是处理不掉的。

任何团队的成长都是一路磕磕绊绊

我经常在想如果回到 5 年前，我会怎么规划那些事情，应该更重点地去关注哪些事情。团队建设和招聘应该没有更好的方式了，这是一个长期持续的过程。

如果说哪些是最需要改进的地方？我会选择在工程实践上更早投入并且投入更多的精力，这包括两个方面：

业务开发，绝大部分公司从一开始就要进行业务开发，如果开始对质量、架构、代码不重视，到后来虽然可以重构，但是会非常痛苦，所以从一开始就要重视质量，从人的标准到代码的标准再到测试的标准都要高，不能放松不能被破坏。
这样也会对团队形成一个非常良好的氛围，就算是新人来了也会不自主地去习惯，不合适的人可以很快的被淘汰掉。以后需要重构时，因为前期的质量好，测试覆盖好可能就没有那么痛苦了。
基础设施，在持续集成、持续部署、运维自动化、监控报警这些基础设施都没有的时候，我们工程师团队的生产效率是不会高的，后期再接入这些会需要花费几倍的时间精力。
另外要特别注重监控和数字，如果对监控和数字不敏感，当系统发生任何变化时，我们都不能感知到，那就危险了。这同时还可以带来效率提高、避免一些人为操作失误，对于整个技术团队的技术积累也是非常有意义的。