• 文档
• 知识库

本文基于 tlroadmap 仓库的英文主 README（translations/README-en.md）整理，讲清这张 Team Lead 能力路线图（Teamlead Roadmap）是什么、从哪里来、如何为「公司」和「个人」两条主线裁剪使用，以及路线图文件（.mm思维导图）与配套知识库的目录组织、条目模板和站点构建方式。读完你可以独立完成：按公司实际需求裁剪出目标能力剖面、为个人或团队制定能力发展计划、以及理解该知识仓库（Crowdin 翻译、VuePress 站点）的内部结构以便深入或参与贡献。

一、Team Lead 能力路线图是什么

"Team Lead is a ❄️, because in each company they are unique and distinct."（团队负责人是一个雪花，因为在每家公司中都是独一无二的。）

"Team Lead"、"Tech Lead"、"Tech Manager" 这些头衔在不同公司含义弹性极大：公司解决的任务不同，角色承担的职责不同；再加上管理风格、个人技能差异，同一个头衔在不同团队里可能对应完全不同的工作内容。这与开发者本身的处境一致——不同的公司、不同的任务、不同性质的职责。

针对这一问题，tlroadmap 团队的调研方法是：访谈了数十家大中小公司，弄清它们对 Team Lead 的期望以及与其协作方式，并据此归纳出一套能覆盖所有调研案例的「基础团队协作能力」统一模型。

这套模型的用法是开放的（原文用词是 "in any way you like"）：

• 制定个人发展计划（development plan）；
• 定义岗位职责与责任边界（duties and responsibilities）；
• 编写职位描述（job description）；
• 设计面试问题与评估标准。

英文 README 中有一条用 🚨 标记的重要提示，值得原样保留其含义：

依赖所在公司，Team Lead 需要负责不同的分支与职责。项目方不认为"把路线图上的所有领域都练满"是目标——首要的是聚焦你工作场所的问题与需求。

也就是说，路线图刻意设计为"可裁剪的超集"：不是要求每人走完全部分支，而是先对照自己的工作场景做减法。

二、两种使用主线：为公司，还是为自己

英文 README 给出了两套编号步骤，二者共享同一步骤 1（下载完整 MindMap），区别在后续裁剪的目标。

2.1 为公司使用（For a company）

1. 下载包含完整 Team Lead 模型的 MindMap（roadmap.mm，README 注明当时仅俄文）。
2. 遍历 Team Lead 职责的所有分支，删除公司不需要、或已经由其他人承担的职责分支。
3. 由裁剪后的地图产出你需要的工件：招聘画像（profile to hire）、角色期望描述（description of role expectations）、发展计划（development plan）。
4. 用配套知识库深入展开任意分支。知识库对每个分支描述：含义（meaning）、使用动机（motivation to use）、好与坏的行为示例（examples of good and bad behavior）、实践与理论两条线的成长路径（ways of development in practice and theory）。

仓库中这套"为公司/为个人裁剪"的说明在俄文指南 tlroadmap/guide/ru.md 里有更细化的四个场景版本（制定发展计划、熟悉团队负责人职责、确定公司内责任区、招聘 Team Lead），流程与英文 README 一致且粒度更细，例如"为个人制定发展计划"的场景中额外要求：把裁剪后的剖面拿给上级、同事做反馈收集，再对照每支"好/坏行为示例"做自评，最后排一个带优先级的成长 backlog。

2.2 为自己使用（For yourself）

1. 同样先下载完整 MindMap。
2. 在图上标出两类能力：你已经具备的、以及你为了在公司内继续成长所需的。原文给出的提示是——观察你的 manager 和同事们正在做什么。
3. 列出"当前剖面"与"目标剖面"之间的能力差集。
4. 借助知识库为每个能力差项制定发展计划，包含理论（theory）与实践应用（practical application）两部分。
5. 把发展计划给 manager 看，并请求其协助（ask for assistance）。

这个流程隐含的工作假设是：个人成长计划应该是一个可以被上级看见、可以协商的工件，而不是自嗨式的能力清单——第 5 步把"展示给经理并请求协助"列为正式步骤。

三、路线图的结构：角色与个人技能两大板块

路线图整体由两个板块组成：

英文 README 的 Roadmap 一节还包含一张roadmap.mm自动生成的目录树（源码中以<!--roadmap.mm table of contents begin/end-->注释块包裹）。四大角色分支与仓库目录的对应关系如下（目录名取自当前仓库实际结构）：

Personal Skills 分支则覆盖：自我发展（学习能力、反思、习惯养成）、人际关系（同理心、情绪智力、理解差异的价值）、思维（系统思维、战略视野、决策）、控制风格（The control styles，目录树中为占位分支）、沟通（促进会议 Facilitation、协作、冲突管理、反馈、网络、公开表达、文字工作）、时间管理（个人目标、时间管理、优先级管理），对应 tlroadmap/self-skills/ 下的self-development、relationship、thinking、management-styles、communications、time-management六个子目录。

README 同时说明了一个关键设计原则：地图上每一个叶子节点，最终都会成为知识库中一篇完整的条目，包含描述、行为示例与技能培养方法。

一个需要留意的历史细节：英文 README 目录树中大量链接指向tlroadmap/old/resource-manager/（如../tlroadmap/old/resource-manager/profile.md）。在当前仓库快照中，tlroadmap/old/目录已不存在，内容已重组为上文表格中的新目录（如招聘相关条目在 tlroadmap/roles/people-manager/people-management/hiring/ 下）。因此把英文 README 的链接当作"旧版导航"来理解，以当前目录结构为准。

四、路线图的获取格式与打开方式

原文档给出的路线图下载项是 PNG 与 MindMap（roadmap.png/roadmap.mm，当时经 CDN 分发、内容为俄文）。补充两个仓库事实：

• 当前仓库根目录中没有静态的roadmap.png/roadmap.mm文件，路线图大图是在线上文档站动态分发/生成的（站点首页 tlroadmap/index.md 用 VuePress 组件<Roadmap/>渲染一张可点击的路线图）。
• 俄文指南 tlroadmap/guide/ru.md 列出了完整格式清单：PlantUML（.puml）、Mindmap（.mm）、PNG、SVG——比英文 README 多出 PlantUML 与 SVG 两种格式。

打开.mm文件的推荐工具（原文原话）：

• Freemind——免费且简单；
• MindNode——昂贵且偏 premium；
• MindMeister——freemium 且在线。

其他思维导图编辑器"很可能也能用，但项目方没有测试过"（we haven't tested them）。.puml文件则可用在线 PlantUML 编辑器或 IDE 插件打开——这一点与仓库里确实随附的 tools/plantuml.jar 相互印证：维护者就是用 PlantUML 这条链路维护路线图源码的。

关于示例模型，英文 README 提供了三套现成的 Team Lead 模型 MindMap 供参考（Scrum 团队中的教练型负责人 playing-coach、纯技术负责人 techlead、初创公司负责人 startup-teamlead）。需要说明的是，当前仓库快照的 tlroadmap/ 目录下没有examples/子目录，这些示例文件同样属于线上仓库/CDN 的配套资产；在本地仓库内，可参照的"裁剪后模型"结构就是各角色目录下的实际条目分布。

五、知识库的组织方式与条目模板

英文 README 的 "The knowledge base" 一节声明了每个方向的最终描述模板，由 Stas Tsyganov、Egor Tolstoy 与社区共同填充：

1. Description——我们在谈什么；
2. Why this branch is important——为什么这个分支重要；
3. What happens if you don't work on it——不投入会怎样；
4. To whom it can be delegated——可以委托给谁；
5. Examples of good and bad behavior——好/坏行为示例；
6. Development techniques——技能、实践、咨询、理论四条线的培养手段。

拿仓库中已按模板写成的条目 tlroadmap/roles/integrator/corporate-culture/ru.md（Corporate culture / 企业文化）验证，六段模板与俄文小节标题一一对应：## Описание（描述）、## Почему ветка важна?（为什么重要，且进一步拆成"对公司/对管理者/对员工"三个视角）、## Что будет, если её не делать?（不做的后果）、## На кого может быть делегирована?（可委托给谁）、## Примеры поведения（分"好行为/坏行为"两列对照）、以及后续的培养方法小节。这说明模板不是纸面约定，而是知识库条目的实际写作规范。

规模上，当前仓库内共有130 个ru.md源文件，覆盖 tlroadmap/roles/ 下 5 个角色目录与 tlroadmap/self-skills/ 下 6 个技能目录，外加 tlroadmap/contributing/ru.md、tlroadmap/guide/ru.md、tlroadmap/license/ru.md 三个基础设施页面。

5.1 多语言约定：ru.md 为源，其余语言是产物

仓库的翻译机制由 crowdin.yml 定义：

files: - source: /tlroadmap/**/ru.md translation: /tlroadmap/**/%two_letters_code%.md

即：所有ru.md是唯一源文件，Crowdin 平台按语言代码（如en.md、zh.md）生成同路径的其他语言版本；当前快照中除ru.md外没有其他语言版本落地。translations/ 目录则存放不随目录树展开的独立译文，本文依据的 translations/README-en.md 即属于这一类——它是项目主 README 的英文翻译，其文件末尾的 "Translation notes" 标注了所对应的上游 commit，作为版本追溯依据。

5.2 质量保障与贡献流程

• 贡献入口：CONTRIBUTING.md 本身只是一行指引，把读者导向文档站内的贡献指南（本地对应 tlroadmap/contributing/ru.md）。英文 README 同样在 "Work in progress" 一节把参与方式指向 CONTRIBUTING，并注明路线图当前为alpha 版本——已建立通用协作结构，但当时只完成了第一个大角色（Resource Manager）的部分描述。
• CI 工作流：.github/workflows/ 下包含三个 workflow，其中tlroadmap_checkbrokenlinks_weekly.yaml是每周一次的坏链检查——这与知识库"每个叶子节点最终都是文档条目"的承诺直接相关，导航树里失效的链接会被 CI 暴露出来。
• 文本规范：仓库根有 .editorconfig 与 .gitattributes（.md统一 LF 行尾、图片等二进制不参与 diff），以及 .yaspellerrc.json 拼写检查配置（配合.github/problem-matchers/yaspeller.json在 CI 中以问题匹配器形式呈现），保证知识库文本的一致性。

六、站点构建：VuePress 文档站

本仓库本质上是一个静态文档站的内容仓库。package.json 给出了最小构建入口：

{ "name": "tlroadmap", "scripts": { "site:dev": "vuepress dev tlroadmap", "site:build": "vuepress build tlroadmap" } }

• 源目录固定为tlroadmap/（即vuepress dev tlroadmap），站点首页是该目录下的 tlroadmap/index.md——其中home: true的 frontmatter 定义了站点标题、标语与三块特性卡片（"如何用于评估/定目标/写招聘"、"谁用得上"、"为什么可信"），并用<Roadmap/>组件渲染可点击路线图。
• 依赖列表可看出站点能力：vuepress-plugin-seo（SEO）、vuepress-plugin-sitemap（站点地图）、@b0g3r/vuepress-plugin-locale-prefix（多语言 URL 前缀）、@b0g3r/vuepress-plugin-generate-tree（目录树生成）、vuepress-plugin-git-log（展示 git 更新日志）、vuepress-plugin-metrika（统计）。这套插件组合解释了为什么知识库文档要"对 Agent 和检索友好"——SEO 与 sitemap 插件都要求每页有稳定语义结构。

本地使用方式（仓库只读，以下均为本地查看/构建操作）：

# 安装依赖（yarn 锁文件为 yarn.lock） yarn install # 本地预览站点（默认端口，浏览器打开即可） yarn site:dev # 产出静态站点 yarn site:build

tools/README.md 则记录了维护路线图内容所用的辅助数据：alternative_names.json（词条别名，例如把 "Teamlead" 关联到"团队负责人职责与角色"页）、links.json（分支名 → 文档文件的映射）、gen_roadmap_contents.py（一键更新主 README 中那张目录树）。其中gen_roadmap_contents.py正是第三部分提到的"README 目录树由注释块自动包裹"这一机制的来源——README 里的roadmap.mm table of contents块是生成物而非手写。

七、项目状态与可信边界

最后明确几点适用前提，均来自仓库事实：

1. 路线图是 alpha 且持续演进。英文 README 与 tlroadmap/index.md 都强调"当前路线图不是最终版，知识库持续填充，分支结构会定期更新"；目录重组（old/resource-manager→people-manager）就是例证。因此引用本文中的目录树时应以所查版本仓库的实际结构为准。
2. 英文 README 是历史 commit 的译文，文件末尾标注了对应 commit 哈希；它引用的部分文件路径（如tlroadmap/old/...）在新版仓库中已不存在，正文中的映射表给出了替代路径。
3. 许可：项目采用 Creative Commons Attribution-ShareAlike 4.0（见 LICENSE.md，本地文档版为 tlroadmap/license/ru.md）：可自由分享与改编（含商业用途），前提是署名、提供许可证链接、标明修改，且衍生作品须以同一许可证发布。
4. 英文 README 的致谢名单列出了参与地图构建的 11 位贡献者（Anatoly Panov、Roman Ivliev 等），知识基座由 Stas Tsyganov、Egor Tolstoy 与社区共同维护——这些信息在 translations/README-en.md 的 Acknowledgements 一节可查证。

小结：tlroadmap 的核心资产是一张"可裁剪的 Team Lead 能力超集"。它的价值不在于"人人练满所有分支"，而在于把公司调研沉淀成的统一模型变成三类工件——招聘画像、职责边界描述、个人发展计划——并通过"六段式条目模板 + 每周坏链 CI + Crowdin 多语言"这套工程化手段，保证知识库可以长期、可验证地生长。

• 文档
• 知识库