工作量估算，用故事点还是人天？这堪称项目管理领域的 “世纪之问”，被反复提及、讨论。
今天，我就带大家深入剖析，力求给这个问题一个清晰的解答。
在探讨之前，先亮明我的观点：用故事点估算工作量是更为科学合理的选择，而单纯用人天估算则存在诸多弊端。
为什么说故事点估算是正确的做法呢？从定义上讲，“工作量” 是一个 “量” 的概念，而非 “时间” 概念。
以软件开发为例，开发一个电商系统的用户订单管理模块，无论开发人员是经验丰富的老手，还是初出茅庐的新手，这个模块的工作量是固定的，它不会因为开发速度的快慢而改变。就像搬一千块砖，不管是大力士还是普通人来搬，工作量始终是一千块砖。
那么工作量与时间如何产生关联呢？答案是 “速度”。回到软件开发场景，同样是开发订单管理模块，熟手程序员每天能完成 10 个功能点的开发，新手程序员每天只能完成 5 个。这里就体现出速度的差异，速度不同，完成相同工作量所需的时间自然不同。
用公式表示就是：工作量 ÷ 速率 = 时间 。
反观用人天估算工作量的方式，其错误之处显而易见。当我们尝试用人天估算时，会发现诸多不确定因素导致无法准确得知速率。
比如，我们不知道具体由谁来负责开发这个功能。如果是经验丰富的程序员，其开发速率会比新手快很多；我们也不确定开发人员每天能投入多少有效时间。
在项目推进过程中，可能会有各种会议、临时任务干扰，导致每天实际用于开发的时间并不稳定；而且项目的不同阶段，开发速率也会有所变化。项目初期，团队成员需要时间熟悉业务和技术架构，开发速率较慢；项目临近尾声时，可能会因为赶进度、疲劳等因素影响开发效率。所以，在这些不确定因素的影响下，根本无法准确用人天来估算工作量。
说到这里，有人可能会问：老板只关心项目能否按时交付，项目要在 10 月 1 日之前上线，只有 “1800 故事点” 的估算，怎么知道能不能按时上线呢？
其实答案很简单，就像了解昨天的天气一样，跑两个迭代就能知道团队的速率。用总体工作量除以团队速率，就能得到预期交付时间，这和初中物理中的公式是一个道理：
项目总体工作量 ÷ 团队速率 = 预期交付时间 。
然而，这个简单的公式背后，还隐藏着一些重要信息。为什么很多团队仍然直接用时间来估工作量，还认为 “以故事点为单位” 和 “以人天为单位” 没区别呢？原因在于他们假设速率是常量。
一旦认定速率是常量，那么工作量与时间就成正比，自然觉得用哪种单位估算都一样。但这个假设背后，实则反映出一系列错误观念：
将程序员视为可随意替换的 “人力资源”：认为 A 程序员和 B 程序员毫无差别，生手和熟手也没有不同，某个程序员离职后能迅速招到替代者，且对开发速率毫无影响。但实际情况是，不同程序员的技能水平、解决问题的能力、对业务的熟悉程度都有很大差异，这些都会直接影响开发速率。
忽视程序员的成长：觉得程序员在项目启动阶段和结尾阶段的速率一成不变，不考虑程序员在项目过程中会积累经验、提升技能，进而提高开发速率。事实上，随着项目的推进，程序员对业务和技术的理解不断加深，开发效率往往会逐步提高。
漠视团队环境的作用：要么认为团队成员间的协作方式不会改变，要么觉得即使改变也不会对开发速率产生影响。但良好的团队协作、顺畅的沟通交流，能极大地提高开发效率；反之，团队内部矛盾重重、沟通不畅，必然会拖慢开发进度。
只有当这些错误观念在团队和公司中根深蒂固，预设程序员是机器上无差别的可替换齿轮时，才会认为软件开发速率是常量，进而觉得工作量估算用故事点还是人天没区别。
当然，故事点估算也并非十全十美。在实际应用中，故事点的定义主观性较强，不同团队甚至同一团队的不同成员，对故事点的理解和赋值都可能存在差异。
比如，对于一个复杂的算法优化任务，有的成员可能认为难度高，赋予 10 个故事点；有的成员则觉得难度尚可，只给 5 个故事点。而且故事点不像人天那样能直接与成本挂钩，在做项目预算时，还需要进一步转化，这增加了一定的操作难度。
虽然故事点估算存在一定局限性，但相较于人天估算，它能更准确地反映工作量的本质，更适应项目中的各种不确定性。
在项目管理中，我们应优先选择故事点估算工作量，同时要注意克服其主观性强等问题。
例如，团队可以制定详细、明确的故事点评估标准，通过多次讨论、校准，尽量减少成员间的理解偏差；在与老板沟通项目进度和成本时，提前做好故事点与人天、成本的转化说明，让老板更好地理解项目情况。
举个例子：
假设我们要开发一款移动办公 APP，主要功能包括文档编辑、日程管理、团队沟通等。团队由 5 名开发人员组成，其中 2 名资深程序员，3 名初级程序员。
（一）人天估算过程
项目负责人根据经验初步估算，文档编辑功能需要 15 人天，日程管理功能需要 10 人天，团队沟通功能需要 12 人天，总计 37 人天。
在分配任务时，将文档编辑功能分给 2 名资深程序员和 1 名初级程序员，日程管理功能分给 1 名初级程序员，团队沟通功能分给剩下的 1 名资深程序员和 1 名初级程序员。
但在实际开发过程中，负责日程管理功能的初级程序员遇到技术难题，原本预计 3 天完成的部分功能，花了 5 天时间。同时，由于项目进行到一半时，公司组织了一次为期 3 天的全员培训，导致开发进度中断。
最终，整个项目实际花费了 45 人天，超出原计划 8 人天。
（二）故事点估算过程
团队采用扑克估算的方式对各个功能进行故事点估算。经过讨论和评估，文档编辑功能被评估为 12 个故事点，日程管理功能为 8 个故事点，团队沟通功能为 10 个故事点，总计 30 个故事点。
在前两个迭代周期（每个迭代周期为 2 周，每周工作 5 天）内，团队完成了 10 个故事点，由此计算出团队的速率为每周完成 2.5 个故事点。
根据总故事点数量和团队速率，预计项目完成时间为 30÷2.5 = 12 周。
在项目执行过程中，虽然也遇到了技术难题和外部培训等干扰因素，但通过对团队速率的持续监控和调整，最终项目在 13 周完成，与预期时间较为接近。
（三）结果对比分析
从这个实例可以看出，人天估算虽然简单直观，但由于无法准确考虑人员技能差异、有效工作时间不稳定以及项目阶段对开发速率的影响等因素，导致估算结果与实际情况偏差较大。
而故事点估算通过综合考虑任务的复杂度、工作量和风险等因素，以及对团队速率的动态监控，能够更准确地预估项目完成时间，对项目进度的把控更为精准。
应对老板对交付时间的关注
很多人会问，老板只关心项目能否按时交付，项目要在 10 月 1 日之前上线，只有 “1800 故事点” 的估算，怎么知道能不能按时上线呢？其实，通过跑两个迭代，就能了解团队的速率。
用总体工作量除以团队速率，就能得到预期交付时间，公式为：项目总体工作量 ÷ 团队速率 = 预期交付时间 。
人天估算误区背后的观念剖析
为什么很多团队仍然直接用时间来估工作量，还认为 “以故事点为单位” 和 “以人天为单位” 没区别呢？原因在于他们假设速率是常量。
一旦认定速率是常量，那么工作量与时间就成正比，自然觉得用哪种单位估算都一样。
但这个假设背后，实则反映出一系列错误观念：
将程序员视为可随意替换的 “人力资源”：认为 A 程序员和 B 程序员毫无差别，生手和熟手也没有不同，某个程序员离职后能迅速招到替代者，且对开发速率毫无影响。但实际情况是，不同程序员的技能水平、解决问题的能力、对业务的熟悉程度都有很大差异，这些都会直接影响开发速率。
忽视程序员的成长：觉得程序员在项目启动阶段和结尾阶段的速率一成不变，不考虑程序员在项目过程中会积累经验、提升技能，进而提高开发速率。事实上，随着项目的推进，程序员对业务和技术的理解不断加深，开发效率往往会逐步提高。
漠视团队环境的作用：要么认为团队成员间的协作方式不会改变，要么觉得即使改变也不会对开发速率产生影响。但良好的团队协作、顺畅的沟通交流，能极大地提高开发效率；反之，团队内部矛盾重重、沟通不畅，必然会拖慢开发进度。
只有当这些错误观念在团队和公司中根深蒂固，预设程序员是机器上无差别的可替换齿轮时，才会认为软件开发速率是常量，进而觉得工作量估算用故事点还是人天没区别。
故事点估算的局限性与应对策略
故事点估算也并非十全十美。在实际应用中，其局限性主要体现在：
主观性较强：不同团队甚至同一团队的不同成员，对故事点的理解和赋值都可能存在差异。比如，对于一个复杂的算法优化任务，有的成员可能认为难度高，赋予 10 个故事点；有的成员则觉得难度尚可，只给 5 个故事点。
与成本挂钩困难：故事点不像人天那样能直接与成本挂钩，在做项目预算时，还需要进一步转化，这增加了一定的操作难度。
针对这些问题，团队可以采取以下应对策略：
制定详细评估标准：团队应制定详细、明确的故事点评估标准，通过多次讨论、校准，尽量减少成员间的理解偏差。例如，明确规定在何种复杂度、工作量和风险程度下，对应何种故事点数值范围。
做好转化说明：在与老板沟通项目进度和成本时，提前做好故事点与人天、成本的转化说明，让老板更好地理解项目情况。比如，向老板解释清楚团队的平均速率以及如何通过故事点估算出项目的预期交付时间和大致成本。
虽然故事点估算存在一定局限性，但相较于人天估算，它能更准确地反映工作量的本质，更适应项目中的各种不确定性。
在项目管理中，我们应优先选择故事点估算工作量，同时要注意克服其主观性强等问题。
敏捷中的许多小问题，都能反映出领导、团队、公司对待软件开发以及软件开发者的价值观。
将软件开发者当作重要的知识工作者，给予尊重和成长空间，我们会得到更科学合理的项目管理方式；反之，若将他们视为无差别的工具，项目管理也会陷入困境。
希望通过这篇文章，能让大家对工作量估算有更清晰的认识，在项目管理中做出更明智的选择。
欢迎加入中国最大的PMO&PM社区
