近几年由于行业不行，经济下行，老板们对降本增效的要求甚嚣尘上，又或者被两三句“没有度量，就没有管理”蛊惑带动，基本稍稍有个三四百人的研发团队的中型互联网软件研发团队，都开始做软件研发效能度量的事儿，但是大部分的团队都没有正视度量过程中的各类问题：需求颗粒度导致的吞吐、交付周期不可看、一线“码农”资源对度量的抵触、数据采集的准确性…………所以想写个系列文章跟大家吐吐槽，也尝试给出一些视角去解决这些问题，能从大家这里吸收一些东西就更好了
第一唠 需求颗粒度的影响
做过效能度量的同学，相信对以下的几个名词不会陌生……
各公司当前对效能度量的方式基本上大同小异，需求的平均吞吐，平均交付周期，缺陷的密度、工程能力的搭建能力等等，其中效能度量的最大比重就在 “需求的平均吞吐，平均交付周期”，但由于无法有效的将所有需求颗粒度拉齐，所以即使数据采集准确，但是数据也存在不可看风险。
举例：X 业务团队本周提出一个业务场景优化，该业务场景仅需要两个研发处理两天，下周又提了个业务场景优化，该业务场景就需要十个研发处理一个礼拜，这样需求是一个，但是具体研发在其中的交付输出不在一个数量级上，但是当前各公司的效能度量均或主动，或被动的忽视了这个影响，对整个效能度量在业务部门或者管理层的信任理解层面是个巨大伤害。提到效能，大家总是把视野都放在研发链路的工程优化上，但是本质上，广义的效能表达应该是用相对短的时间产出高质量的尽可能高的业务价值……
产研效能 = (初始需求价值 * 代码质量) / (流程成本+研发工具之恶成本） 可能的解决方案——
初窥门径：代码行数 五到十年前的火热的研发效能度量角度，简单来说就是研发敲代码的行数，自以为是的老板们强行将研发的脑力劳动变成了流水线上的计件工人，当然了我们这些聪明的牛马们，下有对策：循环、注释、CV结构……猫鼠游戏下，两败俱伤……
小有所成：代码当量？平均颗粒度？ 代码当量是近两年由一个专业做软件度量的公司输出的概念，也是一图流
将初级可能被钻空子的一些复制，无效的循环等缺口堵上了，但是换汤不换药，一旦兄弟们掌握了方法，一样可以愉快的通过分支管理，MR 管理进行自我满足的当量升华～～～～
而平均颗粒度是我当前的探索尝试的一个方向，基于研发同学对需求交付工时的汇总，每个需求各个工种对这个需求的工时投入类和，再去算平均，就能大概测算出这个团队在相应周期内完成需求的平均颗粒度，再对各类效能数据做加权，可惜容易陷入信任陷阱，boss Question1：你确定研发填写的工时是对的？另外这种方法当一个团队真的效能提升了（交付速度、能力），反而比较难客观体现提升，因为你做的快了，自然工时就短了～
可能算是登堂入室？：需求点数——需要慎重
形而上的炒敏捷项目的冷饭，通过产品以及一线团队的感性上的预估，先树立一个标准的 1 点的需求，后续在评审其他需求时，给出一个更加感性的需求点数的数量，咋说呢，你说他合理吧也合理，老外很多团队这么衡量的，人不质疑大家的客观程度呀，但是你说他不合理吧，就是臭狗屎～～～
最后说下更多的公司为何会忽视这个问题，因为大家普遍认为，当将需求的时间维度拉长，各团队进入的需求的颗粒度基本是正态分布的，所以才会说可以分季度、分半年的去观察，但是真实情况是很难，这种场景下仅适用于本团队的效能观察，而不适用于跨团队的效能比较，至于效能比较就是另外个话题了，今天先唠到这，心累了，大家有建议或者想法欢迎多交流下～～～～
