[实践]技术团队的成长之路



  09年,我们在团队建设方面,做了很多探索和尝试,下面我们逐一聊聊。

一、流程改造

  流程改造是首先想到的事情。因历史遗留原因,我们的项目开发模式依然是“作坊式”的组织方式,此模式的特点:项目经理负责制,开发人员和测试人员都以项目经理为中心进行配置,相关工作流也以项目经理为中心展开。此模式的优势明显,即单位响应时间较快,在项目组配备能力比较强的项目经理时,该组项目实施的效率和质量都比较高,即项目实施结果与项目经理的职业能力之间有非常大的耦合度。随着我们系统规模的迅速扩大,而人力资源水平又不能够迅速跟着这一节奏时,项目质量(稳定性)和实施周期就比较没有可靠的保证。为了改善技术团队的绩效,我们需要慢慢挖掘团队作战的优势 ,扩大1+1>2的效果,而团队作战首先要处理的即是工作流的优化。
  流程改造产生的最大的成果是促进了技术团队治理结构的革新:测试人员独立出去,成立了QC部门,专注于质量控制技术的提升。然后又产生了QA部门,专门跟进包含流程优化的质量管理工作。
  流程改造前前后后历时半年,有很多阵痛,尤其是流程改造前期, QC和QC力量也比较薄弱,很多东西都不太完善,产生了很高的流程成本,而各项目组本来就有很大的项目负担,所以大家都不太适应,非常抗拒。后来经过持续的调整,量体裁衣,逐渐形成了相对稳定有效的流程。这个流程将是我们较好保证项目质量和效率的重要的保障系统。
  我想在流程方面,2010年需要考虑的是有几个方面:
  1、避免为了流程而流程的情况,过犹不及,让大家为流程所累。如果流程产生的收益完全被流程的成本给抵销了,那就得不偿失了。所以流程改造一定是一个加加减减,动态调整适应的过程,切不可照本宣科,纸上谈兵。
  2、确保流程中各节点部门的综合能力水平是匹配的。对于瓶颈部门,要大练内功,尽快提高提上来。可以一方面加强内部培训,另外一方面外聘高级人才,来提升整体的人力资源水平。

二、绩效管理

  我们是互联网开发团队,互联网的系统都是有若干站点组成的。我们有十几个固定的项目组,分别负责几个子站,我们的绩效管理也就是以组为单位的。技术团队的绩效管理一直是老大难问题,主要是量化比较困难,指标比较难建立。我们的日常工作就是做项目,那么这个指标一定就是要能够反映各个项目组项目上的情况。后来我们想到了一个比较“巧妙”的办法,即以项目奖金作为基础指标。我们每个项目都是配置一定的奖金的,奖金的额度由项目开发工作量、技术难度、上线风险等因素综合确定。这样所有的项目都可以有共同的基础指标,奖金最终能否全额发放,又有两个决定因素,一个是质量等级,二是完成时间。给这两个因素设置一定的加权关系,这样每一个项目在完成时,都会产生一个奖金配额。
  这样我们每个月下来,盘点一下每个项目组拿到的项目奖金总额,便可形成项目绩效报表。
  而我,其实每个月最关注的一个指标是人均贡献度,就是奖金总额除以总人数。通过这个指标,我可以大约了解整个部门的绩效情况。实际上,这个指标的建立非常有价值,一是各项目组能够在历史的时间轴上看看自己的绩效轨迹。此外,他还可以与平行的项目组进行比较,看看横向来看,自己的组在什么位置。需要注意的是,这种核算方式并不是适合所有的项目组的,例如有的组是负责基础研究,属于技术或项目开拓组,这样的组应该单独考虑。还有的组,不是不努力,而是项目就是少,这个时候也要进行均衡。
  我们上面说了项目绩效的管理方式,而作为一个技术团队来讲,我们的工作还远远不止日常项目工作。还有很多线上支持,团队管理,部门建设等诸多事务。这方面的东西,有一个特点,就是基于事件和行为的,对于这一部分的绩效,我们是通过“红黑牌”来管理的。我们对于正面的事件和行为,派发红牌。反之,对于负面的,派发黑牌。这个方案是由我们的一位QC经理首先提出来的,我觉得非常有价值,就纳入了我们的绩效管理当中了。红黑牌方案需要特别注意一个原则,即多发红牌,尽可能少发甚至不发黑牌。即使发,也最好遵循一个原则,即红牌到个人,黑牌到团队。
  项目绩效和红黑牌绩效,再加上绩效反馈、面谈部分,就是绩效管理的全貌了。每个季度绩效考核的数据,也来源于这两部分内容的汇总。当然,我们也会根据每个阶段,团队目标的不同,对权重进行一定的微调。比如一开始的时候,各项目组只关注自己的一亩三分地,不太关心对整个团队有利的工作,那个时候,我就会将红黑牌绩效的权重提高,以引导大家多做一些对整个团队有利的工作。


三、人力资源

  技术团队最珍贵的资源就是人才,2009年我们围绕人才做了很多工作。
  首先就是大量补充新鲜血液,整个团队现在五十几人,其中有一半,是09年加盟团队的。同时,在工程师队伍中,大力发掘人才,晋升了五六位高程。此外,我们大胆启用新人,培养了好几位优秀的项目经理出来。
  人多好办事,有相对充足的人力资源保障,我们开始了两个重要的尝试,一个是逐步降低项目经理这个岗位的负荷,从而有机会重新定义项目经理的职能,让多个项目经理有机会去拓展自己多方面的职业能力。另外一个事情是拉起了一个迷你的架构团队,这个团队先后完成了多个架构重构专案,在我们现在的架构优化工作中发挥了重要的作用。


四、团队成长

  为推动团队成长,我们也做了诸多的尝试。每一个尝试都会安排一个指定的人负责,通常都是某个项目经理。
1、组织内部培训,定期开展技术讲座。

  我们的广大的工程师们,其实都是非常渴望成长的,希望能够学到更多的技能和知识。我们一方面定期为大家采购技术图书,另外一方面我们开始筹备内部培训。那会,我们没有讲师,没有讲义,可谓一穷二白。凡事开头难,我们就群策群力,联合了几个人,成立了一个培训小组,全力推动内训工作,经过满长时间的准备,终于迎来了第一次的培训。我依然清晰的记得,第一节课,是我们的一位新加盟的项目经理的分享,非常成功,开了一个好头,给了大家很大的信心。后来,陆续推出了很多课程,终于把培训工作逐步推动起来了,现在我们的工程师们,已经不再满足有课程了,已经开始挑内容了,对课程内容的要求显然也越来越高了,这表明内训工作的进步。我们不仅收获了知识,还创造了技术分享的氛围,也同时发掘出优秀的讲师。现在,我们正准备2010年,打造属于我们自己的标准化课程,形成自己的一整套讲义,加油。

2、组建技术俱乐部,不定期组织技术交流。

  这个俱乐部有一个非常上口的名字,叫“空军一号”,技术俱乐部实际上是后来的定位,我们也经过了一个摸索的过程。一开始,我们把它想像成“虚拟研发团队”,定位是对高精尖技术的研究推进,最大限度的挖掘技术的应用价值,成为技术团队的超级引擎并发挥核心驱动作用。后来推进的过程中,发现,很难指望一个虚拟团队去做太多技术研究的工作,所以我们重新定位它是一个技术交流的俱乐部,专注于几个方面:技术研讨、最佳实践、过程管理和行业交流。而原来设想的定位,已经慢慢转移到架构团队身上了。

3、举办技术竞赛,激发大家对技术的热情。

  技术竞赛,也经过一个曲折的过程。一开始,我的想像是搞一个兴趣小组,这个兴趣小组去推动一些辅助工具或公共组件的开发,这些工具可以直接应用到我们的工作上。后来发现参与度比较低,也是因为大家都比较忙,顾及不上。而且通常这样的东西,需要投入的精力也确实是比较大的。后来,负责这一块工作的项目经理,提出是否可以搞一个技术竞赛,我突然意识到这就是我们需要的东西。于是,我们的24点算法大赛就上马了。为了支持这个活动,我们还特别申请了奖金,第一名2400元,第二名240,第三名24。也是源于我们没有相关的经验,这个活动前前后后经历了小半年的时间,有过一个很生涩的前期筹备过程。在中后期的时候,我们加强了宣传力度,还专门做了易拉宝的海报,人气便慢慢上来。比赛期间,那些参赛选手,只要得空,就聚在一起讨论算法,改进算法,那是相当的投入。更让我们意外的是,初赛和决赛的结果差异非常大,黑马的产生,表示我们的工程师是有非常大的创造力和潜力的。同时,这个活动,也是大赛组委会(也就是我们的几位项目经理)集体智慧的一次展现,实际上,也是他们一次很有价值的职业体验,这个过程是非常值得总结和思考的。

4、代码能力的提升

  这是一个非常小的细节了。做开发工作的,代码能力是最最基础的能力。这方面,我们有两个值得说道说道的实践。
  实践一,是代码规范的推行。很难想像,我们以前是没有编程规范的,都是各写各的,非常丑陋。于是,我们决定,开始建立自己的编码规范。规范是建立了,也发给大家了,结果没什么用,原来怎么写还都怎么写,让人很是困扰。结果,我们一位项目经理灵光一现,说得上考试,实在是神来之笔。你猜怎么着,当我们开始用考试来检验大家对编程规范的掌握程度时,大家代码风格一致性嗖嗖的上升。开始的时候,我们每两周考一次,现在基本上只需要一个月考一次了。而且,随着大家对规范的熟悉,我们考试抽查的内容悄悄发生了变化,我们把一部分低级的代码错误放了进去。
  实践二,是代码走查制度的推行。代码走查的发起,是源于我们经常有一些项目,上到线上之后,出现问题,然后我们就想着是不是应该让不同的项目组之间互查代码。然而,这种期望也是自说自话,大家都忙着自己的项目,别人的项目,基本上也就是马马虎虎看一看。显然,这不是大家的问题,这是方法不对路。后来,也是我们一位项目经理提出一个观点,即代码质量的提高,还要从源头上解决,即提升工程师们素养,在写的时候,就保证质量。同时,即使要走查,也应该优先安排项目组内部走查。显然,他说的是对的。于是我们立即修正了代码走查的思路,从目前的情况来看,效果还不错。我下来和工程师作访谈的时候,也有反馈说代码走查,确实有帮助。


五、人文关怀

  我一直有一个有点偏颇的观点,即我认为技术人员是最缺乏人文关怀的人群。所以,给技术人员多少人文关怀都不为过。比如,技术人员应该有一个非常宽松自由的环境,以便技术人员可以更富有创造性的工作。比如,应该由技术管理人员把更多与技术无关的干扰排除在外,当好防火墙,以便技术人员可以专注于技术本身。
  除了以上的内容,我们在人文关怀方面,还有几个具体的举措。
  我们提供免费的体育活动机会,比如羽毛球活动,让大家锻炼身体,缓解压力的同时,也促进团队的沟通交流。实际上,除了体育活动,我们也在尝试拓展活动的形式和种类,比如游泳,钓鱼,台球,网游比赛等等。
  我们提供爱心雨伞。有一次,下雨,我发现部门有很多人没有带伞,于是第二天便安排采购了一批爱心雨伞,供大家不时之需。
  此外,我还收集了部门每一位员工的生日,在他们生日的时候,会为他们写上一张贺卡。
  人文关怀的举措,是一个可以无限想像的区域,作为一个团队的领导者,只要我们在意我们的员工,就一定可以不断想到新的点子。

  最后,我要感谢我的团队,你们很优秀,非常有创造力,我为能够和你们一起工作而感到骄傲,记住我们2010年的两个关键词:重构&分享,加油!

[本日志由 余波 于 2010-02-08 06:53 PM 编辑]
文章来自: 本站原创
引用通告: 查看所有引用 | 我要引用此文章
Tags: 技术 管理 成长 实践
相关日志:
评论: 3 | 引用: 0 | 查看次数: 4627
nzy
回复回复nzy[2011-01-22 08:59 PM | | | del]
看完文章,发现现在本人所在的团队也碰到博主提到的很多问题
关于如何协调这样的技术团队,希望以后能跟博主多沟通
温
回复回复[2010-11-24 09:42 PM | | | del]
你们公司还真不错,有这样的管理人员真是一种幸福。
代码规范也可以借助工具来实施,有些源代码管理工具直接就支持代码规范检查,检查不通过的签入不了。
remus
回复回复remus[2010-04-21 01:32 PM | | | del]
我看了您这篇文章,对代码规范那一节有疑问请教
请问 代码规范具体是怎么来定呢?会详细到注释怎么写,类的命名方法,大括号所在的位置等等这些吗?
考试的话就拿规范里的规则来考试吗?这样的话考上两三次应该就能记住了,还需要每朋都要再考试吗?

回复来自 余波 的评论 余波 于 2010-04-21 13:34 PM 回复

代码规范怎么定,我觉得不是最重要的,重要的是统一代码风格,这其实或多或少有一定的强制性,没有什么道理可讲的。
网络上有很多优秀的版本,我个人理解是代码规范的重点是命名规则。

考试一开始是定期的,各项目组全部参加考试,
然后排名靠后的项目组,进行补考,直到超过一定的要求,比如90分。
再往后,考试的周期就拉长了,同时也不是大面积考了,改成抽人出来考试。

到目前,我们已经不再考试了。
但代码规范的检查还是定期进行的,但检查的内容不局限于代码规范了,已经将代码质量作为其中的主要检查内容。
操作上是定期的让各工程师将近期的一段代码提交,然后集中进行Review,评分。
抽屉·
回复回复抽屉·[2010-02-21 10:26 PM | | | del]
加油!
狐狸达达
回复回复狐狸达达[2010-02-08 11:26 PM | | | del]
沙发没了我板凳!

感觉适当时候要请BOBO给我们上课了
师兄
回复回复师兄[2010-02-08 10:04 PM | | | del]
很不厚道,抢了楼主的沙发
发表评论
昵 称:
邮 箱: 支持Gravatar头像.
网 址: 输入网址便于回访.
内 容:
验证码:
选 项:
虽然发表评论不用注册,但是为了保护您的发言权,建议您注册帐号.
字数限制 5000 字 | UBB代码 开启 | [img]标签 关闭