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 人，不需要特别复杂的组织架构，所有人直接向你一人汇报也可以。在项目执行过程中，项目经理甚至是产品经理可以帮你负责一部分管理工作。在初期，虽然彻底扁平化的架构会很累，但有助于提高效率和执行力。
人员和招聘
对于一般做产品的初创公司而言，业务量不大，不需要高端人才，需要的是踏实肯干、愿意拼搏、愿意与公司一起成长的具有相同价值观的人才。公司初创阶段各岗位需要大量招人，选择合适的面试方式和面试难度非常重要。我会通过笔试初筛，以节省时间，避免和不合适的面试者礼节性聊天。
我的笔试有两个特点：
1、可以开卷
我不反对现场拿手机查资料，但是因为笔试时间固定，现场查资料往往意义不大。第一，我的笔试题不是网上搜的，没有现成的答案；第二，大部分内容考察的都是技术细节或对技术的整体理解。如果面试者之前不理解或是没有经验，临时抱佛脚用处不大。
2、笔试考察的知识面是比较全面的
比如，后端的面试题涉及到语言基础、算法、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 进行密切沟通，使自己的决策得到上级的支持。一般而言，我还会接手对公司外部的沟通工作，让团队成员可以更专注于项目。
本文首发于TGO微信公众号，欢迎扫描页面左上二维码向我提问。