快速成长的创业公司研发模式进化史

冯军@磁系资本

前言

近几年的创业风潮，互联网类的新闻看多了会让人容易产生一种错觉：成功来得太容易。从几人到几十个人的创业团队，成立几年后动辄获得几千万美元投资、估值上亿美元。比如当年的Facebook、Instagram，最近风声水起的滴滴、Uber、Airbnb等等。

而在当下火热的互联网创业浪潮里，技术人员的需求也是供不应求。技术团队伴随着公司业务的高速发展，很快从刚开始的三五条枪就迅速地扩张到几十、几百人甚至更大的队伍。几个人的小团队作战，一人身兼多个岗位的工作，而规模发展越大，责任分工越明确，岗位职责也越来越明确和具体，技术管理者对于研发团队的管理随着团队的成长而不断进化。不得不说这期间从小至大的快速递增过程，对于公司的技术管理者来讲是件非常痛苦的事情。

第一部分：技术选型的演进

技术选型对于创业公司的发展至关重要，选择正确的技术选型方案会让团队少走弯路，让产品更快推向市场，比竞争对手更快地赢得客户，更容易获得更多的融资，拥有更多资源投入产品研发和市场扩展……如此往复更容易形成企业发展的良性循环。反之而言，每一次错误的选型都会给公司带来巨大的技术债务，在互联网圈子里，有很多创业初期团队经常花上半个月时间停止新业务的开发，加班加点地重构系统，对于任何一个技术管理者和员工来讲都非常痛心疾首。对于初创团队的技术管理者，最重要的事情就是选择正确的技术体系。

一、善于借力，使用成熟的开源产品

可以说现在是创业的黄金年代，人人都在喊创业，很多人拿了一个BP就在喊，我只差一个程序员就能成功了。也是这样的商业环境下，很多企业都开始转型做开放基础设施建设，各种云，各种开放平台，只有你想不到的，没有你用不了的。在基础设施方面比如阿里云、亚马逊AWS、腾讯云等平台，提供了平台基础设施的所有服务，而且越来越精细化，从最开始提供云服务器到云数据库，随着这几年的发展，逐步细化到弹性计算解决方案，甚至到中间件的开放服务。可以说有了这些可以直接为公司省下很多人力的投入，在安全和稳定性还有充分的保障。技术框架不同语言也有很多选择的产品，各种开源的中间件、组件等等技术发展以及很成熟，一般来说现在的创业公司从0到1打造一套线上运营的产品已经不是什么难事。

二、打破常规，不要局限于语言和框架本身

技术语言对于研发老司机来讲学习成本不是很高，所以一般都会几种比较熟练的语言来应对不用的场景。但是很多在面对创业公司的平台技术语言选型很多人又开始纠结了。技术界至今的未解之谜---PHP和Java到底谁是最好的语言？对于系统本身来讲，开发一套系统，选择什么语言真的不是很重要。自各种编程语言诞生以来，关于此类的争论一直没有停止过，比如“Python更好，因为……”、“PHP是战斗力不足5的渣，Ruby才是王道”、“Java性能更强，代码质量更高”……此类话题如同一针见血，可以瞬间点燃码农们的斗志。最后我们发现，其实编程语言并不重要，重要的是你拿它做什么。所以，没有最好的，只有最合适、最顺手的。选择任何一种语言要考虑使用成本和应用场景，一般的大型平台多种语言混合也是再正常不过的事。

技术框架是平台的第一着力点，在创业初期很多公司直接拿上就开始开发功能，虽然这样产出很快，但是势必给以后的业务发展系统上埋下了巨大的雷。等业务量发展到一定阶段的时候，开始出现打开很慢或者某个接口出现BUG导致系统直接宕机。有过这样经历的同学一定会想到，在刚开始开发1.0版本系统的时候，一定要考虑系统的分布式和独立性。单纯的利用开源框架来构造系统虽然快，但是一般的成熟开源框架都过于庞大和臃肿，系统灵活性不强，系统的吞吐性能也很弱，也不能把业务单独分离。所以在最开始的时候做好系统架构设计，可以为以后爆发式的业务增长准备好重构的基础，业务模块独立化，即便是一块块的业务单独重构也不会影响系统本身的运行，为公司发展提供了良好的基础。

三、自力更生，伺机自己造轮子

高速公路上的汽车换轮子无疑是自寻死路的做法，如何保障车轮不需要更换轮胎在高速上平稳行使。技术团队发展到一定阶段的时候势必要开始自己造轮子，这里的造轮子不是指要重写MySQL或CDN，而是根据系统的瓶颈来寻找合适的解决方案，比如在一定量的时候开始写一些数据中间件、消息分发中间件，这样的轮子才会更适合自己的平台，也保障了系统在业务量大的时候不会出现各种停止开发新业务重构系统的现象发生。

再往深度技术管理者的技术选型不仅仅是某种语言或者某种架构，而是要纵观于技术开发与技术团队管理的高度来梳理，比如使用一些项目管理工具，代码质量管理体系、文档系统，持续集成工具等等。

第二部分：技术架构的演进

系统平台的技术架构不是设计出来的，而是一步一步随着公司业务的发展而形成的。总结技术架构的演进为四个字：合脚的鞋。鞋子合不合脚只有自己才知道，技术架构的演进亦是如此。作为一个技术管理者来讲，在技术团队的管理与发展方面，不仅仅要做好技术架构的迭代设计，还要考虑团队的组织发展、未来业务领域的细分，甚至之后的组织事业部拆分，业务单元由不同的部门来单独负责，团队越大分工越细，琐碎的各种扯皮的事情也随之而产生。技术管理者不仅要做好技术的把关，还要从平台的发展考虑团队成长生态体系的建设，从而防微杜渐。根据系统的发展，一般的创业公司技术架构的演进也分成以下几部分：

• 1.0时代：蛮荒的原始社会

  在创业初期，平台系统体系的建设对时间的要求很高，往往团队比较急于快速实现平台的功能，统统都是拿来主义，比较忌讳造比较复杂而又作用不大的轮子。很多时候为了这些前提不得不放弃很多设计，最简单系统就分为前台后台两套系统，快速上线产品，到市场上灰度测试，不断快速迭代新的功能需求，打磨成一个用户可用的产品。

• 2.0时代：工业革命推动机械发展

  当平台的业务量逐步提升，随着市场和运营团队在市场的迅速铺开，慢慢系统就开始有点扛不住了，所以在这个时候要开始对系统进行垂直化的系统架构拆解，按照不同的业务领域模块进行降级拆分。随着业务量的提升，技术团队的不断磨合，逐步将技术平台拆解成多条线路，技术团队拆分为多个开发小组，多条业务线同时并发开发，逐步形成垂直结构的系统架构。垂直结构的系统架构发展到一定阶段避免不了系统之间的调用增多，接口耦合度高、相互依赖性强。平台产品越多，系统越复杂类似蜘蛛网状的调用结构就形成了，系统架构关系逻辑复杂，所谓牵一发而动全身，其中某一个API异常会影响整体业务。到现在很多知名的平台都会有这样的问题，系统沉淀的时间长，没有合适的人和时间处理遗留的坑，很多业务不敢随便修改，年代久远，最开始设计的时候没有架构意识，导致功能一直没人敢改，非常痛苦的事情。当出现这样的情况的时候，选择合适的时机果断重构系统。

• 3.0时代：互联网微服务架构时代

  微服务是技术界这几年比较火的词，基本在各个技术大会上讲自己公司的系统架构不提一下微服务就会显得特别low。服务化与否还是取决于系统本身，到了一定量的时候再去考虑使用容器弹性计算，使用微服务拆解业务按职责划分微服务，服务去中心化，前后端彻底分离，按职责微服务拆分，独立部署，技术团队也形成虚拟team协同并发研发，提升效率，这时候部门只是管理职能，形成的小组式的敏捷团队将更具备效率。

  系统架构服务化使得系统更加松散，相对独立，合并、解耦、清晰化是系统架构的目标，所有服务可实时监控调用日志监控可视化在这个过程中非常重要，API的健康度，调用状况跟踪以及自动化的巡检是必要的过程。 随着前端体验要求越来越高，但研发还是原始状态，大量的代码纯靠手工打造，页面效果高度依赖设计团队，产品原型和UI设计图的还原程度是个大问题，所以前端的架构需要进一步的进化，前端开发由MVC进化为MVVM思想，所有前端页面组件化、模块化。随着前端能力越来越强，后端也进化为前端提供各个接口返回数据，后端轻量化的重点核心在于SOA服务化体系打通。服务微型化从基础服务开始，按照service粒度拆分，使用轻量级的协议，可兼容多重语言技术栈，使得系统不受限于技术语言本身。

  这时候除了系统本身以外还要考虑配套的基础设施，比如运维自动化：将业务单元模块固化为标准单元、发布前自动测试发布流程标准化、数据库脚本版本化。不断向持续交付，持续部署，自动运维一步步演进。随着业务系统增加，从而加速了平台的迭代过程，可能每天都会面临多次发布，自动化部署项目的推进也将为发布的过程加速。自动化部署需要注意的几点：

  • 接口测试自动化
  • 使用工具比如Jekins实现持续集成
  • 研发一键部署，自动发布工具
  • 对多环境的支撑（开发环境、A/B test环境）
  • 对系统的安全隔离防护审计
  • 建立发布失败的快速回滚机制

第三部分：管理模式的演进

历史的时空来观照企业组织的变迁，我们看待企业成长的历史与逻辑的起点是怎样的？在CTO班第四单元的课程讲师讲到比较认同的观点，合乎逻辑的描述应该是这样的：企业的产权上属于单个个体业主，经营单一的产品，在就近的当地市场上销售，拥有少量的雇员，岗位职责分工不明确，企业的经营活动上没有供、产、研、销以及客户服务等职能的分化，这是一种混沌未开和初始状态的企业。企业从混沌未开的状态向逐步细化组织关系的结构式发展伴随着业务推进和团队的壮大而逐步演进。

早些年有个朋友跟我说：“我现在所在的公司制度不健全，培训机制、升迁机制、薪资制度等都不公开，而且几乎就是一个人要包办所有的事情，没有部门分工的观念，什么都要懂一些，但什么都不专精，真的很烦，而且什么事情都是老板自己说了算，对或错很讲运气，可能这就是小公司的问题吧，下次我要换一家大一点的公司。”今年他告诉我：“我现在的公司制度很完善，分工很明确，但每次要做一件改变就要层层上报，然后再经过一次又一次的会议讨论才能定案，有些想做的事情又因为公司有过去的包袱而不能做，加上部门的高度分工，其实很多东西都学不到，大公司就是这样子，太讲究管理，讲究制度，一点都快不起来。”聊到这边，顿时觉得很有意思，我就跟他聊了一下，他突然冒了一句话：“大公司小公司好像都有问题，我看我应该去创业才对。”其实他冒出这句话我一点也不讶异，因为同样的话我在网络上已经不知道听了几百次，很多人都是因为在工作上不能调适而兴起创业的念头，网络上的人我不认识，但这个朋友我可再熟悉不过了，我连忙问他：“你是认真的吗？”他说：我有想过，因为给人家打工始终不能开心的做自己想做的事情。我说：那你想做的事情到底是什么？他说：一时也说不上来，但我只是希望不要老是有一堆限制。我说：你有想过创业是什么样的光景吗？他说：没有。但在有一定规模的大公司中可不一样了，因为人多，开始会出现中阶主管，而为了有效的管理这么多人，没有清楚的制度是不行的，否则老板每天为了处理员工的问题就够他疲于奔命了，他必须要有一些规则告诉员工们应该怎么做才对，管理制度就这样建立了起来，同时因为公司太大，老板必须授权给底下的主管们去协助管理，但主管们并非老板，他们不是公司的所有人，他们仅能就他们的权责范围下去做事，对于责任会撇的很清楚，而好处则是要的很理所当然，所以你在大公司中没办法放手做你想做的事情也不是太怪的事。

大公司组织的发展也是从创业的点点滴滴开始沉淀、成长而成为大公司，技术团队的演进发展也是从混沌未开的状态向着精细化岗位职责分工的发展，也要建立起必要的制度来约束和管理。团队核心三要素是：人、工具和流程，使用合适的流程和工具来提升人效。对于简单高效的团队来讲演进的关键：适时而进。

天下武功唯快不破，立刻要有成效的技术平台是个伪命题。很多传统行业和老板们都认为互联网是杀手锏，殊不知任何产品的诞生都需要一步一个脚印，特别是技术可能会成为企业的生命线，作为技术管理者不要盲目追求高大上的东西，先让业务动起来，再做技术与业务的平衡，搭建团队合理分配资源，具体事情具体到人，充分使用开源和成熟产品，不要重复造轮子。

一、初期聚焦业务，及时调整节奏

我们在面对爆发式增长的业务需求都会面临这些问题：

• 业务需求太多，开发排期半年后
• 没有时间和精力做基础架构
• 产品研发同学天天加班，很苦逼
• 业务方三天两头改需求，技术与业务部门动嘴巴的沟通快发展到动手了！

面对这些问题我们要如何面对？

• 初期以业务优先，分清楚紧急重要性
• 逐步抽取人员建设基础架构
• 重视业务规划和系统规划，实时变化调整
• 做好充分有效的沟通，统一团队的思想，集中火力进攻
• 结果导向，让每个人都成为主人，都成为产品的Owner

二、寻找技术、业务、管理的平衡点

快速发展的团队暴露出明细的问题：

• 技术宅专注技术，不懂管理！
• 团队效率低下，气氛不和谐

如何有效地解决这些管理问题？

• 合理的时间分配，加强管理授权，技术管理者不要一心扎在技术上，而是花时间去管理团队，技术上去找更合适的架构师来负责，放手出去会取得更好的成绩
• 根据业务增长情况实时加强团队力量
• 有效地制定计划，按里程碑向前推进
• 宣导人人都是产品经理的思维，说人人都是产品经理是扯淡的，但是每个人都可以站在产品的角度去审视自己的业务块，有没有真正解决用户的需求，解决用户的问题

三、关注团队的核心：人

人才是每个创业公司都紧缺的资源，特别是技术类，找到比较合适的人更是难上加难。在技术招聘方面要注意技术能力和团队精神、创业心态的权衡，尤其对于不合适的人处理越快越好，否则会形成巨大的负能量！相比于技术基础，更看重的是个人价值观。

创业公司招人难，技术管理者要学会放下手中的事情去找人，花70%的时间来招人，30%时间放在技术上，不要死盯着技术去做，找比你更合适的人来承担技术的工作，花时间在人的管理。

做有效的团队沟通，技术人员性格比较内向，一般都不善于沟通，氛围不好的技术团队甚至会出现整天没能讲上几句话的尴尬局面，这时候要积极调节氛围。比如形成虚拟项目小组，破开部门之间的隔阂、能动嘴就动嘴沟通，拒绝邮件、QQ、微信的沟通。

团队激励与团队文化的建设，技术人的情节在于成就感高于一切，使用正确的精神激励方式，在适当的时候给与一定的物质鼓励。学会向外部借力，比如市场部门或运营部门的鼓励。团队文化也至关重要，文化是最坚实的工具，有价值的企业一定是文化先行，在团队形成团队独特的文化、核心价值观，夯实成员的归属感，大力发扬工程师文化，打造分享文化鼓励内部分享、外部分享等等。

写在最后

用冯大辉的一句话来分享给所有有创业梦想的同学：与其苟延残踹，不如从容燃烧！