大家好，我是杰哥

好久不更新，实在惭愧~

今天要给大家分享的是本人历经一年左右的新人团队带领经验的总结，相当于个人的一个总结复盘，也希望其中的几点，能够与您的思想发生碰撞，或者能够对您产生启发~

温馨提示： 文章有点长，但是干货满满！所以建议先收藏，再细看呢~

一、招人选择

评估自己当前的项目安排，预估需要的团队成员应该是怎样的：包括技术栈以及项目经验。比如要看他们是否会有一些独立带领团队，参与模块设计、自己研究新技术并使用到工作中的经验。其次，还有一点也很重要，就是一定要选择富有热情、朝气、能量的人，适应公司性格，与公司的文化相匹配的人。这样他们过来之后，才会很快适应团队的节奏，快速成长，可以负责得了越来越有挑战性的工作。

二、统一标准

1、代码规范工具引入

提前定义好一份代码规范，并引入代码规范工具（如pmd组件）在过程中进行规范规定团队成员在编码前，必须先安装好pmd和代码格式化等组件。在具体实施过程中，将该组件的检测结果作为 Git流水线的一个必检结果，如果某个分支的代码规范检查结果不通过，则该代码合并请求不做处理。在过程中就遵循这套代码规范，最终代码质量最起码不会有太大的偏差

其他规范，如业务相关的处理方式，则通过代码 review 过程来保证。也就是说，通过工具结合人工的方式来保证代码质量，能够有效提升团队整体的代码质量

2、代码规范制定

在第一个版本结束之后，根据版本中代码 review 以及代码走读过程中发现的大家的代码中存在的一些问题，整理出一份编码规范和日志打印规范。从第二个迭代开始，大家除了需要继续遵循之前的 pmd 代码规范以外，还要遵循这套编码规范，从而不断提升团队整体代码质量

此外，对于代码质量来说，也要持续进行代码重构。比如把公共的部分抽取出来，大方法拆分为小方法等。

那么时间久了，代码只会保持清晰、美观，不会留下太多坏味道

3、构建流畅的工作流

对于团队中的通用流程：单测、打包、黑鸭扫描以及上述所提到的代码规等通用流程，提前构建好一个 Git 通用流水线。大家提交代码之后，对于每次的一些必检项，比如单测、代码规范等，设置为提交后自动检查，结果一目了然；对于非必检项，则设置为手动触发检查。能够提升团队整体的效率。

4、团队的问题登记手册

对于每个人日常工作中遇到过的一些典型问题，由团队中的任何一个人登记在问题经验登记手册中，这样自己或者其他人要是也遇到了类似的问题，便可以快速解决掉了

5、开发经验分享手册

开发经验分享手册，指的是项目中各个成员针对项目中总是能够经常用到的一些操作技巧，进行整理分享，并登记在一份手册中。比如我们项目组的开发经验分享中，就包括了 如何在docker中快速执行增量sql脚本、如何快速查看 Git 两次提交间的文件变动、如何快速定位测试环境上的问题等

常用到的这些操作，被登记在一个公共的地方，方便大家的使用。不仅可以帮助新成员快速融入项目团队，也可以帮助团队成员们将时间投入到更重要的事情上

此外，大家在分享过程中，不仅可以加深他们的理解，还能够提升他们自己的成就感，从而能够带动整个团队的氛围，所以总得来说，还是百利而无一害的

除了这些以外，在团队中还可以推广一些工具类。如 Java 中统一的工具库 hutool ，快速定位环境上的问题工具 arthas 以及快速调用 http 接口的工具 Retrofit 等，都可以有效提升团队的整体效能

三、设计分层

将项目中的架构设计，考虑人员的梯队结构，分别进行横向和纵向分层

纵向按照项目架构来进行区分，分为核心层和业务层。其中核心层指的是一般情况不会发生变化、复杂度较高、影响团队整体代码质量的层级，比如对于第三方接口的调用的统一接口封装，公共处理逻辑、对于统一工具类的封装等等，而业务层则相对来说则更偏向于用户需求，随着业务变化相对频繁一点、较为简单一点。核心层一般由有经验的员工前期就预先根据业务梳理好，并封装完成，然后由业务层根据具体的业务场景进行适配调用即可

横向则以实现复杂度来进行区分，分别分为难度较高的模块和难度较低的模块。比如对于我们的项目来说，除了核心模块的底层逻辑比较复杂，功能实现比较困难。这个功能需要进行多个 API 调用的实现导致的一致性问题，以及考虑很多异常场景。而其他模块，则主要是一些增删改查以及一些业务上的处理、校验等。

所以，核心模块还是由有经验的员工来进行开发，在新同事还没那么多时间熟悉核心模块的业务与逻辑时，可以优先让他们从这些相对难度较低的模块入手，渐渐熟悉团队的开发规范、业务流程等，逐步进入状态，然后根据每个人的特点再逐步做出调整

四、需求分析阶段一定要重视

一般一个需求落地有这样几个阶段：需求分析、需求评审、开发、测试、上线。我们的第一个版本中，由于项目成员未及时到位，导致各个开发成员参与的只是是需求评审以及之后的几个阶段。但是实际上这样只参与评审，团队成员对于需求的来龙去脉理解是不透彻的，最后就出现了频繁的需求变更。

所以迭代二，我们在需求分析阶段，就尽可能地让所有干系人参与进来，一方面是让他们更了解业务，另一方面是对需求了解更多之后，在开发阶段才不容易出问题。过程中我会鼓励大家珍惜每次需求分析和评审的机会，因为这是开发同学能够了解业务最直接的机会了，要积极参与到需求的分析思考中去。

直到最新的迭代中，我们的基本上已经提炼出了一套具体步骤：

具体来说：

1、初步需求分析

CTO 和规划、PD 一起从需求和技术思路等方面的合理性，进行初步的需求分析阶段，分别由 PD 输出一版交互，CTO 输出一版系统需求，并输出最终的概要设计文档；

2、需求讲解会

召开一到两次需求讲解会，为大家讲解清楚需求的来龙去脉；确保让大家知道每件事或者每个需求为何这样确定，大家一起讨论参与更有存在感；

3、模块分配，成员熟悉模块需求

由 CTO 将各个模块的需求根据初步估算的工作量，以及以前的迭代中各个成员的表现情况，分别分配给各个组员，由大家分别对自己的模块进行熟悉；

4、需求疑问解答

组员对于自己的模块，再进行细化分析，过程中有任何疑问及时提出来；

5、需求反讲

可能的话，各个干系人都需要参加。相当于使得团队中的各个成员重新对需求有了更进一步的理解；将交流过程中的需求修改点记录下来

6、模块设计反讲

可能的话，各个干系人都需要参加。从设计角度来说，使得团队中的各个成员对于需求也有了更近一步的理解。将交流过程中的需求修改点记录下来，细化需求，并输出《详细设计文档》

7、测试设计、案例评审

各个开发，以测试的角度再重新去反观自己是否在性能、异常场景等方面还没有考虑完全，将没有考虑到的部分记录下来，在前期就考虑到。

总体来说，就是需要各个干系人尽可能早地参与进来，并在整体个需求分析、评审过程中有充分的交流和沟通的碰撞，最大化地细化最终的迭代需求出来。最终开发在编码之前的需求模块，一定是拆分得足够细了的，否则很容易出现理解偏差导致的需求变更。

五、需求矩阵一定要有

等我们的需求分析阶段结束，也就是说所有的需求已经完全确定下来了，这个时候就应该同时输出一份需求矩阵出来了

我之所以特别强调需求矩阵，主要是因为它在项目中还是比较重要的。不仅可以作为整个团队的整个生命周期的一份内部沟通的需求基准。还有一点作用也特别重要，但是常常被忽略，需求矩阵是一份粒度较细的需求文档，在梳理需求矩阵的的过程中，其实也是你与团队在重新整理思路、再次细化需求的的过程。这个过程中，你往往会发现自己之前直接看交互稿时根本没有发现的点，而这些点很有可能会影响到设计方案的变化、需求的变更，甚至导致项目延期

所以，整理需求矩阵的过程，也是在最大化地降低项目风险的过程

六、 过程中的工作逐步转移

在最开始，需要了解清楚团队成员的项目与技术栈背景，在模块分配上，根据大家的背景情况进行分配。经历了一个迭代的开发，通过平常的沟通、代码 review 以及日常工作中的表现，其实可以很容易发现每个人身上的闪光点与不足之处，根据这些，渐渐地就可以调整任务难度与类型的分配了

比如，在一个版本结束后，我们发现团队成员A的态度比较积极，提升自己的意向比较强，而他本人也是反应比较快，逻辑思路比较强，所以在工作之余，我也会通过一小部分测试工作、专门的业务学习以及简单 bug 的修改，渐渐让他开始熟悉核心模块的代码逻辑。经历了一个两个版本的历练，在最新版本的模块分配的时候，我就让他专门负责了一个与核心模块的逻辑类似的一个模块的开发工作

而成员B，则表现出来编码能力比较强，业务理解能力比较高，所以在过程中，若有一些临时的需求，或者较难的 bug，也会直接交给他去处理，渐渐地他表现出的能力越来越强，对于核心模块的业务和代码逻辑理解得也越来越深入。在最新的迭代中，我便将最复杂的一个模块直接交给了他来开发，目前是刚刚完成了需求与设计阶段，他的表现也是比较符合预期的

营造一种承担的越多，得到的就越多的氛围，从而鼓励大家能够多担当，多主动成长。这样既肯定了他们的能力，使得他们更有自信去进行项目的更有挑战的模块开发，又可以提升整体团队的效能

七、人员的培养

项目中的活都是需要团队中的各个成员配合去完成的，那么，成员能力的提升，还是比较重要的。不仅可以让他们自己逐步收获自信、收获成就感，从而提升日常工作的积极性；还可以提升他们的能力，从而提升团队整体的效能。

1、关注成员的成长

要做到关注成员的成长，我是从以下几个方面做的

1）了解团队中的每个人，发挥他们的优势

2）了解他们的弱项，并真心帮助他们提升

3）经常了解团队中各个人员的想法与问题，及时沟通

4）刻意培养，使得每个人成为某一领域的专家

不仅可以提升团队的整体效能，还可以让成员提升自信心

5）人员尽量固定

个人的技能和业务沉淀会更明显，对于项目整体来说，也比较节省时间，提升效能

6）邀请外部专家对部门的代码进行代码走读 以专家的视角来帮忙审视团队中的业务处理与编码思路、规范等，通过提出一些建议，为团队注入一些新鲜的东西。避免团队一直以来只是闭门造车，没有太大成长的可能

2、因人制宜

对于团队中喜欢挑战的人，就需要不断给予更高难度的工作任务，激发他的潜力和工作热情，一旦从工作中获得了成就感和认可，也就对团队有了归属感

对于工作经验或者工作能力不突出的团队成员，可以给予 easy 和 middle 级别的任务，不断积累经验，结合他的工作动机，看是否需要给予更高级别的挑战

一个团队一定是有梯度的，但是这个梯度不是固化的，随着工作经验的积累和团队 leader 的培养，是有可能从一个小萌新成长为团队重量级人物的

3、适当授权

相信大家的能力，适当授权

4、自尊、尊重

每个人都会极力的维持自己的自尊，所以在管理中，我们切记不要采用“说教”、“批判”的语气。之所以对于说教反感，其原因在于说教这个方式就包含了居高临下的意思，对于他人的自尊造成了威胁

所以想要管理好一个团队，首先就是要尊重对方，采用一个平等的方式去和对方交谈

5、关注成员

霍桑效应告诉大家，在下属觉得被关注的时候，会刻意的去改变一些行为。而这种被需要，被关注的感觉，会让他们加倍的去努力工作，来证明自己是优秀的

因此，我们在带领一个团队的时候，不可以让员工觉得自己没有被关注到。而他们在感觉到被关注的时候，哪怕你没空看他们具体的表现，他们也会努力的做到最好

6、自主意识

我们不应该直接地告诉下属该怎么做，而是通过引导他有自己的思考，然后经过和他的讨论，最终完成一个方案的制定，这会让团队成员的成就感和参与感翻倍，从而执行起来就更有效率

八、注重团队氛围的培养

需要通过以下几点，来分别注意团队氛围的培养与团队文化的提升。

1、强调优先级

项目中把握好了优先级，如计划、阻塞、风险类的事项优先被处理，才可以保证项目的进度与质量不发生偏差

2、强调项目的价值和每个模块的意义

强调当前项目的价值与每个人负责模块的意义，使得当前的工作变得有吸引力

3、强调沟通的重要性

鼓励每个人能够及时沟通反馈，强调沟通的重要性

4、带头做技术分享

带头做技术分享，培养团队的技术分享氛围。使得团队整体螺旋上升

5、适当的授权

要对团队成员有足够的信任，适当授权

6、让他们有归属感

对于意愿度比较高、能力比较强的成员，分配一个相对有挑战的模块

7、鼓励大家持有一种主人翁的心态

对于他们所发现的项目中存在的任何问题与个人的困惑等，要及时沟通反馈

8、鼓励主动学习、主动承担的团队氛围

9、工作分配清晰

分配工作时，对期望的工作成果有透彻的理解,明白工作内容如何服务整体工作目标

九、管理者个人能力的提升

一个团队 leader，不仅要做到把握项目全局，更需要带头解决项目中出现的各种疑难问题，化解风险。对于一个新人团队的 leader 来说，我认为，我需要树立一种”靠得住“的角色，做的比承诺的多。鼓励大家遇到问题及时沟通，对于小问题，让他们再多想想，必要时给他们一点提示，鼓励通过他们自己的能力去解决；要是遇到的困难比较大，则可以投入帮他一起解决掉

让大家觉得，虽然自己负责了一个模块，自己就是真正的主人翁，可以放开干，反正后面有人兜底。

那么，作为一个团队 leader，要真正能够带领一个越来越高效能的团队，就需要要注重自己以下几个方面能力的持续提升：

1、技术能力和基础知识

如果管理者本身不是技术出身或者技术功底不足，那么可能无法和技术团队建立共识，沟通成本极高，被动性也比较大，最终很可能让团队变成一个非常低效的组织，人浮于事。所以掌握了比较扎实的技术能力和基础知识，就能看懂技术表象背后的原理，真正做到把握项目全局

所以，我们要持续学习，持续为团队带来新的知识和理解。毕竟技术 Leader 已经是团队技术问题的终结者，不可能再上传递了，所以不要成为技术团队的天花板

2、沟通表达能力

包括向下沟通、向上沟通以及平行沟通。而在沟通过程中则主要需要注意沟通的方式、逻辑、同理心以及遇到冲突时的情绪控制；

3、业务抽象能力（架构和演化）

要做好项目中的用户需求到系统需求的转化，并根据需求确定出最终的架构和技术方案，业务抽象能力则是必不可少的；

4、人才培养能力

有一个真心帮助大家的心态。帮助大家成长，提高效能，最终组织效能也得到提高，实现共赢的局面

5、团队管理能力

一个强大的团队往往是势不可挡的。而团队是否会变得强大，则与团队 leader 的管理能力有重要的关系。

6、了解细节，保持写代码的习惯

因为不熟悉代码就无法提出真正可落地的方案，就无法感知技术团队的痛点在哪里，也就无法团队提高效能。

7、分析总结能力

我们不仅要对项目有阶段性的规划与总结。对于自己，也应该有阶段性的反思与总结。项目只有有了阶段性的分析、总结与复盘，才会找出更好的提升项目效能的方法；一个人只有对自己有了阶段性的反思与总结，才能使自己的努力变得越来越有效，从而有更快速的成长。所以，分析总结能力在一定程度上决定了你成长的方向和速度，做好这点，至关重要。

十、阶段总结复盘

1、项目总结复盘

项目需要在至少每个版本结束之后，进行一次项目整体的总结复盘会议。在开会之前，由各个项目组成员提前准备好几项自己认为该版本中（分别站在不同角度），做得好的方面和需要改进的方面，并由项目经理统一归类汇总；开会时，由每个人针对自己提出的项分别进行补充说明，让大家在讨论中针对各个待改进的点，总结出一到两点大家达成一致的改进措施。并由项目经理进行更全面的梳理总结；会议结束后，将这些复盘经验归纳到 文档 中，并通过邮件发送给各个干系人，并在下个版本中，保持好的方面的同时，采用总结出来的这些改建措施。就这样，项目在不断”滚动“革新中，质量越来越高，效率也会越来越高

2、个人总结复盘

我们的项目会在每个版本结束之后，对开发人员专门做一次个人总结复盘会。流程基本与项目复盘会差不多。也是由大家先分别从以下几个方面，分别输出一份总结文档：

1）版本中的代码review问题总结

2）该版本中个人的主要贡献

3）该版本中个人的收获与成长

4）个人的待改进之处

5）下个版本的措施与计划

在会议上，每个人再将自己的总结分享给大家。大家听了每个人的分享，或多或少也会有一些正面的影响。在之后，我再分别谈一谈在我看来，每个人这个阶段的闪光点和待改进之处，以导师的姿态，对他们提出一些期望。

个人阶段总结复盘，主要是想让每个人有这么一个自我复盘与反思的过程，认清自己长处与不足，从而有针对性的去改进，并可以以更好的姿态进入下一阶段的战斗。而事实证明，效果还是很不错的。

3、项目风险、问题分析会

项目应该定期召开项目分析会，当然如果在一个阶段中出现较多问题导致项目出现质量或者进度偏差时，也需要临时召开一次项目分析会。主要是针对当前阶段出现的问题与风险进行分析讨论，一方面发现这些问题出现的原因，另一方面需要发散考虑是否还存在潜在的更多没有识别出来的风险与问题

如我们项目上个迭代中，针对在项目发布前才发现的几个问题导致项目延期一周发布的情况，召开了一次项目分析会。会上大家针对每个问题、由相关负责的开发和测试分别分析其出现的各方面原因，并由大家一起讨论出以后应该如何避免，最终大家达成共识

这些问题包含需求沟通不清楚、后期测试力度不够；开发改 TD 的时候，对于可能影响到的地方并没有考虑完全；测试人员在测试过程中对于场景没有考虑完全，导致漏测

针对这些问题，我们分别针对几个整改措施达成一致。对于新增需求，沟通时一定要有书面描述，描述清楚范围与边界，双方以这份书面描述为基准，进行设计、开发和测试工作，避免理解偏差；

在过程中开发和测试需要严格执行 TD 规范:开发在修改 TD 的时候，一定要花时间考虑到可能影响到的功能，在提交 TD 时，就需要描述清楚可能影响到的模块以及建议测试的测试步骤。若描述不清楚，该 TD 会被打回；而测试在分析这个 TD 本身的时候，也需要尽可能地考虑到所有相关的场景等

而对于开发和测试能够全面考虑的前提，就是大家能够深入且全面地理解需求，而这些就需要需求分析阶段就要足够重视了

总结

带领团队，总得来说需要做好团队管理，只要做好管事和管人

管人，就主要是对人才的培养，团队氛围的培养，保持团队整体的螺旋上升，从而提升团队整体的效能

管事，则包括构建流畅的工作流，统一制定标准与规范，并不断复盘总结，优化标准，提升团队整体的战斗力。

而对于新人团队的管理，除了管人和管事以外，还需要根据人才梯队，考虑到设计分层、模块拆分到最细粒度，并在过程中实现逐步的模块转移等措施

以上是我分享的带领新人团队的沉淀总结，希望在以后的实际经验中，还会有一些新的沉淀和总结，不断分享给大家。