对于软件研发过程来说，非常重要的课题之一就是如何管理软件研发效能。对于大公司来说，人员臃肿、效率不高是非常普遍的管理问题，对于创业者来说，软件研发效能就更是生死指标了，因为创业本身就是在和时间赛跑，产品的发布每领先或者落后市场一天，产品的竞争格局都很可能会发生翻天覆地的变化，而产品竞争失败对于大公司而言可能会导致项目团队解散，人员重新分配或者裁员，对于小公司来说就可能会直接死亡关闭了，所以了解软件研发效能，对于不管是组织或者是公司而言都非常重要。
而在了解软件研发效能、以及能够度量当前组织或者企业的效能指标之后，我们还需要进行有针对性的管理，在一般的刻板印象中，管理应该是管理层需要关注的事情，员工做好被分配的任务就好了，但随着时代的发展，这样的管理方式越来越落后了。中智咨询针对新生代员工离职员工做了统计发现，新生代员工的离职原因和企业统计的离职原因有很大的差别，比如企业端认为员工离职主要是因为薪资和外部机会，但从新生代员工视角看到的离职原因中，除了薪资之外，更多的是因为不认可公司发展前景和不认同企业文化/价值观，也就是说管理除了关注指标，从上至下的进行模式、流程变革之外，更应该关注员工的需求，用领导力驱动员工自我管理，这样才能更有效的激发员工的动力，从而带来组织企业效能的提升。
那么接下来我们结合以上了解并进行有效管理软件研发效能的需求，一起来看看软件研发效能管理的构成、以及如何管理软件研发效能。
软件研发效能管理的构成
软件研发效能管理的目的和定义
软件研发效能管理的第一部分，我们需要先定义一下管理软件研发效能的目的和定义。
在产品管理中，我们当然都希望研发过程可以越快越好，这样就能够更快地进行市场验证，确认产品功能和市场需求是否符合预期，但是软件研发不是机械式的生产流水线，而是人为创造的过程，只追求快那质量就很难保证，同时想要一个团队无止尽地提高效能上限是不现实的，因此，我们管理软件研发效能的目的应该是以下四个方面：
- 通过软件研发效能的管理了解团队的产出下限，以便于在软件研发排期时，实际开发进行前，就能够比较清晰的了解我们的研发计划是否合理，能否按期交付产品。
- 期望团队能够尽可能稳定的保持产出效率，以便于在软件研发进行时，能够更好的了解研发进度，同时如果有交付风险，也能够更加及时的发现并提前解决问题。
- 期望团队能够高质量的完成交付，而不是为了时间牺牲了产品交付质量，那是得不偿失的。
- 除了保持产出效率和高质量交付之外，我们也希望能随着团队合作的越来越默契、个人技能的不断成长等因素而提高团队原有的研发效能，在未来能够承接更复杂更有挑战的任务。
看完管理软件研发效能的目的之后，我们就能比较清晰的了解到软件研发效能的定义了，软件研发效能就是指在一个长期发展的软件研发团队中，平均完成一次软件研发所花费的时间、软件研发的过程是否是可持续的、所能保证的交付质量以及团队的成长性。
接下来我们再来看看哪些角色应该关注软件研发效能管理。
软件研发效能管理的对象和关注者
从软件研发效能管理的定义可以知道，管理的对象是软件研发的团队，包括团队的项目经理（Project Manager）、产品负责人（Product Owner）、产品经理（Product Manager）、敏捷教练（Scrum Master）、业务分析（Business Analyst）、开发（Developer）、测试（Quality Assurance）、运维（DevOps，Development And Operations）、Support等等。那么谁需要关注软件研发效能的管理呢？
一提到管理，我们往往会认为这是管理者才需要关注的事情，即是由管理层统计观察指标，并进行流程和人员管理变革。对于软件研发效能，更关心的人应该是团队的项目经理（Project Manager）、产品负责人（Product Owner）、产品经理（Product Manager）、敏捷教练（Scrum Master）以及团队的上级领导者等等，但实际上团队的每个参与者都应该关注软件研发效能，这样大家才能知道团队整体的运转状况和自己在当前团队中的状态，我们的通常的管理都是从上至下的，但从下至上的自我管理和驱动，才是更有创造力的团队，这也就需要我们每个人都能主动去了解团队情况，并主动寻求提升。
接下来我们看看如何定义软件研发效能的度量单位和指标，以便于我们衡量评价软件研发效能。
软件研发效能的度量单位和指标
在任何管理之前，我们都需要先能够定义清楚管理的指标，而在指标定义的同时，还需要有指标的度量单位，这样才能统一不同团队的度量标准。
在软件研发管理中，我们一般都会使用“人天”来作为软件研发时间预估的单位，一个“人天”就是指一个人开发一天的工作量。比如说假设我们要开发一个电商平台商品支付的产品功能，在需求分析清楚之后，我们预估需要100个人天来开发，50个人天来进行测试，那按照一个人来完成所有的开发测试工作，就需要150天才能完成软件研发交付，但实际我们肯定不是让一个人独立来完成这么长时间的工作，我们可能会以4个开发，2个测试作为一个团队来共同完成这个产品功能，那时间就缩短到25天开发，25天测试，总计50天，项目周期缩短了⅔。因此，我们通常可以使用人天在实际研发之前预估研发周期，也可以在研发周期进行中来判断当前的产出效率是否符合预期。
基于人天工作量的预估，我们在敏捷实践中，可以通过图表追踪的方式查看研发的进度，比如Jira就提供了燃尽图、燃起图、Sprint报告、速度图、累积流量图、版本报告、Epic报告、控制图、Epic燃耗图等多种图标的形式。
当然单纯用人天作为软件研发效能指标的度量单位也不是完全精准的，原因有以下几个方面：
- 团队人员能力的不均衡。我们都知道每个人的能力都是有差异的，因此单纯以标准人天的指标来衡量人员的产出是不准确的，比如还是开发商品支付的功能，甲同学过去做过类似的功能，那需要50人天来单独完成开发就足够了，而乙同学完全是一个新手，那可能需要150人天来单独完成开发，因此使用人天进行预估本身就会因为人员差异而出现结果偏差。
- 交付质量的差异。当我们只是按照人天来评价软件研发效能，那很有可能就会出现大家为了追求快而牺牲交付质量的问题，因为人天只能说明完成任务的耗时，却没有评价完成任务的质量，而为了速度丢掉了质量，这就和我们设立指标进行软件研发管理的目的背道而驰了。
- 预估本身就是不准确。当我们在预估工作时间时，是期望尽可能详尽的了解整个工作内容的细节，但实际在研发实施中，往往会遇到没有预料到或者与预计差别很大的事情，这都会导致预估与实际的偏差。
由于度量单位的不精准，我们就没法单纯设立一个指标来管理研发效能，需要进一步拆解，在不同的软件研发阶段，可以引入更多的指标来辅助我们客观衡量软件研发效能。我们可以按照需求管理、开发管理、质量管理、发布管理四个阶段来确认不同的指标。
需求管理指标
需求管理是指软件研发和需求方进行软件需求的沟通确认，并最终确认交付周期的过程管理，可以有以下指标：
- 需求交付周期：是指需求提出到软件需求发布上线的平均时间周期。我们可以用它来衡量团队对于业务需求的响应速度，交付周期对于业务而言当然越短越好，但也要考虑需求交付的完整性，从而进行灵活调整。
- 需求吞吐量：是指单位时间周期内交付的需求数量。我们可以用它来衡量团队的需求交付产出效率，但需要考虑需求的大小。
开发管理指标
开发管理是指开发进行软件研发的过程管理，可以有以下指标：
- 开发周期时间：是指从开发团队接收并确认需求细节后，进行实际开发到可以上线的平均时间周期。我们可以用它来衡量团队的开发速度。
质量管理指标
质量管理是指测试进行软件功能测试验收的过程管理，一般包括技术测试、业务验收测试等，主要是为了保障软件交付质量，可以有以下指标：
- 测试周期时间：是指测试人员从测试准备到测试完成可以上线的平均时间周期。我们可以用它来衡量团队的测试速度，当然测试速度越快那交付周期就可以被压缩，但测试速度绝不能以牺牲测试质量来提高，也就是说必须在保证测试功能充分的前提下，度量测试周期时间才是有意义的。
- 需求缺陷量：是指单个需求的平均缺陷数量。我们可以用它来衡量团队的开发质量情况，一般需求缺陷量越低，说明开发质量越好。
- 缺陷修复时间：是指从缺陷提出到开发修复完成并经过测试重新验证通过后的平均时间。我们可以用它来衡量团队质量修复速度，这里需要强调的是必须是经过测试验证通过才能算一个缺陷的修复完成，而不是开发修复完成的时间。
发布管理指标
发布管理是指需求开发测试完成，进行上线发布的过程管理，DevOps可以帮助我们有效的提升发布效率，可以有以下指标：
- 发布准备时间：是指从代码封板到上线发布准备工作完成所需要的平均时间，包括了所有系统和流程所耗费的准备时间。我们可以用它来衡量团队的发布准备效率。
- 发布实施时间：是指上线发布的实际操作实施时间。我们可以用它来衡量实施发布的速度，这个指标也可以用于衡量软件发布对于用户的影响程度。
- 发布频率：是指平均发布的时间周期。这个指标并不是越高越好，因为发布事件本身也会对软件交付过程产生额外负担，需要综合团队情况进行考量。
如何管理软件研发效能
看完软件研发效能管理的构成，即软件研发效能管理的目的、定义、对象、关注者、度量单位和指标之后，我们再来看看最后一块内容，如何管理软件研发效能。这里分为三部分：通过软件研发模式变革提升软件研发效能、通过领导力驱动软件研发效能提升和避免落入指标管理的陷阱。
通过软件研发模式变革提升软件研发效能
传统软件研发管理模式
在传统的软件研发管理中，我们可能会采用瀑布式的研发模式，即按照需求、设计、开发、测试、发布、维护流程分步式的进行软件研发，每个阶段都要确认清楚上个阶段的信息之后才能开始，比如从需求进入到设计，必须要保证需求内容清晰完整，需求文档罗列每个需求细节，这样才能进入设计阶段，而后续的设计、开发、测试、发布、维护也都是参照前一个阶段的交付物接手完成，这种研发模式的特点是边界清晰，方案确定，但是并不适应当前快节奏的产品研发环境，具体体现在以下几个方面：
- 不能很好的适应客户需求不断变化的节奏，当前客观大环境竞争越发激烈，就要求组织或者企业能够快速应对环境的变化，瀑布式的研发模式更强调阶段的确定性，一旦进入到研发流程中，需要当整个流程结束之后才能看到结果，到那个时候再想改变就可能会废弃掉之前的努力。
- 没有合理的循环反馈机制，而是像击鼓传花式的只关注各自阶段的接收传递，缺乏整体的协作反馈。
- 缺乏创造力，瀑布式的研发模式参与者不能很好的关注整体的研发过程，了解需求的来龙去脉，只能关注自己所在阶段的事情，也就不能很好的激发个人创造力。
采用这种研发模式的团队也可以使用我们上面罗列的软件研发效能指标进行追踪管理，并且按照团队的现状进行优化改善，例如关注各个阶段的周期时间，从而提升整体的开发效率，但是局部的优化解决不了整体的模式落后，对于软件研发效能的管理提升来说，也是舍本逐末。对比传统的软件研发流程，敏捷软件研发更能适应新时代的发展需要。
敏捷软件研发管理模式
敏捷是一个术语，强调增量交付、团队协作、持续规划和持续学习。在很多组织企业中可能有一种误解，认为敏捷就是快，这是不准确的，敏捷是期望建立一个文化和环境，通过协作产出解决方案，不断规划和学习，以及更频繁地交付高质量的软件。
敏捷有很多的实践方式，比如我们可以使用Scrum 作为团队用来管理工作的框架，通过产品需求规划、冲刺迭代会议、每日站会、任务看板、开关卡、showcase、冲刺回顾会等敏捷实践活动来进行迭代研发。敏捷的研发管理并不是一成不变的，它需要根据所在团队的情况进行自适应的调整，这也是敏捷迭代不断学习、不断适应变化、不断改进的特点，也符合敏捷软件开发宣言所倡导的价值观：
- 个体与交互优于过程和工具
- 可用的软件优于完备的文档
- 客户协作优于合同谈判
- 响应变化优于遵循计划
对于敏捷研发的效能管理，我们一样可以采用软件研发效能指标进行度量，发现新的问题并进行不断的协作优化，这也契合敏捷响应变化，不断学习，不断进化的特点。
另外需要注意敏捷的是迭代协作的，因此很多的周期时间指标会更加紧凑一些，或者说在并发进行，在指标管理和团队优化中，就更需要识别团队整体的研发优化方法，保持团队协作，共同进步。
通过领导力驱动软件研发效能提升
通过软件研发模式变革提升软件研发效能是针对指标的模式、流程管理的变革，但最后我们格外需要注意的是指标管理只是为了保证软件交付的下限，而不是上限，我们希望软件研发过程可以像机械式的交付流水线一样产出可控，我们更希望软件研发从长远来看能够不断成长，变得更有效率，而这就要考虑人的创造因素了。让产品研发的员工更有参与感才能真正让团队进步，让员工产生内在动力，《驱动力》一书中描述了影响员工内在动力的三个因素：
- 自主：人们需要在做什么、什么时候做、和谁做以及如何做上能够自主。控制带来的是服从，自主带来的则是投入。我们需要让员工有空间可以自己做主去决定一些事情。
- 专精：把想做的事情做得越来越好。专精不仅不认为我们的能力有限，还认为能力能够无限提高；专精需要努力、坚毅以及刻意练习；做到极致不可能完全实现，但正因如此，专精才会令人着迷并契而不舍。我们需要让员工有足够的专精去做事情。
- 目的：超越自身的渴望。那些由个人内心深处驱动的人，会把他们的愿望系于比自己更宏大的事业上。我们需要提供长远的目的，让员工可以自我驱动。
为了激发员工的内在动力，让员工能够产生自主、专精和目的，企业或者组织需要用领导力来驱动，而不是教条式的管理，领导力驱动同样也由三个方面组成：
- 使命：成立的初衷，要解决什么问题，为谁而解决问题，组织或者企业存在和发展的目的和意义是什么。如果没有使命，大家只是在一起做事，而不是做一项事业。
- 愿景：希望发展成什么，或者说未来的梦想是什么。我们需要建立一项足够务实又足够强大的愿景，来点亮我们的方向。
- 价值观：所有人或者大多数人一致赞同的关于组织或者企业意义的终极判断。这也是我们一致行动、共同努力的准绳。
乔布斯曾经说过：“优秀的人才可以自我管理，一旦他们了解到要做什么事情，他们自己就会去做，而不需要被别人管理”，同理，用领导力驱动员工产生参与感和内部动力，是软件研发效能管理的艺术，也才能真正实现突破软件研发效能瓶颈的终极目标。
避免落入指标管理的陷阱
在软件研发效能管理中，我们需要格外注意的是指标不是目标，追求指标达成的管理反而会弄巧成拙。古德哈特定律表明：“如果一项指标变成了目标，它将不再是个好指标”，就是说我们不能把指标当作目标，那就失去了指定目标的初衷，可以一起看两个例子：
英国殖民统治印度时期，英国政府担心印度德里毒眼镜蛇的数量过多，因此提供政策为杀死眼镜蛇的人提供赏金，开始确实起到了作用，大量野生的眼镜蛇被捕杀，但当人们发现捕杀眼镜蛇的收益要高于养殖眼镜蛇时，反而开始人工养殖眼镜蛇，英国政府很快发现了这件事情并取消了政策，眼镜蛇养殖户无利可图于是把眼镜蛇放生野外，反而导致了眼镜蛇数量的增加。
再比如疫情之下航空公司的业务受到了非常大的影响，我们提供了政策如果上座率不满75%就补贴航空公司，一方面帮助航空公司渡过经济难关，另一方面也是为了保障旅客航空出行的需要，以免航空公司因为上座率太低而取消航班，政策出发点是好的，但航空公司却借此提高了机票价格，当上座率较低时可以靠补贴维持，当上座率高时收入反而增加了，对于旅客来说负担反而变得更重了，补贴的指标变相抑制了航空业恢复的速度。
我们在制定软件研发效能指标和执行管理过程中，一方面要利用好指标去帮助我们衡量团队产出，提前识别异常情况，逐步提升团队研发效能，另一方面也要避免将指标当作目标，那样就本末倒置了，不仅不能客观反映情况，而且还会增加软件研发成本，降低实际研发效能。
总结
本文就软件研发效能管理论述了软件研发效能管理的构成和如何管理软件研发效能，我们进行软件研发效能管理的初衷是为了让软件研发的时间效率更高，软件研发的过程可持续，交付质量有保障并且团队的研发能力是可以随着时间不断进步的，这就需要我们能够度量清楚软件研发效能的指标，进行有的放矢的变革改进，但常规的研发模式、流程的变革可以只能帮助我们提升软件研发效能的下限，想要突破上限，就需要管理的艺术-通过领导力驱动软件研发效能提升，这也对管理者提出了更高的要求：真正思考团队和企业的未来，并身体力行的进行实践变革，带动团队和企业成员不断进步。
最后需要强调的是，领导力驱动不是画大饼，更不能是空中楼阁，设定的使命、愿景、价值观必须是切合实际，可以实际达成的，这样才能让团队有信心能够完成，同时在不同的阶段，也需要根据实际情况进行灵活的调整。贪图大而全，遥不可及的目标，这样变形的领导力驱动不仅不能激发员工的动力，反而会适得其反，让员工更没有参与感。