19 — 技术团队管理

核心规律：管理是通过他人拿结果，不是自己做更多 一句话：优秀的技术管理者不是最强的coder，而是最能激发团队潜能的leader

---

一、核心规律

1.1 角色转变

flowchart LR
    subgraph IC["个人贡献者"]
        I1["自己做"]
        I2["写代码"]
        I3["解决问题"]
        I4["个人产出"]
    end
    
    subgraph Manager["技术管理者"]
        M1["指导他人做"]
        M2["审代码"]
        M3["消除障碍"]
        M4["团队产出"]
    end
    
    I1 & I2 & I3 & I4 -->|"心态转变"| M1 & M2 & M3 & M4
    
    style I1 fill:#e3f2fd
    style M1 fill:#e8f5e9

核心规律：从”个人贡献”到”通过他人拿结果”，是技术管理者最大的心路历程。

1.2 管理者三大职责

1. 定方向 — 技术规划、架构决策、目标拆解
2. 带队伍 — 招聘选拔、培养成长、激励留存
3. 拿结果 — 项目管理、交付质量、复盘改进

---

二、团队结构设计

2.1 常见结构

flowchart TB
    subgraph 管理层["👔 管理层"]
        CTO["CTO/技术总监"]
    end
    
    subgraph 技术层["🔧 技术层"]
        TL1["后端组长"]
        TL2["前端组长"]
        TL3["测试组长"]
    end
    
    subgraph 执行层["⚙️ 执行层"]
        E1["后端开发"]
        E2["前端开发"]
        E3["测试工程师"]
    end
    
    CTO --> TL1 & TL2 & TL3
    TL1 --> E1
    TL2 --> E2
    TL3 --> E3
    
    style CTO fill:#FFD700
    style TL1 fill:#e3f2fd
    style TL2 fill:#fff3e0
    style TL3 fill:#e8f5e9

2.2 关键管理动作

动作	频率	目的
1on1面谈	每周	了解状态、解决困惑
团队例会	每周	同步进度、对齐目标
代码审查	持续	保证质量、知识传递
技术评审	按需	把控架构方向
绩效评估	季度	客观评价、制定计划

---

三、项目管理

3.1 敏捷开发流程

flowchart LR
    subgraph Sprint["🔄 Sprint（2周迭代）"]
        P1["Sprint Planning<br/>规划会"] --> P2["Daily Standup<br/>每日站会"]
        P2 --> P3["开发+Review<br/>编码+评审"]
        P3 --> P4["Sprint Review<br/>演示会"]
        P4 --> P5["Retrospective<br/>复盘会"]
        P5 --> P1
    end
    
    style P1 fill:#e3f2fd
    style P3 fill:#fff3e0
    style P5 fill:#e8f5e9

3.2 任务估算方法

方法	适用场景	优点	缺点
故事点	敏捷团队	相对估算，不受绝对时间限制	需要历史数据校准
T-shirt尺码	粗略估算	快速，适合早期规划	不够精确
三点估算	不确定任务	考虑乐观/悲观/最可能	需要经验判断

3.3 风险管理

flowchart TD
    A["识别风险"] --> B["评估影响×概率"]
    B --> C{"风险等级"}
    C -->|"高"| D["制定应对方案"]
    C -->|"中"| E["监控+准备预案"]
    C -->|"低"| F["接受+定期复查"]
    
    D --> D1["规避：改变方案"]
    D --> D2["转移：外包/采购"]
    D --> D3["减轻：缓解措施"]
    D --> D4["接受：预留buffer"]
    
    style D fill:#ffebee
    style E fill:#fff3e0
    style F fill:#e8f5e9

---

四、团队建设

4.1 人才成长路径

flowchart LR
    subgraph 初级["🌱 初级工程师<br/>0-2年"]
        J1["执行给定任务"]
        J2["学习团队规范"]
        J3["在指导下独立工作"]
    end
    
    subgraph 中级["🌿 中级工程师<br/>2-5年"]
        S1["独立完成模块"]
        S2["Code Review"]
        S3["指导新人"]
    end
    
    subgraph 高级["🌳 高级工程师<br/>5年+"]
        H1["架构设计"]
        H2["技术决策"]
        H3["跨团队协作"]
    end
    
    subgraph 专家["🏔️ 技术专家/架构师"]
        E1["技术战略"]
        E2["技术影响力"]
        E3["行业视野"]
    end
    
    J1 & J2 & J3 --> S1 & S2 & S3
    S1 & S2 & S3 --> H1 & H2 & H3
    H1 & H2 & H3 --> E1 & E2 & E3
    
    style J1 fill:#e8f5e9
    style S1 fill:#fff3e0
    style H1 fill:#e3f2fd
    style E1 fill:#FFD700

4.2 绩效评估维度

维度	权重	评估标准
业务能力	40%	代码质量、交付准时率、Bug率
技术深度	25%	技术选型、性能优化、创新方案
协作能力	20%	Code Review质量、知识分享、mentoring
成长潜力	15%	学习能力、主动性、自我驱动

---

五、沟通与协作

5.1 高效会议原则

会议黄金法则：
├── 有议程：提前发出会议议程
├── 有时间：控制在30分钟内
├── 有结论：明确行动项和负责人
├── 有记录：会议纪要当天发出
└── 能异步：文字胜过会议

5.2 反馈模型（SBI）

Situation（情境）→ Behavior（行为）→ Impact（影响）

示例：
"在昨天的代码审查中（情境），
你指出了我忽略了边界条件（行为），
这让我意识到了问题，避免了线上故障（影响）。"

---

六、本章总结

核心规律：技术管理的本质是「通过他人拿结果」。优秀的技术管理者不是最强的coder，而是最能激发团队潜能的leader。

关键记忆点

• ✅ 从”自己做”到”指导他人做”是最大转变
• ✅ 管理三大职责：定方向、带队伍、拿结果
• ✅ 敏捷开发：规划→开发→评审→复盘循环
• ✅ 反馈用SBI模型：情境→行为→影响

---

延伸阅读

• 01~08 — 现有团队管理专题内容
• 20 持续学习与成长 — 个人成长
• 05 架构设计原则 — 技术决策能力