产品经理内容分享(四)：需求的工作量估算以及价值如何度量

目录

工作量估算

迭代需求拆解

需求交付的度量

需求任务的工作量估算

故事点（或工时）度量的意义

如何应对需求紧急插入

价值如何度量

---

工作量估算

度量交付需求的数量和时间相对容易，但度量每个需求的大小则比较难落地，我们需要统一的方法来度量各个团队的需求交付规模，它有利于精细化的组织改进，推动团队以比较舒服的节奏完成承诺，还能稳妥处理紧急需求插入，潜在收益远大于成本。

迭代需求拆解

按照敏捷理论，迭代计划会议要对本迭代的需求进行合理拆解，工作量估算，结合PO决策的需求优先级，确认本迭代要完成的用户故事有哪些。表面看起来，这个迭代计划会议不是测试主导，但是计划制定和测试安排的合理性密切相关。

如果需求或用户故事的颗粒度太大，不利于迭代内的高质量交付，这是最常见的项目风险情形。我经常见到测试人员排期的困境，就是由于需求过大，导致测试设计及场景讨论上就花了太多时间，交付速度很慢。如果一个用户故事的开发周期在2~3人天内，它的测试验收效率是非常高的，可以当天完成测试任务并提交反馈，避免开发等待时间过长。

因此，敏捷特性团队应该对偏大的用户故事进行拆解，以便在本迭代内可以排期完成。

作为测试角色一定要关注这个拆解的“可测试性”，拆解后的用户故事应该可以完整验收，否则违背了敏捷迭代的原则。如图所示，我们应该采用下图中第二行的交付方式，每个迭代完成一个让用户可以使用的“增量”产品。

图：每个迭代都交付可用的产品

需求交付的度量

对于软件交付公司，最核心的交付度量指标，也就是北极星指标，应该是需求交付平均吞吐率（或者需求交付平均周期）。它体现了响应用户需求的速度，自然和市场满意度直接相关。

需求复杂度差异极大，而吞吐率也是看上线需求的数量占比，考虑到敏捷团队会经常改变需求计划，这两个指标很难进一步推进团队提效。

如果管理层想了解“我们每个月交付了多大规模的需求”（或者人均每月交付了多大规模的需求），这对团队的度量就提出了更高的要求。

公司使用的研发管理平台，度量交付需求的数量和时间相对容易（虽然有误差），记录每个需求的大小则比较难落地，我们需要一个统一的共识方法来度量各个团队的需求交付大小。

这篇文章聊聊用户故事的估算和拆解有相关介绍，不同需求的大小可能差异巨大：最小规模的需求就是用户故事；中等规模的需求是特性故事；大型规模的需求是史诗故事。中大规模的需求要能准确评估大小，就要拆解到用户故事的粒度再来评估。

通常，用户故事的大小为3个故事点以下时，开发估算准确度、交付信心和测试效率都会达到一个高水平。反之，故事点大于10的用户故事，交付风险和效率都会迅速恶化，建议尽量拆解为多个可测的用户故事。

需求任务的工作量估算

我们可以把一个故事点的规模锚定为1个“理想人天”的研发工作量，这就可以在系统中把“需求规模”和“评估工时”变成同一件事情。一个需求估算为多少个故事点，就意味着需要技术团队多少“人天”来承担。

注意：交付需求的最小价值尺度是“用户故事”，只有完整实现了用户故事才算交付了完整的价值。但一个用户故事的具体研发工作可以拆分为多个“任务”，其中包括测试任务，完成任务并不代表价值被交付了。因此，有些团队把拆解后的任务定义为“子需求”，这是错误的。

在测试工作量的预估上，我们认为“任务”是最小的工作量估算层次。建议测试任务的划分也不要太粗，单个任务的完成时间不超过一人天，这样有利于团队找到测试效率可以提升的地方，同理，不同测试人员的任务也建议分开估算。

测试任务的独占周期太长，也会影响迭代需求的完成目标，我们有必要具体看看测试范围和优先级，找到合理覆盖策略，保障核心功能用例的验收。

故事点（或工时）度量的意义

针对一个组织的每个交付需求，都在系统上填写故事点或工时，有利于精细化的组织改进。它可以大幅提升度量团队交付效能的准确度，有利于管理层全盘视角，潜在长期收益远大于成本。 比如：

一，迭代计划的需求总规模（点数），是否大于技术总理想人天（工程师人数*迭代工作日）？

比如一个有十个技术人员的Scrum团队，在一个双周迭代能交付的需求规模应该只有100故事点（人天）。

如果排期的需求规模偏大，很可能导致交付目标难以达成，或者交付质量低于预期。因此需要对计划完成的需求进行缩减。

二，度量“计划故事点（工时）”和“实际完成故事点（工时）”的偏差。可以用于迭代复盘，Scrum团队总结如何提高估算技巧，或找到拖慢研发速度的罪魁祸首。

三，如果产品/需求本身有优先级的标签，整个组织就可以度量多少人力投放到了公司战略项目，多少人力投放到了非核心项目上。

有些同学提出几个疑问，我们来回答下。

一，每个Scrum团队的故事大小/工作量预估方法都不同，是否要拉通对齐么？

答案是：不需要！故事点/工时是用来校准Scrum团队的计划执行准确率的，每个团队的成员级别、技能和经验不同，天然会有不同的效率（研发速率）。对于敏捷研发组织来说，重要的是交付可预测，节奏稳定。强行要求不同团队有一样的产出，容易产生灾难性的后果。

因此，我们需要花费几个迭代的时间，让每个Scrum团队内部进行集体估算和集体讨论的实验。初期不太准是正常的，后面的团队估算实践会越来越准确和快速，以比较舒服的节奏完成承诺。

二，既然故事点评估尺度不需要跨团队拉通，那研发团队怎么互相学习呢？

答案也简单，派代表围观其他团队如何集体进行需求大小评估的，识别各种风险对于工作进度的影响。

当开发估算有分歧时，会分享各自的原因，暴露自己不知道的风险，让团队能互相学习。测试等角色也从中受益。为工时估算付出一点成本，会带来极大收益，同时让后期工作计划更靠谱，团队也能更自信。

通过跨团队的故事点实践对比，故事点交付代码规模小、质量相对低的团队，可以像指标高的团队学习，但还是要保持自身的稳定节奏和交付满意度。

估算开发工作人日，可以用一个理想人日完成的工作打一个折扣，比如20%，用于应对迭代工作以外的干扰、学习、会议、交流放松等。如果实践下来发现这个折扣偏高，说明团队应该进行治理，降低非迭代的干扰。

三，有同学会提出自己的担心，故事点度量会用于工程师的考核么？

当然不会，每个团队的人员成熟度和经验不同，业务难度不同，都会形成一个适合自己的开发吞吐节奏，有利于产能最大化和自主改进。

之所以要团队集体估算，也是要减少对个人故事的追踪。

如果把故事点和个人绩效挂钩，会导致个人在评估时降低要求（提高估计值），同时阻碍团队内的互助合作。

四，很多开发工作和需求故事不是强相关，但是scrum团队还是必须完成，比如线上故障，大促，技术债等。怎么办？

把技术故事明确拆解出来，并估算故事点。和产品一起确认哪些技术故事能排入高优先级，能在当前迭代内完成。或者分配指定比例的工作量预留给日常开发运营工作。

五，有些团队没有用户故事拆解的实践，会阻碍故事点的度量实践么？

不会，没有进行用户故事拆解，开发也可以凭团队经验估算工作量大小。

但是用户故事估算实践是行业推荐的主流敏捷方法，有利于团队成员互相学习和提升，估算效果也更稳定。

六，技术团队目前都很支持产品经理的各种需求，如果按照故事点度量，会不会导致支持力度下降，协作意愿下降？

敏捷和精益理论都鼓励跨岗位合作，one team-群策群力。但是这些一定要建立在健康节奏之上才能持续高效，即：团队迭代速率（完成故事点）是一定的，WTP(在制品)最大数量是一定的。

限制故事总大小才能让团队聚焦交付价值的最大化，养成复盘需求的习惯。

当团队为尽可能多的需求实现而精疲力尽时，我们需要扪心自问，真的在交付高价值产品么？

七，业务方要求发布日期不能变，需求工作倒排怎么办？产品经理对接的业务方不止一个，业务方要求都要上线怎么办？

发布日倒排不是问题，从倒排日计算多少个迭代，根据团队速率计算总故事点，看看哪些需求能排入发布计划即可。

产品经理是需求优先级的第一责任人。业务方如果在产研团队外，需求不一定都能满足，这可能导致很多冗余需求。关键是产品经理和业务方能否深入沟通最本质最紧急的需求是什么，能否拉近业务方和研发的距离。比如把业务方卷入研发迭代规划会议，确认需求优先级，甚至参与需求验收。

产品的用户群体到底是谁，业务方是排序第几的用户群体？

产品经理有两种需求排期方式：一，先满足最重要用户群体的重要紧急需求，还有故事点空间再满足次重要群体的。二，给每个用户群体分配固定比例的故事点（即分配泳道大小）。

如何应对需求紧急插入

实际迭代排期中，经常出现产品负责人把新的需求紧急插入本迭代的场景，这会让开发和测试人员很不满。针对紧急插入需求，我们应该如何正确看待？

从敏捷价值观而言，我们拥抱变化。没有必要强制需求排期计划不能变更，哪怕是在本迭代这么短的时间内。但是我们有必要集体确认：新排入的需求优先级如何？它和本迭代中计划完成的其他需求对比起来，优先级是高还是低？如果它优先级比本迭代某个需求高，在迭代剩余工作量能完成的情况下，可以替换这个目前在做的需求。

简而言之，针对紧急需求插入，不能只做加法，而是有加有减。根据优先级拥抱变化，根据团队速率大小替换一定大小的排期需求。因此，我们也要检查产品backlog中的需求优先级，是不是有严格的唯一排序？这个很重要，有进就会有出。

存在一种可能性，有的产品需求，永远都无法排期开发上线，因为它的优先级PK永远不过后面的新需求。这也符合敏捷设计的原则，即适时设计。当前重要的产品想法，可能到了后期便不再重要了。

 

价值如何度量

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

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

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

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

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

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

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

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

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

• 本需求是满足用户的紧急需求，度量指标就是用户通过UAT验收。

• 本需求是提高用户在某个场景的满意度，度量指标就是用户对该场景的反馈满意度上升了多少个点。注意：老板也是需求的一类用户。

• 本需求期望用户在本场景的渗透率提升，度量指标就是渗透率从XX%提升到XX%。

• 本需求期望通过新特性达到拉新效果，度量指标就是通过新特性入口，上线1个月吸引新用户注册数XXX人。

• 本需求期望提高老用户活跃度，度量指标就是埋点场景的用户使用次数提高XX%，UV提高XX%。

不同的干系人从不同的收益角度会有自己的指标看法：

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

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

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

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

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

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

我们系统从组织层面会度量这几个关键数据：

• 多少需求在开发前设定了价值指标？

• 多少需求上线后进行了价值是否达成的复盘？

• 多少需求达成了价值目标？没达成目标的需求，是否留下分析记录？

从大型组织层面，只要有这几个指标能跑起来，就会走向胜利，不用关心不同小组的产品目标是否有进取心。团队自己会养成闭环改进的舒适习惯。

 

PS：还有一个万能的价值交付度量指标，用户NPS。 不过为了精确度量本需求带来的价值，团队可能需要在功能生效时马上让用户填写本场景的NPS，但这门槛也挺高呀

产品经理很排斥度量需求价值的两个理由，很有意思，我们剖析一下：

一 以前我说清楚需求规格，你就吭哧吭哧去实现了，大家精诚团结多好。现在你还要质疑我的需求，还要秋后算得失，狗子你是不是不爱我了？

二 产品需求就是要各种尝试啊，不试我们怎么知道用户喜不喜欢呢？不多试试我们怎么达成考核目标呢？谁能保证预估的价值一定能达到？

回归精益需求的本质，小步快跑探索试错是对的，但是跑之前不定目标，跑之后不复盘，就没有办法有效提升交付水平。

需求的技术实现和验证，耗费总成本远大于需求规格制定成本，用精准的价值描述有利于让整个团队理解用户和商业，让技术任务更有目标导向。