04-12-02 技术小组长 - 学习笔记

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 Review1小时 └─ 计划和总结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 章笔记 · 技术小组长