17611538698
webmaster@21cto.com

创业团队技术Leader应该避免的九大错误

资讯 0 2765 2017-03-25 12:00:47

foucs.png


21CTO社区导读:
此文说的是创业技术团队管理如何组建,要遇到的坑,咋填旧的坑,咋应付互相伤害,如何不给自己挖坑。不论是创业团队和小公司都有参考价价值,尤其对于一些非技术产品老板治下的技术负责人,所谓早看早得利,谁用谁知道。


 
要成为创业公司的技术Leader或技术合伙人,从自己心理上再不能只是一个单纯的码农。
 
许多朋友和我吐槽,这些CEO们看见一个认识的程序员、工程师就晓之以情动之以理说服来做CTO,结果失败率非常非常高。
 
其实不管是在大公司还是小公司,做产品一定是靠一个团队。
 
优秀的技术团队一定不能有个人主义的氛围。技术leader要思考的不是某个功能模块的代码如何实现,而是优先考虑如果打造一支“短小而精悍”的核心技术团队、如何搭建高可用的技术框架、如何高效打造出优秀的互联网产品。


组建技术团队的正确姿势


 
 
如何建立初期技术团队?以下的经验或许有参考意义:
 
第一,根据技术解决方案和个人做事风格去挑选和掌控团队。
 
这点很重要。比如有一家拿了天使轮的团队,CEO是从阿里巴巴出来的“女神”,项目启动不到半年,原技术Leader因为各种原因走了,后来急着想拉我替补进来。
 
我只提了一个条件:“阿里巴巴的文化我不懂,如果我进来,我可能需要按照我自己的风格去管理。” 
 
但是公司的负责人否认了我,说:“CEO是从阿里巴巴出来的,团队我们会自己去带,你只负责写代码和解决技术问题就好了。” 于是我没有往下谈了。
 
其实这种事情没有对错,这是我个人的做事风格和原则。
 
第二,前期的技术团队也许谈不上管理,但是基本清晰的组织架构和简单的绩效考核制度必须到位。
 
第三,前期的技术部门最好用“弹性工作制”来管理。
 
团队越小越应该实施这样的制度。因为不拘小节、没有时间概念的技术研发工作反而效率更高。
 
第四,发现“蛀虫”立即砍掉。
 
我之前带过一支团队,所有技术成员没日没夜的开展着开发工作,大家根本没有时间考虑福利、节假日这些事情(当然、这些东西应该是由公司主动做就可以了)。
 
有这么一个人,事情还没做好就不断跟我斤斤计较、谈各种条件,多上一个小时都觉得自己委屈,工作紧急时候却偷偷占用公司网络资源下载电影,还经常发出消极的言论、做事慢效率低下。
 
这种人就像一个“蛀虫”时不时折腾得让大家都不爽,负能量满满,影响他人不说,团队破坏性极大。
 
于是我立马让他工作交接对其劝退。
 
第五,技术Leader要引入或者培养自己的左膀右臂。
CEO要有自己的军师和大将,CTO或技术Leader也一样。
 
第六,团队成员要有责任心、人品好的,而不是要最优秀的、浮躁的。
 
令我感动的一段经历,团队里有个工程师下班坐车回到一半,就突然给我发微信说,有个事情没做好,问我在不在公司,他要坐车回来重新做一下。
 
他不是团队技术最优秀的,确实最能吃苦和有责任心的,这是我喜欢的员工类型之一。
 
第七,技术团队一定要有定期的一对一沟通。
 
技术团队不论大小,团队里的直属上司一定要有定期的沟通制度。
 
我也是程序员出身,我知道程序员是以“闷骚”的特点著称。对于长期的低调、苦逼的IT技术宅男,没有定期的心理疏导工作,会出现很多尴尬的问题,不信你认真观察试试。这也是团队磨合的一个重要工作。


技术团队的管理


 
那么问题来了,初创技术团队需要管理吗?技术团队如何做管理?
 
老夫掐指一算:当然需要!
 
尤其是技术团队,只要大于3个人,就必须有管理。这个管理包含:代码管理、项目管理、团队管理等角度。
 
见过太多失败的案例了,大多数的技术团队出现的效率低、团队一盘散沙、开发没有方向、团队不稳定等问题都是因为缺乏管理或者管理不到位引起的。
 
如何做好技术团队管理?我没事闲的时候,脑子里总在思考这个问题。
 
将来有一天我成为一家创业公司的技术负责人,哪些错误应该是避免犯的呢?
 
人从一种状态到另一种状态的时候,先思考的不应该是如何快速去做,而是如何避免犯一些错误。
 
为了避免我太跑题,先设置一个限定,比方一个创业团队近期融了一笔钱,需要快速的抢占市场。这时需要有一个技术负责人(已谈好全权负责)来带领研发团队更好的支持业务发展,这个团队原来的技术人员没有超过 5 个人。


善待原有技术团队


 

这个产品能够成功融资,原有技术团队肯定付出了很多。也许他们技术能力并不突出,也可能听不懂你的技术术语,可能也没有做过高负载的网站。
 
但是他们肯定足够辛苦,因为一直在默默付出,对待他们要抱着帮助的心态,不要一上去就提出批评或者质疑,不要提扩展性、可维护性这样很虚的概念,而要了解目前遇到了什么难题,你能够坐下来仔细和他们分析,并实实在在帮助解决问题,技术人员都很单纯,你帮助了他们,就会服你,会尊重你。
 
假如技术负责人不能帮助他们,那就不要去添乱。比如用行政的命令要求他们遵守代码规范,画架构图,进行代码审查,不要有高高在上的感觉,你过来是解决问题的,而不是来生产制度的。
 
就算你看到了技术团队有很多问题,也要逐步的去优化。因为在现阶段,原有团队是最了解目前的技术组成,不要试图全部推翻,也不要用新来的人去替代他们,尊重他们,帮助他们,才是最好的方式。


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


 
很多公司负责人找技术负责人的一个标准,就是看这个人的人脉,能不能找到很多技术人员,快速搭建技术团队,整锅拉来一个团队,这个思路其实是没问题的。公司负责人需要放权,专业的事情交给专业的人去做。
 
可是假如技术负责人招的人都是原来的朋友、同事,形成家族式技术团队,那么就要警惕了。
 
首先这个用人成本非常高。招来的人并不完全是因为技术负责人的个人魅力而来的,他需要平衡是否值得,所以高工资成为必然,当然假如确实是高水平的技术人才,这也是合理的。
 
其次以关系这种方式引进的员工,技术水平肯定良莠不齐,很多人因为和技术负责人良好的关系而进来的,更要命的是技术负责人引进人只是为了证明他的人脉那就危险了,所以技术负责人只要觉得一个人听话,这个人可能就会被引进,而不是以技术能力而衡量了。
 
另外一般技术负责人的年龄可能不小了,而必然原来的同事年龄也不小了,可能他们原来是技术人才,可随着年龄的提升,他们可能是个“技术管理者”,而失去了编码能力,对于创业团队来说这是非常不好的事情,创业团队其实更需要业务开发人员。


家族式管理的弊端


 
在特定的时间,家族式管理很有用。技术人员任何的行为都是建立在帮助技术负责人的角度,所以干劲会很足,对于技术负责人来说就更好了,不用动员,不用讲管理技巧,只要建立兄弟之间的关系就行了,任何事情都能搞定。
 
假如这些兄弟确实技术能力很强,那么技术体系可能会很好,假如技术能力不强,设计和开发出的东西没有任何的审查,技术负债就会很多,而技术负责人本来的职责不就是掌控技术质量吗?你完全放开,要你有啥用?
 
家族式团队很有可能和原有团队产生摩擦。比如原有团队感觉受到了排挤,很有可能处处不配合,而新进团队可能为了有更多的话语权,会抢班夺权,所以这两个团队就为了私利,不会专注于技术,内耗就会很严重。
 
这种事情就很多,比如某个公司,新来的技术负责人带来了自己的团队,并且都是级别很高的职位,而老同事感觉这些人啥都不懂,什么也解决不了,而新来的团队又各种的变革,导致互相利益不平衡,很多老同事就走了。


请先进行技术方案的设计


 
对于一个刚来的技术负责人来说,有许多工作,比如组建团队、了解产品,但更重要的是设计靠谱的技术方案。
 
首先要了解系统存在的问题,要了解产品未来的走向,要了解技术团队的现状,针对这三点,你需要亲自操刀,设计一个针对目前最优的技术方案。
 
为什么要亲自上呢?因为你是技术负责人,不了解技术问题,就无法进行技术管理,亲自设计了,才能有针对性的去解决问题,将来系统遇到瓶颈,就能更好的优化或者重新设计。不要用各种理由不去做这个事情,这在早期这很重要。


不要过度追求专业化


 
其实在互联网创业公司,一般追求小而快的概念。但是很多从大公司出来的技术负责人充满激情,任何事情都想追求专业化,这可能会出现很多问题。举几个栗子。
 
(1)没意义的技术岗位
 
比如现在很多产品并没有多少用户,可非要搞数据挖掘,很多数据通过简单的 Shell 脚本就能解决,可专业的数据挖掘岗位要求并不低,从成本和效益看,并不建议设置这样的岗位。
 
(2)重复造轮子
 
重复相同的开发工作,应该多用开源的解决方案。现在发现很多公司喜欢自己实现或对原有软件做扩展,假如没有特殊原因,应该用成熟的解决方案,原因第一就是研发成本,第二就是这个开发成本会很长,第三就是稳定性有待考量。
 
(3)系统设计过度
 
另外,很多创业公司存在大量的系统过度设计。
 
即设计的方案不结合目前的实际情况,考虑的太复杂,所以实现的也特别复杂,和造轮子一样,也存在同样的浪费,其实过度设计到还好,就怕错误设计。
 
比如我原来的公司,非觉得 MySQL 性能不好,非要加一层 Memcached 或Redis缓存,最后设计并线上使用发现后,缓存命中率非常低,白白浪费了大量服务器,损耗了性能,并增加了系统的复杂性。
 
其实是代码写的烂,为了Redis而Redis,复杂会显得很牛吗,所以这个行为非常不值得提倡。
 
(4)技术债
 
另外不要有开发语言歧视。比如某些公司搞的前端业务层用 PHP,后端数据层用 Java,性能没有想象的那么夸张,这也是细分岗位的一种缺陷。
 
专业化的反面其实就是技术负债,上面也只是简单的说下,有很多的最佳实践指导,想表明的就是太专业化是对效率的最大打击(时间、成本等)。
 
我原来也遇到很多类似的情况,这个伤害分为两个阶段。
 
第一阶段就是短期的一锤子伤害,比如说技术方案上线了,浪费了一些时间和成本,但是这个浪费是固定的,可衡量的。
 
第二阶段就非常难衡量了,为早期的决策还债,比如说原来的技术方案上线后,后期开发特别难扩展,维护也非常困难,累计起来是对生产力的极大打击,成本就非常昂贵。


招人要慎重


 
关键词就是数量和质量,没有合适的情愿不招。在创业团队,项目一个接着一个,很容易造成一个假象,开发人员不够,所以就大量的去招人,这是非常不成熟的行为。
 
尤其假如这个技术团队没有太强的最佳开发实践,新来的人员可能会很茫然,各有各的开发习惯和模式,会导致 1+1 < 2 的现象产生。人一多,分工就要细化,一细化协作就会产生一定的问题,所以招人要控制数量。
 
第二就是重视质量,质量这个词每个人都有自己的标准,我核心的观点就是情愿使用一个技术底子扎实的毕业生,也不愿意使用一个有多年开发经验但无技术底蕴的人。
 
一个没有技术体系的开发人员总有一些瓶颈和不好的习惯,会有很多累。


不了解公司负责人


 
很多公司负责人找技术负责人的时候,都是求才若渴,目标就是希望这个人去搞定技术事宜,可在头脑中并没有衡量标准,一切都是变化的。
 
对于一个技术负责人来说,可以天天和他聊,告诉他架构的重要性,人员的重要性,这些确实很重要,但并非必要性,对于公司负责人来说他其实就关注开发速度、稳定性、产出,他并不关心深层次的技术内部是如何运转的。
 
举个我遇到的情况,原来一个同事去一个公司做负责人,他天天搭基础,优化系统,后来不知道什么原因走了,而产品负责人这么评价他“来这么久一个产品也没上线”。这个例子对技术人员应该很具有打击性。


不要有求必应


 
和技术合作最多的就是产品人员。个人觉得产品人员思维有点发散,做任何事情都比较着急,天天思考这个功能,那个功能。一个简单的数据需求就问技术要不要弄个后台出来,反正一刻也不会让你闲着。
 
对于一个成熟的技术负责人来说,不能什么都快速答应——因为这是对自己的伤害。
 
第一,开发人员就算多一倍也会不够,需求会源源不断的来;
 
第二,产品人员很多情况会考虑不成熟,假如你完全按照他们说的去设计,方案会非常复杂,有的时候逻辑性也会显得有问题,会让系统很难有效的持续运转。
 
第三,有时候人工完成的时间比开发一个系统完成的时间少得多。
 
因此,少开发一些无意义的脚本或后台,比如刚开始产品人员觉得这个数据很重要,过了几天就会突然觉得没用了。
 
这样的例子很多很多。我的意思并不是不去配合产品人员,而是从自己专业角度出发,给出合理的意见,当然需要避免激化矛盾。


不要依赖测试


 
在创业团队,由于开发时间要求特别高,开发人员在评估时间的时候,特别喜欢加上测试时间,等同于拿测试时间完成其开发时间,这是一种非常不好的行为。
 
比如说一个项目开发时间要 5天,测试时间要 5 天。看上去好像开发时间只占一半(开发人员好像很高效),但实际上测试时间开发人员肯定还在开发,给测试人员的是一个半成品。另外开发人员知道有测试人员会测试出问题、会把关,初期的开发质量肯定不高,这种案例也见过很多。
 
所以,不要变现的用测试时间弥补开发时间。有可能的话,开发人员自己负责测试,当然这个实际操作起来开始有一些困难,有了开始就能够适应。


小结


 
每家互联网创业公司都有自己特殊的情况。我要表达的中心思想就是先考虑不犯错,然后再考虑更好的改进。
 
尤其在互联网创业早期,追求轻量而不是重量,技术成本非常昂贵,要效率。


作者:虞大胆(虞卫东)。新浪网高级技术经理。前赶集网移动事业部技术总监。主要供职于新浪网,经历所有新浪博客技术演进。有十余年的互动类产品开发经验,熟悉 LAMP 平台 和 Python 的开发,提倡益软件开发理论。
本文已经过21CTO优化修正,欢迎在网站投稿。


评论