如何用增长的思维做提效
埋点作为记录用户行为的常规手段，伴随着前端技术的发展早已历经春秋，不过直到“增长黑客”系列理论出现，才真正让埋点分析变得内涵丰富且有章可循。
与产品领域的“增长”类似，“提效”一直是研发领域里长盛不衰的主旋律。在软件研发过程中，伴随着项目开展，同样会以事件的形式记录下许多与代码库、流水线、任务相关的行为数据。这些数据的来源虽与页面埋点不尽相同，其实质用途却有许多可类比之处。然而当产品经理们纷纷开始通过埋点的实时数据争分夺秒调整市场营销策略时，研发团队的TL和PM们依然只能使用统计方法+汇总指标为主导的事后分析手段，在每个版本和迭代完成后对团队效能进行回顾和评估，并乐此不疲地谈论如何将迭代周期从一个月缩短到两周，从而获得“更快的反馈”。
本文将讨论一种尚未被实践过的方法论，即能否将“增长黑客”理论作用到研发过程的改进上，从而实现更可靠的定向效能优化？
一研发团队的北极星指标
在进行增长目标制定之前，团队往往需要先确定一项能够反映团队成功情况且易观测的“北极星指标”，譬如销售额、签单率、活跃用户数等等。对于研发团队来说，关键的指标主要是需求完成时长、功能缺陷率、用户满意度，诸如此类。以“需求完成时长”为例，这是一个相对客观且直接反映开发团队响应用户需求速度的指标，即一个需求从提出到最终交付可用，所需要经历的平均时间长度。
接下来我们定义一个相对理想的需求交付过程，并参考产品流量分析的“转化漏斗”结构表示出来：
相应的，将项目中的所有需求都添加进来，可以绘制出类似这样的“需求交付路径图”（示例，实际阶段划分应该更丰富）：
虽然略显粗糙，但通过这种展现方式我们确实能够追回不少在往常只统计结果数据的图表里丢失了的信息。譬如同样是两个花10天完成的需求，一个开发用了7天，另一个开发只用了1天，其余时间花在了等待测试上，它们的差异在交付路径图上就能被清晰的区分出来。
这样做的另几项好处包括：
即使一个需要还未最终交付，而是被阻滞在了某个环节、或者出现了返工，也能够在第一时间以异常流量的形式显著的展现在路径图上，从而及时引起TL和PM的