我从未结束的Java之旅(二)

大胆北漂

餐饮

团队扩张

   由于公司业务的扩展以及战略方向的变更，之前负责得小团队不得不扩招，由5个人得团队补充到了20人。当时我们saas服务已经很庞大了，基本涉及到餐饮相关的所有业务，可能有的业务不太成熟，但是也在持续完善。为什么扩张团队呢，因为决策层想在saas的基础上做多品牌。什么叫做多品牌呢？就是在原有多租户的基础上再做一层业务耦合，一个品牌下面有多个租户。🤔🤔一句话能概括的事能有多难？那肯定是非常难，不然也不至于疯狂扩张，整体差不多50多人的团队在半年时间扩张到了200多人。
   团队扩张面临一个问题，就是面试。大家都知道北京面试很卷，但是你们不知道的是北京的培训机构很多，多到数不清，这也导致来面试的人鱼龙混杂，水平参差不齐，特别是工作经历造假的非常多，到底有多假，我给你们举个栗子🌰，我问一个面试者如何遍历一个集合把奇数找出来的时候，他说用眼睛看的时候我就知道这个选手肯定不简单🙈🙈🙈。刚开始每天差不多要面试5~10个人，每个人大概半小时的时间，问的也都是一些制式问题，随着不断的面试，发现第一波人面试完之后，培训机构会收集面试题给学员进行集中的培训，第二波人来的时候就都是标准答案，对答如流😂😂，不得不佩服机构的高效。于是我们就抛弃制式问题，去用一些业务场景来考量面试者是否有实际经验、他的经验能解决什么程度的问题，等差不多能给面试者一个层级的定位，之后再去考察他的代码功底、基础、算法、中间件等等。果不其然，这样晒掉了大把的培训机构学员。

扩张的烦恼

   "We try to create teams that are no larger than can be fed by two pizzas," said Bezos。
   我大哥贝索斯说过two pizzas team是比较合理的配比。刚开始我的团队两个披萨还是可以喂饱的，所以对于我来说相对比较轻松，你可以当救火队员，到处修复bug；你可以当码农，安心坐下来写代码；你可以当产品经理，和产品经理们一起坐下来讨论业务；总之你还可以做你自己。🤨🤨
   但是疯狂扩张之后，别说两个披萨了，四个披萨都够呛，你就能体会出来管理者的烦恼了。这一种身份转变也对应着你的工作内容的改变，你对整体工作的关注点就会变得不一样。刚开始接手20人团队的时候还有点小兴奋😏😏，毕竟出去吹牛皮也有点东西。随着工作的展开，发现这个牛批可不是那么好吹的，由于是新的需求，我需要参与整体架构设计、技术选型、数据结构变更的规划、业务逻辑的梳理…等等内容。突然发现自己没时间写代码了。每天的工作时间拆分成了一个一个的会议。工作的具体内容从具体的代码变成了指导别人如何去理解业务、如何去设计功能、如何具体实现代码的时候，我发现这对我的个人能力又是一次新的挑战，这非常考验一个人的综合能力。

团队管理的探索

   初期的一个月时间，我磕磕绊绊的在摸索，疲于应付，只有在下班的时候才有一点属于自己的时间去撸一下代码，虽然说要负责一个团队但是还是不希望自己脱离一线开发，因此还是会给自己布置开发任务去完成，其他时间都贡献给了组员、日常会议、还有和产品经理撕逼。一个月的时间暴露出来很多很多问题，比如人员水平参差不齐、业务实现难度不一、需求排期、技术问题攻坚、人员管理等等。我的同事兼好大哥虎哥曾给我说过最难管的就是人，经过这一个月的摸索我是深有体会。
   在磨合期间，你就会发现5个人的游击队有什么事大家坐一起商量一下就很好解决，人数越多你的沟通成本就越高。磨合期间我最主要的工作就是开会梳理业务方案和技术方案，再组内开会进行任务拆分和分配，最后再开会跟踪一下每日进度防止有任务因为种种原因delay。这个时候墨菲定律就跑出来说："你必须延期"😵‍💫😵‍💫。
   那么如何提高人效比就成了一个关键问题。从这个小团队的建设到成长，我学会了几个关键词：“发掘”、“平衡”、“放权”。这也在这次团队磨合中占有重要的作用。
   首先，我认为一个好的管理者一定是对自己下属的能力了如执掌的，管理圈里面流传着一句话叫"如果有一个紧急的事，你就把他交给目前最忙的一个人准没错",这句话凝结着许多管理大佬的智慧，不可否认有一定的道理，但是站在我的角度，我认为是不合理的，尤其是工作内容是研发生产工作，特别是针对新团队的建设，往往需要管理者去发掘每个人的潜能，并且对每个人的技能擅长方向、不同业务方向熟练程度去有一个综合评判，只有这样才能面对排期从容不迫，面对问题胸有成竹。
   从团队组建初期开始，人员的扩张意味着你任务量的增大，这一变化打破了之前5人团队建立的平衡，小团队好管理的原因在于任务数量有限，当一个人能力足够强的时候可以力挽狂澜。任务数量由量变产生质变的时候，个人能力就显得十分有限。这时我意识到前期的平均分配确实存在一定的管理失职。
   经过一段时间的观察，我对团队人员能力(综合能力及研发能力)进行了重新评估，划分出了一些责任心比较强且沟通能力尚可的人员去分担我的一部分和产品经理撕逼的工作,放权让下属去大展身手会释放管理者的时间，同时也会给他们带来更多的参与感，但是也会带来一定的风险，此时的管理者就需要及时纠正偏差，他们作为团队内部与其他部门连接的桥梁，效果好过某一个人去单独沟通某个需求，如何纠正偏差，我们每天会有站立会，分别在上班后和下班前，晨会要求大家没人3分钟说明今天自己的任务，晚会要求也是在同样时间内说明当天为完成的内容及原因，这里开会的目的是由老人来综合判断任务进度及偏差及时纠正，并解决当日未完成的问题，而不是单纯的听取汇报。
   当面对一些技术难题的时候，我会选择让一部分性格比较急的同事去攻关，因为互联网行业不同于传统行业，它对用户体验和时效性十分讲究，性格较急的同事比较容易暴露问题，我想要达到的目的无非就是两种：一、能快速解决问题。二、能尽快暴露问题。快速解决问题不用多说，尽快暴露问题是说当你解决不了的时候我希望你能动用团队的力量而不是自己在那里苦思冥想，毕竟我们的职责是研发而不是研究，究其根本是为了快速解决问题而生。
   这时有人肯定会说那技术呢？分配任务难道跟技术水平没有关系么？当然有关系，之前说的两点只是粗略的划分了问题种类，说到具体任务如何平衡，我参考了敏捷开发中的任务分配方式，首先我们会进行任务拆分，将任务粒度尽可能的精细化，以小时为单位，并且对任务进行粗略的难易度划分，最后由每个人去自由的领取任务，当然绩效会向任务数量及综合评分较高的人员倾斜。平衡不代表着平均，在我的概念里面，你的付出和你的回报成正比，才是一个好的管理者去平衡的基点。
   逐渐对人员潜能的发掘，在管理中对团队成员进行放权，及时纠正偏差，平衡任务分配权重，团队在不断磨合中走向正轨，管理方法是很灵活的，这些内容是我在针对我这个团队不断摸索出来的心得，并不适用于所有团队，每次接管新的团队都需要用心去经营，不断的思考才能权衡出一个合适的管理方式。