快速组建的开发团队要怎么活下来？
1 引子
大约在半年前，笔者去澳洲启动了一个新的项目，在项目初期只有笔者一人，到后来，随着需求的增加，团队也在慢慢的在增加，六月份是3个人, 7月10人, 到12月底已经28个人了。也就就是说一个全新的团队从启动之初到半年之后增加了将近30人，这还是笔者努力控制加人节奏的情况下。其中新人有19个人（完全没有公司经验），这些新人中还包括5个小鲜肉毕业生。有人会觉得说这是一件大大的好事，有人会觉得这是一件应该避免的事。
觉得是好事的同学，会这么想，团队规模大了，能够大展拳脚了，leverage的人多了，资源也向自己倾斜。
觉得应该避免这么完的同学，会这么想，短期，快速且绝大多数都是新人的团队启动方式显然太过激进，尤其是最为团队我们还承担着体现公司技术实力的重担。
笔者认为不到万不得已，还是不要这么玩火，这是一件风险极高的有挑战的好事！
2 组团之前
但是，万一幸运女神降临到你的头上，先深吸一口气，然后，你需要问自己三个问题：
- 利益相关者期望是什么？
- 这么快的加人，有什么坑需要我来填？
- 我要在这个过程中扮演什么角色？
-
利益相关者期望是什么？
一切没有原因的加人，都是耍流氓。就团队而言，利益相关人有三类：客户，公司，个人。客户对团队的期望。在上人之前，你需要弄明白的是，为什么要加这么多人，这个团队组件之后，客户对该团队有什么样的期待呢。有些客户是因为这个财年的钱有可能花不完，不把这些经费烧完不甘心，当然这种土豪客户还是稀有动物；有些客户是因为突然增加的商业计划；有些客户是因为有更换供应商的需要，基于技术，行业经验，解决方案上的优势，在其他供应商和你之间TA选择了后者；了解了客户的期望之后，不要给客户设定太高的期望，尤其是不要给他这种错觉——想要多少人都行，这都是小事一件。那句话怎么说来着，“少承诺，多交付！”
公司对团队的期望。公司处于各种考虑，会对团队有不同的期望。比如，希望团队能够把该客户发展成战略客户，因为客户所在行业能够提高公司竞争力；或者，希望能够体现公司的技术影响力；或者，借此培养公司某一领域（大数据，数据分析，移动应用等）的技术能力和实践。不同的期望也就意味着不同的人员组成，你不会期待一个由毕业生组成的团队在客户那里体现公司的技术深度，同样你也不会期望由一堆技术牛人组成的团队，仅仅为客户提供产品维护工作。理清这个期望，也有助于团队争取合适的资源。
个人对团队的期望。每个人都有自己的诉求，有的人是为了学习先进的生产关系，有的人是为了向牛人致敬，有的人想带带团队学习学习管理技能，有的人想增强自己和客户沟通的能力。你不会想要把一个只想做前端的开发放到devOps的团队里，你也肯定不想把一个iOS开发放进一个Java后台的坑里，因为这样做只能是互相伤害罢了。所以，你不仅需要找到技能比配的人，更为关键的是目标。
-
这么快的加人，有什么坑需要我来填？
理清楚不同的期望，对于你如何挑选合适的团队成员是非常关键的，当然这是理想情况啦！因为，给你的人永远要缩水于你想要的人，比如能力和经验。 “我需要1个资深开发，2个高级开发再加上3个初级开发”， “好的，知道了，你需要6个开发”， 第二天，你收到了1个高级开发，2个初级开发外加3个毕业生。 回到这个问题本身，坑是多种多样的，如果要给出一个定义的话，那可以是这样子， “期望和现实之间的差距”。如果在加上限定词的话，可以是“由于过快的加人导致的团队无法达到期望的阴影面积”。好了，定义已经有了，那么我们来看看有什么坑呢？如果团队在任何方面和期望有差距的话，就会形成各式各样的坑，比如：技术坑，沟通坑，项目管理坑，交付坑，业务目标坑，团队建设坑...。那么问题来了，谁来填呢？还用问吗！
-
我要在这个过程中扮演什么角色？
你要做的是搭建一个平台，一个框架体系，供团队成员在里面愉快的和客户玩耍。当然不是说你就是上帝，你说要有风就有风，你说要有树就有树，你更多的是一个协调者，参与者，谈判者，组织者，然后和很多人一起，比如说，客户，团队核心成员等，你起动手搭建这个框架。
游戏规则非常重要，千万不要成为黑哨，没人知道你的规则是什么，也别说什么没有规则就是最好的规则，或者我们是自组织团队，不需要规则，自组织团队已经是很高境界了，没有多少团队能够达到，所以也就不要指望新组建的团队能够在短时间内成为那样一种理想的存在。
当然，我们的目标不是限制，不是约束，而这个规则／框架的目标是为了能够支持该团队成为一个高效的交付团队。
3 团队建设
好了，认清形式，弄明白自己的目标，接下来就是具体怎么搞了。
技术面
核心目标：构建的是团队的能力
没有任何一个团队能在组建初期就达到技术能力的最大化，抛开团队协作的成分来看，团队至少需要了解目标客户的商业模式，业务需求，目标用户等，如果涉及遗留系统，还需要对它们进行深度学习，以便为维护，新特性开发或者和新系统集成时做些铺垫。因此团队的能力是需要培养的。不过，同样是能力建设，它确要被分开来看，目的是：给客户信心（能力提升还能给客户提供信心，是的，没错！），为团队设定能力提升目标。怎么分能达到这个两个目的呢？一般会这个分：技术能力和应用能力。 来，先看下图
图中有两个蛛网图，分别体现了团队的这两种能力。第一种能力，Technical Skill，主要是指的普遍使用的技术能力，比如.Net技术栈的能力，前端能力，devOps能力，构建的能力，版本管理的能力，自动化测试的能力等，这些能力的特点就是和客户没有任何关系，不管是和客户A合作还是客户B合作，这些都是不已客户为转移的；第二种能力，Application Skill，主要是指与客户强相关的应用能力，比如客户不同系统，代码库，基础设施，架构，甚至包括编码规范。当然，既然和客户强相关，那么不同客户的该类能力的差别就极大了，可以说是客户定制化能力。
继续回答上面的问题，第一种能力给客户信心，第二种能力为团队提供能力提升目标。较为理想的状态是前者能力足够强，后者能够明确识别被给出团队需要提升的量化目标。我们来进一步解释一下，怎么就算足够强？和如何量化？目标怎么确定？
先说如何量化，要做到量化就需要标准，它可以是客户定义或者团队定义，其实都没有关系，重点是双方能够达成一致。当然由团队定义的标准且有客户赞同是最好的，因为这样能够量化标准可以从团队的实际情况出发，让能力体现最大化。
再说怎么算够强，这是相对概念，首先可以定义出满足客户需求的技术能力要达到何种量化水平，再给出当前团队的评估，最差情况也需要刚刚满足开发要求，比如客户想要做一个类淘宝的电商平台，而你的团队能力只能做静态门户网站，这显然是不够的。客户对团队的信心和两者之间的正向差距是成正比的。
最后说目标怎么定，和客户一起制定，只需要保证步子不要迈的太大即可，且目标应该是阶段性的而非一次性。有了目标和现状，之间的差距就显而易见，于是自然而言的就驱动出各种能力提升计划，它可以是双方出差做知识分享，可以是结对编程，可以是一系列的workshop，以及持续的代码审核等等。
管理面
核心目标：构建的是团队的协作体系
团队管理的核心是如何最大化团队的生产效率，并且随着团队的发展，团队管理的重点也在迁移。以刚刚成立团队为例，管理的目的如何让组员快速进入状态，清楚自己的和别人的职责，以及对事物的一致看法（使命，愿景，价值观，笔者会在之后的文化面提到）。在该项目上，笔者主要从以下三个方面出发：
-
标准的新人上手流程。在该项目中快速启动是核心目标，因此如果和让新人能够快速上手，了解客户的业务模式，组织架构，现有系统以及架构，代码库，如何构建部署，已经日常的事物，如请假等，我们把它称之为《新手上路指南》。不论何种形态的指南，有一个很重要的原则就是——宏观到微观。切记新人刚刚进入团队就开始熟悉代码，这样做损失的不仅是长期利益，甚至也牺牲了短期利益，因为不知道为什么而做出的决定，写出的代码不会好的！下图是该项目启动初期，团队快速增加时制定的上路指南，它是一个5天的活动，帮助新人了解客户，了解项目情况，而80%的活动都是在了解宏观的项目上下文，只留给新的开发人员20%的时间真正看看，了解一下代码库。
-
标准化工作流程。 一提到流程，很多人可能都会想到臃肿，复杂，冗长，无用，显然这不是实情。千万不要相信『没有流程是最好的流程』之类的理论，否则就这个团队要么像大雁那样自组织，要么就只能布朗运动了，当然成为后者的概率是不言而喻的。标准化工作流程的目的是让这个团队有组织有纪律的运行起来。
需要制定哪些流程呢？这个问题的答案是随着团队的不同，同一团队的不同阶段而不一样。笔者的原则是，取决于当前团队面临的问题，以为未来的发展目标。在团队刚刚组件的时候，我们标准化了这么几个流程：基础开发流程，请假流程。随着人员不断增加，新的问题出现了，比如，提交代码后构建失败的概率大大增加，团队成员能力参差不齐，被标准化的流程又增加了：构建提交流程，请假流程，分享机制。在后来的时候，笔者开始未团队的未来发展考虑了，我们需要提现团队的技术领导力，于是流程又有新成员：每2周一次的小组长会议，以及同频率的核心成员例会，分别用于项目进度和风险的更新，追踪，以及对未来发展的思考和行动。
- 定义组织结构。 看到这个话题，可能读者会想，不就是一个团队嘛，有必要搞什么组织架构吗？会不会太重了？还有我们是扁平化的组织，不要搞那么多层级好不？先回答第一个问题，有没有必要不是说出来的，而是根据实际情况来，团队组建初期，10人以下的时候，Team Lead（以下简称TL）怎么搞都行，就那几个人，双手是能数得过来的，每个人在做什么、需要什么样的帮助、进度怎么样了、能力如何都一清二楚(具体如何从个人转型团队leader可以参见<<从自我驱动到带领10人团队>>)。当团队人数增加到15，20人时，TL就吃不消了。第二个问题，太重吗？那就不一定了，这个完全取决于TL，如果要把组织结构归类的话，不妨把它暴力的不负责任的归为：提升组织效率的和降低组织效率的，前者肯定不重，后者不言而喻，至于组织效率如何定义，则不在本文的讨论范畴。至于第三个问题，层级不意味着不扁平，扁平也不意味着没有层级，两者是没有因果关系的。下图是笔者团队在4个月时候的样子
由于团队成员的增加，笔者已经不能照顾到每个人，同时也到了想想未来这么大的团队如何发展的时间点，因为核心成员和STL这两种角色被提出。前者和笔者一起，规划，制定下一步发展计划，后者和笔者一起保证项目的正常交付。
文化面
核心：构建的是团队的行为模式
什么是文化？ 本文并不研究它的严格定义，笔者认为它就是没有明文规定的团队的行为模式。
比如TA收到指责时的反应，当TA听到不同声音时的行为，当TA发现上级的决定有可能是错误的时的反应，当TA发现别人的开发进度很慢且很有可能会让团队延迟发布时的反应，各种各样不同的行为和反应最终在团队内形成一种模式，没有具体规定和流程，但是人人遵循。在刚刚笔者团队刚刚成立的时候，团队文化建设并没有提上日程，因为人数还很少，但是四个月之后，人数增长到20+，有毕业生，有社招，有自己公司的。那时候出现了一个显著问题，就是大家不愿意表达自己真是的感受。边现在哪里呢？毕业生在团队中感到迷茫，但是他们仅原因私下在自己的小圈子里面分享这些，Senior开发感到迷茫，觉得自己没有表现出应有的价值，但他们也仅仅在团建时和一小撮人私下里吐个槽。显然，团队体量扩张的速度超出了团队的安全感的增长速度，这个混合团队已经没法给大家提供心里上的安全感了。笔者做了这几件事儿：
- 人员能力培养计划，该计划主要是通过知识分享来提高大家对项目中使用到的关键技术的理解
- Senior人员胜任力模型，主要描述了作为一个高级开发工程师，TA需要在团队中表现出的行为准则
- 反馈导入，明确大家对于反馈的正确态度，如何给别人提供反馈以及如何收集反馈，详情请参见《你会给别人提反馈吗？》
前两件事情是在解决个人能力以及团队对自身期望的问题，希望能够通过这种方式，鼓励他们做出与与自己定位想匹配的事情，换句话是说，降低了关键行为的心理门槛。
当你做完这些，你就能稍稍喘口气了，至少你有很大概率活下来了。
