团队管理

团队搭建

管理层次

为了便于下面的讨论，我们先约定如下从上到下的管理层次：

• CTO：首席技术官，管理岗。
• Manager：部门负责人/经理，管理岗，基本不写业务代码。
• Leader：团队负责人/组长，半管理岗，需要同时编写代码，而且经常是主力开发。
• Staff：一线员工，负责编写代码。

对于一个大型研发团队，这 4 个层级都会有。对于一个微型研发团队，这时的 CTO 其实就是 Manager/Leader，直接带 Staff。而介于这两个体量之间的研发团队，通常是 CTO + Manager + Staff 的组合或者 CTO + Leader + Staff 的组合。

有趣的话题：不同的组织结构适合管多少人

对于 CTO => 前端、后端、算法、测试、运维 5 个部门 Manager => Leader => Staff 这种完整的组织结构：

• 最多可以支撑大约 286 人（1 个 CTO + 5 个 Manager + 5 _ 7 个 Leader + 35 _ 7 个 Staff）。这里我们不考虑将一个部门按业务进一步拆成多个部门有多个部门 Manager 的情况。
• 最少可以支撑大约 56 人（1 个 CTO + 5 个 Manager + 5 _ 2 个 Leader + 10 _ 4 个 Staff）。注意，Manager 和 Leader 层级同时存在的话，1 个 Manager 至少要带 2 个 Leader。

对于一个微型团队，只需要一名管理者：

• 最多可以支撑大约 11 人（1 个 CTO + 10 个 Staff）。注意，这里的 CTO 实际上是一个 Manager。
• 最少可以支撑 1 人（光杆司令）。

对于一个中小型团队，全部 4 个管理层次只需要保留 3 个。

• 最多可以支撑大约 56 人（1 个 CTO + 5 个 Manager + 5 * 10 个 Staff）。
• 最少可以支撑大约 11 人（1 个 CTO + 5 个 Leader + 5 * 1 个 Staff）。

以上只是举例说明，实际上人员配置可以更加灵活，比如可以采取部分部门设置 Leader 由 Leader 直接向 CTO 汇报，部分部门不设置 Leader 由 Staff 直接向 CTO 汇报，也可以跨部门设置 Leader。比如这样：1 个 CTO + 前端（1 个 Leader + n 个 Staff） + 后端和运维（1 个 Leader + n 个 Staff） + 1 个算法 Staff + 1 个测试 Staff。

管理幅度

“管理幅度”（Span of Control）是管理学里的一个名词，其实就是“管理人数”，表示一名管理者应该能够直接管辖的下属人数。关于管理人数，不同管理学理论里有不同的建议，而且也和具体的团队性质有关系。

基于网上的一些管理学理论，结合我自己的实际管理体验和观察，我觉得基于以下标准（按直接带 Staff 来举例）来进行调整是比较合理的：

• Leader 的管理幅度为 4~7 人。Leader 要写代码、调研技术方案、审查代码、排查 bug、关注团队成员成长、协调资源，一旦管理人数过多，就会顾此失彼，降低团队战斗力。
• Manager 的管理幅度为 6~10 人。

然后需要根据以下一些情况来调整管理幅度：

• 如果新人、初级开发多，管理者的管理幅度应适当往较小值走；反之，如果老人、高级开发多，管理者的管理幅度应适当往较大值走。
• 如果项目复杂耦合度高（意味着任务难拆、代码易冲突、团队成员沟通成本高），则管理者的管理幅度应适当往较小值走。反之，如果项目简单耦合度低，则管理者的管理幅度应该适当往较大值走。
• 如果项目成员超过 12 人，则应考虑进一步拆分小组，增设 Leader。
• 如果管理者的非管理职责较重（比如技术性公司要发论文），其管理幅度应适当往较小值走。
• 如果项目节奏比较慢，管理者的管理幅度可以适当往较大值走。

盲目扁平化管理（比如 1 带 15）的危害

短期看，节省了管理层级。实际上，会带来以下问题：

• 基本上只能疲于抓进度，无瑕关注人员成长和技术负债，弱者得不到辅助难以成长，优秀者得不到关注流失率高，代码得不到优化迭代成本越来越高。
• 开会时间成本变高，决策变慢。

团队配置

Manager 直接带 Staff

这种情况下 Manager 一般带的人比较多但是又没达到进一步拆分出 Leader 的程度，由于 Manager 不负责写代码，团队里必须有至少 1 名 Owner 精神比较强的资深骨干开发（半个 Leader、扮演技术带队角色）。

Leader 直接带 Staff

由于 Leader 要兼顾管理和编码，并且通常是主力开发，Staff 人数不宜过多。

CTO 同时带 Leader 和 Staff

其实就是部分部门有 Leader，部分部门没有 Leader，有 Leader 的部门由 Leader 向 CTO 汇报，没有 Leader 的部门由 Staff 直接向 CTO 汇报。Leader 的能力一定要强。没有 Leader 的部门里，Staff 最好工作比较积极，如果其能力较为突出，建议也给他一个 Leader 的 title，即便当前他名下没有 Staff 需要管。

团队管理（Manager 视角）

研发经理完整管理体系分四大核心板块：业务交付、技术治理、人员管理、组织流程。

研发经理核心定位：不只是催进度，是业务与技术的桥梁、团队能力的搭建者、风险兜底人。区别于 TL（写代码），研发经理核心工作是管人、控风险、对齐目标、向上争取资源。

目标与交付管理：保障业务稳定落地（第一优先级）

首先，作为管理者需要明白，公司招你来是让你做事的，研发部门可以有自己的声音，但核心应该是业务导向的。

目标对齐，统一预期

年度 / 季度 OKR 拆解

承接公司业务目标，拆成研发可落地指标：交付周期、线上故障数、技术债务清理、性能优化等；和产品、测试对齐，避免需求频繁变更。

需求准入管控

建立需求评审机制：产品输出完整 PRD、验收标准、排期预估，无明确价值、边界模糊需求直接打回，杜绝临时插需求打乱排期。

排期客观化，拒绝盲目承诺

不拍脑袋排期，TL 评估工时 + 预留缓冲（20% 风险时间）；提前识别跨团队依赖、第三方接口、环境问题，同步给业务方预期。

过程管控，风险前置

固定迭代节奏

标准 2 周迭代：迭代启动会（拆分任务）、每日站会（15 分钟同步阻塞点，不聊细节）、迭代评审（演示功能）、迭代复盘（问题总结、优化方案）。

分级风险上报机制

• 轻微风险：TL 内部解决；
• 中度风险（延期 3 天内、小故障）：同步研发经理；
• 重大风险（上线阻塞、线上 P0 故障、延期一周以上）：立刻同步上级 + 产品负责人，同步备选预案。

上线与线上稳定性管控

规范上线流程：灰度发布、回归用例、回滚方案；建立故障分级处理机制，故障后强制复盘，输出改进项跟踪落地；设定稳定性指标（故障时长、线上 bug 逃逸率）。

向上管理：主动汇报，争取资源

• 定期同步：周进度简报、月度团队总结，内容包含：交付成果、风险阻塞、需要上级协调的资源、下月规划。
• 诉求前置：缺人、缺环境、第三方配合问题，不要等到延期才提，提前给出数据证明缺口，同步备选方案。
• 承接压力，保护团队：业务方不合理排期、临时紧急需求，经理做缓冲层，不要直接把压力传导给工程师。

技术治理管理：避免团队越做越乱（解决技术债务、架构腐化）

很多研发经理只盯交付，忽略技术治理，长期会出现迭代越来越慢、线上故障频发。

架构统一规范

定期架构评审，新增业务模块强制遵循统一架构，禁止各写一套。

技术债务闭环管理

迭代预留固定技术优化工时（每迭代 20% 容量）；梳理技术债务清单，标记优先级，重大债务纳入季度 OKR，不无限堆积。

代码质量管控

落地强制 CR、自动化 Lint、单元测试覆盖率指标；定期代码复盘，针对高频 bug、不规范代码做团队分享。

沉淀团队资产

推动公共组件库、工具脚本、问题排查文档、踩坑记录沉淀；组织内部分享会，每周 / 每两周一次技术分享，提升整体技术水位。

也包括其他一些文档建设：

• 团队编码规范。
• 发版规范。
• 仓库版本管理规范。
• 新人入职手册、快速上手指南。
• 项目级的介绍文档。

人员管理：研发经理核心核心工作（识人、育人、留人）

研发是知识型团队，人是核心资产，管理幅度参考之前结论：直属下属 6–10 人为最佳。

日常沟通：建立信任基础

一对一 1on1（最重要的人员动作）

• 固定周期（每周 / 每两周 30 分钟），不聊进度，聚焦个人：
  • 工作侧：当前卡点、需要什么支持、对团队流程 / 架构的意见；
  • 成长侧：职业规划、想学习的技术、短板；
  • 情绪侧：工作压力、协作矛盾、满意度。
• 1on1 记录存档，员工提出的诉求必须给出反馈，不敷衍。

公平透明，减少内耗：

• 任务分配兼顾能力与成长，不把脏活累活固定分给某几个人；奖惩标准公开，绩效、评优规则提前同步，避免员工猜忌。

人才培养：分层管理，打造梯队

• 新人（0–6 个月）：
  • 制定新人成长计划：导师绑定、前两周轻量化任务、每周单独复盘、规范培训；设置转正考核标准，定期跟进适应情况，避免新人流失。
• 中级工程师（主力交付）
  • 核心诉求：提升技术深度、有独立负责模块的机会；分配独立业务域、鼓励主导技术方案、参与架构评审，安排分享输出。
• 高级 / 资深工程师、储备 TL
  • 核心诉求：技术影响力、管理机会；安排负责复杂预研、技术治理专项；给到带新人、主持 CR、主导复盘的机会，作为小组长储备。
• TL（技术组长）
  • 明确 TL 权责：任务拆分、代码评审、小组风险把控；经理重点赋能 TL 管理能力，同步管理方法，下放小组内部分配权限。 :::

绩效与激励管理

• 绩效标准量化
  • 不单纯看 “写了多少代码”，考核四大维度：业务交付、代码质量、团队协作、技术沉淀；区分产出和潜力，不唯进度论。
• 多元化激励
  • 物质：绩效奖金、晋升推荐、项目专项奖励；
  • 精神：公开会议表扬优秀员工、重要项目署名、优先参与核心技术预研；
  • 成长：晋升通道清晰（专业线 / 管理线双通道），明确每一级能力要求。
• 冲突与负面员工处理
  • 协作矛盾：单独沟通双方，梳理矛盾根源，制定协作规则，当场对齐；
  • 消极 / 低产出员工：先 1on1 了解根源（能力不足、心态问题、适配度差），设置改进周期，给出明确改进目标；到期无改善，启动调岗或淘汰流程，不拖累整个团队。 :::

留人：降低核心人员流失

• 核心员工离职成本极高（知识断层、项目延期、团队士气打击）：
• 定期关注核心员工诉求，主动匹配成长机会；
• 向上争取晋升、加薪资源，主动为核心员工背书；
• 营造轻松的团队氛围，杜绝无效加班、无意义会议；
• 员工产生离职意向时，第一时间深度沟通，区分是薪资、成长、协作还是管理问题，能解决则挽留，无法达成共识友好放手。

流程、团队氛围与成本管理

流程优化，减少无效工作

定期迭代复盘梳理流程痛点：冗长评审、重复沟通、繁琐上线流程；简化无价值流程，引入自动化工具（自动化测试、一键发布、监控告警）降低重复工作量。

打造健康团队氛围

• 拒绝职场 PUA，允许员工提出不同意见，技术方案鼓励辩论；
• 区分 “对事不对人”，线上故障、交付延期只复盘流程和技术问题，不人身指责；
• 适度团队建设，缓解研发高压，增强团队凝聚力。

成本与资源管控

• 人力成本：合理规划团队编制，根据业务峰谷调整人力，避免人力冗余或严重缺人；
• 服务器、第三方服务、测试环境资源管控，推动资源优化降本；
• 时间成本：严控无效会议，站会限时、评审会提前发材料，杜绝全员长时间参会。

研发经理避坑指南（高频错误）

• 只盯进度，忽略人员感受：长期压榨员工，核心人才批量流失；
• 深度介入写业务代码，无暇管理：陷入具体开发，团队风险、人员成长完全失控；
• 过度扁平化，管理幅度过大（12 人以上）：无暇一对一沟通，团队问题不断；
• 只交付不治理技术债务：短期迭代快，后期系统腐化，迭代效率断崖式下跌；
• 向上只报喜不报忧：风险隐藏到无法挽回，给上级和业务带来重大损失。