管理话题

目录

• 管理上常见问题
• 敏捷质量度量指标
  • 效率指标
  • 质量
• 如何考核TL
• 其他
  • 关于需求吞吐量准确度的问题
    • 一、先解决“评估标准模糊”：统一口径，减少“多估”空间
      • 1. 定义“评估锚点”，杜绝“因人而异”
      • 2. 统一“需求颗粒度”，避免“大需求多估”
    • 二、引入“客观校验机制”：让“多估”被数据暴露
      • 1. 用“团队速率基线”预警异常评估
      • 2. “多人独立评估+共识校准”：避免单人主观偏差
      • 3. 追溯“评估 vs 实际耗时”的偏差率，纳入复盘
    • 三、调整“激励与衡量导向”：从“多完成”转向“估得准、做得好”
• 参考资料

技术管理做什么
https://www.cnblogs.com/aibi1/p/18755163#做事

管理上常见问题

1.交付质量一直不太如意，生产故障多
2.事情多，人总是不够
3.项目经常延期
4. 每个项目都疲于奔命，加班多，研发幸福指数不高

管理思路
1 找到问题，找到根因，逐个突破
2 找差距（标杆），小目标。 SCRUM敏捷开发+ 研发度量
敏捷成熟度模型。我们从1-2-3

敏捷质量度量指标

效率指标

1 . 需求吞吐量。 （需求吞吐量的准确度通过最后面的指标来衡量）
2. 事务性需求占比。不高于30%
评估的需求点数跟实际投入有差距。

质量

缺陷逃逸率（Defect Escape Rate）：生产环境发现的缺陷数 ÷ （测试环境发现的缺陷数 + 生产环境发现的缺陷数）×100%，反映测试环节的覆盖有效性（越低越好）。
OPPO CRM逃逸率是低于8%
缺陷密度（Defect Density, DD）：每千行代码（KLOC，迭代变更的代码）中发现的缺陷数量。
测试环境参考范围：0.5-2 个 / 千行代码（KLOC）
生产环境缺陷密度：0.1-0.5 个 / 千行代码（KLOC）

如何考核TL

• 常规。 项目按时上线，上线质量达标。上线之前考核（千行代码缺陷）
• 加分项。
  1 主动解决模块或者服务的难啃历史遗漏问题并解决
  2 主动识别模型或者服务对未来无法支撑的难题，并解决。
  3 主动寻找系统一些可公共的工具，并推广使用，提升产品组的研发效率。比如封装一些工具
  4 主动引入新的方法论，并推广，并提升效率。

其他

关于需求吞吐量准确度的问题

一、先解决“评估标准模糊”：统一口径，减少“多估”空间

“多估”的首要前提是“标准不明确”——不同人对“故事点大小”“需求复杂度”的理解差异，导致评估可随意调整。需先通过“标准化评估规则”压缩主观操作空间。

1. 定义“评估锚点”，杜绝“因人而异”

2. 统一“需求颗粒度”，避免“大需求多估”

大需求需要拆成不超过S的需求。

二、引入“客观校验机制”：让“多估”被数据暴露

即使有标准，仍可能有人为了数据好看“刻意高估”（如把实际1点的需求估成2点，确保迭代完成率100%）。此时需通过“历史数据对比”“多角色交叉校验”“实际耗时追溯”等机制，让偏差显性化。

1. 用“团队速率基线”预警异常评估

“团队速率（Velocity）”是指团队在一个迭代内实际完成的故事点总量，长期来看会趋于稳定（如成熟团队每月迭代的速率稳定在30-40点）。

• 操作步骤：
  1. 记录过去3-5个迭代的“实际完成速率”，计算平均值（如35点），作为“速率基线”；
  2. 每次迭代规划时，若“评估的总故事点”远超基线（如突然涨到50点），工具或Scrum Master自动触发“评估复核”；
  3. 复核时要求团队逐一说明“为何本次评估速率大幅上涨”——若无法提供合理理由（如引入了新工具提升效率、需求复杂度降低），则需重新评估，压缩多估空间。

2. “多人独立评估+共识校准”：避免单人主观偏差

采用“规划扑克（Planning Poker）”等方法，让多个角色（开发、测试、产品）独立评估，再通过讨论达成共识，减少“单人多估”的影响：

• 具体流程：
  1. 产品经理讲解需求细节后，所有人闭眼出牌（用规划扑克卡片选择故事点，如1/2/5/8）；
  2. 亮牌后，若评估差异大（如有人出1，有人出5），让“最高估”和“最低估”的人分别说明理由（如最高估者认为需要跨服务，最低估者认为仅前端修改）；
  3. 重新讲解需求细节，消除信息差后再次出牌，直至所有人评估结果差异≤1个故事点（如最终统一为2点）。
• 核心逻辑：多人独立评估可避免“某个人主导评估”，共识讨论能暴露“刻意多估”的不合理性（如有人刻意高估，会被其他人用锚点和案例反驳）。

3. 追溯“评估 vs 实际耗时”的偏差率，纳入复盘

每次迭代结束后，必须做“评估偏差分析”——计算每个需求的“评估故事点”与“实际耗时对应的故事点”的差异，形成“偏差率报告”：

• 偏差率公式：|（实际耗时对应的故事点 - 评估故事点）/ 评估故事点 | × 100%
  （注：“实际耗时对应的故事点”需对照锚点换算，如实际用了3天，对应锚点的5点，则实际故事点为5）
• 复盘动作：
  • 若某需求偏差率＞50%（如评估2点，实际5点），或某成员评估的需求普遍偏差率高，需分析原因（是评估不准？还是刻意多估？）；
  • 若发现“多估”（如评估5点，实际仅2点），需明确下次评估的改进点（如需更严格对照锚点）；
  • 将“团队整体评估偏差率”作为敏捷成熟度指标之一，而非仅看“吞吐量完成率”——偏差率高说明评估能力弱，需优先优化评估流程，而非追求“数据好看”。

三、调整“激励与衡量导向”：从“多完成”转向“估得准、做得好”

“多估”的根本驱动力往往是“KPI导向错误”——若团队仅考核“吞吐量完成率”（如完成率100%有奖励，未完成则扣分），成员自然会通过“多估”确保达标。需重构衡量体系，让“评估准确性”和“交付质量”与“效率”同等重要。

参考资料