点击围观!腾讯 TAPD 助力金融行业研发提效、敏捷转型最佳实践! 了解详情
写点什么

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

  • 2017-04-13
  • 本文字数:3687 字

    阅读完需:约 12 分钟

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

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

请善待原有技术团队

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

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

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

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

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

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

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

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

家族式管理的弊端

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

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

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

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

请先进行技术方案的设计

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

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

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

不要过度追求专业化

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

  1. 存在很多没有意义的技术岗位,比如现在很多产品并没有多少的用户,可非要搞数据挖掘,很多数据通过简单的 Shell 脚本就能解决,可专业的数据挖掘岗位要求并不低,从成本和效益看,并不建议有。
  2. 喜欢造轮子,在创业团队,其实应该多用开源的解决方案,现在发现很多公司喜欢自己实现或对原有软件做扩展,假如没有特殊原因,应该用成熟的解决方案,原因第一就是研发成本,第二就是这个开发成本会很长,第三就是稳定性有待考量。
  3. 过度设计,就是设计的方案不结合目前的实际情况,考虑的太复杂,所以实现的也特别复杂,和造轮子一样,也存在同样的浪费,其实过度设计到还好,就怕错误设计,比如我原来单位,非觉得 MySQL 性能不好,要加一层 Memcached 缓存,最后设计并线上使用发现后,缓存命中率非常低,白白浪费了大量服务器,损耗了性能,并增加了系统的复杂性。
  4. 不要有开发语言歧视,比如前端业务层用 PHP,后端数据层用 Java,性能没有想象的那么夸张,这也是细分岗位的一种缺陷。

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

招人要慎重

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

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

不了解公司负责人

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

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

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

不要有求必应

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

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

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

不要依赖测试

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

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

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

作者介绍

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

2017-04-13 17:232164

评论

发布
暂无评论
发现更多内容

Redis-技术专区-知识问题总结大全(上篇)

洛神灬殇

redis 5月日更 问题分析

多家银行增设数字金融部 架构调整背后透露出哪些信号?

CECBC

银行

我与 InfoQ 写作平台的这些事

xcbeyond

个人成长 1 周年盛典 InfoQ 写作平台 1 周年 5月日更

【JS】作用域(入门篇)

德育处主任

JavaScript 大前端 Web js

顺序一致性(Sequential Consistency)

UNDEFINED

sequential consistency Java Concurrency distributed system

3.5 Go语言从入门到精通:标准输入输出fmt包

xcbeyond

Go 语言 5月日更 fmt包

通向未来的十二个趋势

CECBC

人工智能

数字化转型能力成为中国纺织服装业未来发展的核心动能

CECBC

纺织面料

白嫖福利!阿里P7大神梳理的Java数组详细知识点,太实用了

飞飞JAva

Java

别再傻傻分不清AVSx H.26x MPEG-x了

LoveYFan

音视频

网络攻防学习笔记 Day3

穿过生命散发芬芳

5月日更 网络攻防

OAuth 2.0 了解了,OAuth 2.1 呢?

Zhang

OAuth 2.0 认证授权 OAuth 2.1

【LeetCode】砖墙Java题解

Albert

算法 LeetCode 5月日更

清华学霸!用18行代码讲解Java接口,程序员:果然厉害,学到了

牛哄哄的java大师

Java 接口

限时白嫖!腾讯内部员工培训Java资料,网友:大厂就是不一样

牛哄哄的java大师

Java

高级研发工程师都有哪些特点?【超级准】

liuzhen007

技术人生 工作体会 程序猿

自己在 InfoQ 平台的期冀——共同成长

liuzhen007

1 周年盛典

区块链如何推动人力资源和薪酬管理体系变革?

CECBC

人力资源

模块三作业

c

架构实战营

把复杂留给自己,简单留给用户

石云升

5月日更

第八大洲环游记(一):平流层上的非洲故事

脑极体

未来5年或将出现颠覆型区块链应用,资产通证化将重构实体经济

CECBC

区块链

C++基础语法

IT蜗壳-Tango

算法训练营 - 学习笔记 - 第四周

心在飞

让 Go 代码跑上移动端

Rayjun

Go 语言 gomobile

Redis-技术专题-Redis分布式锁实现方案

洛神灬殇

redis 分布式锁 5月日更

网络攻防学习笔记 Day2

穿过生命散发芬芳

5月日更 网络攻防

【音视频】弱网下的音视频通讯

Bob

音视频 直播技术

微服务-技术专题-微服务进程间通信

洛神灬殇

微服务 分布式架构 5月日更

如何提升工作效率

wangwei1237

工作效率 文化 大历史理论

软件开发不同阶段的命名风格

顿晓

5月日更 命名 风格

创业团队技术Leader应该尽量避免的9个错误_语言 & 开发_虞卫东_InfoQ精选文章