05. 团队磨合
上一篇介绍了团队组建的过程，当团队搭建起来开始运转时，作为领头羊、团队的掌舵者，我们首先需要解决的就是团队协作问题，即我们应该再团队的磨合期做些什么，以此来实现彼此的逐步熟悉、建立信任和提高协作效率
本文组织结构的思维导图如下，基于3w原则
1. 什么样的团队需要磨合
再看这个命题的时，首先需要明确的是，什么样的团队需要磨合？
一般来说，一个成熟稳健的团队，是不需要磨合的，对于这样的团队，需要关注的是信任的融入过程是否丝滑，是否有完善的培养晋升机制
而需要磨合的，则往往是我们这种新组建的团队，团队成员可能是新招，也可能是来自不同的部门进行抽调组成，由于大家彼此不熟，既往的工作履历、习惯、背景都存在差异，相互的信任还未建立，从而导致团队的整体运转不够高效明朗、相互之间的协作混乱冲突。 新组建的团队，都会经历一个磨合期，对于团队的管理来说，我们需要干的就是加快这个磨合过程，迅速增强凝聚力。
2. 磨合什么
对于管理者而言，我需要做什么？ 基于我个人的实际认知，分成下面几点
2.1 明确目标与期望
正如每个旅程都有目的地一样，每个团队当然也有自己的使命与目标。对于团队管理而言，明确要干什么当然很重要，那团队成员呢，真的重要么?
以我个人的实际工作体验来说，当我是一线小兵时，对于团队的整体目标，并不会特别关心，我只要知道我自己负责什么、要做什么、什么时候交付，将自己的事情做好即可。
当站在管理者的视角，再看上面的表述，你会发现上面的执行过程没有任何问题，只是可能出现问题的地方在于管理者对成员的定位以及任务分配，我对他的这些规划，是不是符合我们团队的整体预期？ 请牢记我们是掌舵者，这条船开往那里是由我们来决定的，当你发现团队走偏时，不用怀疑其他，90%以上可能性就是你自己的问题
2.2 标准的工作流程
从研发的角色，当然时崇尚自由、探索；但是作为管理者的角色，统一的标准和基线，是减少我们工作量的重要手段
2.2.1 统一的研发流程规范
只要一个公司的研发人数大于10，那么必然会有自己的研发规范（无论这个规范是明文还是潜规则，合理or不合理），这些或明文或潜规则的规范，可以简单理解为这个团队所有人认可的工作过程，比如对于研发而言，一套完整的工作流程需要遵循的有：
- 代码分支管理
- 需求交底，反串讲
- 方案设计、评审
- 统一的编码风格
- 提测前的功能自测
- 测试验收
- 部署上线
- 线上回归验证
2.2.2 受信服的项目管理过程
这里的项目管理过程，可以简单理解为我们常见的需求交付过程，比如常见的
- 产品需求交底
- 研发反串讲
- 研发
- 上测试，提测
- 测试通过，上预发
- 产品验收
- 上生产
2.2.3 清晰高效的沟通机制
工作上出现多人协同工作的可能性非常之高，那么必然会出现沟通，而沟通表达可能是很多研发的弱项，由于沟通的缺乏导致的信息差，对于团队管理者而言，往往是一拳重击。
2.3 共识的技术标准
由于我个人是研发出身，所以会单独说一下技术标准共识的磨合，why?
研发，通常会有一种技术崇拜，喜欢折腾新技术，乐于尝鲜；高级的研发认为代码写得好完全不需要研发；杀鸡用牛刀的炫技写法（潜台词即设计模式并不是所有场景通用，某些时候简单的if/else比设计模式更值得）
但是对于团队、公司而言，稳定可持续的交付更重要，对于新技术的引入一般会很慎重，更重视代码的可维护性、阅读性
因此这里说的技术标准，包含但不限于以下：
- 技术栈选型
- 编码规范
- 架构设计原则
- 通用的文档模板:
- 新技术/组件的引入原则、评审机制
- ...
2.4 熟悉工具栈
每个团队都会有自己的效率/运营工具，请不要把这些大家今后工作中，高频使用的东西“藏起来”，我们应该金align的让所有的小伙伴，可以无障碍，快速的熟悉这些，比如
- 代码管理工具：git/svn
- 项目管理软件：jira/禅道
- 持续集成/持续部署CI/CD
- 知识库：钉钉/飞书/石墨/wiki
- 内部的运营工具等
2.5 问题解决机制
这个也是团队磨合中需要提前解决的点，这里指得问题，有两类
- 人的问题
- 团队成员关系问题
- 工作习惯的冲突问题
- 外部沟通、配合障碍的问题
- 事的问题
- 系统故障处理预案
- 线上问题处理机制
- 业务边界问题
人的问题，若不能提前解决，那就真如那句“人心散了，队伍就不好带了”； 事的问题，解决不好，则容易带来直接的经济or口碑损失
2.6 共享机制
磨合期间，个人强烈建议需要解决的一件事情是建立一套透明的共享机制，让知识再团队内最大化的流动起来，避免出现单点问题；同时一个良好的分享氛围，也可以有效的提高团队的稳定性
分享主题尽量可以分散一点，不要局限在技术侧
- 业务分享
- 技术分享
- 人文分享
2.7 信任建立
在磨合期间，需要解决信任问题，这个拖的时间越长、解决得越差，那么团队得磨合期就只会更长
我们需要重点解决两种信任：
- 团队成员对领队的信任
- 团队成员相互之间的信任
2.8 绩效与考核机制
透明的绩效与考核机制，对于团队的稳定性有较大的帮助，当然一般团队的管理对绩效制定这块并不会有太大的抉择权，所以在磨合期间做好宣贯即可
3. 怎么做
当我们明确上面指出的几点之后，接下来就是需要去实现、去解决。 下面将结合个人实践进行阐述
3.1 目标与期望的宣贯
目标主要针对的是团队的职责、任务目标； 期望则是上级对团队的预期以及你个人对团队成员的预期
step1: 认清目标与期望
作为团队管理者，这个是自己首先需要明确的点，关注项目背景、团队的组建原因，和上级多交流，总结自己的认知然后和上级领导、横向的团队管理进行交流，确保没有大的理解偏差
以我所经历的这次团队组建来说，上级制定的目标比较明确
- 短期目标： 一个月内可以承接商城的简单需求研发交付
- 中期目标： 三个月内独立原团队，完成所有研发、运营任务的研发交付
- 长期目标： 彻底掌握商城，运营商城，改进商城
对我们的期望总结两字就是“专业”
step2: 目标同步
当我们搞清楚目标和期望之后，需要在一个相对正式的环境下，给团队内的所有小伙伴进行宣贯，告诉大家我们应该往哪个方向努力，这一阶段请确保每个人都明确知道中短期目标，尤其是短期目标，是否都认可，愿意往这方面去努力
step3: 任务拆解
告诉大家方向之后，作为管理者，我们还需要为他们分工，每个人应该做哪些事情以使得我们可以实现目标
同样以我所处的团队为例进行说明（在新的项目组，我主要负责商城的订单和中团两个团队，下面以订单为例进行说明）
首先圈定团队业务边界
- 订单团队负责下单之后的所有流程
针对所有业务，按人头的方式进行粗分
- 下单到采购计划： 1人
- 订单: 1人
- 收发货：1人
- 物流：1人
- 结算：2人
- 支付：1人
- 金服：1人
- 售后评价：0人 --> 在我们这个商城项目中非常不重要，因此前期不用排人
step4: 明确要求
上面是任务分工，如果活只是派下去了，但是没有明确的要求或者时间限制，那么这个任务的执行情况恐怕并不会好，因此一个合理的任务分配，除了告诉对方要干什么之外，还需要明确时间、产出物
如我所属的订单团队，任务职责划分之后，定了几个使用短期的关键节点计划
- 3天：熟悉研发运维等流程规范，应用本地能跑起来进行debug测试
- 3天：梳理出各自领域内的数据模型，最后建立各主数据的关联关系
- 1周：实际体验商城的整体流程，梳理各自领域内的主体业务逻辑
- 1月：完成一次完整的线上迭代交付流程，熟悉常见的线上运维工具
step5: 阶段性验收
按时检验任务执行情况，对交付好的不吝称赞，对实现的不好的找一下根因，动态调整交付任务与目标
3.2 沟通机制建立
这一块内容较大，后面放在团队沟通这一块的内容进行展开。 可以简单说一下团队磨合期间我的个人做法
- 方式一： 和组内的小伙伴一起吃饭，吃饭的过程中闲聊，增进关系
- 方式二： 和组内的小伙伴1v1面对面的交流，聊工作、聊困惑、聊生活
- 方式三： 组织分享，就分享主题进行沟通讨论
- 方式四： 前期，重点关注各位组员的任务交付，主动去了解他们的执行情况，是否有问题，及时掌握第一手的信息
3.3 建立标准的工作流程
让我们从0到1建立一套标准的工作流程并不太现实，但是抄一份适用的还是比较简单的。 大部分的技术管理，都是积年的老开发，或多或少在不同的公司、团队都待过，将自己既往的工作方式，提炼重整一下，输出一份工作流程还是有可能的。若实在不行，直接将之前工作过程中，认为不错的标准拿过来直接用，也不是不行
在我们制定工作流程时，切记几个注意实现:
- 邀请资深成员参与流程制定的讨论，避免采用少数服从多数的策略。这是基于团队成员的常见梯度，即初级成员通常占据大部分。
- 标准工作流程的目标是为了统一和规范我们的工作机制。我们不能盲目迷信教条和大厂的光环。如果我们采用了其他大公司的工作流程，我们需要根据我们的实际情况进行调整。
- 工作流程制定完成后，我们需要在一个正式的场合，向所有团队成员进行宣讲
比如我们当时制定的几个流程规范 （后续再给大家进行介绍）
- git工作流规范
- 代码规范：java后端编码规范 & 代码检测规范 & 命名规范 & 日志应用规范
- 数据库与SQL规范
- 需求自测、提测，发版上线流程规范
3.4 熟悉工具栈
这个比较简单，首先身先士卒去了解所有相关的工具栈，然后整理一个图谱和简易的使用手册，然后这个手册的维护与更新交由团队内最后一个入职的小伙伴（即将这个手册顺道做成新人手册，再新人熟悉项目的同时，同时记录自己疑惑以及对应的解答，这样也可以减小后续小伙伴的融入成本）
常见的工具栈包括研发 + 运维两类，如
- 代码管理工具：git/svn
- 代码仓库：gitlab/gerrit/github/gitee等
- 项目部署：jenkins/gitlab ci等
- 代码检测：sonar
- 日志查看：grafana
- 全链路： skywalking
- 监控预警： sentry
- Sql审核查询平台： archery/Yearning
- api管理平台： yapi/swagger
- 研发运营管理后台：xxx（通常是自己实现的，共研发、运营使用的工作台）
- 项目管理软件：jira/禅道
- 知识库： 钉钉文档/飞书文档/Confluence Wiki等
3.5 问题解决机制
关于问题的处理，可以衍生的内容也很多，会再后续的内容中以真实案例进行展开，这里主要说一下再磨合阶段，我们可以做的努力，以及预期达到的效果
首先说我们的预期目标：
- 融洽的团队关系
- 养成问题及时上报的习惯
入我们现在得到共识和执行落地问题处理机制如下：
系统问题
为了确保线上问题能够得到有效且高效的解决，我们制定了以下通用的问题解决流程图。该流程图详细标注了从问题出现到问题解决的全过程，以指导相关人员如何进行问题处理。
- 开放沟通的习惯：在遇到问题时，首先需要养成开放沟通的习惯。一旦发现问题，应立即上报，确保问题能够被及时捕捉并得到关注。同时，需要有人主动跟进，确保问题能够得到及时的处理。
- 问题追踪文档的建立：根据我们的问题处理模板，我们需要新建一个问题追踪文档，用于记录问题处理过程中的关键节点信息。这包括：
- 问题的提出：记录问题是由谁在何时提出的。
- 问题的接取：记录问题是由谁在何时接取的，并对问题的影响范围进行评估。
- 问题原因的发现：记录问题的原因是由谁在何时发现的。
- 问题的解决：记录问题是由谁在何时解决的。
- 问题原因的分析：在问题处理过程中，我们需要对问题的原因进行深入分析，找出问题的根本原因，以便能够从根本上解决问题。
- 复盘：在问题解决后，如果必要，我们需要进行复盘，回顾问题处理的过程，总结经验教训，以便在未来遇到类似问题时，能够更加迅速、有效地进行处理。
人际问题
- 作为团队管理，周期性的和组内成员1v1面谈。这种沟通方式不仅有助于了解成员的工作进度和挑战，还能加强彼此之间的信任和理解，从而确保团队的高效运作。
- 在每个大型需求交付的过程中，明确指定一个负责人进行全程跟进；团队管理则对负责人的推进过程进行兜底（如与外部沟通时的协助，内部推进的站台等）
- 请注意始终为你的团队成员站台，即该护短的时候别退缩（请知晓，你的团队成员可能除了你可以依靠之外，很难再得到其他的资源，若你不能为你的团队成员解决问题，那么你的权威和威信将难以建立起来）
3.6 共享机制
在组织中，若仅对成员施加超出其常规职责范围的额外任务，而未提供相应的激励措施，尤其是当领导层自身不参与其中时，这样的任务往往难以为继。具体而言，团队内部的业务技术分享活动，正属于这类缺乏直接激励的非日常工作内容。
基于我个人在多个团队的经历，具备良好分享文化的团队并不多见；而一个缺乏积极分享文化的团队，通常也会在成员的技术追求和交流氛围方面表现欠缺。 共享机制的搭建，真实尝试去推动之后，发现很难，下面是我的一些尝试过程
- 以身作则，亲自参与团队内部的知识分享，为建立分享文化奠定基础
- 制订详细的分享计划，并与团队成员进行一对一沟通，鼓励他们参与分享，协助他们确定分享的主题。
- 建立积极的反馈机制，在分享过程中充当热情的听众，确保主讲人不会因沉默而感到尴尬；每次分享结束后，与主讲人进行交流，肯定其优秀表现，并提出建设性的改进建议。
通过这些措施，我努力营造一个支持性的环境中，团队成员能够感受到他们的努力被认可，并从中获得成长和满足感。
比如下面就是我组织团队内成员做的一个面向整个项目团队的分享专栏（最后一个主题是我的🤭）
3.7 建立信任
这里主要说一下再团队组建初期，快速让团队成员信任自己； 不同的团队管理，采用的方式可能各不一样
我得执行方式则比较粗暴简单
- 身先士卒，参与团队内成员的所有需求交付过程；让自己成为团队内的业务专家
- 技术方案的把控，参与技术设计过程，展现自己的技术能力
- 拦截所有的线上运营问题，充当团队成员的第一道门户（尤其是我们这个新组建的团队，从另外一个团队手中接手新的项目，大家对系统都不熟），给团队成员熟悉系统的时间和空间
- 参与团队成员和产品、测试、外部人员的对接过程，协助他们的推进过程
- 帮团队成员背锅，能抗事
- 主动分享（技术 + 业务 + 效率工具 + 运营排查手册）
3.8 绩效与考核
这个没什么好说的，一线的团队管理没有这个权限；后续会给大家说一下有效的 “精神激励法”
4. 小结
这一篇主要介绍的是团队磨合的相关内容，对于一个刚开始带团队的技术管理而言，可能对这块不知道怎么做，一如几年前只知到莽的我。。。
这里总结了一下个人的实际经验，介绍了磨合什么，怎么去做的一些个人看法； 当然每个团队的实际情况不一样，并不存在通用的万能公式。总的来说，这个磨合过程，主要就是实现大家的工作同频、拉齐认知，减少团队内的龃龉；接下来一篇，我会给大家介绍一下这个磨合过程中的输出物：《如何做项目的持续交接（项目流程规范制定与宣讲）》