BT

你的观点很重要! 快来参与InfoQ调研吧!

创业团队技术Leader应该尽量避免的9个错误

| 作者 虞卫东 关注 0 他的粉丝 发布于 2017年4月14日. 估计阅读时间: 11 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

自己闲的时候总是思考一个问题,将来有一天我成为一家创业公司的技术负责人,哪些错误应该是避免犯的呢?人从一种状态到另一种状态的时候,先思考的不应该是如何快速去做,而是如何避免犯一些错误,这就是本文的出发点。

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

请善待原有技术团队

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

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

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

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

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

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

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

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

家族式管理的弊端

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

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

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

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

请先进行技术方案的设计

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

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

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

不要过度追求专业化

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

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

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

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

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

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

招人要慎重

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

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

不了解公司负责人

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

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

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

不要有求必应

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

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

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

不要依赖测试

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

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

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

作者介绍

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

建议 by tian tekin

文章写得不错,受教了

随便提一下,这里有个错别字

“所以不要变现的用测试时间弥补开发时间” “变现” 应该是 变向 把?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT