来啦，请坐。

我是老杨，这是我的《数字化研发管理》书籍的前奏，我带你稍微见识下其魅力。

如果你有强化管理能力，量化技术产出，提升技术效能，打造技术团队等需求，那么这套课程会为你揭开技术管理的神秘面纱，可以让“妈妈再也不用担心你的工作了”。

这是《数字化技术管理的方法和实践》第十讲，衡量技术价值最关键的2个指标，技术支持业务的效率和质量。

一句话解释下：技术做的好，最直接的表现就是业务支持的好，如果技术和团队的能力是内功的话，那么对业务的支持就是外在武功招式。而衡量技术支持业务的优劣最关键的指标就2个：效率和质量，技术完成产品、工具、服务、平台的效率几何，技术交付的产品、工具、服务、平台质量几何。

效率表征技术团队出活是不是够快，质量表征技术团队出活是不是够好，两者缺一不可，少哪个都差点意思。

下面直接进入效率的讲解，天下武功唯快不破，对于互联网业务而言更加如此，什么小步快破，什么迭代，什么MVP，强调的都是快，也就是效率，那么效率怎么去计算呢？我想是时候上公式了。

技术支持业务架构图

效率是技术团队一周完成技术需求数除以技术团队一周接收技术需求数，接收技术需求的数量就是技术从产品侧、业务侧接收到的任务经过技术拆解成技术需求的个数；完成技术需求的数量就是技术在一周内完成技术需求的个数，注意此处需求的单位必须都是经过技术拆解的技术需求，否则没办法统一度量衡，那么衡量优劣就更加无从谈起了。

细心的同学会问：“老杨，这个效率似乎和研发容量有一定的关系，研发容量是一个客观值，它决定技术团队能够完成多少任务”。

的确如此，你说的非常对，技术管理者需要做的恰恰是把研发容量发挥到百分百，这样才能够保证技术团队都是在满负荷运转的，也只有如此效率才会达到最大，能够做到这步田地也会很少出现挑战技术团队效率低能力差的事情了，因为技术团队已经达到极限了，如果还要更快，那么只能加人了。

还有一点，不难看出，效率还可以反向表征出产品产出的需求个数是不是能够满足技术的容量，如果效率连续一个月都是100%，那么可以确认产品漏过来的需求数是不够的，产品同学需要加把劲儿啦，当然技术同学也必须把多余的时间投入到技术创新、技术稳定性等操作上面，别闲着。

好，那下面进入质量的讲解了。很显然只是快是远远不够的，如果错误频出，对于用户的伤害是非常大的，进而也会伤害到公司的利益，所以质量也要抓起来哦。

细心的同学会问：“质量我当然也想抓起来，但是效率和质量不可兼得啊，追求了效率自然就会损失质量，追求了质量也自然会损失效率”。

NoNoNo，这个，我真的不敢苟同了，你可以去牺牲个数、美观性、便利性等，但是功能本身的质量、完整性这些是绝对不能够去牺牲的，一个半吊子功能扔到线上去，那真的太不负责任了，这一点一定要切记。

那么质量该怎么计算呢？直接上公式。

质量是技术团队一周线上bug数除以技术团队一周完成任务数。注意此处任务的单位是产品侧的任务，因为产品侧一般是按照功能去拆解任务的，以功能为维度去界定质量更加合理，总不能说某个接口质量如何如何吧，你说了别人也未必理解啊。提升质量的方法也很简单，从意识上每个人对自己交付出去的东西要足够的重视和负责；从技术上增加自动化手段，把80%的问题消灭在萌芽状态之中。

至此，技术价值的最关键指标：效率和质量，已经讲清楚了。

细心的同学会问：“怎么感觉这一讲有点凑数的意思，这么关键的事情，怎么讲的这么简单？”

其实呢，并不是凑数，恰恰相反，大道至简，越是简单的东西越是精髓的东西，我也是死了无数的脑细胞才总结出来如此简单的指标的，理解万岁吧少年。总而言之，对于技术而言，支持业务的效率和质量要不遗余力的去提升到最大。

好，欢迎持续关注，下次见啦。