思考IT部门的绩效管理

Posted on Edited on

基于前面三篇文章
《基于DORA指标体系的项目管理.md》
《软件项目代码健康度评估体系.md》
《OST（Outcome-System-Team）模型构建的IT效能指标体系.md》
来思考IT部门的绩效考核。特别是针对1万人以上的大型团队。

一、把客观技术 /交付指标纳入绩效考核 — 优点

  1. 公平性要高
  • 使用数据驱动的指标 (如故事点吞吐量、交付周期、DORA 指标等) 可以减少管理者个人偏好对考核结果的影响，让考核更透明。
  • 对于高层 (如 CIO) 来说，用这些指标可以更准确评估不同团队或个人对业务价值和技术稳定性的贡献。
  1. 有助于战略对齐
  • 将 OST 指标 (Outcome / System / Team) 纳入绩效，可以把工程绩效与业务目标（银行业务目标、风险、效率等）紧密对齐。
  • 促使团队更关注高价值交付 (outcome)、系统稳定 (system) 和长远可持续性 (team)，而不是短期 “写多少代码 /发多少功能”。
  1. 可驱动改进
  • 明确量化指标可以帮助识别瓶颈 (例如交付速度慢、线上缺陷率高、技术债务重) 并推动改进。
  • 如果大家知道考核是基于这些数据，他们可能更积极参与流程改进 (如 CI/CD 优化、代码质量提升、减少回滚等)。
  1. 建立数据文化
  • 长期来看，当绩效考核与数据指标结合，可以推动组织成为更加数据驱动 (data-driven) 的工程文化。
  • 也可能促进透明度：团队可以看到自己在关键指标上的表现和进步空间。
  • 投资数据基础设施：支持构建一个可靠、透明、自动化的指标平台，这是保证整个过程公平公正的技术基石。
    做到公平，公正，公开的原则。

二、必须警惕的风险 &挑战

不过，也有一些非常现实的风险 — 尤其当你把这些技术 /系统 /团队指标纳入绩效考核 (与薪酬 /晋升等挂钩) 时，需要非常谨慎：

  1. 指标被滥用 / “游戏化”
  • DORA 等指标如果成为绩效评估目标 (而不是诊断工具)，容易被策略性优化 (Goodhart 定律)。
  • 比如部署频率、变更交付时间等，如果被当成 KPI 目标，可能导致团队做很多小型频繁变更而忽视质量或业务价值。
  • BlueOptima 的分析就是提醒这种风险：误用 DORA 会忽视创新、长期战略、团队体验等重要维度。 
  • 还有一些业内实践指出，DORA 在不同类型团队 (例如平台团队) 上可能根本不适合作为绩效衡量标准。比如 Reddit 上有人说：

    “DORA metrics should never be used as a measure of team performance for any team … if that is the main measure that a manager uses to evaluate a team then they are not much of a manager.” 

  1. 定义与测量的一致性问题
  • 不同团队可能对 “Lead Time”、“部署频次”、“变更失败”等指标的定义不一致。测量方式、数据来源差异大。
  • 如果没有标准化，就难以公平比较或设定统一绩效目标。
  1. 文化与信任问题
  • 开发者可能担心这些数据被用于 “惩罚” / 评判，而不是改进。
  • 如果考核机制太“硬”，可能压抑创新 (团队可能更保守、不敢承担风险)。
  • 还可能影响团队士气：当绩效主要看硬指标时，开发者可能感受到压力和不公平。
  1. 指标忽视其他重要但难量化的维度
  • 虽然 OST 已经比 DORA 更全面，但仍可能漏掉某些非常重要但难量化的工作 (例如重大架构重构、技术研究、技术债务长期偿还、团队 mentorship 等)。
  • 绩效机制如果完全依赖量化指标，有可能不鼓励那些对长远价值做出贡献但短期不可量化的行为。
  1. 廉洁 /合规风险
  • 把绩效和数据高度绑定，如果没有合规设计 (权限、透明度、复核机制)，可能导致数据滥用或“擦边操作”。
  • 在绩效管理中，很重要的一点是设计合理的治理机制，以防止数据造假或考核操纵。

三、如何在现实里把 OST 指标作为绩效考核部分落地 (作为 CIO 的角色)

使用客观 OST 指标做绩效考核，这里是一些建议 +落地策略：

  1. 混合考核模型 (Balanced Performance Framework)
  • 将 OST 指标作为部分权重：不要把所有绩效都挂在这些指标上。可以设 “技术 /工程绩效 (Engineering KPI)” 权重 + “业务 /战略贡献” + “行为 / soft skill (沟通、协作、领导力)” 等维度。
  • 通过混合模型 (例如 KPI + OKR + 360 评估) 来平衡硬指标和软指标。OKR 是一个不错的工具，可以与你的 OST 目标对齐。 

==> 同意。Manager提名top performance at year end，OST不可以是差。

  1. 逐步引入 +试点
  • 选几个代表性的团队 (不同类型：业务交付、平台、基础设施) 进行试点，将 OST 指标纳入绩效考核。
  • 在试点阶段收集团队反馈 (他们对于指标、权重、压力、改进方向的看法)；根据反馈调整考核机制。
  1. 标准化指标定义与数据收集
  • 建立统一指标定义 (例如 “什么算一次部署”、“变更失败率如何定义”、“恢复时间如何衡量”)。
  • 建立数据管道 (数据平台 +自动采集) 确保数据质量和一致性。
  • 对指标采集、报告和访问权限做好治理 (谁能看到、谁能行动、如何复核)。

==> 同意。抓取SonarQube / ServiceNow 等工具中的数据，renew&publish performance weekly。而不是另行制作工具，保证工具公平公正，结果公开。
==> 分数以阶梯样式呈现出结果的状态（例如，绿色80～100；黄色60～80；红色0～60；又例如service available time 绿色99.99%；黄色99.9%；红色99%）

  1. 建立透明和反馈机制
  • 向团队明确说明这些指标用于什么目的 (改进 vs 评估)；强调不是为了“追你分数”，而是帮助团队成长。
  • 定期 (季度或半年) 开“指标回顾会议”：展示 OST 指标趋势，讨论背后原因 (好的 /差的)，共同决定改进方向。
  • 允许团队对考核机制提出异议 /反馈 (例如 “某个指标对我们团队不公平 /不适用”)，并建立治理制度 (修正权重、调整指标、剔除异常数据)。

==> 同意。每周小leader开会，展示OST指标，negative case (incident / CR / Jira Ticket / etc.)；每月大leader开会，展示OST指标以及趋势。CIO主持复盘：亲自参与定期的考核复盘会议，不仅看数据，更要关注制度本身是否健康，及时调整方向。

  1. 设置合理目标与 guardrails
  • 目标不要设得太激进 /绝对。可以用趋势 (improvement over time) 作为目标，而不是一次性 “达到 X 水平”。
  • 设 guardrails (安全阈值)：即使某指标很差，也不能直接惩罚个人 /团队，而是先做诊断、支持改进。

==> 同意。要逐步提高。

  1. 培养 “指标文化”
  • 教育管理层和团队，让他们理解 OST 指标背后的价值和局限性 (不是万能，也不会自动等同于 “好员工”)。
  • 鼓励使用指标作为学习工具 (diagnostic tool)，而不是确定 “谁干得差 /谁干得好”。
  • 建立正向激励 (例如，对指标改善 (velocity 提升、失败率下降、团队满意度提升) 的团队给出奖励) — 不只是惩罚。
  1. 合规与审计机制
  • 保证绩效数据采集、报告和评估是透明、可审计的。考虑权限控制 (谁能看、谁能修改)、数据存证 (记录、审计日志) 等。
  • 对关键指标 (尤其涉及系统稳定性 /重大生产事件) 建立复核机制：不仅看数字，还要看上下文 (例如某次失败是因为外部不可控问题)。

任何工具都是手段，而非目的。最终的目标是建立一个既能高效交付业务价值，又能让优秀人才感到被激励、被认可，从而可持续发展的健康组织。