你好，我是有米科技 CTO 蔡锐涛。有米科技已成立 8 年，从创业期到发展期再到平稳期，这一路走来，作为技术管理者，我有很多思考，今天分享给你，希望对你有用。

了解行业发展趋势

创业前有必要了解行业发展趋势，做好心理预期、人才准备、资金储备等。每个公司都会经历 5 个发展时期，即技术萌芽期、狂热期、幻想破灭期、复苏期与平稳期。

公司在不同时期，技术团队的状态也会不同。首先，在技术萌芽期，所有人都非常兴奋，加班、熬夜、赶工都不是问题。比如人工智能出现时，技术人觉得“这就是未来啊”，所以创业的信心爆棚。之后进入狂热期，可能会接到大量的行业风投与外界给予的资源，这时也是泡沫最大的时候。紧接着会跌入谷底，因为理想与现实差距过大，幻想破灭，此时需要寻求新的增长点。等你扛过这段时期，就会进入复苏期，也是高速发展阶段，这时该考虑如何让团队维持商业化，也是证明自己商业能力的时候。最后进入平稳期，遇到行业天花板，就该考察新机会，寻求新的突破点了。


所以，我会围绕创业启动期、高速发展期与寻求突破期这三个阶段展开分享内容，每个阶段都需要考虑人、财、物这三个问题。对于技术管理来讲，“人”即人才梯队与团队建设；“财”是团队赚钱的能力，理清团队状态和业务需求，这一点很重要；“物”就是对技术栈、技术架构的选择。

创业启动期

一、团队状态与业务需求

创业前期，团队成员目标一致，凝聚力非常高，此时，急需出产品，推向市场，快速迭代。

有米科技刚起步时，我们还在读大三，当时没钱、没办公室，于是想尽办法去忽悠楼管，从她手中拿到了学生宿舍活动室的钥匙，我们在活动室埋头苦干一个月，做出了第一版产品。当时的感觉就像你在做一件可以改变世界的事情，很有激情，所以你为此可以做出任何牺牲。

二、技术栈

在创业启动期，对于技术栈的选择非常重要，我跟很多创业者交流过，技术合伙人想法过于天马行空，喜欢炫技是不少创业者头疼的问题。

我认为，技术创业应该尽量避免使用新潮技术，我们就深受其害，而是要尽可能减少技术成本，使用成熟、稳定的技术，即使那不是自己喜欢的技术。

举个例子，早期的时候，我们在 MongoDB 2.4 时就开始使用它，当时存的数据量不到一亿，使用非常顺畅，但当数据量达到十亿时，数据库平均两天出现一次故障。我们找了一些国外公司的使用经验，但是仍旧没解决，毕竟是一个比较新的数据库。最后迫不得已，改用了 MySQL，虽然它又老又无聊，但稳定、好用。

另外，在创业初期，要专注于自己的核心业务，使用一切外部能够提供的工具。

三、重视技术文化建设

首先要重视知识储备。虽然创业前期人少，但是一定要注重知识储备。这是我们团队受益至今的一件事，我们在创业第一年就建立了自己的 WIKI 系统，将产品设计、架构，以及每一次遇到的故障和解决方案，甚至每个决策，都写进 WIKI 系统中。逐渐累积，它就会变成宝藏，甚至现在在招聘与培养人才时都能用到它。

其次要启动技术文化建设。早期注重技术文化建设也很重要，当时，我们会在每周五学习硅谷的 TGIF（thank God it’s Friday）分享会制度，公司二三十号人聚在一起，随意聊各种各样的话题，包括用到的好用的 APP、吃到的好吃的食物等。不仅加深了彼此间的关系，还能加上对公司的认同。那批最早的核心同事现在都已经变成了公司技术文化的布道者。

高速发展期

一、团队状态与业务需求

当公司进入高速发展期，业务可能一个月翻一倍，团队像打了兴奋剂一样冲劲满满。这时，业务增长非常迅速，人员大规模扩张，沟通、协作效率逐渐降低。

二、技术架构

在高速发展期，关于技术架构有三个关键点：

第一，Design for Growth，也就是为你的 10 倍增长设计。当时，我们也遇到了很多发展问题，我经常去国外交流请教经验。在理念方面，我最大的收获就是：你每个模块的设计、重构都要为 10 倍的增长而准备，按照这个 10 倍指标，去做升级。因为在重构的过程中，业务还在不断增长，等重构完成后，新的架构需要能够满足新的业务需求。

第二，重视人员的知识储备，遇到问题时再学习就晚了，应该未雨绸缪，着眼于下一个业务量级所要面对的问题。

第三，设立基础研发部门，实现基础组件服务化。当时我们设立了一个基础研发部门，把面向机器的人员剥离出来，只留下面向业务的人员，他们不用再担心机器层面的问题，可以专心处理业务问题。

这样的组织调整在大公司里司空见惯，但对创业公司来说，早期并不适合做这件事，也没那么多人手，但在发展期，当你能够预见问题的时候，就应该开始去做这件事。

三、沟通协作

在高速发展期，我们会直面沟通复杂度的线性增长。在这里，提升沟通效率有两个关键点：

第一，在于工具，重视内部流程自动化，不要吝啬对工具化的投入。当时，我们设立了一个新的小组，专门负责优化内部的协作流程工具，保证沟通协作效率。

第二，在于人才梯队建设的改变。从人管人、人带人到文化、制度管人，培养人。当时，我们在技术团队做了一个尝试，让所有的核心技术人员写下他们的最佳实践存入知识库（比如在 Python 中对于数据的最佳处理方式），用文字来沟通、来传递信息，可以达到一对多沟通的效果，从而提高协作效率，降低部门沟通成本。

四、人才梯队建设

在这方面，我们也做了一些改造组织架构、技术体系的事情，来适应大规模招聘带来的问题。

首先是人才管理方面，保持社招，重视校招，引入 OKRS，因为我们在广州的大学城，又重视校招，所以，在公司快速成长期，只有 20 名正式员工的情况下，招入了 30 个应届实习生。因为在 2013 年左右，大公司招人不计成本，我们在社招方面根本抢不到人才，所以就只能自己培养。当时校招的 30 人，最后留下来的将近 10 人。

我们的培养方式就是以老带新，新同事学习老同事的教程和最佳实践方案，然后将理论投入实践。

其次是技术架构方面，从靠人，到靠系统自动化管理，适应高频度的迭代上线。我们只有三个人负责海外的业务，所有的服务器都是自动化。只有机器高频度的迭代上线，才能使人尽快响应这么快的开发节奏，使系统能够响应整个业务发展。

然后是组织架构方面，我们做了分层，拆分，用单独项目组面对高速发展的业务需求，用独立团队把握基础架构的弹性和稳定。

最后在培养方面，我们建立了领域委员会和学习机制，每周有专人组织分享会，我觉得分享的难点在于愿意分享，所以，在创业早期，就应该鼓励分享，什么内容都可以，逐渐形成分享文化。

五、知识系统管理

高速发展期，人员流动大，所以要重视知识沉淀，降低人员流动带来的传承问题。作为技术管理者，要吸纳技术人才，更要将他的能力留下来，对此我总结了三点：
1. 总结公司各领域最佳实践到 WIKI。
2. 梳理公司技术栈，减少重复造轮子，减少重复招人带来的成本。
3. 重视内宣，鼓励技术团队对内宣传自己的优秀组件，鼓励同类团队间的交流。

我认为 CTO 中的 T 是 Talk（讲话），你要多谈话、多分享，多宣讲正能量，多营造交流氛围。比如，我们的程序化交易团队，会跟算法团队一起交流。我们鼓励交叉分享，这样不仅能互相学习，还可以碰撞出更多可能性。

寻求突破期

一、团队状态与业务需求

当我们最初选定方向时，其实就确定了天花板。比如，选择做游戏，游戏在中国的市场不到千亿，腾讯和网易就切割掉 70%，剩下的 30% 既是你的市场，也是你的天花板。当然，在公司寻求突破时，就说明它已经成功了一半，目前我们正处于这个阶段。

在寻求突破期，业务多且稳定，在满足财务指标的同时，需要寻找新的突破点。这时人员流动也较大，因为泡沫挤出后，我们就不需要那么多人了。

另外，因为你要不断尝试突破，而新项目尝试的失败率也非常高，相当于再次创业，所以，成功率在百分之二就已经非常不错了。

二、技术架构需求

既然尝试突破是当下最重要的事，首先我需要不断提高组件化能力，降低试错成本。比如我们的公众号业务，利用爬虫软件每天抓取全国上万个公众号文章内容，供业务人员参考，降低试错成本。

其次要围绕数据，建立在数据之上挖掘需求，给运营团队提供非常好的工具，帮助他们精准分析数据。

三、寻找突破点

我认为，在平稳期寻求突破的最大挑战是，从关注一个点，到关注多个点，对于这个挑战，我有三点建议。
1. 走出去，强化情报和线索搜集能力。
2. 保住人，就是核心人才保留计划。我们会尽量满足核心人才的需求，比如钱、婚姻等，也可以送他读 EDP、MBA、EMBA 等等。
3. 强技术，提供更好的技术研发条件。这也关乎试错率的问题，作为技术管理者，要鼓励技术创新，而创新过程中一定会有失败，也要求技术人员有承受失败的能力。因为有的人在失败一两次之后就受不了了，所以技术管理也要区分哪些人适合试错，哪些人不适合。对于后者，那他只需做好自己的工作就可以了。

四、组织变革

组织架构其实是围绕各种极端性变化的，早期人少，没有关键点，到发展期，随着人员能力的增长，组织架构需要进行优化，从而提升团队效率。但在寻求突破期又有不同，我希望我的组织架构能多变化，在碰撞中寻求最优架构，我们组织变革的关键点是拥抱不确定性。

比如我们弱化部门，强调项目组，提高组织的灵活性，鼓励大家用脚投票，如果你在某个项目组待不下去，可以调换项目组。我们会及时处理状况不好的项目组。

在业务相对稳定期，大家的工作内容相对固定，所以我要利用这段时期让所有人都能多了解其他工作内容，而不是只盯着自己手头的一亩三分地，特别是那些优秀人才。

总结

创业初期比较容易忽略文化建设；高速发展期，重要的是人才梯队建设和知识沉淀，以便传承；而寻求突破期，就要营造氛围，加深人员之间的联动，碰撞出最大能力。

作者简介

蔡锐涛，有米科技 CTO，联合创始人，中国最早的移动营销技术专家，专注于移动广告平台及移动应用商业化变现方向相关产品技术的研究。