您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 其他 > 正文

血的教训!技术团队管理应该避免的九大“坑”!

发表于:2018-01-26 作者:虞大胆(虞卫东) 来源:51cto 点击数:

创业公司技术团队如何组建?技术团队管理过程会遇到哪些坑?如何填旧的坑,如何应付互相伤害,如何不给自己挖坑?

以下经验不论是对创业团队或小公司来说都有参考价值,尤其是对于一些非技术产品老板下的技术负责人,所谓早看早得利,谁用谁知道。

要成为创业公司的技术 Leader 或技术合伙人,从自己心理上再不能只是一个单纯的码农。

许多朋友和我吐槽,这些 CEO 们看见一个认识的程序员、工程师就会晓之以情动之以理说服来公司做 CTO,结果失败率非常非常高。

不管是在大公司还是小公司,做产品一定是靠一个团队,优秀的技术团队一定不能有个人主义的氛围。

技术 Leader 要思考的不是某个功能模块的代码如何实现,而是优先考虑如果打造一支“短小而精悍”的核心技术团队、如何搭建高可用的技术框架、如何高效打造出优秀的互联网产品。

组建技术团队的正确“姿势”


如何建立初期技术团队?以下的经验或许有参考意义:

第一,根据技术解决方案和个人做事风格去挑选和掌控团队

这点很重要,比如曾有一家拿了天使轮的团队,CEO 是从阿里巴巴出来的“女神”,项目启动不到半年,原技术 Leader 因为各种原因走了,后来她急着想拉我替补进来。

我只提了一个条件:“阿里巴巴的文化我不懂,如果我进来,我可能需要按照我自己的风格去管理。”

但是公司的负责人否认了我,说:“CEO 是从阿里巴巴出来的,团队我们会自己去带,你只负责写代码和解决技术问题就好了。” 于是我没有继续往下谈了。

其实这种事情没有对错,这只是我个人的做事风格和原则。

第二,前期的技术团队也许谈不上管理

但是基本清晰的组织架构和简单的绩效考核制度必须到位。

第三,前期的技术部门最好用“弹性工作制”来管理

团队越小越应该实施这样的制度,因为不拘小节、没有时间概念的技术研发工作反而效率更高。

第四,发现“蛀虫”立即砍掉

我之前带过一支团队,所有技术成员没日没夜的开展着开发工作,大家根本没有时间考虑福利、节假日这些事情(当然、这些东西应该是由公司主动做就可以了)。

有这么一个人,事情还没做好就不断跟我斤斤计较、谈各种条件,多上一个小时都觉得自己委屈,工作紧急时候却偷偷占用公司网络资源下载电影,还经常发出消极的言论、做事慢效率低下。

这种人就像一个“蛀虫”时不时折腾得让大家都不爽,负能量满满,影响他人不说,团队破坏性极大,于是我立马让他工作交接对其劝退。

第五,技术 Leader 要引入或者培养自己的左膀右臂

CEO 要有自己的军师和大将,CTO 或技术 Leader 也一样。

第六,团队成员要有责任心、人品好的,而不是要最优秀的、浮躁的

令我感动的一段经历,团队里有个工程师下班坐车回到一半,就突然给我发微信说,有个事情没做好,问我在不在公司,他要坐车回来重新做一下。

他不是团队技术最优秀的,但他确实是最能吃苦和有责任心的,这是我喜欢的员工类型之一。

第七,技术团队一定要有定期的一对一沟通

技术团队不论大小,团队里的直属上司一定要有定期的沟通制度。

我也是程序员出身,我知道程序员是以“闷骚”的特点著称。对于长期的低调、苦逼的 IT 技术宅男,没有定期的心理疏导工作,会出现很多尴尬的问题,不信你认真观察试试,这也是团队磨合的一个重要工作。

技术团队管理应该避免的九大“坑”


那么问题来了,初创技术团队需要管理吗?技术团队如何做管理?

老夫掐指一算:当然需要!尤其是技术团队,只要大于 3 个人,就必须有管理。这个管理包含:代码管理、项目管理、团队管理等角度。

见过太多失败的案例了,大多数的技术团队出现的效率低、团队一盘散沙、开发没有方向、团队不稳定等问题都是因为缺乏管理或者管理不到位引起的。

如何做好技术团队管理?我没事闲的时候,脑子里总在思考这个问题。将来有一天我成为一家创业公司的技术负责人,哪些错误应该是避免犯的呢?

人从一种状态到另一种状态的时候,先思考的不应该是如何快速去做,而是如何避免犯一些错误。

为了避免我太跑题,先设置一个限定,比方一个创业团队近期融了一笔钱,需要快速的抢占市场。

这时需要有一个技术负责人(已谈好全权负责)来带领研发团队更好的支持业务发展,这个团队原来的技术人员没有超过 5 个人。

善待原有技术团队


这个产品能够成功融资,原有技术团队肯定付出了很多。也许他们技术能力并不突出,也听不懂你的技术术语,还可能没有做过高负载的网站。

但是他们肯定足够辛苦,因为一直在默默付出,对待他们要抱着帮助的心态,不要一上去就提出批评或者质疑,不要提扩展性、可维护性这样很虚的概念。

而要了解目前遇到了什么难题,你能够坐下来仔细和他们分析,并实实在在帮助解决问题,技术人员都很单纯,你帮助了他们,就会服你,会尊重你。

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

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

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


很多公司负责人找技术负责人的一个标准,就是看这个人的人脉,看他能不能找到很多技术人员,快速搭建技术团队,整锅拉来一个团队。

这个思路是没问题的,公司负责人需要放权,专业的事情交给专业的人去做。

可是假如技术负责人招的人都是原来的朋友、同事,形成家族式技术团队,那么就要警惕了。

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

其次以关系这种方式引进的员工,技术水平肯定良莠不齐,很多人因为和技术负责人良好的关系而进来的,更要命的是技术负责人引进人只是为了证明他的人脉那就危险了。

所以技术负责人只要觉得一个人听话,这个人可能就会被引进,而不是以技术能力而衡量了。

另外,一般的技术负责人年龄可能都不小了,而必然原来的同事年龄也不小,他们原来可能是技术人才,可随着年龄的提升,他们现在可能是个“技术管理者”,而失去了编码能力。

对于创业团队来说这是非常不好的事情,创业团队其实更需要业务开发人员。

家族式管理的弊端


在特定的时间,家族式管理很有用。技术人员任何的行为都是建立在帮助技术负责人的角度,所以干劲会很足。

对于技术负责人来说就更好了,不用动员,不用讲管理技巧,只要建立兄弟之间的关系就行了,任何事情都能搞定。

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

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

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

请先进行技术方案的设计


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

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

为什么要亲自上呢?因为你是技术负责人,不了解技术问题,就无法进行技术管理。

只有亲自设计了,你才能有针对性的去解决问题,将来系统遇到瓶颈,你就能更好的优化或者重新设计。不要用各种理由不去做这个事情,这在早期很重要。

不要过度追求专业化


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

没意义的技术岗位

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

重复造轮子

重复相同的开发工作,应该多用开源的解决方案。现在发现很多公司喜欢自己实现或对原有软件做扩展,假如没有特殊原因,应该用成熟的解决方案,原因第一就是研发成本,第二就是这个开发成本会很长,第三就是稳定性有待考量。

系统设计过度

另外,很多创业公司存在大量的系统过度设计。即设计的方案不结合目前的实际情况,考虑的太复杂,所以实现的也特别复杂。

这和造轮子一样,也存在同样的浪费,其实过度设计到还好,就怕错误设计。

比如我原来的公司,觉得 MySQL 性能不好,非要加一层 Memcached 或Redis缓存,最后设计并线上使用发现后,缓存命中率非常低,白白浪费了大量服务器,损耗了性能,并增加了系统的复杂性。

根本原因是代码写的烂,为了 Redis 而 Redis,复杂会显得很牛嘛!所以这个行为非常不值得提倡。

技术债

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

专业化的反面就是技术负债,上面也只是简单的说下,有很多的最佳实践指导,想表明的就是太专业化是对效率的最大打击(时间、成本等)。

我原来也遇到很多类似的情况,这个伤害分为两个阶段:

第一阶段就是短期的一锤子伤害,比如说技术方案上线了,浪费了一些时间和成本,但是这个浪费是固定的,可衡量的。

第二阶段就非常难衡量了,为早期的决策还债,比如说原来的技术方案上线后,后期开发特别难扩展,维护也非常困难,累计起来是对生产力的极大打击,成本就非常昂贵。

招人要慎重


招人的关键词就是数量和质量,没有合适的宁愿不招。在创业团队,项目一个接着一个,很容易造成一个假象,开发人员不够,所以就大量的去招人,这是非常不成熟的行为。

尤其是假如这个技术团队没有太强的最佳开发实践,新来的人员可能会很茫然,各有各的开发习惯和模式,会导致 1+1 < 2 的现象产生。

人一多,分工就要细化,一细化协作就会产生一定的问题,所以招人要控制数量。

第二就是重视质量,质量这个词每个人都有自己的标准,我核心的观点就是宁愿使用一个技术底子扎实的毕业生,也不愿意使用一个有多年开发经验但无技术底蕴的人。

一个没有技术体系的开发人员总有一些瓶颈和不好的习惯,会有很多累。

不了解公司负责人


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

对于一个技术负责人来说,可以天天和他聊,告诉他架构的重要性,人员的重要性。

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

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

不要有求必应


和技术合作最多的就是产品人员,个人觉得产品人员思维有点发散,做任何事情都比较着急,天天思考这个功能,那个功能。

一个简单的数据需求就问技术要不要弄个后台出来,反正一刻也不会让你闲着。

对于一个成熟的技术负责人来说,不能什么都快速答应——因为这是对自己的伤害。

第一,开发人员就算多一倍也会不够,需求会源源不断的来。

第二,产品人员很多情况会考虑不成熟,假如你完全按照他们说的去设计,方案会非常复杂,有的时候逻辑性也会显得有问题,会让系统很难有效的持续运转。

第三,有时候人工完成的时间比开发一个系统完成的时间少得多。

因此,少开发一些无意义的脚本或后台,比如刚开始产品人员觉得这个数据很重要,过了几天就会突然觉得没用了。

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

不要依赖测试


在创业团队,由于对开发时间要求特别高,开发人员在评估时间的时候,特别喜欢加上测试时间,着等同于拿测试时间完成其开发时间,这是一种非常不好的行为。

比如说一个项目开发时间要 5 天,测试时间要 5 天。看上去好像开发时间只占一半(开发人员好像很高效),但实际上测试时间里开发人员肯定还在开发,他们给测试人员的只是一个半成品。

另外开发人员知道测试人员会测试出问题、会把关。所以初期的开发质量肯定不高,这种案例也见过很多。

所以,不要变相的用测试时间弥补开发时间。有可能的话,开发人员自己负责测试,当然这个实际操作起来开始有一些困难,有了开始就能够适应。

小结


每家互联网创业公司都有自己特殊的情况,我要表达的中心思想就是先考虑不犯错,然后再考虑更好的改进。

尤其在互联网创业早期,追求轻量而不是重量,技术成本非常昂贵,要效率。

 相关文章