如何用增长的思维做提效？

简介： 埋点作为记录用户行为的常规手段，伴随着前端技术的发展早已历经春秋，不过直到“增长黑客”系列理论出现，才真正让埋点分析变得内涵丰富且有章可循。

作者 | 金戟
来源 | 阿里技术公众号

埋点作为记录用户行为的常规手段，伴随着前端技术的发展早已历经春秋，不过直到“增长黑客”系列理论出现，才真正让埋点分析变得内涵丰富且有章可循。

与产品领域的“增长”类似，“提效”一直是研发领域里长盛不衰的主旋律。在软件研发过程中，伴随着项目开展，同样会以事件的形式记录下许多与代码库、流水线、任务相关的行为数据。这些数据的来源虽与页面埋点不尽相同，其实质用途却有许多可类比之处。然而当产品经理们纷纷开始通过埋点的实时数据争分夺秒调整市场营销策略时，研发团队的TL和PM们依然只能使用统计方法+汇总指标为主导的事后分析手段，在每个版本和迭代完成后对团队效能进行回顾和评估，并乐此不疲地谈论如何将迭代周期从一个月缩短到两周，从而获得“更快的反馈”。

本文将讨论一种尚未被实践过的方法论，即能否将“增长黑客”理论作用到研发过程的改进上，从而实现更可靠的定向效能优化？

一研发团队的北极星指标

在进行增长目标制定之前，团队往往需要先确定一项能够反映团队成功情况且易观测的“北极星指标”，譬如销售额、签单率、活跃用户数等等。对于研发团队来说，关键的指标主要是需求完成时长、功能缺陷率、用户满意度，诸如此类。以“需求完成时长”为例，这是一个相对客观且直接反映开发团队响应用户需求速度的指标，即一个需求从提出到最终交付可用，所需要经历的平均时间长度。

接下来我们定义一个相对理想的需求交付过程，并参考产品流量分析的“转化漏斗”结构表示出来：

相应的，将项目中的所有需求都添加进来，可以绘制出类似这样的“需求交付路径图”（示例，实际阶段划分应该更丰富）：

虽然略显粗糙，但通过这种展现方式我们确实能够追回不少在往常只统计结果数据的图表里丢失了的信息。譬如同样是两个花10天完成的需求，一个开发用了7天，另一个开发只用了1天，其余时间花在了等待测试上，它们的差异在交付路径图上就能被清晰的区分出来。

这样做的另几项好处包括：

即使一个需要还未最终交付，而是被阻滞在了某个环节、或者出现了返工，也能够在第一时间以异常流量的形式显著的展现在路径图上，从而及时引起TL和PM的关注。

不但能直观的看出总体的各阶段交付进展情况，也能从单个需求角度查看流经的每个节点，并找到其他情况类似的需求，便于分析它们的共性特征。
用于事后分析时，可做交付结果的反向追溯，譬如查阅未按时交付的需求流经此前各节点的比例。

基于以上参照，我们可以得出以研发需求价值转化的“效能黑客”模型（对应增长黑客的AARRR模型）：

有了北极星指标和可视化的路径，接下来的关键在于用数据指导效能改进。

二时间轴上的AB测试

并非所有客户都值得投入大量力气来维系，增长团队总是优先专注于高价值客户的留存。在进行效能改进时也应当首先识别差异，然后因材施教。

正如增长团队常用的“RFM模型”客户分类方法，针对研发需求，同样可以通过与效能相关的正交维度来分类出可采用不同应对措施的需求集合，譬如“RIW模型”：

A（Activity）需求的近期活跃度（相关事件频率）
I（Importance）需求的重要程度（优先级、距离计划完成的剩余时间）
W（Workload）需求关联的已投入开发工作量（譬如代码修改行数）

三个维度能将所有样本分为8组，这个粒度非常适合圈定重点，同时又避免信息太多过度发散。而选择以上三组属性，不仅是因为它们具备较高区分度，还因为这几项指标的观测值都较容易获得且能够高频更新，从而在研发过程中及时发现异常样本并进行纠偏。

软件研发是一项脑力劳动为主的活动，影响研发效能的因素包括且不限于开发者的个人能力、团队氛围、公司文化、项目进度压力、成员间的默契度、外部沟通成本、相关流程工具等等，其中绝大部分都是无法简单用数值化衡量的主观成分。虽然以往提及研发提效时，我们会出于技术可控的角度，着重谈论平台能力、研发流程、工具支持等“疗程短，见效快”的方法，但真实世界的研发提效手段要丰富得多。既可以采用技术工程手段，如提升构建速度、简化上线流程、改进发布工具；也可以采用组织文化手段，譬如优化奖惩策略、树立先进标杆、调整人力结构、提升员工福利、加强技能培训等等。那么究竟哪种提效方法才最适合研发团队呢？

对此，增长理论早就给出了答案，不论黑白猫，只要抓住老鼠就是好猫：做个AB测试。

与面向产品用户的AB测试不同，进行项目研发时，不能直接以单个需求为粒度进行AB测试（不便于项目管理），相比之下，团队或者迭代都是比较合适的AB粒度。具体的AB方法大家一点也会不陌生，譬如让两个项目团队采取不同的提效策略，对比效果，类似于“试点”和“样板间”。或者让同一个团队在不同的迭代里分别尝试一些新的提效方法，然后根据效果来决定保留或放弃，这就是在“时间轴上做的AB测试”。

喏，一个新概念就这么被创造出来了，不过现在还保持清醒着的读者很快就会发现，这也不是什么新鲜的主意，迭代回顾和改进会议不就是做这事情的嘛！其实不尽然。以往迭代回顾时的可分析数据主要是迭代燃尽图和需求/缺陷累积图，反映的是整体的趋势情况，“整体均值”往往会掩盖局部问题，这是达不到“AB测试”严谨性要求的。而前述的“需求转化路径”和“RIW分布”情况恰好能够弥补上迭代过程细节，为效能改进的方法提供指导依据。

三舶来主义的局限

在许多方面，通过埋点分析增长策略与通过研发事件分析提效策略之间确有共通之处，譬如埋点的四大要素：

此四项要素研发事件皆有，因而但凡埋点可用之方案，研发事件皆可套。这是舶来主义。

然而增长关注的是固定的一群用户，追求拉新留存；提效面对的是日新月异的需求，追求按时交付。由于两者的分析对象和目标不同，本质上依然存在差别：

用户离开了又会回来，可以持续追踪；需求完成就结束了，下次进来的是新需求。这也是需求不适合做为AB测试粒度的原因。
拉新和留存可以越高越好，不设上限；交付效率不能单方面过度苛求，否则以牺牲质量和疲劳战术换取“提效”终将得不偿失。
页面路径相对固定，譬如必须先经过下单页才能进入付款页；需求路径则不一定，譬如一个“开发超期”的任务最终依然可能“按时交付”。

此外，埋点记录的页面点击总是实时准确的，而需求的状态依赖人工更新，实际操作未必及时，采集的事件数据因此经常存在时间偏差，这是研发数据分析的一项老大难问题。更充分的自动化是一种解决思路，譬如在阿里云·云效的新版协作产品中，支持通过规则让研发行为与任务更新关联（比如代码提交触发任务开始、流水线发布触发任务完成等），此举将十分有助于增加效能分析的准确度。

最终，即便是模式化的借鉴，是否有效还需要实践来证明。