CTO来分享：探讨组织研发效率提升的核心指标及部门岗位SOP

前言和背景

现在正值2023年2月20号，二月初一龙抬头的日子。

回望过去这一两个月，也正是各大企业年度总结和2023年年度规划最为热潮的阶段。我作为技术顾问，有幸深度参加了不同企业的年度规划计划制定之中，和企业的创始人、公司的管理层、各部门负责人、以及一线的研发工程师，一起群策群力，共同制定可执行、可量化、可落地的执行方案和研发部门岗位的具体SOP。

在这样的背景下，相比以前仅是作为一位职业经理人制定年度计划，此时站在外部更客观、更立体、更全面的角度，对于研发这个黑洞和泥潭，仿佛又找到和领悟到了新的思路、见解和策略，以及可达成目标的关键路径。

故记录分享之，希望对还在研发管理上迷茫的团队，提供一些价值参考。

寻找研发团队的核心提升指标

软件行业，没有银弹（No silver bullet）。

但再复杂的系统、再庞大的工程模型，总能对其进行量化和度量。如果一个系统不能对其进行量化，我们就很难对其“看得清、看得懂、看得透”，更别提要改进和提升。

软件研发也如此。针对研发这个黑洞，针对软件这个泥潭，我们应该关注哪些核心指标，或者说：我们（当前企业、当前研发团队、当前管理层）最关心哪些重要的数据指标？又或者，软件工程的本质指标是什么？

受最近一位朋友的指导老师启发，“在衡量项目进度和风险时，对比项目的实际交付时间和计划完成时间的进度差距，是最终结果，而不是原因，也不能作为过程控制的指标。”

诚然如此，项目的颗粒度是最大的、最复杂的、最漫长的、最不确定、也是最不可控的。不应该把项目的交付指标作为核心提升指标（因为他是结果，不是过程，更不是原因）。那么应该把什么当作研发团队的核心指标呢？你们的团队现在有没有绩效考核指标，使用的又是什么指标？

借鉴过往企业和团队的考核和管理方式，以及我的见解，分别对比介绍两种核心交付指标：把任务工时作为核心交付指标，以及 把需求交付作为核心交付指标。

第一种：把任务工时作为核心交付指标

有些公司，会把员工每日的日报或每日登记的任务工时，作为核心交付指标之一。其做法是：查看每个员工有没按时提交和填写每日任务完成和计划情况，想看下背后有没“摸鱼”的情况。不过讲真，这种方式，有点“劳民伤财”，没有具体的量化，只会让管理层淹没在事务信息中。

又有些公司，会每周或每个月，统计每个部门、每个员工的有效任务工时。那怎么才算是有效任务工时呢？比如一个员工，正常每天工作8小时。那么减去上厕所、中途走动、偶尔接个电话之类的私人自由时间，得出假设每天有效工作是6小时。那么再结合每位员工的出勤天数，最终算出每个人应该登记的总完成工时有没达到标准值。如果没有达到，则要补充工时或进行说明，或进行相应的绩效扣除。这种方式，有了可量化，但不够明确。

因此，又有公司，改进了这种任务工时登记和统计的做法。在原来的基础上，再计算出用于有效研发的任务工时是多少，再除以总登记的有效工时，最终计算得出研发的有用功率是多少。有效研发的任务工时，是指排除开会、改Bug、故障处理、需求沟通等不直接作用于需求交付的工时。研发的有用功率是介于0%和100%之前的百分数，比例越大，意味研发团队的交付就越有价值（回忆、联想和参考物理学中热能的有用功计算公式）。

热机的效率： η=W有用/Q总×100%，其中W有用指用来做有用功的能量，Q总指完全燃烧释放的能量。

以上几种关于任务工时的方式和做法，我都曾亲身经历过和使用过。但我觉得这种任务工时的做法，对于处于一线的研发人员有间接参考作用，但没有直接提升和指导的价值作用。与此同时，对于研发管理和整个企业的发展来说，过多关注于具体事务的任务工时，会让人“只见树木、不见森林”，只关注“把事情做正确”而忽略了“做正确的事情”。

为此，我觉得，应该——

第二种：把需求交付作为核心交付指标

是的，把需求交付作为核心交付指标，可以统一一线人员、管理层和企业三者的共同目标，并且是可量化、可执行、可用于过程进度和风险控制的。

把需求交付作为核心交付指标，而不是把任务工时作为核心交付指标，可以让研发团队更关注“做正确的事情”，以及如何花更小的力气、更少的资源就能达到最好的效果和既定目标。

把需求交付作为核心交付指标，也能让每个人去挑战“跳一跳就能够得着的目标”，提高每个人的参与感。不因岗位职级而限定每个人的发挥，而是让大家都群策群力、扁平化协作、自组织管理、彼此信任和理解。让实习生可以去做普通开发工程师的事务、让普通开发工程师可以试着担当项目负责从零到一推动某一个项目、让项目经理可以有更多时间在整体的宏观角度把控企业每条产品业务线的进度和风险、让CTO和高管有更多的时间和精力专注在技术壁垒和未来布局发展规划之上。这是一种整体向上的风气和氛围。

相反，如果CTO做技术经理的活，技术经理干了研发工程师的活，研发工程师在做实习生的事务，实习生每天都是在学习和旁观。那边，这是一种压制的等级氛围。

再具体一点，可以把每个月作为一个统计的周期和考核的周期。把每个月，按业务团队的每月交付需求数量作为核心的交付指标，并且结合任务工时、Bug质量、测试用例、团队人员进行展开。

为此就有了以下的核心交付指标统计模板：

涉及的指标有：

研发人数 总需求 已完成需求 需求完成率 人均每月完成需求 总问题数 已修复问题 每需求Bug数量 Bug修复率 测试用例 平均每个需求用例。

具体情况，可结合自己团队在YesDev协同工具的使用、记录和统计数据进行汇总和统计。

层层剖析研发核心交付指标（结合YesDev协同工具）

项目是一个动态的集合，需要指定角色人员在既定的时间范围内完成一系列具体的目标需求。

因此，将需求交付作为研发核心交付指标，有利于在项目过程中，对于项目里程碑、开发计划表、项目甘特图等，进行过程的进度控制和风险识别。

通过项目的概览，可以随时查看项目最新的整体进度和风险。

YesDev项目概览

在项目启动前，可以通过项目的里程碑和排期表，分别汇总项目的计划。

YesDev项目排期表

如果需要细致到需求维度，则可以使用项目甘特图，可以从需求维度和人员维度分别进行自动的汇总和统计。

YesDev项目甘特图

在项目进行过程中，可以使用项目燃尽图，了解每天项目的实际进度和计划进度之间的落差和项目延期风险。

YesDev项目燃尽图

如果需要进行每日站会，则可以使用敏捷任务看板。

当你作为项目经理或技术负责人，需要每天、每周、每月或不定时汇总项目进度时，则可以使用自动生成和汇总的项目汇报邮件，还能支持和上一次邮件发送的内容进行增量对比。

如果你需要获取项目WBS工作分解结构，以梳理项目的层层结构，可以查看项目的脑图。它会以项目-需求-任务的层级结构进行自动汇总和展开，并以脑图的方式呈现，还可以放大缩小和拖动。很直观、很形象。

部门岗位SOP（结合YesDev协同工具）

有了过往的历史交付指标数据，那么接下来，制定2023年的工作计划和目标，并进行拆解和对应的安排就很简单了。

例如，假设2022年团队的每月人均完成需求是：5个需求/月/每人。

那么，2023年的研发个人目标则是：交付效率提升，从原来人均每月完成5个需求提升到 8个需求/人/月。

至于具体制定多少，可以结合自身的情况进行制定。但请记住，每个月请汇总和统计、跟进研发人个以及团队整体的核心交付指标。坚持执行、坚持汇总、坚持总结和改进，相信到了半年后，将会看到不一样的协作氛围、不一样的研发团队！

即刻协作、轻松管理。加油！