导读：衡量技术团队的效能，是不是只需摆出一堆数字方针就行？对交给价值的定义，一般有哪些误区？好的量化方针，必定会带来好的作用吗？本文从定义、衡量交给价值、研发本钱、交给时长以及细化方针四个方面，共享怎样量化效能。
一 背景
项目处理的理论有许多，但大多是从理念和方法论的视点启航。当在一个团队推行项目处理的某种实践的时分，难免被挑战的一个问题：“怎样衡量技术团队的效能”。所以不得不企图去把逻辑题转成数学题，用数字方针去证明一些“不证自明”的方法论。
但假设我们只是摆出一些方针，不可避免地会堕入“上有方针、下有对策”的循环（只需不加其他束缚，数字还不是想怎样优化怎样优化）。我们也应该能看到这些数字反面，需求坚持的一些原则，和需求遵循的一些硬性标准。
假定方针是进步技术团队的效能，会得到如下OKR（Objectives and Key Results，方针与要害作用法）：
O：
进步技术团队的效能
KR：
增加总的价值交给率和交给质量
增加单位研发本钱的平均交给价值
下降单位价值的平均交给时长
本篇偏重点在怎样量化，而不是怎样进步。所以接下来继续分解，我们要做的作业就是：
定义、衡量交给价值
定义、衡量研发本钱
定义、衡量交给时长
细化方针
二 怎样定义交给价值？
1 这里或许会存在两个误区
误区1：交给的价值就是产出的方案、代码的数量和质量
这样衡量交给价值，就很少有人愿意制作公共设施了（因为质量好不好很难量化，制作公共设施初期的耗时往往显着大于直接结束业务需求），也很少有人愿意运用公共设施（因为用别人的，不如自己建，还能拿个作用）。而关于技术团队，长时间发明价值的才干，离不开公共设施的完备和对公共设施的运用。
误区2：交给的价值就是业务KPI中方针的增量
有许多功用并不带来直接的增量，或许比较难以衡量，但或许带来公司的比赛壁垒，如产品的体验。这样衡量交给价值，带来的问题就是，大家都只关注短平快的增量功用（比方营销），毕竟产品的比赛力下降。
2 我现在的答案：交给价值是需求反面的客户价值
不完美是技术方案、代码的数量和质量，也不完美是KPI方针的增量。交给价值就是按照用户的需求，对用户供给的整个产品、服务的数量和质量。这个定义几乎是不证自明的，但是把交给价值定义为客户价值，会不会让这件作业愈加凌乱，变得愈加不或许量化？这就需求我们改变一下思路，经过按照优先级加权的需求的作业量来衡量。
按照优先级加权的需求的作业量代表着客户价值，这里做一些根本假定（假定不成立的场景可以作为另外的问题处理）。
假定1：技术的上游（一般是业务、产品）关于客户价值的判别是根本准确的
我们知道业务是会试错的，给业务小本钱试错的机遇、在业务试错的进程中堆积一些通用的产品技术才干，往往不是部分最优，但是全局最优。
假定2：技术的上游会按照客户价值推扮演优先级然后给技术提需求
假定3：技术的上游提给技术的需求是充分的（不存在业务产品人员装备的缺失而导致需求质量数量缺少的情况）
依据这几个假定，上游提出的需求或许就很大程度上代表着客户价值，研发在非功用性需求方面对上游的需求做补偿。
三 衡量交给价值
交给价值有个十分主观但有用的衡量方法，是上游（一般是产品业务）的满意度。反面的逻辑是，交给价值（反面代表的客户价值）往往很难量化，而产品业务的满意度，体现了技术与业务是否很好的协同，也反映了技术是否很好的交给价值。
需求的作业量不应该经过人日来评价，因为不同团队，关于相同功用点的开发时长是不同的。需求的作业量的单位应该是分解到最终的功用点数量。再细化一些，关于服务端是领域模型、领域服务数量，流程分支节点数量，关于前端、交互我不是很了解，但偏展示层或许更多的是页面区块、交互流程、行为点的数量。这些已经有量化的或许性了。
四 定义、衡量研发本钱
研发本钱，在一般的工程效能里面有时分会被简略的了解为人日，单纯的交给人日的衡量，其实比较简略，整个团队的人数*作业天数。但简略被流程规划者忽视的是，站在企业本钱的视角，交给人日，或许还要按照开发人员的收入进行加权。从这个视点来看，技术团队效能里面的研发本钱，准确的来说就是公司关于研发的金钱投入，包括购买服务器、云服务、训练、行政投入。
这部分关于进步效能的启示是：
哪些功用自研、哪些功用靠购买，有时分真的得算一笔帐。
软件开发是一个边际本钱递减的行业，怎样让功用更简略的得到复用，或许是对效能进步最有协助的部分之一（复用50个人日的功用模块，就几乎等于省了50人日的研发本钱。当然也或许存在复用及后期保护的本钱大于新建本钱的情况，需求有杰出的规划去躲避）。
五 定义交给时长
我自己之前从前堕入一个误区，认为交给时长就是从开始开发，到结束上线，这个就是交给时长。但是回到客户价值这个维度来思考，技术团队交给时长（这个时分或许说产研团队更适宜一些），应该是从业务的一个想法，到验证、立项、结束发布、灰度，到毕竟用户可以真正运用的时长。
所以单位价值的平均交给时长，就变成了以下公式：
需求的交给价值量/需求功用真正被用户运用的时间-业务提出该功用、产品立项的时间
六 怎样衡量交给时长
衡量交给时长其实也比较简略，记录下业务提出该功用的时间以及功用开发的时间。难点或许是整个价值流交给进程中细化的方针，而细化的方针更能协助我们发现问题。所以我们可以从一般项目的生命周期来看，哪些节点的时长会影响我们的交给：
需求立项到鉴定的时长
需求鉴定到技术方案鉴定的时长（假设项目很大或许会有多个层次的规划方案）
技术方案鉴定结束到开发结束自测的时长
自测的时长
多端联调的时长
检验的时长
bug验证的时长，bug的数量（reopen可以数量+1）
环境布置等候的时长
代码吞并的时长（主干发布的情况下）
回归的时长
发布的时长
灰度的时长
这部分关于进步效能简略忽视或有启示的点是：
需求的拆分红根本的功用闭环进行迭代（以不引入或少引入检验的重复回归为标准），或许能比较有用的下降需求价值量的平均交给时长。
自测充分、削减bug数量，毕竟削减联调、检验回归的次数和时长，在必定的单测覆盖率要求曾经，是收益大于本钱的。
代码吞并有时分抵触处理很费事，会导致一次布置的时间很长，且代码吞并引入了更多次的检验回归作业（这或许是某些BU往主干开发分支发布走的原因之一）。所以依据业务的了解，进行运用的拆分，削减单个运用的并发数量，也可以进步研发效能。
在缺少有用的项目处理的情况下，资源的相互等候或许是项目延期的一大要素，有时分某端开发完了，另一端资源没到位，一直不能联调提测。项目处理的同学关于资源现在的分工和瓶颈应该给上游及时的反馈。
简略堕入误区的点是：
技术方案（架构、具体规划）的鉴定既然是很大的一块耗时，是不是可以直接写代码，少写方案。我了解在技术方案写不熟练的情况下，写技术方案的确比较耗时。但是技术方案体现的是剖析规划的进程和作用，这部分假设不写出来，增加的是大量的沟通本钱。而剖析规划就算不写出来，这部分作业量在编写代码的时分也是没办法省掉掉的，只是变成了在大脑中进行（或许在大脑中真的不如在纸上写出来来的快和清晰，真的省掉了规划，毕竟就会成为技术负债）。我个人感觉关于多大的需求需求技术方案鉴定的比较好的实践，是以Code Review能否不依据技术方案直接阅览代码为准。
七 最终
但我仍然认为，好的量化的方针往往是好的作用的必要不充分条件。简略粗暴的优化某项方针往往会因为两个问题而使得毕竟的作用各走各路：
某项方针变好，带来的是其他方针的下降，部分最优并非全局最优（如：撤销技术方案的编写和鉴定，形成的是编码时间或许后期保护时间的增加）。
效能是多个变量一起作用的作用，缺少理论基础和方法论的情况下，很或许在短期优化方针的时分，疏忽了长时间的团队生长、体系才干堆积等要素；或是忽视了业务方满意度等难以量化的要素。
所以，效能的优化，不止应该有方针，还应该有路径，而路径往往是最难的部分。
一 背景
项目处理的理论有许多，但大多是从理念和方法论的视点启航。当在一个团队推行项目处理的某种实践的时分，难免被挑战的一个问题：“怎样衡量技术团队的效能”。所以不得不企图去把逻辑题转成数学题，用数字方针去证明一些“不证自明”的方法论。
但假设我们只是摆出一些方针，不可避免地会堕入“上有方针、下有对策”的循环（只需不加其他束缚，数字还不是想怎样优化怎样优化）。我们也应该能看到这些数字反面，需求坚持的一些原则，和需求遵循的一些硬性标准。
假定方针是进步技术团队的效能，会得到如下OKR（Objectives and Key Results，方针与要害作用法）：
O：
进步技术团队的效能
KR：
增加总的价值交给率和交给质量
增加单位研发本钱的平均交给价值
下降单位价值的平均交给时长
本篇偏重点在怎样量化，而不是怎样进步。所以接下来继续分解，我们要做的作业就是：
定义、衡量交给价值
定义、衡量研发本钱
定义、衡量交给时长
细化方针
二 怎样定义交给价值？
1 这里或许会存在两个误区
误区1：交给的价值就是产出的方案、代码的数量和质量
这样衡量交给价值，就很少有人愿意制作公共设施了（因为质量好不好很难量化，制作公共设施初期的耗时往往显着大于直接结束业务需求），也很少有人愿意运用公共设施（因为用别人的，不如自己建，还能拿个作用）。而关于技术团队，长时间发明价值的才干，离不开公共设施的完备和对公共设施的运用。
误区2：交给的价值就是业务KPI中方针的增量
有许多功用并不带来直接的增量，或许比较难以衡量，但或许带来公司的比赛壁垒，如产品的体验。这样衡量交给价值，带来的问题就是，大家都只关注短平快的增量功用（比方营销），毕竟产品的比赛力下降。
2 我现在的答案：交给价值是需求反面的客户价值
不完美是技术方案、代码的数量和质量，也不完美是KPI方针的增量。交给价值就是按照用户的需求，对用户供给的整个产品、服务的数量和质量。这个定义几乎是不证自明的，但是把交给价值定义为客户价值，会不会让这件作业愈加凌乱，变得愈加不或许量化？这就需求我们改变一下思路，经过按照优先级加权的需求的作业量来衡量。
按照优先级加权的需求的作业量代表着客户价值，这里做一些根本假定（假定不成立的场景可以作为另外的问题处理）。
假定1：技术的上游（一般是业务、产品）关于客户价值的判别是根本准确的
我们知道业务是会试错的，给业务小本钱试错的机遇、在业务试错的进程中堆积一些通用的产品技术才干，往往不是部分最优，但是全局最优。
假定2：技术的上游会按照客户价值推扮演优先级然后给技术提需求
假定3：技术的上游提给技术的需求是充分的（不存在业务产品人员装备的缺失而导致需求质量数量缺少的情况）
依据这几个假定，上游提出的需求或许就很大程度上代表着客户价值，研发在非功用性需求方面对上游的需求做补偿。
三 衡量交给价值
交给价值有个十分主观但有用的衡量方法，是上游（一般是产品业务）的满意度。反面的逻辑是，交给价值（反面代表的客户价值）往往很难量化，而产品业务的满意度，体现了技术与业务是否很好的协同，也反映了技术是否很好的交给价值。
需求的作业量不应该经过人日来评价，因为不同团队，关于相同功用点的开发时长是不同的。需求的作业量的单位应该是分解到最终的功用点数量。再细化一些，关于服务端是领域模型、领域服务数量，流程分支节点数量，关于前端、交互我不是很了解，但偏展示层或许更多的是页面区块、交互流程、行为点的数量。这些已经有量化的或许性了。
四 定义、衡量研发本钱
研发本钱，在一般的工程效能里面有时分会被简略的了解为人日，单纯的交给人日的衡量，其实比较简略，整个团队的人数*作业天数。但简略被流程规划者忽视的是，站在企业本钱的视角，交给人日，或许还要按照开发人员的收入进行加权。从这个视点来看，技术团队效能里面的研发本钱，准确的来说就是公司关于研发的金钱投入，包括购买服务器、云服务、训练、行政投入。
这部分关于进步效能的启示是：
哪些功用自研、哪些功用靠购买，有时分真的得算一笔帐。
软件开发是一个边际本钱递减的行业，怎样让功用更简略的得到复用，或许是对效能进步最有协助的部分之一（复用50个人日的功用模块，就几乎等于省了50人日的研发本钱。当然也或许存在复用及后期保护的本钱大于新建本钱的情况，需求有杰出的规划去躲避）。
五 定义交给时长
我自己之前从前堕入一个误区，认为交给时长就是从开始开发，到结束上线，这个就是交给时长。但是回到客户价值这个维度来思考，技术团队交给时长（这个时分或许说产研团队更适宜一些），应该是从业务的一个想法，到验证、立项、结束发布、灰度，到毕竟用户可以真正运用的时长。
所以单位价值的平均交给时长，就变成了以下公式：
需求的交给价值量/需求功用真正被用户运用的时间-业务提出该功用、产品立项的时间
六 怎样衡量交给时长
衡量交给时长其实也比较简略，记录下业务提出该功用的时间以及功用开发的时间。难点或许是整个价值流交给进程中细化的方针，而细化的方针更能协助我们发现问题。所以我们可以从一般项目的生命周期来看，哪些节点的时长会影响我们的交给：
需求立项到鉴定的时长
需求鉴定到技术方案鉴定的时长（假设项目很大或许会有多个层次的规划方案）
技术方案鉴定结束到开发结束自测的时长
自测的时长
多端联调的时长
检验的时长
bug验证的时长，bug的数量（reopen可以数量+1）
环境布置等候的时长
代码吞并的时长（主干发布的情况下）
回归的时长
发布的时长
灰度的时长
这部分关于进步效能简略忽视或有启示的点是：
需求的拆分红根本的功用闭环进行迭代（以不引入或少引入检验的重复回归为标准），或许能比较有用的下降需求价值量的平均交给时长。
自测充分、削减bug数量，毕竟削减联调、检验回归的次数和时长，在必定的单测覆盖率要求曾经，是收益大于本钱的。
代码吞并有时分抵触处理很费事，会导致一次布置的时间很长，且代码吞并引入了更多次的检验回归作业（这或许是某些BU往主干开发分支发布走的原因之一）。所以依据业务的了解，进行运用的拆分，削减单个运用的并发数量，也可以进步研发效能。
在缺少有用的项目处理的情况下，资源的相互等候或许是项目延期的一大要素，有时分某端开发完了，另一端资源没到位，一直不能联调提测。项目处理的同学关于资源现在的分工和瓶颈应该给上游及时的反馈。
简略堕入误区的点是：
技术方案（架构、具体规划）的鉴定既然是很大的一块耗时，是不是可以直接写代码，少写方案。我了解在技术方案写不熟练的情况下，写技术方案的确比较耗时。但是技术方案体现的是剖析规划的进程和作用，这部分假设不写出来，增加的是大量的沟通本钱。而剖析规划就算不写出来，这部分作业量在编写代码的时分也是没办法省掉掉的，只是变成了在大脑中进行（或许在大脑中真的不如在纸上写出来来的快和清晰，真的省掉了规划，毕竟就会成为技术负债）。我个人感觉关于多大的需求需求技术方案鉴定的比较好的实践，是以Code Review能否不依据技术方案直接阅览代码为准。
七 最终
但我仍然认为，好的量化的方针往往是好的作用的必要不充分条件。简略粗暴的优化某项方针往往会因为两个问题而使得毕竟的作用各走各路：
某项方针变好，带来的是其他方针的下降，部分最优并非全局最优（如：撤销技术方案的编写和鉴定，形成的是编码时间或许后期保护时间的增加）。
效能是多个变量一起作用的作用，缺少理论基础和方法论的情况下，很或许在短期优化方针的时分，疏忽了长时间的团队生长、体系才干堆积等要素；或是忽视了业务方满意度等难以量化的要素。
所以，效能的优化，不止应该有方针，还应该有路径，而路径往往是最难的部分。
