互联网创业公司如何规模化研发团队？
移动互联网创业公司在不断地发展与迭代的过程中，会面临研发团队的 “野蛮” 增长，可能每天都会有新面孔进入到团队中。如何规模化研发团队是管理者首要考虑的问题。和大家分享多年工作心得：基于九宫格 (9 Box Grid) 的绩效管理模型来打造 High Performance 的研发团队。
移动互联网创业公司在不断地发展与迭代的过程中，会面临研发团队的 “野蛮” 增长，可能每天都会有新面孔进入到团队中。下图是一个典型创业团队的迭代周期：
如果创业团队做到 A 轮、B 轮的，就意味着具有了一定规模的产品研发、运营团队，这个时候研发团队的管理、经营就会经受以下考验：
1．我们还来能保持并优化：快速开发，快速发布，快速迭代的移动互联网产品开发模型吗?
2．新进入的不同经验层级的研发人员如何更好、更快融入现有产品研发团队并且发挥绩效。
3．我们管理和沟通的 Overhead 会达到什么程度？还能不能像 10 人团队那样愉快的做产品和运营?
就上面涉及的技术领导者问题，不同的管理者根据背景和经验，估计有不同的答案。下面根据自己在开发管理中的一些经验总结提出一个基于九宫格 (9 Box Grid) 的绩效管理模型来打造 High Performance 的研发团队：
该模型以九宫格（9 Box Grid）为管理手段，从 4 个维度来抓研发团队的管理工作：
-Organization管理者能根据业务和产品需要灵活的设计组织架构，这里面没有 Bible，一切以更快，更灵活的方式服务于 Business 需要为前提，在迭代中不断的优化，完善；
-Pyramid合理的人才梯队规划，高低技能的人手分布，核心团队成员的设计；
-Utilization合理的资源 (人、钱) 利用，用最少的成本达到最大的输出，同时更好的维持团队的活力；
-Competence framework业务或产品相关的技能分解，更好的匹配人力资源，避免杀鸡用牛刀的错配。
1 九宫格 (9 Box Grid)
关于 9 Box Grid 在绩效管理中的原理网上有非常详细的文章，这里不做系统的介绍。但是我们需要注意下图右上角 High Potential 和 Potential 的人群，以及左下角的红色标记的人群，然后通过前面提到 4 个维度来合理的管理团队。
2 人才梯队 (Pyramid)
《这个杀手不太冷》里昂（让•雷诺饰）是意大利裔的顶尖职业杀手，电影里有这样一段对白，非常喜欢：
马蒂达问里昂:生活是否永远艰辛？还是仅仅童年才如此？
里昂回答：总是如此。
一个软件团队的打造与可持续发展就如里昂的回答：一直如此艰难；
这里提出 1 个概念，“独立软件程序员” 或 “独立硬件设计师”： 能在限定的时间内独立完成一个具体的软件或硬件开发任务，比如：
15 天完成浏览器从零到原型开发
1 小时完成 XML 文件的解析
“独立软件程序员” 就像里昂一样 Professional，在无开源，断网的艰苦条件下都能给产品经理交付 Code,这样的人才往往落在九宫格（9 Box Grid）右上角的 High Potential 或 Potential 方框里面。
有个段子是：程序员分为几大流派，一派以复制 stackoverflow 代码为主，另一派以复制 git 代码为主，还有以复制百度知道代码为主。 －－复制和借鉴不是什么可耻的，但是学而不思是可悲的。
“独立软件程序员” 是独立思考的类型；
所以我的观点是，在业务线或产品线的每个领域都必须有一个技术牛人，他们就是自己所在领域的 “独立程序员”，一人撑起一个细分领域或一个细分技术领域。这个也秉承了创业公司早期 5-10 人团队的核心搭配，每个人都具备守住公司业务的一个核心领域的能力，同时高效，200%的 get things done。
例如早期的微信开发团队也就 6,7 人的规模，人人都是 “独立程序员”，即便在后来的大规模的发展上，这些核心的 “独立程序员” 的内核也支撑了微信研发团队的不断发展和壮大
团队的实力是速度的上限，要想更快只有一个秘诀: 花重金打造 “独立软件程序员” 第一梯队。也就是我们 9 宫格中的 HiPO。
当我们拥有了心目中的 “独立程序员”，我们就可以开始软件团队的第二梯队的建立，拿 10 人团队来说，我们根据团队的成熟度和产品的研发复杂度来选择你想要的梯度：
无论哪种队形，你都需要结合工作内容与技能要求来做 mapping，比如配比多少个熟练工，多少个有 Potential 的高级程序员；多少个新手，他们往往更有耐心做搬砖的活路；一个个目标清晰的小型团队，组合起来就是我们看到的大规模研发团队，他们的输出就像细流最后汇聚到一起，形成我们产品的迭代主线，从而满足业务的需要。
3 能力框架 (Competence Framework)
假如你碰到像郭靖这样的程序员，你还必须要有耐心来面对这样的谈话：
“二师父，这个 SQL 我还是看不懂，我太笨了。”
“七公，你昨天教我的 redis 和 memcached，我今天都忘了，能再教我一下吗？”
大部分人都是普通人，学不会不可怕，只要我们的研发团队有着技术领域完整的知识框架，并且提供了与之匹配的系统性的能力达成方法，就能 “拼” 出我们整个业务和产品线所需要的整体能力，从而增强团队各个经验层级的人的自信和输出。
比如移动互联网中对以下技能有着大量的需求：
-Android
-iOS
-Web
-Java 或 PHP
-UI/UX
根据应用的场景不同，对于不同经验和层次的软件开发人员的需求也不一样。比如我们需要如下的 Android 技术框架，那么我们就需要在 Android 三个层级 (App，framework 和底层) 配备人手。如何调配 “独立程序员” 和普通程序员的人手比例也会更清楚。
再比如，我们对移动互联网运营的有如下的能力框架体系，那么我们在人力的需求上可以根据各个能力点配备相应的人才，做到合理利用资源，而无须在所有岗位都配备高大上的专才。
在可能是技术类经理们能真正发挥能力的地方，尽可能合理的细分工作领域，然后找到与之匹配的人；如果不是高度技术化的工作，领导者就可以通过分解来领导，而不需太强的个人能力，这也是大规模研发团队走向合理，成熟分布的方式之一，这也能降低离职率对于产品研发进度的冲击，为研发团队迭代提供保障。
4 组织架构 (Organization)
研发团队的架构裁剪能力是一个技术管理者的基本职能，在日常工作中都会有所涉及。你随便翻看一本关于组织架构的管理类书籍，都会看到大同小异的类似描述：
1、管理明确原则，即避免多头指挥和无人负责现象。
2、职责权对等原则。
3、有效管理幅度原则，即管理人员的直接下级人数应在一定范围内。
4、灵活性原则，即能够对外部环境变化作出适应的调整和变化。
. . .
这里我们主要讨论如何开发适用于迭代产品开发模式的研发团队架构，通常可以采取以下步骤来操作：
以上这个过程随着业务或产品迭代而迭代，最终找到适用于更加有效地沟通的工作方式来支撑 Agile/Scrum 的 Engineering Process。但是在选定关键职位上，如果我们没有与之匹配的人选，我们一定要自己来，而不是将就而配备一个能力与之不匹配的队员，这样的后果是灾难性的。
例如：一个典型的移动互联网产品开发、运营的组织架构：
在不同的阶段，我们并不一定需要每一个角色或职位配备一个人，比如一个懂软件开发技术的项目经理完全可以兼顾一个小于 10 人开发团队 lead 的这个角色。 再比如，如果这个产品是一个交易类软件产品，那么对软件质量与性能要求就非常高，此时测试经理就变成了一个非常重要的岗位，我们就要配备与技术要求严格匹配的人选，同时一定要专职。
5 利用率 (Utilization)
软件团队的利用率一般有 2 大维度： 根据业务与产品开发需要，合理预测一个团队规模，基于工作量的预测来配备团队大小； 另外一个维度是根据 budget 大小来配备团队规模，充分挖潜来发挥团队的能力，尽可能的用最小的人力成本创造更高的产品价值
这里，我们不探讨如何准确进行工作量与团队规模之间的数字映射，重点关注九宫格（9 Box Grid）左下角红色标记的人群的管理：
落在 Poor Performer 和 Attention 区域的队员，通常会离开团队；落在 Problem Child 区域的队员，可以选择给他换一个管理对象或者工作内容进行适当的调整；由于我们的产品迭代非常迅速，每一个队员都是重要的资源，所以需要快速做出反应！挖掘潜力，提升 “独立程序员” 的核心价值。
以 100 人的团队来说，如果我们做到大于 90%的人力资源利用率，从管理的角度来说已经属于非常高效的研发团队了，但是依然有近 10%的挖潜空间，如果能找回浪费的空间，那么就可以让高产能的 “独立程序员” 投入一定的精力在 Innovation 的产品或项目上。一来可以支持战略性质创新项目的原型开发，二来他们也能更进一步迭代自己的能力，从而提升团队整体的实力，更好的为下一步的发展做好储备，同时这个自然调节的过程也会增强团队的凝聚。
6 简单与迭代
互联网时代，简单是非常重要的目标——因为简单，你就开始聚焦；因为聚焦，你的产品的迭代就会迅速。所以我们可以在产品每个关键性迭代周期中加入员工的九宫格（9 Box Grid）迭代；从而做到团队的迭代随着产品的迭代而发展。
[本文转自微信公众号点融黑帮，作者高勇，转载请注明来自威客安全（www.secwk.com）]
