作为技术管理咨询顾问,在服务的企业越来越多以后,我就发现一个问题,那就是创始人对于技术团队的定位往往是一种简单而固定的,就像奥运口号一样:更高,更快,更强,就如同做一个架构的时候似乎就是奔着完美结构去的,阿里用啥我用啥好像就不会有错一样。技术团队的演进本身也是有所侧重和变化的,也不是单纯追求规模的扩大以及素质的提升那么简单,更多的是随着公司的发展而演进的,在我看来演进大概分成三个阶段:

第一阶段:做得快

冯大辉曾经说过:“创始人往往在早期高估技术,而在后期则低估技术。”我分析这个现象背后的原因在于技术在早期对于创业人来说是切实感受到的痛,因为这个时候想法很多却没有人来实现,或者有了新的想法改得不够快。面对技术合伙人缺失的情况一般很多创始人会请外包,好处是终于有的东西了,但是问题一定是后续的修改,做创业的本质是要变化,外包是按劳计费,大家都知道外包是技术的底层工作,基本上所有的互联网公司招聘技术的时候,一看见有外包经验都是减分项目。这么做的唯一希望就是创始人运气好,他设想的产品恰好满足了用户的需求。不是说不能用外包,而是说要知道怎么用好,对于外包的使用建议就是“短平快”,需求清晰,时间周期短,验证完扔了也不可惜,这样成本可控。

如果不幸以前没有跟优秀的技术人员合作过,没找到技术合伙人,我理解最好的办法,找个经济适用型的技术,做了三五年的工程师,做起来特别快的,能带几个小朋友的最好。这种人在十年前有个流行的叫法,叫做“主程”,就是“主要程序员”的简称。初创阶段的公司一般适合那种万金油类型的技术同学,什么都懂得一些,但是什么都接触不太深,能快速实现的最好。在很多已经成熟的公司里面,也会有些这样的同学,他们一般也都会被派去做一些尝试性的项目,开疆拓土。

站在一线互联网公司的经理或者总监级别的人来看这种A轮之前的企业,不建议加入,除非满足两点:1)这个创始人跟你很熟悉,知根知底,绝对信任。2)这是一个技术驱动型的企业,而这个技术正是你所擅长和感兴趣的。我们必须承认技术人员一般在商业判断上的能力是较弱的,而且天使期间的风险又是巨大的。

第二阶段:跑得稳

经过前面一段时间的快速试错,业务也该要稳定下来了,这个时候大概是在A轮前后,好不容易九死一生地活下来了,但是接下来面对的才是真正的巨大挑战。从现在看融资的情况大概是这样的,两头热中间冷,天使和种子都是相对好拿的,一个是钱多,第二是这个时候谁也看不准,所以只能多投几个项目去分散风险,而且早期又把价格搞得很高,让A到B又带来了估值上的压力。而真正到了preIPO的时候又变得简单了,因为赛道上的选手已经很明确的,基本就那么几个,同时这个时候投进去更多的是拼资金量,所以这个阶段的投资人大多PE化了,虽然回报的相对值不大,但是绝对值大。

“A轮死”有一部分问题是业务本身的问题,但是有很大部分的比重是在技术方面。就像《腾讯传》里面谈到的当年OICQ有很多类似的竞争对手,但是他们的系统稳定性更好,能支撑更大的业务量,所以活下来了。在这个阶段,技术更重要的是考虑对于大规模业务扩张的承载能力。“A轮死”有很大一部分是栽在这个坑里面的。再次回到我开头说的,这个时候又是考验创始人认知的时候,那就是转换增长方式,而这个事情必须从创始人的角度上转变才行:1)减少产品的功能性需求,重点打磨核心流程的体验,减轻技术团队需求实现的压力。2)在技术团队中组建架构小组,以保障系统稳定性为重要任务,同时提高研发效率。3)在招聘环节改变用人策略,引入更高素质,更加专业性的技术人员。

再从一线互联网公司的技术人员的视角来看这个创业公司,我认为A轮是最好的加入的时间,原因是:1)风险较小,业务模式基本开始展现。2)有用武之地,这个时候往往问题多多,千疮百孔,百废待新,价值体现的时候。这也是HiCTO的价值体现的时候,我们来协助找到优秀的技术合伙人,架构师等技术关键岗位,同时影响业务发展的关键技术问题。

对于CEO来说,我看到有两个认知误区,在这个时候在创始人看来,线上的bug总是会很多,感觉好像大家很不认真。就会出现两个行为,一种是对于bug的惩罚机制,在我看来bug是需要记录的并且需要让大家有意识地,尤其是影响核心业务的P0的bug,但是惩罚是不适合的,技术本身就是要试错的,严厉的惩罚机制会遏制创新。第二种情况就是招一堆的测试,测试是必要的,尤其是对于APP和支付等重要功能,但是代码质量的核心是在于开发人员的素质和意识,打个不恰当的比喻,测试是铲屎的,开发是拉屎的,前面拉的越多,后面的工作量越大,测试的工作更多的是需要从源头上堵住bug产生的机会。

在这个阶段,技术也容易走一些误区,一种就是不以核心业务为导向地搭建心目中的完美系统,所有不以解决核心业务问题为出发点的架构设计都是耍流氓,而要命的事情是90%的架构师都在耍流氓,都是“伪架构师”,架构师真正最需要接受的教育就是业务教育。

第三阶段:变聪明

曾经一位资深的运维工程师跟我说过一句话我印象很深:“一个优秀的运维的最终目标就是让人忘了你,就像你不在这个公司存在一样。”确实,对于运维来说,要是整天CEO都想起他,必然是系统不稳固了。但是要真正做到这一点,背后其实是要更多的主动,更多的防患于未然,这是运维的工作。比如说做的快的事情,技术团队要考虑很多的基础框架,能够让前面为业务服务的工程师更快的实现,或者是工程师已经把常用的功能配置化了。系统服务也是一样,做好容量的评估,预留一定冗余的能力,以应对快速增长的业务。

但是,这些还不是我说的重点,这些工作在技术角度看起来是主动的,但是在业务角度绝对不会这么认为,业务和产品希望的主动有另外的定义。这个时候面临的情况往往这样的:1)业务产生了一波爆发性的增长,但是同时也在寻找新的增长点。2)用户行为的数据也开始有了一定的积累,对于数据的分析的价值越来越高。这是两者结合的最佳时间点,就是在原有的平台上进行进一步优化,或者找到新的爆发点。

对于数据这个事情,他和研发有些差别,主要是在于推动方变得模糊了,以前的从运营->产品->技术。现在不同了,往往是变成商业分析和数据仓库一起合作来发起了,商业和技术之间的距离第一次拉得这么近了。所以,这个时候有两个团队是必须要建立起来的,一个是商业分析的团队,就是把我们的业务问题转换成数据问题,第二个团队就是数据仓库团队,就是把所有的用户行为数据全部收集起来,并且搭建数据处理平台,让所有的数据计算变成可能。

在所有的技术团队中,数据团队是最不像技术的技术,因为他们离业务很近,他们要调动的数据量很大,计算量也很大,需要很强的架构支撑,玩转各种不同的算法,但是他们对于业务的影响也是很有效的,就是有个问题,那就是投入大见效慢。技术团队的好处对于之前没有尝过甜头的人来说,又是没有感知度的,这就回到大辉说的那句话:“创始人往往在早期高估技术,而在后期则低估技术。”

总结

最近在读一本书《宇宙的琴弦》,有一个强烈的体会,那就是一个新的理论的出现,往往是在过去的理论需要突破边界遇到无法解决的问题的时候,而同时新的理论要解决的问题不是完全否定原有的理论,而是用一种全新的方式去兼容了原有的体系,而原有的理论在限定条件内继续有效。比如牛顿力学在遇到光速这种极端速度下遇到解释困难,狭义相对论对于时空有了新的认知之后也没有完全推翻牛顿力学,因为在低速下时空扭曲几乎可以忽略,只在高速和对时间精准要求较高的情况下才有效,比如GPS定位卫星的时间计算。这就是科学的冲突与包容,所有的过去有效的东西必然有他的使用场景,而无法解释的东西需要新的理论。

在技术团队的演进中也是一样,实现是王道的“牛顿力学”,稳定压倒一切的“相对论”,数据为王的“超弦理论”,需要我们一个个去突破,去体会,然后找到各自使用的场景,他们就能够相容了。