简介： 本文将探讨一种尚未被实际过的方法论，即是否将“增长黑客”实践作用到研发过程的改良上，从而实现更牢靠的定向效力优化？

埋点作为记录用户行为的惯例伎俩，随同着前端技术的倒退早已历经春秋，不过直到“增长黑客”系列实践呈现，才真正让埋点剖析变得外延丰盛且有章可循。
​
与产品畛域的“增长”相似，“提效”始终是研发畛域里长盛不衰的主旋律。在软件研发过程中，随同着我的项目发展，同样会以事件的模式记录下许多与代码库、流水线、工作相干的行为数据。这些数据的起源虽与页面埋点不尽相同，其实质用处却有许多可类比之处。然而当产品经理们纷纷开始通过埋点的实时数据争分夺秒调整市场营销策略时，研发团队的 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 测试粒度的起因。
• 拉新和留存能够越高越好，不设下限；交付效率不能单方面适度奢求，否则以就义品质和疲劳战术换取“提效”终将得失相当。
• 页面门路绝对固定，譬如必须先通过下单页能力进入付款页；需要门路则不肯定，譬如一个“开发超期”的工作最终仍然可能“按时交付”。

此外，埋点记录的页面点击总是实时精确的，而需要的状态依赖人工更新，实际操作未必及时，采集的事件数据因而常常存在工夫偏差，这是研发数据分析的一项老大难问题。更充沛的自动化是一种解决思路，譬如在阿里云·云效的新版合作产品中，反对通过规定让研发行为与工作更新关联（比方代码提交触发工作开始、流水线公布触发工作实现等），此举将非常有助于减少效力剖析的准确度。
​
最终，即使是模式化的借鉴，是否无效还须要实际来证实。
​

四、畅想与小结

​
增长和提效，两个看似驴唇不对马嘴的主题，因为一个脑洞，被分割到了一起。
​
用产品思路经营技术团队，用埋点数据还原研发过程，用转化门路洞察要害瓶颈。效力黑客，让我的项目进度更主观，让研发过程更通明。

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。