139團隊（大型研發團隊，大型靈活開發團隊，大型團隊結構，靈活績效管理）

定義

簡單看，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種等級，分别是：需接受指導的、可獨立的、可提供指導的、可提供教育訓練的，來整體區分程式員的等級。這種體系結構不太關注人的實際技術水準，而是更關注一個人對團隊和部門的貢獻。無論你的水準多高，如果縮在角落裡自己幹自己的，都不能晉升。