产研指南针的量化指标实践笔记

背景

在公司和业务发展到一定阶段，高层管理者会逐步期望从直觉化的管理逐步转向量化的关键指标管理；同时从 hr 层面 okr 和 kpi 的考核逐步从直觉化的定性考核，转变为数据化指标考核为主做评估和分析。此时中层管理者要实践关键指标读取和分析，及对团队成员从长期关注，变成短期快速反馈并推进绩效改进。

难点

1. 研发成果难以评估：研发属于研究性的脑力输出,不同能力输出的结果是不一样的，难以通过可见性的指标精准评估成果的好坏。

2. 研发指标容易作弊：研发指标难以通过自动化的标准准确输出可靠，诸如代码质量只能是相对的。特定的指标容易通过作弊的方式达成（比如代码行数）。

3. 大量重复性的统计：量化指标需要大量研发过程性数据的统计，需要打通多种过程工具，按照多维度产出报表，对于管理者耗时耗力。

4. 过度的透明化，造成目标转移：定性考核往往以结果为目标（虽然容易造成大锅饭），结果目标明确。量化考核往往以人和团队为衡量，量化结果容易造成团队内卷，变成指标为目标，而非业务为目标(而个人成果难以量化对齐业务结果)。

思考

1. 研发应当以多个指标考核结果,分别从用户的反馈，运营的结果，过程的量化，质量情况(故障率)，hr 的统一管理标准，360 评价，目标的 kpi/okr 的综合结果，计算比较合理的权重分值(可以自动化算出合理权重)。

而实际落地需要根据实际业务的场景，团队的规模情况及公司的管理策略及文化价值观决定，定义核心的几个关键指标（毕竟每家公司和管理的方法论都是不一样的，比如高效能研发体系建设阐述的管理一体化的实践）为佳，过于全面反而耗时耗力。通过多维指标综合判定和行政管理，可以解决单一指标作弊和不准的问题。

2. 研发的体系，人员组成，架构方案在不同公司，不同业务场景，包括管理工具肯定都是不一样的。即便管理者的方法论或许一样，但是过程性的数据来源肯定是不一样的。重复性的统计输出，肯定会造成重复性的劳动，所以同样指标的分析和统计肯定要系统化和工具化，去解决重复性的问题。通过自研投入（非开源）来解决实际方案和数据源不一样的等问题。

3. 研发的指标不应当过度透明化公开（对个人透明），但是要体现团队优秀人员的指标，让个人了解差距和问题，激励个人成长。团队管理最终应该以人为本，考虑人本身管理的差异和定位，而量化指标应当是结合实际情况，去分析管理问题的依据和问题点，反推管理的不足和问题的本质因素，从而推进个人效能提升和改进。所以量化指标应该重视并分析（应该作为微管理的辅助参考数据），但不应过于倡导造成团队内卷(对于没有实在无法对齐业务目标结果的同学可以考虑直接优化，而非通过指标去过度评判)。

实践

不同公司的研发管理工具和数据分析工具都是不一样的，诸如结合小型研发团队（50 人以内），采用飞书协同，禅道管理，sonar 质量分析，gitlab 管理代码，java/react 开发及标准化的研发体系的基础上，我们自研自己的指南针量化指标小工具（荣誉榜），去解决人员管理对于快速复盘效能情况，快速发现管理问题，快速反馈人员状态，量化数据考核指标的问题。我们提出几个关键研发指标去参考和衡量研发个人的产出和状态，分别为平均工作时长，累计加班时长，迟到/缺卡次数，任务数，任务工时，制造 Bug 数，发现 Bug 数，代码提交数，代码不合格(未解决数量)，性能差接口数,故障数。在这些指标量化的基础上，通过同类型研发角色（测试，前端，后端）的多维度对比，去思考研发人员优良差的情况和原因。

人事维度关键指标

平均工作时长：系统打通飞书 api，获取飞书每日的打卡时间，排除请假，缺卡，迟到等因素外的正常上班的时长为准。

累计加班时长：系统打通飞书 api，获取飞书每日正常下班之后，24 点之前的加班时长为累计。

迟到/缺卡次数：系统打通飞书 api，获取飞书每日迟到和缺卡的次数（排除请假）。

上班时长是一些基础性的数据，也是 hr 比较关注的核心数据指标。管理者一般也期望通过上班时长去了解团队成员和整体的激情和状态。

过程维度关键指标

任务数：系统打通禅道，获取禅道每人的工作任务明细，并统计数量，包括任务的分布甘特图等情况。

任务工时：系统打通禅道，获取禅道每人的任务的开始和完成时间（预估时间），包括统计每人的工作整体饱和度和每日的饱和度情况。

制造 bug 数：系统打通禅道，获取禅道每人的 bug 数的情况和每日分布情况。

发现 bug 数：系统打通禅道，获取禅道提交 bug 数量，主要统计分析测试人员的工作情况。

代码提交数：系统打通 gitlab，获取每个人的 gitlab 代码提交的数量，主要是统计分析每个人的代码新增的代码数量减去删除代码数量。实操过程中我们发现一些异常的代码管理会造成数据差异过大的情况。诸如删除项目日志（已进入仓库）,新建项目时候的脚手架代码数，格式化代码等问题。

日常的项目沟通到立项阶段，以飞书协同文档为主（多维表格项目管理模板），在项目管理之外所有已确定的工作任务录入禅道，以禅道做项目管理模板，进行统一的集中式管理，这个也是目前公司要求的通用管理模式。但无论何种模式下，管理者在这个阶段比较关注的是人员的工作饱和度和过程质量两个关键问题及相应的关键指标。

质量维度的关键指标

代码不合格（未解决数量）：系统打通 sonar，获取 sonar 代码分析之后的质量情况，统计到每个人的代码异常情况。比如 java 会按照阿里巴巴的代码编写规范做标准分析。

故障数：系统打通飞书文档，我们通过故障群统一接收线上故障信息，通过机器人自动录入到飞书文档进行归档，我们通过 2 周一次复盘故障的责任人，级别，类别，时长（故障等级标准），超过一定级别的故障需要有故障报告并通知关键成员；而故障数是最重要的质量参考指标。

性能差接口数: 系统打通“全链路自动化压测平台”,通过录制和回访模式,自动化统计性能差的接口并归类到具体研发。

代码实际设计情况一般来说很难通过自动化的方式去量化去判别，人工 codereview 也难以精准判别；在人员有限的资源下，通过真实的质量反馈和代码规范是关键质量考核参考。

北极星荣誉榜

主要有两个功能：荣誉排行榜和多维分析报告。

荣誉排行榜：面向普通开发人员，去公开最近两周优秀的指标排行榜，去让成员了解自身在团队内的表现情况，了解并分析差距的因素。

多维分析报告：面向管理人员，对同类型团队成员对比表现情况，实时分析每周（近期）的真实表现情况，去了解和分析量化数据背后的真实因素。将定性管理转变为数据管理模式，将直觉管理转化量化管理模式；从而快速，及时，有效的分析项目问题和人员情况，尽快介入解决管理问题。

如图：

业内参考

万位数字 CTO 分享他们的量化指标维度实践,并将之作为量化考核。如图:

搜狐社交总经理分享他们的六象限雷达图，将之作为量化结果管理辅助参考。如图:

总结

作为管理者，我们需要思考虽然管理方法，指标及工具能够带给我们的一些便利性和实践，但是我们也谨慎的意识到工具和方法终究在管理之术的范畴，管理本身面对的是人，最终要以人为本，核心关键在于目标和激励（五个维度构建研发管理体系阐述了研发管理整体性的思考）。同时管理者也要清晰，管理的职能仅仅是达成目标的手段和过程，而我们最终要以业务和结果为目标！！！

以上心得，多做反思，勤做笔记，与君共勉~

by 车江毅

2022-11-10