这是鼎叔的第九十篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

前文说过，度量需求的数量和时间比较容易，度量需求大小（颗粒度）要麻烦些，那么，度量需求的价值呢？

outcome 比 output 重要，价值比需求规格重要

我们最终给用户交付的是具体的价值，而不是平台统计的需求个数。如何保障我们以价值交付为中心？

度量需求价值的方法很简单，但要落地不容易，来自产品团队的阻力可能会很大，需要高级管理者的支持。

产品团队对需求价值度量可能会敏感，就好像开发对于用有效代码量或缺陷数量度量自己的成果，也很敏感。我们务必树立一个共识：交付需求的价值评估，不会用于衡量产品经理的绩效，仅仅用于集体协作和自我改进。

“价值” 这个词本身就是手提箱词汇（suitcase），你可以从任意一个角度去定义价值，这反而导致团队从实践的第一步就开始纠结。选错了定义的维度，会不会导致很难看到进步，会不会带来虚荣业绩？

其实这个不重要，只要产品经理给出一个锚定价值的任何指标，需求价值提升活动就成功了一半。

度量需求交付的价值，两步法：

第一步，产品负责人要在需求讨论阶段定义价值指标，而且指标足够简单透明，比如：

本需求是满足用户的紧急需求，度量指标就是用户通过 UAT 验收。
本需求是提高用户在某个场景的满意度，度量指标就是用户对该场景的反馈满意度上升了多少个点。注意：老板也是需求的一类用户。
本需求期望用户在本场景的渗透率提升，度量指标就是渗透率从 XX% 提升到 XX%。
本需求期望通过新特性达到拉新效果，度量指标就是通过新特性入口，上线 1 个月吸引新用户注册数 XXX 人。
本需求期望提高老用户活跃度，度量指标就是埋点场景的用户使用次数提高 XX%，UV 提高 XX%。
不同的干系人从不同的收益角度会有自己的指标看法：

不同产品发展的阶段，会有不同的侧重指标；

有的指标看重短期效果，有的指标看重长期价值；

有的指标体现了用户场景的普适性，有的指标体现了需求的长期稳定性，还有的指标体现了产品战略的一致性。

最终还是应由产品负责人确定哪个是关键指标。产品负责人有权决定指标多少是符合预期，且每个需求的指标都可以不同，不鼓励拿通用指标管所有需求。

只要有这个指标就很好，其他角色不用质疑指标是否合理。

第二步，成功的另外一半，来自需求上线后的集体复盘。成功上线一定时间后，在团队复盘会上，对需求是否达成价值目标的数据进行快速确认，如果没有达成目标，产品人员进行原因分析并记录教训。