Team Lead 的日常工作

在我们的一个敏捷团队中，作为团队重要成员的 Team Lead 其实承担了很多非技术方面的工作，那么如何管理和安排自己的每日工作应该是每一个 TL 都值得去深入思考的事情。

因为项目的成员更替和自我发展的需要，我有幸在过去一年担任了团队 TL 这一角色，通过各种方式不断提高自己，努力做一些事情来推动团队前进，在这个过程中总结了一些自己的经验，在此和大家分享一些自己的心得，也欢迎大家提出宝贵的建议和意见。

日常工作的分类

在我们公司，项目中的 TL 可以分为 2 种，一种是偏技术的，我们可以称之为 Tech Lead，ta 更多的是负责团队工作中技术方案的讨论、设计和落地，但是这种纯粹的技术角色在实际工作是比较少见的，大多数的 Tech Lead 除了承担技术工作之外，还有一些（或者很多）非技术的工作，我们可以称之为 Team Lead（下面简称为 TL），例如与 BA 的业务讨论，团队敏捷开发的实践，组内成员的个人发展，新人的培养，还需要参与项目上的各种会议等等，这些非技术的工作甚至可能占据了 TL 超过 70% 的工作时间，但是既然工作在追求技术卓越的我司，相信大多数 TL 心里还是舍不得对 coding 的那份热情。那如何将堆积在 TL 面前这些工作做一个分类我觉得是一件重要的事情，只有理清了它们的关系，做好了分类，才能让我们对自己的工作有一个清晰的认识，进而更好的开展自己的工作，让我们的工作与生活更快乐！

通过自己对 TL 日常工作的总结和项目的实际情况，我将 TL 日常工作分为以下几个类别：

• Activities 团队会议以及客户活动；

• Features 团队交付的产品功能；

• Onboarding/off-boarding 团队成员上下项目;

• Support System 工作中常用的支持系统和服务；

• Environments 各种开发环境；

• Technologies 日常开发中用到的技术技能；

• Repositories 团队开发维护及需要关注的代码仓库；

下面我会对上面列出的分类逐个进行解释和说明。

Activities 团队会议以及客户活动

作为敏捷开发团队，我们在每个迭代周期内都会有很多固定的敏捷活动，同时这些活动客户也会全部或部分参加，除此之外还有由客户方发起的一些活动，作为团队 TL，我们需要关注以下几个活动：

• Showcase

• Team Retro

• Capability Building

• Tech Huddle

• Metrics Updating

• OKRs Roadmap

• ADRs

• Lights on the hill

• Leave Plans

Showcase 作为项目迭代中的一个重要会议，是向客户展示团队在上一个迭代周期中完成的交付内容和产出，为了完整的展示我们的成果，需要团队每个人对这个活动有足够的重视。具体在我们团队，团队中每个人会轮换来负责这个活动，保证每个人都有机会参与其中，而关于需要展示的内容，团队都会提前进行会议讨论来确定，showcase 负责人则需要提前进行展示内容的准备工作，包括展示环境，测试账号，测试数据等，提前进行演练，对于可能出现的异常场景进行调整，保证最终功能的展示符合我们的预期，同时我们也会在 showcase 会议前，提前一个小时通知团队及关联团队进行展示环境的 lockdown，保证 showcase 会议进行中不会因外界因素导致出现异常情况。

Team Retro 是第二个需要 TL 关注的活动，因为这是一个团队成员对发生在上一个迭代周期中各种事宜发表个人看法的好机会，借此我们可以了解团队每个人的想法，并鼓励他们提出自己的看法和建议，从而识别出需要解决的问题，提出对应的改善行动，后期还需要团队每个人，特别是 TL 去重点关注这些改善行动的落地情况并跟踪结果，从而进一步改进团队的交付状态。

在公司组织的 TL 培训中特别提到 TL 需要关注三方面，团队成员则是其中之一，特别是每个小伙伴的成长是需要我们花费更多的精力去关注，所以 capability building 就是一个解决这个问题的活动。我们项目上有和客户技术业务相关的 capability growth，分别从技术、技能，业务以及关联系统等四个方面来评估团队成员对当前项目所要求的技术业务等内容的掌握和熟悉程度。除此之外，我们团队内部也有固定的知识分享活动，为此我们还建立了一个自己的 session & workshop tracking board，根据每个季度 capability growth 的结果识别出团队需要提高的技术技能，并创建条目，添加到 board 上，再打上相应的分类标签，之后会根据团队成员的技能侧重情况，由最擅长者进行认领，完成内容准备，最终在我们每周固定的分享会议上进行分享。如果某个技能团队没有成员特别擅长的，我们也会寻求组外的帮助，比如我们会寻求对应的技术能力提升社区的帮助，请他们来对团队进行相应内容的分享和培训，这样我们就能将项目技能需求与成员个人发展结合起来，让每个小伙伴在项目内部都有提高个人能力以及发展他人的机会。

与 capability building 相关的另一个活动是 tech huddle，这个一般是和客户方进行技术分享及讨论的会议，我们可以结合 capability building 中团队的已有产出，进行一定的调整和修改，放到这个活动里向客户进行展示和分享，并一起进行讨论。Tech Huddle 不仅是团队与客户进行技术分享和讨论的重要渠道，也是一个团队成员在客户方提高个人影响力的好机会，同时它也是增进团队与客户之间紧密合作，提高双方相互信任的一个桥梁，这都是我们关注客户的具体做法，基于此也是需要 TL 去重点关注的。

在团队的每一个迭代交付，我们不仅在 showcase 中展示我们的交付内容，也会关注团队的交付质量以及交付指标，这时候作为 TL 就需要进行这些数据的收集和整理工作，因为在我们项目中 PM，DCM 等关键成员会重点关注这些数据，及时记录和提高这些内容对他们的工作也是有很大帮助的；同时 TL 也需要和组内 BA 针对这些指标数据进行一定的讨论，识别其中可能会出现的风险和问题，探讨出对应的改进方案，并给出相应的 actions，与团队一起讨论、实施并跟踪结果。

有的团队会有由团队 product owner 主持的 OKRs Roadmap 会议，这个会议可能一般 BA 参加的比较多，不过 TL 去听一听也是有很多好处的，通过参与这个活动，可以让我们开发团队知道产品团队对于未来 3 个月到 6 个月年甚至 1 年的规划，也可以了解目前的产品交付计划和对应的优先级，识别出可能需要团队储备的知识技能，结合之前的 capability building 活动，提前准备相应的培训内容，降低未来团队交付中可能存在的风险。

**ADRs（Architecture Design Authority）**是团队对一个产品功能在技术方案的列举和优缺点对比说明活动。如何做好 ADRs 及讲好 ADRs 其实是一个蛮有挑战的事情，这里因为我自己主导完成的 ADR 不是很多，经验尚欠，若有需求大家可以咨询身边擅长的小伙伴，但这里提到这个活动是想强调它的重要性，因为 ADRs 其实是一次向客户展示团队技术能力与业务掌握程度的机会，特别如果项目中有专职的架构师的话，ta 应该会额外重视团队在 ADRs 里的内容和相应的解释说明，做好 ADRs 就是向客户及客户架构师展会团队技术能力的一次绝佳机会，也可以认为是维护与客户良好关系、赢得客户信任的又一个渠道。

Light on the hill（LOTH），这又是一个与客户交流沟通的重要活动，也是团队参与产品方向讨论，解决团队痛点问题的重要会议，如何做好 LOTH 其实是需要花费很多精力的。

最后一个 activities 里的项目是 leave plan，大家可能会奇怪为什么会有这个？其实原因有几个，一个是在我们公司各个 Unit 在财务方面是有需求的，他们希望能预算 Unit 内的财务状态，因此 TL 就需要统计组内小伙伴们的 leave plan；再一个统计结果对我们在迭代周期中 IPM 也是很有帮助的，能让我们能根据组内小伙伴的请假计划合理安排迭代工作量；最后有了这个预测结果我们也可以跟客户提前去沟通，让客户了解我们组内未来的出勤情况，方便他们的工作安排，特别是每逢国内节假日前将团队的 leave plan 发给客户，这是我们重视与客户维护良好关系，保持充分沟通，进行信息同步的方式，也算是客户关注的一部分。

Features 团队交付的产品功能

这个分类其实比较简单，就是列出团队完成的核心功能列表，我们需要收集团队主导完成的功能，而对每个功能需要关注以下内容：

• 功能业务介绍（如果有 feature one page 就最好了）；

• 功能技术架构设计；

• 功能 UI 设计（figma，Zeplin 等）；

• 功能相关内部及三方集成系统；

• 功能测试环境及测试账号；

上面的内容很容易理解，关注它们的目的就是从不同方面（业务，技术，设计，集成和测试等）来理解和掌握我们所要完成的功能，而且随着时间的流逝，迭代的不断进行，团队成员对之前做过的功能可能会有一定的模糊和生疏，整理收集这些内容是让我们在遇到问题时，可以快速查找和回顾相关的知识，同时这些内容对 onboarding 或者功能分享及任务交接都是有一定帮助的。

Onboarding/off-boarding 团队成员上下项目

之所以将 Onboarding/off-boarding 的部分单列，是因为这是一个项目成员从加入项目到下项目所需要完成一些系列任务和活动的归纳和总结，我把这部分为下面几个部分：

• New Member process

• Business

• Security

• Roll-off

首先我们在新成员上项目时需要提前为 ta 准备相关的资料并提交给客户确认，之后申请各种资源账号（电脑，显示器，客户账号，签署协议等），这里我们最好有一个关于这部分的流程文档（当然如果项目组上有一个统一的流程说明就更好了），以便如果 TL 由于一些原因不能处理 onboarding 事宜，组内其他人可以参考执行；完成新成员基础流程后，我们重点是与 ta 一起进行项目业务的熟悉和讲解，这里也推荐能有一个关于团队业务的文档页面，可以让新成员快速从 0 到 1 了解业务上下文，同时针对团队所完成的多个功能，在团队里可以有专门的 feature owner，这样如果新成员有更深入的问题就可以找对应的小伙伴帮忙答疑；在完成上面的工作后，还有一个很重要的方面就是关于安全方面的，让团队成员重视软件开发过程中相关的安全问题是怎么做都不为过的，一般我们组内都有专门的安全员来负责组内的安全问题，而项目组上一般也会有自建的安全响应团队，而在 onboarding 这里我们需要重点强调安全意识的提高，告诉新成员软件开发中我们公司内部的安全要求是什么样的，在此基础上客户方又有哪些额外的要求。我们的目的是通过各种安全培训，各个级别的安全要求来提高团队每个成员的软件开发安全知识和意识，尽最大努力避免安全事件的发生；最后我们提到的是项目组成员的 roll-off 流程，跟 onboarding 一样，我们这里也需要一个关于 roll-off 流程的一个文档，同时 TL 做为负责人还需要做一些收尾工作来保证成员 roll-off 后没有任何安全漏洞，从而规避相应的安全风险。

Support System 工作中常用的支持系统和服务

因为项目的不同，我们在功能开发需要了解和关注那些与我们开发工作有密切关联的系统和服务，大致包含以下方面：

• 与核心功能相关的上下游系统和服务；

• 项目功能所用到的云平台及部署服务；

• 项目功能所用到的监控、报警、日志查询系统和服务；

• 项目功能所用到的代码质量及安全扫描服务；

• 项目功能所用到的 Pipeline；

• 项目功能所用到的 UI 设计系统；

• 与团队有合作关系的其他团队所开发的功能系统；

• 其他与功能开发相关的三方系统和服务；

我们需要强调的是这里列出的内容都是与我们核心交付功能直接或间接相关的系统和服务，虽然它们不是我们团队直接去开发和维护的系统，却对我们自己的功能有着重要的支撑作用，也需要我们持续关注；如果我们对所交付的功能做 C4 Model 分析，这些支持系统应该是要有所体现的。

Environments 各种开发环境

我们需要聚焦项目功能所使用到的各种开发环境，一般来说都会分为本地开发环境，测试环境，预生产环境和生产环境。

对于本地开发环境，我们需要重视如何保证团队成员本地开发环境的一致性，包括如下方面：

• IDE 的统一及配置的一致（如 code style，check style 等）；

• 编程语言运行环境管理（sdkman, nvm 等）；

• 容器运行环境（如 docker desktop，colima，podman 等）；

而对于剩下的环境如测试环境，预生产环境和生产环境我们只需要区分他们的不同环境地址和对应的测试账号就够了，当然如果我们能使用一些密码管理工具将这些不同的测试账号进行统一管理并对团队提供统一的访问控制就更好了，最好能整理一个关于所有测试账号的说明文档，帮助我们更好的了解每个测试账号的用途。

Technologies 日常开发中用到的技术技能

这部分我们应该关注项目中所要使用的各种技术栈，大致包含如下方面：

• 项目所使用的的主要编程语言；

• 项目开发所使用的数据库以及对应的管理工具；

• 云平台开发技能及知识；

• 项目中所采用的测试工具及测试原则和策略；

• 项目开发中遇到的一些技术问题及其解决方案；

这里我们主要关注的是项目技术技能的要求，也是上面提到的 Capability building 中的 technologies 的那部分，列举这些条目的是想让我们对项目的技术栈有一个整体认识，建立一个项目技术栈合集，帮助团队成员查漏补缺，同时它也能指导我们后面的技术能力提升活动。

Repositories 团队开发维护及需要关注的代码仓库

这部分很简单，我们需要维护一个团队直接负责的那些功能的代码仓库列表，如果代码仓库比较多，可以从功能来进行分类；这里需要强调的一点就是代码仓库中 readme 文档的编写，良好的 readme 文档包含以下几个方面：

• 代码仓库的功能描述；

• 安装指导；

• 开发和贡献指南；

• 测试策略及要求；

• 常见问题及解决方案；

• 项目使用许可信息；

• 项目支持及联系信息；

当然如果团队或者项目组有类似统一的软件产品系统及系统目录（System Catalogue）就更好了，可以对我们维护的每个服务和代码有一个更详细的分类和信息说明，让团队及其他不熟悉我们业务的人更好的了解我们所完成的系统和服务。

总结

以上就是关于我自己对于团队 TL 的日常工作的一些整理和总结，可以看到这个更多的是侧重于分类，在实际使用中我会把上面这些内容以浏览器书签的形式记录下来，这样比较方便去归类和查找，再结合 Chrome 浏览器的tab group功能，可以让我们对日常繁多工作的管理更加方便快捷，工作更有效率！