作者:陈勇
出处:/cheny_com
定义
简单看,139团队就是1个项目经理,3个小组长,9个开发人员,小组长管理各自管理3个左右开发人员。
139团队从管理上缩减了团队规模,可以被视同只有1个项目经理和3个小组长,细节交由小组长处理。这样就方便在大型团队中进行敏捷开发了。
角色
在Scrum敏捷团队中,队员们是平等的,只有Scrum Master是个个例。但由于在国内很难找到Scrum Master(一则知识缺少,二则一般PM不愿意放弃管理权和技术而转而做“协调”工作),且团队往往超过7~9人,139团队会是一个替代方案。
项目经理
主要工作与原来的项目经理无异,如果在做敏捷可以向自组织团队偏斜一下,即减少其管理职能,增加其领导职能(管理与领导有何差异会另有博文解释)。
作为项目的主心骨,项目经理的技能越高越好,毕竟将辐射到多达10人身上。
小组长
小组长要对开发工作相当熟悉,上要与项目经理加强管理沟通,下要与组员加强技术沟通。
开发人员
帮助小组长干活。
还有一种人介于小组长与开发人员之间,他们可以独立工作(一般用来攻坚),但是尚不能带领下属(可能因为技术能力,也可能因为性格,或技术与职责过于专一)。
工作方式
开会(计划会/每日立会/总结会/技术方案讨论会……)
项目经理可以认为自己手下只有这几个小组长,开会时主要的沟通发生在项目经理与小组长/小组长与小组长之间。
开发人员多数情况下每次均与自己的小组长列席各种会议,倾听小组长们的沟通,除非有特殊问题不直接介入讨论。但开发人员必须保证自己理解组长们的沟通,否则必须补充发问。
日常
小组长和3个开发人员如果还要开会就迂腐了,而是必须以至少“松结对编程”(将另有博文描述),也就是每人拥有自己的电脑独立工作,但重要工作小组长要在一台电脑上指导开发人员完成(“编到读数据库的语句的时候叫我一声我来帮你”)。
日常工作的沟通非常重要,否则在开会的时候,就很难保证几位“不说话”的开发人员和小组长对任务的理解是相同的。
绩效管理
传统的大团队绩效考核无外乎是考察每个人做出的贡献,按称分金银。但这会造成人与人之间缺少互助,遇到困难躲着走等等诸多弊病。
139团队给大型团队的个人绩效开辟了一个新的思路。它认为团队中人的绩效在于其为团队做出的贡献,而非直接完成的任务,而“贡献”的直觉反应,就是一个人在139团队中的位置:是1?是3?还是9?
基于位置建立绩效等级
即认为个人绩效=团队×位置,1最高,9最低。
笔者在01年供职的企业尝试使用4种等级,分别是:需接受指导的、可独立的、可提供指导的、可提供培训的,来整体区分程序员的等级。这种体系结构不太关注人的实际技术水平,而是更关注一个人对团队和部门的贡献。无论你的水平多高,如果缩在角落里自己干自己的,都不能晋升。
无独有偶,在访问NEC的时候,他们使用几乎完全相同的等级制度,只有最后一个不同:需接受指导的、可独立的、可提供指导的、可担当重任的(就是大项目经理或部门经理)。
非物质激励
存在等级后,激励的种类就变多了。当我问及NEC为何一个人会甘愿带徒弟时(他们带徒弟没额外奖励),大家面面相觑表明之前真没太想过这个问题,最后有一个人说:当然要带徒弟了,日后领导要提拔谁,很大程度要看谁在团队中更有威信;如果你连徒弟都没有,怎么让你管这么多人?
点击下载免费的敏捷开发教材:《火星人敏捷开发手册》