发布于 

怎样带领一个技术团队

从2012年的Team Leader到现在负责公司的产品团队,在技术管理的道路上也走了6年的时间,看过不少管理的书,也经历过从零开始组建一个团队,和团队成员的更替。下面谈谈我自己的一些感受和理解。

本文的标题特意用了「带领」,而没有用「管理」,因为我觉得一个好的团队的每个成员都应该是自我驱动型的,如果处处都需要有人「管」,需要靠外在的驱动力,即便是最终完成了任务,也不会是用更好的、更合理的方式完成的任务。有一句话是这么说的:外驱力让我们可以做好本职工作,而自我驱动才能让我们成就卓越,我觉得很有道理。

一个团队的组建,到能正常运转大概有这么几个步骤:

1、找人:找到一群志同道合的人;
2、愿景:给团队成员一个愿景,让所有人能够齐心协力朝着一个目标而努力;
3、制度:制定一套制度,让团队成员做事有章可循;
4、文化:建立团队文化,打造一个快乐的学习型团队,让每个成员都能快乐工作,持续成长。

找人

组建一个团队,首先是人,人是一个团队的根基,最重要的组成部分,大的来分,团队分为项目团队和产品团队。项目团队和产品团队在目标上有所不同,项目团队更注重的满足客户的业务需求,直到最终的项目验收和回款;产品团队则更注重持续的迭代,能随时满足市场的变化,对代码的要求和人员的要求相对更高。正因为有这样一些差别,所以在找人时也有着不同的方式:

项目团队:

1、从公司闲置资源临时组建;
2、招聘一些一两年经历的开发人员。

产品团队:

1、从公司现有开发人员中选拔一些符合要求的开发人员进入团队;
2、熟人内推;
3、招聘有多年经验的资深开发人员。

拿我现在带领的产品团队来说,成员大多是公司的「老人」了,也有通过招聘入职的新人,其实最好的方式还是内推,内推的方式更知根知底,有助于团队的稳定性。

愿景

技术人员都是很有个性的,短短的面试时间并不能彻底的了解一个人,即便在一起共事多年的同事,也未必能够十分了解。要能做到让这么一群人能为了一个目标取共同努力,很重要的一点就是信任。团队成员之间的互相信任,Leader和团队成员之间的互相信任。

相互信任

相对来说,技术人员通常不善沟通,但是否被真诚对待,是否受到尊重,心里跟明镜似的。如果缺乏信任,可能有一天,会有成员找一个你不能拒绝的理由提出辞职,那个理由未必是他内心真实的想法。而你这时想挽回却为时已晚。

以目前的经验来看,经常组织一些团队活动,会让团队成员之间有更多的了解,而不仅限于工作内容的沟通。互相更了解了,才原因说出内心真实的想法。我们应该随时了解团队每个人的真实想法,在能力范围内解决他们的后顾之忧。

学会发现优点

人无完人,每个人都有优点和缺点,要学会去发现别人的优点,学习这些优点,形成一个正向的良性循环。你的团队的成员可能是这样的:

1、有的人做事非常快,但比较粗心,经常犯一些低级错误;
2、有的人做事严谨,但在一些细节的地方容易钻牛角尖,导致经常会延后任务;
3、有的人经验丰富,但不善沟通,不能更好的分享知识;
4、有的人基础一般,但态度很好,原因去学习。

想过没有,如果团队的成员通过持续的成长,最终都能拥有上面所描述的优点,那将会是一个无比强大的团队。

发现别人的优点很难,再说技术人员又是那么的自傲,所以团队Leader要做好引导,组织一些技术交流会、公开的Codereview,开诚布公的表扬做的好的地方同时也指出一些问题。让每个人都能够意识到:三人行,必有我师焉。

为产品负责

既然愿意进入到产品团队,就应该清楚产品的最终目标,都应该为了产品最终的成功而努力,而不应该仅仅只是当成一个工作。公司层面也应该给予团队相应的回报承诺(看的见的承诺),而不只是画画饼子。想让马儿跑得快,又想马儿不吃草是行不通的。

转变技术人员的思想需要一个过程,在平日的工作中,技术人员常常会这样说:

1、这个代码不是我改的,我没有动过这部分代码;
2、谁动过我的代码;
3、我本地是好的,没有问题。

上面的情况说明开发人员更关注的还是自己所负责的功能,并且对自己写的代码有一种独特的占有欲,不允许其他人侵犯;出现问题容易推卸责任。理想的团队氛围应该是这样的:

1、每个成员都应该了解产品整体的需求;
2、每个成员必须要了解自己所做功能的业务背景,而不仅仅只是实现一个功能,要时常站在普通用户的角度去思考问题;
3、不要怕暴露问题,而是要尽早暴露问题;
4、出现问题并不是要去追究谁的责任,而是要找出问题的根因,以免下次再犯。

制度

无规矩不成方圆,在开发团队中,这个规矩制度就是指导开发的方式,之前传统的项目开发中比较习惯使用瀑布模式,而在互联网产品团队中习惯使用敏捷的方式。

我们团队采用的算是敏捷的开发方式,离真正的敏捷还是有相当距离,这个需要时间去适应和调整。

正在做的

1、每周例会,每日晨会(没有完全做到,但保证团队随时能流畅沟通);
2、采用GitLab做源代码管理工具;
3、采用GitLabMerge Request工作流程;
4、采用Jenkins做持续发布;
5、采用Docker部署应用;
6、任务的分解,粒度尽量到每日,每日可以验证,持续的集成发布。

还未做的

1、结对编程(敏捷开发中经常会提起,短期内没打算使用);
2、Codereview,非常重要的一个环节,目前做的还不够好,希望最终能达到团队成员之间能互相Review
3、定期分享会,讨论如何改进流程,提高效率(在周例会上会有提及,没有专门的会议);
4、随时交付可工作的软件(很难,功能上可以保证,质量上还需要努力);
5、自动化测试相关(质量的第一道关卡)。

好的制度是不断优化出来的,会随着团队的成长持续的改进,一旦制定就要严格执行,不能每个人有什么意见就各行一套。

文化

文化是一个团队的精神粮食,我的理解是所有人都认同的一种价值观。好的团队文化可以让人在工作中感到快乐。最高的境界就是,早上起床想上班,晚上下班想回家,就像刚工作时的一位导师说的那样:快乐工作,健康生活。

形成一个好的团队文化我觉可以从团队氛围和个人做事风格和原则来谈。

团队氛围

好的氛围会让人在工作的时候心情愉快,有好的团队氛围至少要满足下面几点:

1、认同现在所做的事情,如果每天都做自己不想做的事,能开心的了吗;
2、任何事情,公开、公平、公正,做到奖惩分明;
3、开放式的沟通,所有人都是平等的,为了一个共同的目标,有任何的意见或建议可以随时提出。

个人做事风格和原则

尽管每个人性格各异,做事风格也不尽相同,但还是有一些共性的地方是需要要求每个人都能达到:

1、敢于承诺,在一个互相信任的团队中,你承诺了,我就相信你能够做到;
2、每个人应该是自驱动的,这个在文章开头也说过,「我要做事」和「要我做事」的区别是很大的;
3、分享精神,不要怕知识被别人学走了,互相学习才能共同提高;
4、实现闭环,做事有始有终,每个人的任务都能形成闭环,才能持续发布质量可靠的产品。

总结

以上是最近的一些思考,带领团队这事,思想可以借鉴,但不能生搬硬套,因为每个团队的事不一样,人也不一样。就像敏捷开发,在不同的团队中有不一样的实践方式。希望本文对您有些启发。