首先为了避免太跑题,先设置一个限定,一个创业团队近期融了一笔钱,需要快速的抢占市场,需要有一个技术负责人(全局负责)来带领技术团队更好的支持业务发展,这个创业团队原来的技术团队人员没有超过 5 人。

请善待原有技术团队

这个产品目前融资了,而原有技术团队肯定付出了很多,也许他们技术能力并不突出,也可能听不懂你的技术术语,也没有做过高负载的网站。但是他们肯定足够辛苦,因为一直在默默付出,对待他们要抱着帮助的心态,不要一上去就提出批评或者质疑,不要提扩展性、可维护性这样很虚的概念,而要了解目前遇到了什么难题,你能够坐下来仔细和他们分析,并实实在在帮助解决问题,技术人员都很单纯,你帮助了他们,就会服你,会尊重你。

假如技术负责人不能帮助他们,那就不要去添乱,比如用行政的命令要求他们遵守代码规范,画架构图,进行代码审查,不要有高高在上的感觉,你过来是解决问题的,而不是来生产制度的。

就算你看到了技术团队有很多问题,也要逐步的去优化,因为在现阶段,原有团队是最了解目前的技术组成,不要全部推翻,也不要用新来的人去替代他们,尊重他们,帮助他们,才是最好的方式。

整锅挖来一个团队需要慎重

很多公司负责人找技术负责人的一个标准,就是看这个人的人脉,能不能找到很多技术人员,快速搭建技术团队,这个思路其实是没问题的,因为公司负责人需要放权,专业的事情交给专业的人去做,可是假如技术负责人招的人都是原来的朋友、同事,形成家族式技术团队,那么就要警惕了。

首先这个用人成本非常高,招来的人并不完全是因为技术负责人的个人魅力而来的,他需要平衡是否值得,所以高工资成为必然,当然假如确实是高水平的技术人才,这也是合理的。

其次以关系这种方式引进的员工,技术水平肯定良莠不齐,很多人因为和技术负责人良好的关系而进来的,更要命的是技术负责人引进人只是为了证明他的人脉那就危险了,所以技术负责人只要觉得一个人听话,这个人可能就会被引进,而不是以技术能力而衡量了。

另外一般技术负责人的年龄可能不小了,而必然原来的同事年龄也不小了,可能他们原来是技术人才,可随着年龄的提升,他们可能是个“技术管理者”,而失去了编码能力,对于创业团队来说这是非常不好的事情,创业团队其实更需要业务开发人员。

家族式管理的弊端

在特定的时间,家族式管理很有用,因为技术人员任何的行为都是建立在帮助技术负责人的角度,所以干劲会很足,对于技术负责人来说就更好了,不用动员,不用讲管理技巧,只要建立兄弟之间的关系就行了,任何事情都能搞定。

假如这些兄弟确实技术能力很强,那么技术体系可能会很好,假如技术能力不强,设计和开发出的东西没有任何的审查,技术负债就会很多,而技术负责人本来的职责不就是掌控技术质量吗?你完全放开,要你何用?

家族式团队很有可能和原有团队产生摩擦,比如原有团队感觉受到了排挤,很有可能处处不配合,而新进团队可能为了有更多的话语权,会抢班夺权,所以这两个团队就为了私利,不会专注于技术,内耗会很严重。

这种事情就很多,比如某个公司,新来的技术负责人带来了自己的团队,并且都是级别很高的职位,而老同事感觉这些人啥都不懂,什么也解决不了,而新来的团队又各种的变革,导致互相利益不平衡,很多老同事走了。

请先进行技术方案的设计

对于一个刚来的技术负责人来说,有许多工作,比如组建团队、了解产品,但更重要的是设计靠谱的技术方案。

首先要了解系统存在的问题,要了解产品未来的走向,要了解技术团队的现状,针对这三点,你需要亲自操刀,设计一个针对目前最优的技术方案。

为什么要亲自呢,因为你是技术负责人,不了解技术问题,就无法进行技术管理,亲自设计了,才能有针对性的去解决问题,将来系统遇到瓶颈,就能更好的优化或者重新设计。不要用各种理由不去做这个事情,在早期这很重要。

不要过度追求专业化

其实在创业公司,一般追求小而快的概念,但是很多从大公司出来的技术负责人充满激情,任何事情都想追求专业化,这可能会出现很多问题,这里举几个例子。

1. 存在很多没有意义的技术岗位,比如现在很多产品并没有多少的用户,可非要搞数据挖掘,很多数据通过简单的 Shell 脚本就能解决,可专业的数据挖掘岗位要求并不低,从成本和效益看,并不建议有。

2. 喜欢造轮子,在创业团队,其实应该多用开源的解决方案,现在发现很多公司喜欢自己实现或对原有软件做扩展,假如没有特殊原因,应该用成熟的解决方案,原因第一就是研发成本,第二就是这个开发成本会很长,第三就是稳定性有待考量。

3. 过度设计,就是设计的方案不结合目前的实际情况,考虑的太复杂,所以实现的也特别复杂,和造轮子一样,也存在同样的浪费,其实过度设计到还好,就怕错误设计,比如我原来单位,非觉得 MySQL 性能不好,要加一层 Memcached 缓存,最后设计并线上使用发现后,缓存命中率非常低,白白浪费了大量服务器,损耗了性能,并增加了系统的复杂性。

4. 不要有开发语言歧视,比如前端业务层用 PHP,后端数据层用 Java,性能没有想象的那么夸张,这也是细分岗位的一种缺陷。

专业化的反面其实就是技术负债,上面也只是简单的说下,有很多的最佳实践指导,想表明的就是太专业化是对效率的最大打击(时间、成本等等),我原来也遇到很多类似的情况,这个伤害分为两个阶段,第一阶段就是短期的一锤子伤害,比如说技术方案上线了,浪费了一些时间和成本,但是这个浪费是固定的,可衡量的。第二阶段就非常难衡量了,为早期的决策还债,比如说原来的技术方案上线后,后期开发特别难扩展,维护也非常困难,累计起来是对生产力的极大打击,成本非常昂贵。

招人要慎重

关键词就是数量和质量,没有合适的情愿不招。在创业团队,项目一个接着一个,很容易造成一个假象,开发人员不够,所以就大量的去招人,这是非常不成熟的行为,尤其假如这个技术团队没有太强的最佳开发实践,新来的人员可能会很茫然,各有各的开发习惯和模式,会导致 1+1 < 2 的现象产生。人一多,分工就要细化,一细化协作就会产生一定的问题,所以招人要控制数量。

第二就是重视质量,质量这个词每个人都有自己的标准,我核心的观点就是情愿使用一个技术底子扎实的毕业生,也不愿意使用一个有多年开发经验但无技术底蕴的人。一个没有技术体系的开发人员总有一些瓶颈和不好的习惯,会有很多累。

不了解公司负责人

很多公司负责人找技术负责人的时候,都是求才若渴,目标就是希望这个人去搞定技术事宜,可在头脑中并没有衡量标准,一切都是变化的。

对于一个技术负责人来说,可以天天和他聊,告诉他架构的重要性,人员的重要性,这些确实很重要,但并非必要性,对于公司负责人来说他其实就关注开发速度、稳定性、产出,他并不关心深层次的技术内部是如何运转的。

举个我遇到的情况,原来一个同事去一个公司做负责人,他天天搭基础,优化系统,后来不知道什么原因走了,而产品负责人这么评价他“来这么久一个产品也没上线”。这个例子对技术人员应该很具有打击性。

不要有求必应

和技术合作最多的就是产品人员,个人觉得产品人员思维有点发散,做任何事情都比较着急,天天思考这个功能,那个功能;一个简单的数据需求就问技术要不要弄个后台出来。反正一刻也不会让你闲着。

对于一个成熟的技术负责人来说,不能什么都快速答应,因为这是对自己的伤害,第一开发人员就算多一倍也会不够,需求会源源不断的来;第二产品人员很多情况会考虑不成熟,假如你完全按照他们说的去设计,方案会非常复杂,有的时候逻辑性也会显得有问题,会让系统很难有效的持续运转。第三有时候人工完成的时间比开发一个系统完成的时间少得多,所以少开发一些无意义的脚本或后台,比如刚开始产品人员觉得这个数据很重要,过了几天就会突然觉得没用了。

这样的例子很多很多,我的意思并不是不去配合产品人员,而是从自己专业角度出发,给出合理的意见,当然需要避免激化矛盾。

不要依赖测试

在创业团队,由于开发时间要求特别高,开发人员在评估时间的时候,特别喜欢加上测试时间,等同于拿测试时间完成其开发时间,这是一种非常不好的行为。比如说一个项目开发时间要 5天,测试时间要 5 天。看上去好像开发时间只占一半(开发人员好像很高效),但实际上测试时间开发人员肯定还在开发,给测试人员的是一个半成品。另外开发人员知道有测试人员会测试出问题、会把关,初期的开发质量肯定不高,这种案列见过很多。

所以不要变现的用测试时间弥补开发时间,有可能的话,开发人员自己负责测试,当然这个实际操作起来有困难。

这篇文章有点偏理论,每个公司有其特殊的情况,中心想表达的思想就是先考虑不犯错,然后再考虑更好的改进;在创业早期,追求轻量而不是重量;技术成本非常昂贵,需要效率。

作者介绍

虞卫东,新浪网高级技术经理,前赶集网移动事业部技术总监,主要供职于新浪网,经历所有新浪博客技术演变,有十余年的互动类产品开发经验,熟悉 LAMP 平台 和 Python 的开发,提倡益软件开发理论。