如何应对快速发展的团队所面临的挑战？
为了加深EGO会员之间的相互了解，同时也为更多的技术人提供相互学习交流的机会，EGO开展了线上分享活动。本文是根据洪强宁线上分享的内容整理而成。
先介绍一下自己，我毕业于中南大学，有三段从业经历，分别是深交所信息公司，证券时报和现在的团贷网你我金融。其中，证券时报和团贷网你我金融两次都是白手起家从零开始招聘技术团队，现在管理的开发团队过百人。下面我主要想分享一下自己在从零开始的技术团队快速发展过程中积累的一些经验和教训。
新团队建立的过程中遇到的首要问题就是人员的招聘与筛选。如何组建团队、迅速招到合适的人?
首先，我觉得团队带头人要有一个规划，所谓男女搭配干活不累，虽然技术团队大多数是和尚居多，但是人才梯队、人员气质和层次的搭配互补事先要想好，谁都希望团队里个个都牛逼，但这个代价不一定每个老板都能承受得起，所以做服务器这块可能要求稳重型、能力强、经验丰富的人多点，页面端可能要求年轻化、偏活泼、思路偏开阔的人多点，是否需要专门的架构师等等，这些在团队组建之初就要事先规划好。
在规划好团队人员之后，接下来最主要的工作就是招人，在团队组建初期最高峰我曾经一天面试了四十多个人，人称面霸。如何能迅速招到合适的人，我个人的方法有以下几个：
1、面试出场景化题目，给开发人员拔高。例如对于Java开发的人员，问完他熟悉的框架之后，我一般会出个稍微复杂点的、跟前后台相关的中大型架构题目，我说的前后台指的是APP+java API这种架构或者通用的MVC架构，这个架构题目一般都有两三种以上的做法，答案很多时候见仁见智，也没有固定的对与错。
通过开发人员的答复，你可以判断出这个人是偏保守还是偏激进，另外很多开发人员在之前的开发过程中都是只做自己的那一块，当面向这种稍微复杂点的中型架构题的时候可以看出开发人员的思路是否清晰、是否周全、之前有没有想过这些架构问题，这些都能看出来。
2、渐进式提问：提问-倾听-观察-记录-控场-识别谎言。层层深入问问题，例如请讲下你工作中遇到的最有挑战的事情-你是如何解决的-你为什么这样解决-如果换成现在的你有什么更好的解决方案-通过这个事情你学到了什么，这些问题环环相扣，对此，一方面可以迅速判断出之前的回答中是否有谎言存在，另一方面，可以观察面试者在回答这些问题时逻辑的严谨程度、态度、情绪、综合素质和能力。例如声音较大一般来说性格较外向，语速较快一般来说思维较敏捷，但严谨性方面可能要打问号，性子可能较急，如果结结巴巴可能是自信心方面可能有问题或者之前回答的问题可能有水分等。
3、问其喜好。一般外向主动型的人会更多的喜欢户外运动、球类和K歌等活动，内向含蓄型的人更多的会喜欢读书，看电影等活动，不过这个也不是一定的，要结合前面的问题来看。
团队磨合也是团队气质养成的最重要阶段。所谓的团队气质，很大程度上就是团队带头人的气质。招到一群一起做事的人，大家能够气味相投、休戚相关、荣辱与共，这样团队的整体效率和认可程度才会大幅度的提高。
在快速发展的团队中，人员一下子扩张的速度相当快，互相之间来不及统一思想甚至连认识都来不及，每个人的学历不同、家庭背景不同、过往从事过的公司不同、代码规范不同、开发流程也不同，程序员相对于其他岗位来说又比较单纯，不会绕弯子，有一说一有二说二，而且一般来说都认为自己的选择是最牛逼的，遇到问题很容易发生争吵。导致新团队的磨合是个大问题，team leader经常很头痛。
其实刚招进来的人还不能说是团队，充其量是团伙，如何把团伙迅速转变成团队，这个问题在每一个快速发展的团队都会遇到，如何解决？见仁见智，我说下我的几个思路，大家可以讨论下:
1、团队领导者要在团队中迅速树立自己的威信，做好冲突协调者。因为刚招进来，大家对你的感觉还停留在部门经理或者老大的认知上，需要迅速让大家认可你，从而你的思路才能迅速的贯彻到位。
方法上我一般采用技术分享会的模式，多给大家讲之前的经验教训，然后分析我们马上要开工的项目的具体目标、最后成果、技术路线、关键里程碑、难点在哪、会用哪种架构、业界现在流行的架构有哪些，我们为什么会选这种架构，优缺点在哪里，安全性如何考虑，性能方面如何考虑，扩展性方面如何考虑，开发模式是敏捷还是瀑布还是原型，优缺点在哪里，用什么项目和bug管理工具以及培训。磨刀不误砍柴工，通过技术的沟通和交流，使大家思想统一，今后干起活来有最基本的共同点。
2、团队工作作风统一，强化团队纪律。例如每个小组的责任分工，今日事今日毕，每天下班前填写工作日报，下班前合并测试完整代码分支，bug发现提交关闭转交的具体流程等具体事项，必须要有具体的规章流程。让大家统一工作风格，从而形成整个团队的工作风格，后面新加入团队的同事，自然而然的就会跟上不掉队。把某种共识复制到各个成员，则整个团队的目标趋向一致，每一位成员自然知道压抑自己的某些自由主义的想法而满足项目团队的需要。
3、如果发现有人没做好，采取个别谈话的方式来解决。个别谈话的方式要从核心圈展开，从骨干成员到一般成员依次进行，先统一骨干员工的思想，把他们争取为同盟军，再和他们一起去统一其他成员的思想。最后检验统一思想的标志就是所有成员对团队工作的理解是一致的。
4、逐步累积团队各方的信任。团队磨合的阶段最显著的问题是团队成员间没有建立起信任关系，这和成员间的相互了解不够有很大的关系。信任关系的建立需要一个过程。所以，团队带头人要通过一些事件来建立项目成员间的信任关系，包括测试组和开发组，架构师和普通开发人员等，团队成员之间也会透过一些事件来评估自己的合作对象的可依赖性，所以，彼此都能信守承诺的成员，他们的信任会逐渐积累，信任积累到一定程度就会成为默契。
信任是项目成功的基本保障，默契是项目实施过程中最大的财富。在项目团队中营造一种如期保质保量地完成任务的项目组文化是团队带头人最重要的工作，没有之一。
其实刚才谈的都是快速发展过程中必定会遇到的问题，除上面那些之外，我还想说下沟通问题也是大家伙在团队快速发展过程中最容易遇到的。
随着人数的快速增加，沟通的成本也呈现几何倍数的增长。当团队十来个人的时候，其实沟通根本不是问题，开个午餐会当众宣导一下就结束了，当团队膨胀到五十人、八十人、一百多号人、几百号人的时候，如何迅速建立一种高效的沟通机制是团队管理者迫在眉睫的问题。
我采取的办法是军队当年的三三制。
现代军队中的“三三制”是指“一师三旅、一旅三团”等编制原则，即上级单位辖有三个下级单位的编制。军队体制编制“三三制”，最早起源于英国将军汉密尔顿爵士依据军事组织的历史得出的结论。他认为管理幅度应在三至六人之间，三人将使一名军官相当忙碌，而六人也许要一天工作十小时。
他论述道:“我们越是接近整个组织的最高司令，就越是应当按三人一组进行工作,我们越是接近整个组织的基层(战列步兵),就越是应当按六人一组进行工作。”他的这个理论影响甚大，英国的军队体制依此按“三三制”编制。随后，苏联等国均采用此编制。国民党军在黄埔建军之后，师法苏联，改行为“三三制”编制，即师辖三团，团辖三营。我大解放军也在很长一段时间内运用过这种组织形式。
回到我们的团队管理，三三制的本质是缩小管理和沟通范围，降低管理成本。我们也将大团队按照项目组拆分成一个个的小组，每个小组最多不超过6人，每个小组设立一个项目经理，但这样在一个大团队中，项目经理可能会偏多，在百人以上的团队中项目经理可能超过10个，如何管理？再编组，接口或沟通密切的三个项目经理为一个团，设个轮值小团长，对三个组进行有效的沟通和管理。
轮值小团长有沟通和协调解决问题、汇报问题的责权利，团队带头人在事项紧急的情况下，直接召集轮值小团长进行沟通，有问题迅速传达。这样的好处是可以将带头人的思路迅速准确的传达到每一个团队成员，同时由于小团长是轮值的，不是常设职位，也不是层级职位，比较好的解决了团队扁平化的问题。团队还是CTO-项目经理-团队成员三级。
最后说的一个问题是快速发展团队的KPI，对此，我来说说自己的想法：
到底初创团队要不要KPI，我认为不要。初创团队我指的是50人以下的团队，这个时候以目标和关键成果OKR为主，结果跟工资或绩效不直接挂钩，通过周例会或者月度会议来review我们共同制定的OKR。为什么这样说，KPI是过程导向，强调的是过程参数，OKR是目标导向，强调的是结果。
在初创团队没有形成一定规模的时候，知名度不高，优秀人员招聘难度也很大，有技术人员来就不错了，好的人基本不来，你作为一个团队管理者，很大程度上面临的是整合一部分二流甚至三流的技术人员（当然BAT那些自带主角光环拉一票人出来高起点开干的我们不在这里做讨论），却要迅速搭起来一套可用的系统。
注意我说的是“可用的”三个字，为什么这么说，创业之初技术部门首先面临的就是创业成本的压力、老板的压力、业务部门的压力，团队的每个人都处于赶工的状态，大家都在拼命的向前跑，都在等你技术部门出成果去推广拉新用户，这个时候很大程度上会牺牲掉系统的性能架构等一系列的东西，这个阶段去强调KPI，强调过程管理，强调过程参数，更多的是本末倒置；强调目标，强调团结，强调结果，在这个阶段更能满足业务需求。
在团队发展到一定规模（我认为50人是个分水岭）需不需要KPI，我认为要。但是是相当有限度的要，还是与OKR结合起来的KPI，OKR为主，KPI为辅，为什么这么说， KPI从最大程度上提高了效率，却也是一把双刃剑。
原因有二：其一，技术改进是每个技术团队在渡过最初的产品赶工的阶段都会面临的事情，有些事情大家都清楚值得去做，但在做出来一部分之前无法测量，也因此无法制订KPI。没有写进激励机制，那创新就显得困难了些。其二，如果没有人对最终结果负责，每个人只对自己的过程负责。那么，为了KPI上几个数字而忘了初心，就难免发生了。
回到OKR，为什么硅谷那些高bigger的公司都抛弃KPI选用OKR，OKR恰恰不以考核为目标，是让人更加聚焦重要领域。对关键结果可量化，而且公开透明更加容易获得大家的认同。
那OKR这么好，为啥在我大天朝落地还要KPI作为辅助呢，团队慢慢大起来了，人员也开始鱼龙混杂，KPI更多的是团队指挥棒而不是非要说扣钱不可。在某个阶段整个团队可能会强化某个思想理念，例如优化月、代码review的覆盖率、bug率等等，这个时候用KPI可以更有效的让团队来重视当期这些指标。
但是团队管理者要注意的以下几个方面:
第一、团队这个阶段有可能更多的去重视这些指标从而放弃其他方面的要求，尤其是创新。第二、需要仔细分析团队中KPI的变化，而不能简单地认为KPI中预先制定的某个指标变差就是团队工作出现问题。例如新上线重构版本，肯定会带来bug率的提升。（线上稳定跑了一段时间的版本肯定bug率较低），如果因为这个KPI指标的下降否定重构所带来的创新和性能的增加，则是捡了芝麻丢了西瓜，得不偿失，这个值得我们每个技术管理人员切记。
最后总结下，在我的理解里面，这两种绩效工具没有优劣之分，KPI强调的是“要我做的事”。而OKR致力于“监控我要做的事”。适时地运用两种绩效工具，理性的分析每种绩效工具产生的数据而不是单纯地奖优罚劣，才是我们技术管理人员要做的事。