公司各个阶段 CTO 须要作什么？

CTO 是企业内技术最高负责人，对企业的发展起到相当重要的做用。但随着公司的不断发展，CTO 的工做重心也会不断变化。只有在正确的阶段作正确的事，才能更好地为公司作出贡献。我是空中金融 CTO ，TGO 鲲鹏会上海分会会员。加入空中金融以前，我曾在饿了么、空中网、5173 等互联网公司担任中层技术管理者，有过三次从 0（ 或 0.5 ）开始的创业公司工做经历。本篇文章，我将为你们分享，公司初创阶段 CTO 须要作的事。

假设一个公司发展有如下几个阶段：

• 0 ：创始阶段；
• 0.5 ：有产品但无管理阶段；
• 1 ：通过 1年的发展初步稳定的阶段；
• 1+ ：稳步发展阶段。

这一篇，我将和你们聊聊公司初创阶段 CTO 须要作什么。剩下的阶段将会在另一篇文章分享。

初创公司 CTO 或者技术负责人，最重要的目标是在最短期内用有限的预算打造合适的团队把项目作起来。说说我遇到的两种初创公司的状况。

从 0 开始的状况

从 0 开始指的是：你是公司第一个技术人员，你须要从 0 开始搭团队。最初，你须要作以下几项工做：

预算和组织

评估项目初版在规定时间内上线须要多少人的技术团队，是否须要分产品线，规划出不一样岗位的人数。好比，项目经理 1 人、前端 2 人、后端 5 人、客户端 2 人、UI 设计 2 人、产品经理 2 人、测试 3 人、运维 2 人等等。而后根据技术团队的规模预估人员成本，以及作服务器、软硬件的预算，把这些预算和整个公司的预算放到一块儿评估，看是否可行。若是可行，当即全面开启人员招聘。若是初期人数不超过 20 人，不须要特别复杂的组织架构，全部人直接向你一人汇报也能够。在项目执行过程当中，项目经理甚至是产品经理能够帮你负责一部分管理工做。在初期，虽然完全扁平化的架构会很累，但有助于提升效率和执行力。

人员和招聘

对于通常作产品的初创公司而言，业务量不大，不须要高端人才，须要的是踏实肯干、愿意拼搏、愿意与公司一块儿成长的具备相同价值观的人才。公司初创阶段各岗位须要大量招人，选择合适的面试方式和面试难度很是重要。我会经过笔试初筛，以节省时间，避免和不合适的面试者礼节性聊天。

个人笔试有两个特色：

一、能够开卷

我不反对现场拿手机查资料，可是由于笔试时间固定，现场查资料每每意义不大。第一，个人笔试题不是网上搜的，没有现成的答案；第二，大部份内容考察的都是技术细节或对技术的总体理解。若是面试者以前不理解或是没有经验，临时抱佛脚用处不大。

二、笔试考察的知识面是比较全面的

好比，后端的面试题涉及到语言基础、算法、SQL 、虚拟机、Linux 、架构设计、设计模式、框架等分类，难度比较高。30% 的面试者在看到笔试题后会选择放弃，其实只要是认真回答问题的，哪怕只答出 40% ，我也会安排面聊。我只是但愿经过难度较高的面试题刷去一些内心不那么强大的面试者。

在招聘淡季，我会要求人事广撒网进行笔试，由于确实遇到过一些工做经历不那么出色，但技术基础特别扎实的面试者，若是简历初筛淘汰了这样的面试者是比较惋惜的。笔试以后的面聊会针对笔试的问题展开讨论，而且要求面试者介绍以前的项目经验、学习方式以及对技术的追求。

面试是搭团队最重要的一个环节，搭团队是技术管理者最重要的事情之一，怎么强调面试的重要性都不过度。最好在最初能招到几个优秀的人做为核心成员，这样可让他们来分担一些面试工做，让本身有时间作其余的事情。初创团队的人员必须个个是精英，好比，一个只有 3 我的的前端团队，其中 1 我的很平庸，那么你的前端团队就有 33% 的人是很平庸的。若是所以前端成了短板，那么 1 人的问题就极大限制了整个技术团队的效率和产品质量。

项目和产品

在招聘的同时应该抽时间来制定项目计划，若是技术管理者不熟悉业务，须要先作功课熟悉产品的业务形态，这样才能够评估产品的技术难度和工做量，以便作出合适的计划。有了明确的研发计划，公司的运营、业务部门才能根据这个计划作相应的推广运营计划。

除了计划，须要先用脑图把核心业务的领域、模块、功能梳理出来，和管理层一块儿把产品形态讨论清楚，而后在产品研发内部宣讲，让你们对产品的目标达成共识。在初期，产品能够根据这个方向来细化造成产品文档，技术能够根据这个方向来调研须要的技术。

技术和架构

技术架构方面有几点很是重要：

语言

开发语言是招聘以前就应该肯定的。通常而言，技术管理者会选择本身熟悉的语言做为项目最初的核心语言。对于业务型项目，采用 Java 或 Python 这种普适性语言；对于纯高并发的服务端项目考虑 Go ；对于 Windows 项目或企业级项目考虑 .Net ，按照这个方向来作不会出大错。我不太建议在初期融入太多语言，或许不一样语言的结合能够发挥出性能和开发效率的优点。但在初期就混用会增长管理成本，提升基础框架的开发难度，并且每一种语言的开发都须要学习和成长路线，得不偿失。

框架

肯定了语言以后，围绕语言咱们要肯定开发框架。通常而言就是前端的 JS 、CSS 框架、后端的 MVC 、SOA 、ORM 框架的选型。若是没有必定积累，不建议选择自研，能够先选用成熟稳定的开源技术做为开始。项目发展到必定阶段，若是开源技术不能知足须要，在选择自研合适的框架或中间件来进行逐一替换。

架构

包含几个方面的不一样类型的架构，这些事情虽然不可能在很短的时间内都想清楚，但这是领导者必须考虑的。不少公司不少项目在运行了几年以后，核心系统整体上仍是维持了初版的架构，虽然遇到各类问题想要推翻重来，但都由于代价实在太大而搁置或放弃：

• 产品架构：战略是怎么样的，是否须要进行产品化抽象，扩展性是怎么样的；
• 系统架构：网络怎么接入，哪些环节作高可用，涉及到哪些中间件，存储是什么，容量评估；
• 业务架构：多少领域，多少子系统，对内仍是对外，怎么相互支持；
• 应用架构：层怎么分，逻辑层仍是物理层，模块或服务怎么分，模块和模块之间怎么通信，同步仍是异步；
• 工程化：咱们是须要考虑可持续、可迭代的，一个良好的工程结构和工程方式也是初期须要肯定的。好比，肯定项目结构、源码管理方式、分支管理方式等等。

核心业务

在几个创业公司工做时，我都会本身来实现最底层的技术框架或核心业务代码。一方面本身能够彻底把控最难的核心系统，另外一方面能够顺便把技术架构搭建起来。接下去，团队成员就能够在这个骨架上填肉，这样即使一开始没有很好的标准和指导原则，也能够把控住整个项目的代码。

技术难点

除了核心业务，我会在最初就分析项目的技术难点，这些技术难点咱们会选择三方技术来实现。可是一开始咱们就要去考虑之后要脱离三方技术本身实现核心技术的可能性和代价，把这些问题摆在桌面上，让全部管理层都认识到。

除了这些，技术管理者须要作到的很是重要的一点就是以身做则，给你们作榜样。团队的规则和规矩一视同仁，这样，团队成员在执行你定的这规则的时候才没有任何理由拒绝和作不到。

从 0 开始确实须要作大量的工做，研究讨论产品方向，作产品计划，大量面试和新人培训，本身参与部分代码编写，还要凝聚初始的团队和团队磨合。这些事情每每会让你以为分身乏术，但这段时间熬过去后，你就会体会到，这些工做都很是有意义。相反，若是一开始缺失这些工做，让技术野蛮生长，以后的工做就会很混乱。

从 0.5 开始的状况

从 0.5 开始的状况是，公司已经有一支团队，产品也已经上线。因为前期缺少管理，技术方面处于一个烂摊子的状态。开发效率低、问题多，没法知足公司高速发展的须要。这个时候进入公司和从 0 开始的状况略有不一样（但这其实又不一样于成熟公司空降管理层），对内，我会在最短的时间作下面的工做：

熟悉产品

熟悉这个行业或领域，熟悉公司既有的产品，评估产品的技术难度，内心对指望的团队形态有一个底。同时能够花一点时间过一遍现有项目的技术架构和代码，对于现有的技术债也有一个预期。

熟悉团队

对现有团队成员进行 1 对 1 沟通（或者直接点说就是面试），了解每个人的技术水平，当前的心态和状态以及对公司的指望。

开展救火

根据对产品的理解和已经与各需求方沟通的结果，按照轻重缓急整理出目前技术上须要调整的部分，挑选最重要的任务进行突击救火。能够进行小黑屋形式的集中开发，给予团队必定的压力，把工做分配到具体的人。一方面考察每一个人的能力，一方面也考察成员的抗压能力和拼搏精神，追求安逸的人不适合在创业公司工做。若是业务在高速发展，不太建议一开始就停滞业务的迭代，把老项目推翻重来。最好的方式，是先进行必要的重构，等之后每一块业务进行大调整的时候进行逐一推翻。

调整团队

根据 1 - 3 的结果，快速进行团队调整，劝退不合适的人，招聘须要的人才。这些调整是基于一段时间对于产品和团队熟悉后的结论来的。并不建议所谓的新官上任三把火，在不了解团队的状况下直接调整。有的时候可能会心软，认为不合适的人能够去干一些没有那么大技术含量的工做，我也这么作过，但最后都付出了代价。

完全融入

我我的的习惯是挑选比较重要的某个痛点本身上阵，对代码或架构开刀，只有这样才能真正了解你们目前遇到的问题，而且能尽快熟悉业务，你们融入到一块儿。若是时间有限，就把工做放到晚上或者周末进行。只有本身走到了最前线，才能在作出更有利于团队实际状况的决策。

创建信任

做为管理者进入新团队，团队的成员会担忧新上级作出的团队调整会对本身有影响，会形成军心不稳。因此，在进行团队调整时，必定要对核心成员进行确定和鼓励，另外，信任的创建不能仅靠权势，更重要的是，在平常工做中和你们一块儿拼搏，给予你们帮助，和你们创建平等的信任关系。

对部门外，须要同时和其余部门的负责人进行逐一沟通，了解你们对产品和技术的指望。另外，须要和 CEO 进行密切沟通，使本身的决策获得上级的支持。通常而言，我还会接手对公司外部的沟通工做，让团队成员能够更专一于项目。

0.5到1的阶段

公司通过了初创阶段，产品也已经上线运行。接下来产品须要高速、高质量迭代，做为技术管理者须要把各方面都规范起来。

管理须要标准化

创建项目管理流程：

• 是否要使用一些项目任务管理工具，好比 Jira 或 Tower 等；
• 是否要使用一些文档知识管理工具，好比 Confluence 等；
• 选择什么样的开发模式，是敏捷开发仍是传统瀑布开发；
• 制定各类会议制度，好比固定的晨会、周会、总结会等；
• 规划分支使用的流程，代码审核的流程；
• 测试如何进行，选用什么样的 Bug 管理平台，Bug 的分级等；
• 和公司其余部门按期同步并讨论项目整体计划流程。

创建沟通汇报流程：

• 规划平常对内、对外 IM 沟通工具和邮件使用的规则；
• 肯定平常工做流程（评审、提测、发布、上线）；
• 制定每个团队成员的日报或周报的模板。

绩效管理：

绩效管理如何来作，选择 OKR 仍是 KPI ？你们有太多讨论和不一样意见。在 TGO 鲲鹏会的小组活动中，咱们组员也常常会针对这个话题讨论，每个公司都有不一样的作法，这和公司层面的文化、背景、项目属性、甚至是管理层的性格都有关系，没法彻底照搬别人的作法。

我认为一个相对成熟的公司，适合公司的绩效管理方式必不可少，须要不断探索。通常而言，考核是用来激励那些不太优秀的人，特别优秀的人才不管如何考核，他们永远都是是冲在最前面的一批人。可是，任何公司都不可能作到 100% 的员工都有合伙人的心态和冲劲，也不可能 100% 的员工都是世界一流人才。因此，帮助全部员工创建清晰的目标而且进行回顾和考核很是重要，要让全部人的目标都是清晰、具体且正确的。

技术须要标准化

各个环境标准化：

• 定义明确 Dev 、QA 、Staging 、Live 环境的做用、每一个人的权限，以及每个环境的使用方式；
• 创建一套统一的发布系统来处理平常发布。好比，能够封装 Shell 脚本或 Jenkins ，而且明确在线上发布事中过后，包括：运维、开发、测试、产品等每个应该负责的点。

创建技术标准规范：

• PRD 产品需求文档和 UI 标注的标准；
• 开发标准，好比，能够在阿里的 Java 开发规范基础上和你们一块儿讨论，总结出符合本身公司需求的开发标准，而且经过代码规范插件来约束；
• 概要设计文档的标准，文档必须包含哪些点，何时提交评审；
• 概要设计时表结构和服务定义的标准，各类中间件使用方式的标准和最佳实践；
• 自测标准，单元测试的要求，自测不完善测试打回的惩罚等；
• CMDB 的创建、服务器配置，操做系统基础配置，程序安装方式的运维标准化。随着时间的推移能够总结出适合本身团队标准或最佳实践，全部的标准应该是全部团队成员共同承认和遵循的，能够按期就这些标准进行回顾和讨论。

创建监控管理制度：

• 搭建日志、监控报警基础设施。好比，可使用 ELK 、Grafana 、InfluxDb 等来搭建；
• 统一公司的日志、打点框架，规范明确项目的日志和打点标准；
• 为各个业务创建监控面板和报警规则，明确报警处理标准；
• 定义事故分级流程，复盘方法以及追责方式；
• 定义运维平常监控容量巡检方式以及应急响应预案。

1+ 的高速发展阶段

随着业务规模的扩大，极可能有了多条产品线；随着团队规模的扩大，完全扁平化的组织架构可能没法知足须要；随着访问量的增大，对技术和架构的要求也愈来愈多。这种状况，无论是对技术的要求仍是对管理的要求都更上一层楼，这个时候须要在标准的基础上再作一些管理和组织结构的演进，站在更高的角度管理去思考。（这个时候作一些细枝末节的工做对于总体的意义就不大了）。

技术方面的升华

随着公司的发展，产品要么形态丰富，各类产品和业务衍生出来，要么产品形态不变，访问量急剧增大。对于前者，管理方面很容易犯的一个错误就是简单的进行业务线的拆分和招人、招人、招人，造成 N*20 个这样的团队，每个团队之间相对独立，技术没有沉淀。对于后者，很容易犯的错误是经过堆服务器和堆运维来抵挡压力的上升，致使技术架构老旧问题增多。这种粗旷风格的团队扩张是不太健康的，更好的方法仍是多折腾：

1. 个人建议是经过进行技术和组织架构的调整，造成专才，造成纵向技术线，把通用技术提炼出来，让整个公司均可以积累统一的、可以向前发展的技术平台；
2. 强制经过自动化手段把人解放出来，人应该去作创造性的工做；
3. 消除团队安逸的状态，让团队或业务线之间造成竞争，保持冲劲。

组织架构调整

随着业务规模的扩大，团队规模也在扩大，仅仅对业务线的技术团队进行横向拆分（ X 维度拆分 ）还不够，还须要有专门的垂直团队服务于横向的业务团队。经过创建架构、中间件、运维等垂直团队服务于全部业务团队，确保技术和架构的统一（ Y 维度拆分 ）。

若是团队人数超过 20 不足 50 ，咱们须要增长经理层来管理一线员工，变为三层架构，若是人数超过 50 不足 100 ，咱们须要增长高级经理来管理经理，变为四层架构（ Z 维度拆分 ）。固然，可能还会造成一些虚拟的或实际的技术或项目管理委员会，对技术人员的发展、技术的标准化、公司层面的技术大任务进行定义和协调。

补充如下几点：

1. 随着层级的增多，管理者对于一线员工的触达会愈来愈难，可能致使执行效率下降。这个时候，对下属主管的任用和管理很是重要。与管理一线员工相同的是，主管也须要绩效考核和标准，不一样的是，主管们承担了管理职务，一线员工是由他们直接管理和影响的，此时对于主管的培养很是重要。不只仅要让他们使用 CTO 原先定的标准和套路来管理，更多的是让主管明确意识到本身的管理职责，激发出他们本身的管理风格；
2. 在确保主管被充分受权，而且有团队管理自治性的同时，最好提供一个通道，让一线员工有机会表现和表达本身的想法，让高层管理者能够了解到任何一名员工的想法，保持公正透明；
3. 在公司这个阶段，能够和人事一块儿把人员的职级要求和薪资标准进行统必定义，要和绩效考核结合起来，造成固定周期的职级调整方案，造成明确的上升通道。让每一位成员意识到只要经过本身的努力，在公司内部一样能够走的很远；
4. 业务团队和平台架构团队的目标使命不一样，会存在一些矛盾存在。做为 CTO 要作好引导，让业务团队认识到架构统一的重要性，让架构团队认识到业务团队的压力。也能够鼓励团队之间的人员换岗以及作一些技术团队的培训，让架构团队理解业务，让业务团队深挖技术。

创建文化

人毕竟是社会动物，是有感情的，若是公司全部的管理手段都是硬手段，员工很难从心里承认。咱们能够和 HRBP 配合，打造有团队特点的技术文化。好比，分享文化、开源文化、学习文化、鼓励自动化的文化等。

咱们能够创建技术团队的微信公众号，让全部人一块儿来发文和运营。能够把自研的项目开源出去贡献给社区，让社区一块儿来完善，能够组织按期的公司内部或公司与公司之间的技术培训或交流，组织一年一度的技术之星、产品之星评选等等。初期能够经过使用必定的奖励激励手段来传播固定技术文化，造成文化后，每一位团队成员会以为工做不只仅是完成我的的任务，而是在一个集体中成长，在团队中生活，有归属感价值感。

创建价值观

通常而言公司层面会提炼出 3 - 5 项重要的价值观，技术团队也能够在此基础上细化、提炼技术方面的价值观，并归入考核。

我的认为价值观一方面能够给咱们定一个大方向，好比，咱们须要怎么样的人；另外一方面又相似于心理暗示，潜移默化的影响每一位员工。慢慢地，员工会演变为符合公司价值观的人（变得和公司有“夫妻相”），或者意识到没法适应价值观而主动离职。好比，若是能够定义一专多能、主动承担、敢于创新、言出必行做为技术团队的价值观，而且展开列出一些子项归入考核。即便员工的业务能力没问题，但平常的表现不符合价值观，那么他只能是一个过客，没法和公司一块儿发展，这也是为何不少大公司如此强调价值观的缘由。

团队规模小的时候，咱们只要本身冲在前线就能够很好的管理团队，在规模中等的时候咱们能够利用一些标准和制度进行管理，在规模更大了之后，咱们须要更高维度的文化价值观等手段来感染到每个员工，让员工认同公司，这比约束命令式管理更有效。

处于这个阶段的公司，CTO 不只要作好对内的管理工做，还要抽出时间作一些对外的工做，来帮助公司作品牌宣传，而且用技术争取更好的资源，好比，按期和同行以及投资人交流，组织参与一些技术讨论，跟进行业趋势等。

最后，想聊聊技术如何服务于公司战略？

就我我的而言，我以为两点很重要，一是坚持，二是应变，三是要思考。围绕这几点，我列了一些技术服务公司战略的要点。

产品技术部门最基础的职责

做为产品技术团队，最本职的工做仍是持续高效输出高质量、高可靠的产品，知足公司的业务须要。而且在不断提升可用性的同时，经过自动化、标准化提升效率，节省人力成本。在组织规模变大了之后，还能经过管理手段来保持团队的高效。随着业务和团队规模扩大，作到这几点并不容易，但这只是技术服务于公司战略的基本要求。

以技术创新把不可能变为可能

举个例子，有一次，业务给我提了一个需求，由于受到底层外部接口的限制，这个需求没法实现。可是业务表示，为何别的公司能够实现，咱们就不行。这时候，我才花时间去认真思考是否有一些突破的办法，尝试找到别人的实现方式，最后想到了能够绕开限制的方式，把这个项目实现了。我没想到的是，项目上线后业务告知当时问错了，其实别人也没法实现这个东西，由于只有咱们实现了这个技术，因此不少人都愿意来找咱们合做。

不少时候，我会认为本身有十几年的技术研发经验，我对公司既有技术足够理解，我觉得我能够对一件事情是否能够实现很快下结论。其实这是不对的，在收到外部需求的时候，应该反过来思考，先假设这个需求是必须实现的，或者竞品已经实现了的，在拒绝别人以前，给本身几天时间，给团队几天时间来想一下怎么去实现，若是你作到了别人作不到的，那么你的技术就是核心竞争力。

创建一支能够打快战的铁军技术团队

随着公司技术的标准化和成熟，团队应该 具备打快战的能力，可是稳定的业务每每会让老兵们进入温水煮青蛙的状态。做为技术管理者，应该用各类手段来激励你们的斗志（好比搞阶段性的重构、黑客马拉松比赛），保持团队的活力。这样，若是有新开辟的项目，能够在公司内部轻松找到并造成一支敢死队来参与战斗，超高的执行力使得新业务能够尽快进行低成本试错或抢占市场，这也是技术产品团队成熟于否的体现。

根据战略及时调整团队架构和技术架构

无论是团队架构仍是技术架构应该有必定时间的先行，通常而言对于线性发展的项目，公司目前若是处于 A 量级的 PV ，就应该开始储备十倍 A 量级 PV 的架构。根据业务的发展估算技术架构的挑战，提早半年或者一年进行新一代架构方案的确立，确保技术不拖业务后腿。团队架构也是一样须要先定义骨架，再在每个可能的职位上进行填坑招聘。技术管理者须要对公司的战略敏感，根据公司的发展和战略，提早作好这两个架构调整的准备，并在须要的时候及时应用调整。

提炼核心技术，产品化产品，探索进行产品输出的可能

若是作的是 2C 的产品，在一个领域作了多年或许就有能力把核心技术或产品提炼出一套 2B 或 SaaS 的产品来卖，若是成功，这就不只仅是一个 2C 的产品，极可能又多出一套 2B 的产品甚至是一套 2C 的平台。若是作的是 2B 的产品，或许就要思考一下，如今的产品是复制粘贴的定制化产品仍是彻底配置的产品化产品，若是不是，怎么让他更通用地进行产品化，减小人力成本。产品化平台化的过程是一个痛苦的抽象过程，对技术的要求更高，不过一旦实现就可让公司的用户和规模获得爆发式发展，真正的技术改变战略。

关注前沿技术，思考前沿技术和公司业务的结合

目前正处在技术变革的一个关键阶段，在将来 5 年内，垂直细分的 AI 将会变得成熟，区块链也可能会出现大量的实际应用，技术管理者应该时刻关注这些技术，不断思考可能的结合场景。这个世上不缺爱思考的人，但不少懂业务的人不懂技术，懂技术的人又不能理解业务痛点，只要积极关注前沿技术并和业务专家保持讨论沟通，说不定哪天就会碰撞出具备革命性的产品。

- End -