04-12-02 技术小组长 - 学习笔记
章节信息
核心主题: Tech Lead 的角色定位、工作内容、项目管理方法、技术路线与管理路线的选择
学习目标: 理解 Tech Lead 的职责边界、掌握技术项目管理方法、明确职业发展方向
关键要点: Tech Lead 是半管理半技术的角色、项目管理的核心是沟通和风险管理、职业拐点需要深思熟虑
核心概念
1. 什么是技术小组长（Tech Lead）
定义
技术小组长 (Tech Lead)是一个"既做技术又带团队"的角色。在 Camille Fournier 的描述中，Tech Lead 是"一个小团队的技术负责人"，通常管理 3-10 个人，同时自己也参与编码。
Tech Lead 的定位:
Tech Lead 的位置: ├─ 在 IC 和 Manager 之间 │ ├─ 比 Senior IC 多了一些管理职责 │ └─ 比 EM 少了一些人事管理的责任 │ ├─ 核心职责 │ ├─ 技术方向和技术决策 │ ├─ 项目交付和进度管理 │ ├─ 团队成员的技术辅导 │ └─ 跨团队的技术协调 │ └─ 典型特征 ├─ 仍然写代码（但比例减少） ├─ 负责项目的成功交付 ├─ 是团队的技术权威 └─ 但不一定是人事管理者Tech Lead 和 Manager 的区别
┌──────────────────────────────────────────────────────────┐ │ Tech Lead vs Engineering Manager │ ├──────────────────┬───────────────────────────────────────┤ │ Tech Lead │ Engineering Manager │ ├──────────────────┼───────────────────────────────────────┤ │ 负责技术方向 │ 负责人员发展 │ │ 负责项目交付 │ 负责团队健康 │ │ 仍然写代码 │ 基本不写代码 │ │ 技术决策权 │ 人事决策权（绩效、晋升、招聘） │ │ 影响团队内的技术 │ 影响多个团队的组织 │ │ 通常不是 HR 角色 │ 正式的 HR 角色 │ └──────────────────┴───────────────────────────────────────┘关键区别: Tech Lead 的"管理"主要是技术管理和项目管理，而不是人员管理。他们通常没有正式的汇报关系（direct reports），但在技术上领导团队。
Tech Lead 的时间分配
Tech Lead 典型时间分配（5-10 人团队）: ├─ 编码和技术工作 30-50% ├─ 技术评审和架构讨论 15-20% ├─ 项目管理和进度跟踪 15-20% ├─ 团队辅导和指导 10-15% └─ 跨团队协调和沟通 5-10%重要趋势: 团队越大，编码时间越少。当团队超过 8-10 人时，Tech Lead 基本上就写不了多少代码了，这时候往往需要转成全职 Manager。
2. Tech Lead 工作的入门常识
2.1 核心职责
Tech Lead 的核心职责: ├─ 技术方向 │ ├─ 确定技术架构和方案 │ ├─ 选择技术栈和工具 │ ├─ 制定技术标准和规范 │ └─ 解决重大技术难题 │ ├─ 项目交付 │ ├─ 制定项目计划和里程碑 │ ├─ 分配任务和优先级 │ ├─ 跟踪进度和风险 │ └─ 确保按时交付 │ ├─ 团队建设 │ ├─ 辅导团队成员成长 │ ├─ 组织技术分享和培训 │ ├─ 提升团队整体技术水平 │ └─ 营造好的技术文化 │ └─ 沟通协调 ├─ 和产品经理对齐需求 ├─ 和其他团队协调接口 ├─ 向上级汇报进度和风险 └─ 管理利益相关者的预期2.2 Tech Lead 的第一周
新 Tech Lead 的第一个月: ├─ 第1周：了解现状 │ ├─ 和每个团队成员 1:1 │ ├─ 了解当前项目状态 │ ├─ 审查代码库和文档 │ └─ 识别技术债务和风险 │ ├─ 第2周：建立节奏 │ ├─ 建立定期的团队会议 │ ├─ 设立 code review 标准 │ ├─ 明确沟通渠道和方式 │ └─ 和 PM/其他 TL 对齐 │ ├─ 第3周：做出改变 │ ├─ 推动一个小的改进 │ ├─ 修复一个长期痛点 │ ├─ 展示你带来的价值 │ └─ 建立信任 │ └─ 第4周：制定计划 ├─ 和团队一起制定技术路线 ├─ 确定短期和中长期目标 ├─ 明确每个人的角色和期望 └─ 开始执行2.3 技术决策怎么做
技术决策框架: ├─ 收集信息 │ ├─ 了解需求和约束 │ ├─ 研究可选方案 │ └─ 咨询相关专家 │ ├─ 评估方案 │ ├─ 技术可行性 │ ├─ 开发成本和周期 │ ├─ 维护成本和风险 │ └─ 对团队的影响 │ ├─ 做出决策 │ ├─ 明确说明选择 │ ├─ 解释决策理由 │ ├─ 承认 trade-off │ └─ 记录决策过程 │ └─ 执行和调整 ├─ 推动实施 ├─ 监控效果 ├─ 收集反馈 └─ 必要时调整决策原则: 不是所有决策都需要完美分析。有些决策"做了比做对了更重要"。
3. 项目管理
3.1 项目管理的本质
定义: 项目管理是把"想法"变成"交付物"的系统化过程。Tech Lead 最重要的职责之一就是确保项目的成功交付。
项目管理的三个维度:
项目管理三要素: ├─ 范围 (Scope): 要做什么 ├─ 时间 (Time): 多久做完 └─ 资源 (Resources): 有多少人手 │ └─ 铁律: 三个要素中只有两个可以固定 ├─ 固定范围 + 固定时间 = 需要更多资源 ├─ 固定范围 + 固定资源 = 需要更多时间 └─ 固定时间 + 固定资源 = 需要缩减范围3.2 项目生命周期
项目生命周期: ├─ 启动阶段 │ ├─ 理解需求和目标 │ ├─ 识别利益相关者 │ ├─ 评估可行性和风险 │ └─ 制定初步计划 │ ├─ 规划阶段 │ ├─ 分解任务（WBS） │ ├─ 估算时间和依赖关系 │ ├─ 确定里程碑 │ └─ 分配资源 │ ├─ 执行阶段 │ ├─ 跟踪进度 │ ├─ 管理风险和变更 │ ├─ 解决阻塞和问题 │ └─ 保持沟通 │ ├─ 监控阶段（贯穿执行） │ ├─ 进度 vs 计划 │ ├─ 质量 vs 预期 │ ├─ 风险 vs 预期 │ └─ 及时报告偏差 │ └─ 收尾阶段 ├─ 验证交付物 ├─ 回顾和总结 ├─ 知识沉淀 └─ 庆祝和认可3.3 项目估算
为什么估算总是错:
估算不准的原因: ├─ 乐观偏差 │ └─ 人们倾向于乐观估计 │ ├─ 未知未知 │ └─ 你不知道你不知道什么 │ ├─ 依赖风险 │ └─ 其他人的工作影响你 │ ├─ 需求变更 │ └─ 过程中需求会变化 │ ├─ 中断和上下文切换 │ └─ 实际有效工作时间 < 日历时间 │ └─ 集成和测试 └─ 人们总低估这部分时间估算技巧:
改善估算的方法: ├─ 三点估算 │ ├─ 乐观估计（一切顺利） │ ├─ 最可能估计（正常情况） │ ├─ 悲观估计（各种意外） │ └─ 加权平均 = (乐观 + 4×最可能 + 悲观) / 6 │ ├─ 类比估算 │ ├─ 参考类似项目的实际时间 │ └─ "上次类似的功能花了 3 周" │ ├─ 分解估算 │ ├─ 把大任务拆成小任务 │ ├─ 每个小任务不超过 2 天 │ └─ 加起来就是总估计 │ └─ 预留缓冲 ├─ 在总估计上乘以 1.5-2 倍系数 └─ 对外沟通时明确这是估计不是承诺3.4 风险管理
风险管理流程: ├─ 识别风险 │ ├─ 技术风险（新技术、复杂集成） │ ├─ 人员风险（关键人员依赖、技能不足） │ ├─ 外部风险（第三方依赖、API 变更） │ └─ 时间风险（截止日期不可行） │ ├─ 评估风险 │ ├─ 概率（高/中/低） │ └─ 影响（严重/中等/轻微） │ ├─ 制定应对策略 │ ├─ 避免（改变方案规避风险） │ ├─ 缓解（降低概率或影响） │ ├─ 转移（让别人承担） │ └─ 接受（准备好应急计划） │ └─ 持续监控 ├─ 定期检查风险状态 ├─ 识别新风险 └─ 更新应对策略风险登记表示例:
风险登记表: ┌──────────┬──────┬──────┬──────────────┬──────────┐ │ 风险描述 │ 概率 │ 影响 │ 应对策略 │ 负责人 │ ├──────────┼──────┼──────┼──────────────┼──────────┤ │ 第三方 │ 中 │ 严重 │ 提前验证 │ 张三 │ │ API 不稳 │ │ │ 准备备用方案 │ │ ├──────────┼──────┼──────┼──────────────┼──────────┤ │ 新员工 │ 高 │ 中等 │ 安排导师 │ 李四 │ │ 不熟悉 │ │ │ 延长上手期 │ │ ├──────────┼──────┼──────┼──────────────┼──────────┤ │ 需求 │ 中 │ 严重 │ 锁定核心范围 │ 王五 │ │ 可能变更 │ │ │ 预留 20% 缓冲 │ │ └──────────┴──────┴──────┴──────────────┴──────────┘3.5 项目沟通
项目沟通机制: ├─ 日常 │ ├─ 站会（15 分钟，进度 + 阻塞） │ └─ 异步更新（Slack/群组，重要变更） │ ├─ 每周 │ ├─ 进度汇报（给上级和利益相关者） │ ├─ 风险评审（检查风险登记） │ └─ 技术评审（讨论技术方案） │ ├─ 里程碑 │ ├─ 阶段总结 │ ├─ 演示和验收 │ └─ 计划调整 │ └─ 异常 ├─ 立即报告延期风险 ├─ 主动沟通，不要等问题爆发 └─ 提供解决方案，不只是报告问题好经理，坏经理：项目沟通版:
┌──────────────────────────────────────────────────────────┐ │ 好经理 vs 坏经理 │ │ 项目沟通的差异 │ ├──────────────────────────────────────────────────────────┤ │ │ │ 坏经理 │ │ ├─ 报喜不报忧 │ │ ├─ 等到最后一刻才说延期 │ │ ├─ "我们会想办法"（其实心里没底） │ │ ├─ 只告诉上级，不告诉团队 │ │ ├─ 出了问题先甩锅 │ │ └─ 结果：信任崩塌，问题恶化 │ │ │ │ 好经理 │ │ ├─ 好消息坏消息都及时报 │ │ ├─ 发现风险立即沟通 │ │ ├─ "目前有风险，我的应对方案是..." │ │ ├─ 所有利益相关者信息同步 │ │ ├─ 出了问题先承担，再解决 │ │ └─ 结果：建立信任，问题可控 │ │ │ └──────────────────────────────────────────────────────────┘4. 职业拐点：技术路线还是管理路线
4.1 这个选择为什么重要
核心问题: 当你在技术上足够资深后，你会面临一个选择——继续深入技术，还是转向管理。这个选择会影响你的职业轨迹、工作内容和满足感来源。
两种路线的本质区别:
技术路线 vs 管理路线: ├─ 满足感来源 │ ├─ 技术：解决技术难题的快感 │ └─ 管理：看到团队成长的喜悦 │ ├─ 技能要求 │ ├─ 技术：深度、广度和判断力 │ └─ 管理：沟通、协调、影响力 │ ├─ 工作方式 │ ├─ 技术：独立思考、编码、设计 │ └─ 管理：开会、沟通、决策 │ ├─ 可替代性 │ ├─ 技术：你走了，别人很难立刻接手 │ └─ 管理：你走了，组织会安排接替者 │ └─ 职业天花板 ├─ 技术：Fellow / Distinguished Engineer └─ 管理：VP / CTO4.2 如何判断自己适合哪条路
自我评估问题:
选择技术路线的信号: ├─ 你最大的满足感来自解决技术难题 ├─ 你不喜欢管理别人的工作和绩效 ├─ 你享受深度思考的时间 ├─ 你愿意在一个领域钻研 10 年以上 ├─ 你对"影响力"的定义是技术贡献 └─ 你不喜欢处理人事纠纷和办公室政治选择管理路线的信号: ├─ 你从帮助他人成长中获得满足感 ├─ 你擅长协调和沟通 ├─ 你喜欢影响更大的范围 ├─ 你善于在模糊的情况下做决策 ├─ 你享受组织和协调的乐趣 └─ 你对"影响力"的定义是通过团队实现常见的误区:
职业选择的常见误区: ├─ 误区1："管理是晋升的必经之路" │ └─ 纠正：好的公司技术路线和管理路线级别对等 │ ├─ 误区2："技术好就能管好" │ └─ 纠正：技术和管理是完全不同的技能集 │ ├─ 误区3："管理比技术轻松" │ └─ 纠正：管理是另一种形式的辛苦，只是方式不同 │ ├─ 误区4："做了管理还能回去" │ └─ 纠正：可以，但技术上可能会落后，需要补课 │ └─ 误区5："管理薪资更高" └─ 纠正：在同级别下，技术和管理薪资应该对等4.3 两条路线的转换
路线转换指南: ├─ 技术 → 管理 │ ├─ 先做 Tech Lead 试水 │ ├─ 学习管理基础知识 │ ├─ 接受你可能不如以前"产出高" │ └─ 做好心理转换准备 │ ├─ 管理 → 技术 │ ├─ 需要技术补课 │ ├─ 从 Senior IC 重新开始 │ ├─ 管理经验是加分项（架构、协调） │ └─ 接受可能降级的事实 │ └─ 最佳实践 ├─ 不要急着做选择，先做 Tech Lead 体验 ├─ 两条路都可以走到高层 └─ 选让你更有满足感的那条5. 流程控的陷阱
5.1 什么是流程控
定义: 流程控是指那些过度依赖流程、工具和方法论来管理团队的人。他们相信只要流程够好，结果自然就好。
流程控的表现:
流程控的典型症状: ├─ 过度工程化的流程 │ ├─ 每个小改动都需要多层审批 │ └─ 流程的开销比实际工作还大 │ ├─ 工具崇拜 │ ├─ 相信某个工具能解决所有问题 │ └─ 不停换工具，不换思路 │ ├─ 指标驱动 │ ├─ 只看数字不看实际效果 │ └─ 为了达标而优化指标 │ ├─ 一刀切 │ ├─ 所有团队用同样的流程 │ └─ 不管团队的实际情况 │ └─ 忽视人的因素 ├─ 流程比人重要 └─ 流程不能变通5.2 好经理，坏经理：流程版
┌──────────────────────────────────────────────────────────┐ │ 好经理 vs 坏经理 │ │ 流程使用的差异 │ ├──────────────────────────────────────────────────────────┤ │ │ │ 坏经理（流程控） │ │ ├─ 把流程当目的，不是为了结果 │ │ ├─ 要求团队严格遵守流程，不管实际情况 │ │ ├─ 用流程替代思考和沟通 │ │ ├─ "流程就是这样规定的" │ │ ├─ 流程越来越多，从不删减 │ │ └─ 结果：团队效率降低，士气低落 │ │ │ │ 好经理（务实派） │ │ ├─ 流程是手段，结果是目的 │ │ ├─ 根据团队情况调整流程 │ │ ├─ 用流程辅助沟通，不是替代沟通 │ │ ├─ "这个流程对我们有帮助吗？" │ │ ├─ 定期审视和精简流程 │ │ └─ 结果：团队高效运转，流程服务于人 │ │ │ └──────────────────────────────────────────────────────────┘流程的原则:
好的流程设计原则: ├─ 最小化原则 │ └─ 流程只保留必要的部分 │ ├─ 灵活性原则 │ └─ 允许团队根据实际情况调整 │ ├─ 透明化原则 │ └─ 所有人理解流程的目的 │ ├─ 持续改进原则 │ └─ 定期回顾和优化流程 │ └─ 服务于人原则 └─ 流程是为人服务，不是人为流程服务关键知识点
知识点1: Tech Lead 的核心矛盾是编码 vs 管理
Tech Lead 的时间困境: ├─ 编码需要连续的专注时间 ├─ 管理需要频繁的沟通和切换 ├─ 两者本质上是冲突的 └─ 解决方案: ├─ 保护编码时间（如上午编码，下午管理） ├─ 减少编码量，接受自己不再是主力开发者 ├─ 把关键路径的编码交给别人 └─ 专注于架构设计和代码审查知识点2: 项目管理的核心是管理预期
管理预期的方法: ├─ 事前：明确目标、范围、里程碑 ├─ 事中：持续沟通、及时报告偏差 ├─ 风险：提前预警、提供方案 ├─ 变更：评估影响、重新对齐 └─ 事后：总结回顾、建立信任知识点3: 项目延期的应对
发现可能延期时的做法: ├─ 立即沟通，不要拖延 ├─ 说明原因和影响 ├─ 提供应对方案 │ ├─ 方案A：砍范围，保时间 │ ├─ 方案B：加资源，保范围和时间 │ └─ 方案C：延时间，保范围和质量 ├─ 让利益相关者选择 └─ 执行选定方案并持续跟踪知识点4: Tech Lead 的技术权威来自哪里
Tech Lead 的技术影响力来源: ├─ 技术深度：解决过复杂问题 ├─ 技术广度：了解多种方案的选择 ├─ 判断力：知道什么时候用什么方案 ├─ 沟通能力：能清楚解释技术决策 ├─ 信任：过去的决策被证明是正确的 └─ 谦逊：承认自己不是什么都懂知识点5: 好的流程 vs 坏的流程
判断流程好坏的标准: ├─ 好的流程 │ ├─ 团队理解流程的目的 │ ├─ 流程减少了沟通和协作的摩擦 │ ├─ 流程可以根据需要调整 │ └─ 流程的开销小于它带来的价值 │ └─ 坏的流程 ├─ 大家不知道为什么要有这个流程 ├─ 流程增加了工作负担 ├─ 流程不能变通 └─ 流程的开销大于它的价值实战技巧
Tech Lead 的一天时间分配
推荐的时间分配: ├─ 上午（专注时间） │ ├─ 编码和架构设计（2-3小时） │ └─ 邮件和消息处理（0.5小时） │ ├─ 中午 │ ├─ 团队午餐/非正式沟通 │ └─ 技术文章阅读（0.5小时） │ ├─ 下午（沟通时间） │ ├─ 1:1 和辅导（1-2小时） │ ├─ 项目评审和会议（1-2小时） │ └─ 跨团队协调（0.5-1小时） │ └─ 傍晚 ├─ Code Review（1小时） └─ 计划和总结（0.5小时）项目启动检查清单
项目启动 Checklist: □ 需求和目标是否清晰？ □ 利益相关者是否都确认了？ □ 技术方案是否评审过？ □ 任务分解和估算是否做了？ □ 依赖关系是否识别了？ □ 风险是否评估了？ □ 里程碑是否设定了？ □ 沟通机制是否建立了？ □ 团队成员是否都清楚自己的任务？ □ 是否有预案应对可能的延期？自我评估清单
Tech Lead 角色自查
如果你是 Tech Lead（或即将担任）: 技术方面: □ 我是否仍在参与编码（即使比例不高）？ □ 我的技术决策是否有清晰的理由？ □ 我是否尊重并倾听团队的技术意见？ □ 我是否在培养团队的技术能力？ □ 我是否在关注技术趋势和最佳实践？ 管理方面: □ 我是否清楚项目的进度和风险？ □ 我是否及时向上级和利益相关者沟通？ □ 我是否在帮助团队成员成长？ □ 我是否在管理需求和优先级？ □ 我是否在协调跨团队的工作？ 个人方面: □ 我是否享受这个角色？ □ 我的编码时间是否足够？ □ 我是否在过度陷入管理或过度陷入编码？ □ 我是否清楚自己的职业方向？项目管理自查
如果你正在管理一个项目: □ 目标和范围是否所有人都清楚？ □ 是否有书面的项目计划？ □ 是否有定期进度跟踪？ □ 是否有风险登记表？ □ 发现偏差是否立即沟通？ □ 是否有明确的里程碑？ □ 是否有应对延期的预案？ □ 团队成员是否知道该做什么？ □ 利益相关者是否信息同步？ □ 项目结束后是否安排了复盘？职业选择自查
如果你在考虑技术 vs 管理路线: 自我评估: □ 我更享受解决技术问题还是帮助他人成长？ □ 我的优势是深度思考还是沟通协调？ □ 我希望通过什么方式产生影响力？ □ 我愿意投入时间学习管理技能吗？ □ 我对处理人际冲突的感觉如何？ □ 我是否愿意接受编码时间的大幅减少？ 行动计划: □ 我是否可以先做 Tech Lead 试水？ □ 我是否和管理者聊过他们的日常？ □ 我是否和技术大佬聊过他们的日常？ □ 我是否了解公司的职级体系？ □ 我是否和家人/导师讨论过这个选择？本章总结
速查表
┌─────────────────────────────────────────────────────────┐ │ 04-12-02 技术小组长 · 速查表 │ ├──────────────────┬──────────────────────────────────────┤ │ Tech Lead 定位 │ 半技术半管理，负责技术方向和项目交付 │ ├──────────────────┼──────────────────────────────────────┤ │ 编码时间占比 │ 30-50%（团队越大越少） │ ├──────────────────┼──────────────────────────────────────┤ │ 项目管理三要素 │ 范围 + 时间 + 资源（只能固定两个） │ ├──────────────────┼──────────────────────────────────────┤ │ 估算技巧 │ 三点估算 + 分解 + 1.5-2x 缓冲 │ ├──────────────────┼──────────────────────────────────────┤ │ 延期应对 │ 立即沟通 + 提供方案 + 让对方选 │ ├──────────────────┼──────────────────────────────────────┤ │ 技术 vs 管理 │ 选让你更有满足感的那条 │ ├──────────────────┼──────────────────────────────────────┤ │ 流程原则 │ 最小化、灵活、服务于人 │ ├──────────────────┼──────────────────────────────────────┤ │ Tech Lead 陷阱 │ 编码不够放、管理不够做、两头都差 │ ├──────────────────┼──────────────────────────────────────┤ │ 项目沟通核心 │ 好消息坏消息都及时报 │ ├──────────────────┼──────────────────────────────────────┤ │ 职业拐点 │ 先做 TL 试水，不急着做选择 │ └──────────────────┴──────────────────────────────────────┘实战心法
Tech Lead 入门三件事: 1. 保护好你的编码时间（但也接受它会减少） 2. 建立项目节奏（计划 → 跟踪 → 沟通） 3. 培养团队的技术能力（你一个人干不完） 项目管理口诀: 早报告坏消息、晚报告好消息、 永远带着方案去汇报。 职业选择原则: 不要为了头衔做管理， 要做为了你能获得的那种满足感。 流程使用准则: 流程是仆人不是主人， 有用的留下，没用的砍掉。收尾金句
“Tech Lead 最困难的事情不是技术，而是如何在编码和管理之间分配自己的时间和精力。”
“最好的项目管理是让人人都知道发生了什么，包括坏消息。”
“流程应该让好的事情更容易发生，而不是让坏的事情不可能发生。”
“选择管理路线不是因为这是唯一的晋升路径，而是因为你从他人的成功中获得的满足感，超过了自己写出好代码的满足感。”
《技术为经》第 3 章笔记 · 技术小组长
