我之前提过「建议使用需求个数而非估算点数来衡量需求规模」，观点引发大量讨论。本篇将围绕一个访谈案例展开，并对估算和估计进行概念厘清，阐述我们不建议采用点数估算的理由。

他们为何放弃了点数估算？

曾经，我们对一家研发组织进行了访谈。最初，他们使用故事点数进行估算：

我们两周一个迭代。每次开计划会，扑克牌估算要花很长时间。为期半天的计划会，至少有两个小时花在估算上。完成估算后，再用故事点总数决定进入迭代的需求是否符合工作量预期。

但是，经过一段时间的统计，他们发现：

不管计划会形成了怎样的估算结果，最终进入迭代的故事个数都是差不多的。

基于这种情况，他们从估算点数改为个数：

于是，我们决定不再把时间浪费在打牌上！需求人员在梳理需求时数好故事个数，计划会上直接进行需求澄清，计划会时间立刻从半天缩短到了1.5小时。

组织观察对估算行为有反作用

放弃点数估算，不止在于上面案例中提到的原因。

类似量子力学的观察者效应，组织对估算的观察会影响到估算者的行为。这是定义估算体系时必须充分考虑的因素，也是我们反对用点数来进行估算的主要原因。

一家大型国有行的软件研发中心，曾对软件需求进行功能点估算，并以此为基础对开发团队进行产能评估。很快地，研发团队为了显示自己干活多，把需求文档写得越来越复杂。于是，大量时间被花费在写文档上，直接影响了交付速度和项目进度。

最后，功能点估算法在全行被废弃。

另一家股份行的研发中心，鉴于上述问题造成的弊病，让测试团队介入功能点计算。结果，测试团队不时跑去开发团队询问信息，增加了更多的干扰和浪费。

点数估算很容易引起开发团队的规模冲动。我在咨询辅导中时常发现，同一个团队，在引入故事点估算的几个月后，团队完成的需求个数基本没变，但交付的故事点数可能翻了一倍甚至几倍之多。

另外，点数估算会加剧业务和研发之间的不透明。对业务人员来说，点数计算难以理解且不可控，与故事点相比，功能点这类问题更加严重。还是前面提到的国有大行，业务每年按一个折扣和研发计算功能点产能，这也彰显了业务和研发之间由功能点计算引发的不信任。

个数到底比点数好在哪里？

业务提出一个大需求，被研发拆成了若干个小需求，分步上线交付，加起来还是最初的那个大需求。这是需求个数比点数好的地方，直观可见且容易被业务同学理解，有利于业务与研发之间互信的建立。

估计需求个数，可能让开发产生拆细需求以增加个数的冲动。但是，这种「副作用」对组织甚至是有益的。需求拆分到细小的颗粒度，会让团队更快速地完成交付，减少进度和质量风险，从而尽早实现业务价值。

需求颗粒度拆分还受到需求可测试、潜在可发布的制约。虽然开发想把需求尽可能拆细，因为增加了测试和产品的管理成本，会受到来自测试和业务同学的阻力。于是，开发、测试、产品三方之间形成制衡，有效避免了需求无节制细分的可能性。

因此，我们建议将需求拆分成粒度相对均匀的条目，再使用经过平准化的需求个数作为规模基数进行估计。

厘清概念：估计与估算

第三节中出现了「估计」和「估算」两个概念，通常均被译为「Estimate」。其实，两个词的含义并不相同，需要特别注意并加以区分。

估计是对未来的预测。对个人而言，估计可能是预测某个任务完成的时间：

对团队而言，估计可能是预测某个项目上线的时间，也可能是预测某个版本将要完成多少需求：

估算是被组织刻意观察的估计。如果组织对估计结果与实际结果进行统计分析，那么，估计行为就变成了估算行为。

我绘制了一张估计与估算关系的简要示意图，便于读者理解：

估计是人类应对不确定环境的必要手段。Martin Folwer 在一篇文章中提到，估计的价值在于为管理者做出相关决策提供支持，如帮助分配资源、协调进度、提升沟通效率等。本文题目「放弃点数估算」强调的是估算行为，而非估计行为。

需求规模自然地趋于一致

对个数估算常见的质疑之一是：需求规模有大有小，很多组织不知道该如何拆，或者拆不好，估算也就无从谈起了。

回到本文第一节的访谈，该组织认为能进行这种改变有个基本前提：

即使不刻意进行需求拆分，我们的需求颗粒度也是比较一致的。

这也是我们长期观察所印证的一个发现：

每个组织都有一种「平整化」的力量，能让需求规模（颗粒度）自然地趋于一致。

上面访谈的组织不是孤例。十年来我们接触的很多组织都有类似的「平整化」力量，这是组织内部长期习惯的表现之一。组织经过一段时间的磨合，某些合适的做法被沉淀下来，这些做法会对组织成员（包括新成员）持续产生影响。即使不施以人为控制和提醒，组织成员的习惯、偏好也会彼此传染。久而久之，需求提出、需求澄清、任务分解、开发测试……不同角色会在「平整化」力量的影响下，逐渐达成这种「不可见」的一致。

再来看个现实数据的例子。下图为一家研发规模约900人金融企业，在刚过去的9月和10月，研发每周完成的需求个数相对均匀（国庆假期除外），基本一周上线30个需求。没有被刻意要求和调整过，数据分布清晰显示了组织内「平整化」的力量。

另外，有江河流域生活经历的读者可能知道，一定区域内的鹅卵石不会在大小上出现明显差异，因为持续的水流冲刷会导致鹅卵石之间互相摩擦，造成该现象的产生——这也是一种「平整化」的力量。

最后，总结本文的几个核心观点：

• 估算是被观察的估计，会对组织起反作用；
• 点数估算让研发产生规模冲动，容易造成浪费，损害业务和研发之间的信任关系；
• 个数估计推动需求拆分，对组织利大于弊；
• 每个组织都有一种「平整化」的力量，让需求规模自然地趋于一致。

作者：吴穹；20年经验软件工程专家，Agilean 创始人

本文由 @吴穹 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议