139团队（大型研发团队，大型敏捷开发团队，大型团队结构，敏捷绩效管理）

作者：陈勇

出处：blog.csdn.net/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种等级，分别是：需接受指导的、可独立的、可提供指导的、可提供培训的，来整体区分程序员的等级。这种体系结构不太关注人的实际技术水平，而是更关注一个人对团队和部门的贡献。无论你的水平多高，如果缩在角落里自己干自己的，都不能晋升。

无独有偶，在10年访问NEC的时候，他们使用几乎完全相同的等级制度，只有最后一个不同：需接受指导的、可独立的、可提供指导的、可担当重任的（就是大项目经理或部门经理）。

非物质激励

存在等级后，激励的种类就变多了。当我问及NEC为何一个人会甘愿带徒弟时（他们带徒弟没额外奖励），大家面面相觑表明之前真没太想过这个问题，最后有一个人说：当然要带徒弟了，日后领导要提拔谁，很大程度要看谁在团队中更有威信；如果你连徒弟都没有，怎么让你管这么多人？

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》