功能点、故事点和人天分别回答三个不同问题：软件有多大、这项工作相对多难、需要投入多少时间。功能点度量与技术和人员无关的功能规模，故事点是团队内部用于比较任务难度的相对单位，人天则把工作折算成可排期、可核算的时间投入。三者用途不同，不能直接互换，换算也需要借助团队速率或行业参考区间，而非固定系数。
要点总览（TL;DR）
- 功能点度量软件功能规模，与实现技术和人员无关；故事点度量团队内的相对规模与复杂度；人天度量投入的时间与成本。三者分别回答“软件有多大”“这项工作相对多难”“需要投入多少时间”。
- 可比范围不同：功能点可跨团队、跨技术比较，适合对外承诺、外包计价与行业对标；故事点只在同一团队基准内可比；人天受人员能力影响，跨团队比较需谨慎。
- 三者之间没有固定换算系数。功能点与人天借助行业参考生产率区间折算，故事点与人天借助团队历史速率间接关联，折算结果只作参考区间。
- 常见做法是先以故事点做迭代内相对估算，需要对外承诺或跨团队比较时用功能点校准规模，再结合速率或生产率折算人天用于排期与预算。
- 常见误用包括把故事点当人天直接排期、用功能点考核个人产出、跨团队比较故事点，以及把换算系数当成固定值长期沿用。
三者分别度量什么：定义与度量对象
要正确选用估算单位，先要分清每个单位背后度量的是什么对象。功能点、故事点和人天分别对应软件规模、相对难度和投入时间三种口径，混用往往源于对度量对象的误解。
功能点：度量软件功能规模
功能点（Function Point）是一种基于用户可见功能和数据处理的规模度量方法。它从系统对外提供的功能、涉及的数据以及内外部的交互出发，统计软件在功能层面的体量，与具体用什么技术实现、由谁实现无关。因此，同一套业务需求无论用哪种语言、由哪个团队开发，功能点计数理论上应保持稳定。功能点计数通常需要遵循专业方法（如 IFPUG 或 Nesma 等计数规则），由受过训练的人员完成，计数结果可作为规模基准。
故事点：度量团队内的相对规模与复杂度
故事点是敏捷团队自定义的相对估算单位。它没有绝对物理含义，数值大小只在同一团队的同一套基准内才有意义。团队通常先选一个中等复杂度的任务作为参照，其他任务通过与参照比较得出点数，综合考量工作量、复杂度、不确定性和风险。故事点衡量的是“这项工作相对参照有多难”，而非实际耗时。
人天：度量投入的时间量
人天指一个人工作一天的投入量，属于时间与成本口径。它把工作折算成可排期、可核算的人力投入，直接对应项目计划中的工期和预算。人天估算会受人员能力、熟悉程度、协作效率等因素影响，同一任务由不同的人完成，人天数可能不同。
度量对象对照
| 单位 | 度量对象 | 是否与人员/技术相关 | 典型计数依据 |
|---|---|---|---|
| 功能点 | 软件功能规模 | 无关 | 用户可见功能、数据处理、交互 |
| 故事点 | 团队内的相对规模与复杂度 | 相关（团队基准） | 与参照任务的相对比较 |
| 人天 | 投入时间与成本 | 相关（人员能力） | 任务所需的人力投入 |
同口径差异对照：用途、可比性与换算关系
把三者放在同一组维度下对照，能更清楚地看出它们各自适合回答什么问题、在什么范围内可比，以及换算时需要注意的局限。
| 维度 | 功能点 | 故事点 | 人天 |
|---|---|---|---|
| 典型用途 | 规模基准、跨团队与跨技术比较、外包计价、行业对标 | 迭代计划、速率跟踪、团队内任务排序 | 排期、预算、人力配置与成本核算 |
| 可比范围 | 可跨团队、跨技术比较 | 仅同一团队内可比 | 受人员能力影响，跨团队比较需谨慎 |
| 换算方式 | 通过行业参考生产率区间折算人天 | 通过团队历史速率间接关联人天 | 直接表达时间投入 |
| 主要局限 | 计数需要专业方法与训练 | 不可跨团队直接比较 | 估算易受个体差异影响 |
在可比性上，功能点的优势在于其度量对象与实现方式无关，因此不同团队、不同技术栈的规模可以放在同一基准上比较，适合对外承诺、外包结算或行业对标。故事点则天然是团队内部的“方言”，两个团队同样标为 5 点的任务，实际难度和耗时可能相差很大，跨团队比较故事点没有意义。人天虽然直观，但同一任务由资深成员和新成员完成，人天差异明显，跨团队直接比较人天同样需要谨慎。
换算关系上，三者之间都不存在固定系数。功能点与人天之间，行业里存在参考生产率区间（例如每人天完成多少功能点），但这个区间随组织能力、技术栈和项目类型波动，只能作为参考范围而非精确换算。故事点与人天之间，通常通过团队的历史速率建立经验关联：团队在一个迭代内完成多少故事点、投入多少人天，由此得出大致的折算比例，这个比例只对建立它的团队有效。因此，任何“1 故事点等于 X 人天”或“1 功能点等于 Y 人天”的固定说法都应谨慎对待。
实际估算中如何配合使用
三者在同一估算流程中承担不同分工，合理的顺序是先做相对估算、再校准规模、最后折算时间，让每个单位在它擅长的环节发挥作用。
配合使用的流程顺序
- 迭代内相对估算：团队用故事点对需求或任务做相对估算，快速形成迭代待办，并持续跟踪每个迭代完成的故事点，积累团队速率。
- 规模校准：当需要对外承诺、跨团队比较或外包计价时，用功能点对需求做规模计数，得到与团队无关的规模基准。
- 折算人天：结合团队历史速率把故事点折算为大致人天，或结合行业生产率区间把功能点折算为人天参考范围，用于排期、预算和人力配置。
换算示例（演示情景）
以下为说明方法的演示情景，不代表任何具体团队的真实数据。假设某团队过去几个迭代平均每个迭代投入 40 人天、完成 20 个故事点，则可粗略认为该团队 1 个故事点约对应 2 人天，用于排期参考。若某需求经功能点计数为若干功能点，再乘以行业参考生产率区间，可得到人天的参考范围。两种折算都只是参考区间，实际排期仍需结合团队情况调整。
使用边界
估算环节产出的是预估结果，实际工时填报与审核属于工时管理流程，团队产出指标分析属于产能分析范畴，两者不应在估算环节混用。把估算值直接当作考核依据，或用工时填报数据反过来否定估算，都会让估算失去参考价值。估算结果需要在工作项中承载和跟踪时，可以借助 ONES 的资源与工时管理能力统计项目工时、查看成员工作量与饱和情况，辅助安排和协调资源；ONES 效能管理则可从交付效率、资源效率等维度形成分析指标，帮助团队回顾估算与实际投入的偏差。这些能力服务于估算结果的落地跟踪，估算方法本身仍由团队按上述流程确定。
适配场景与选择建议
选择哪种单位，取决于团队类型、管理目标以及是否需要对外承诺。多数团队会同时使用多种单位，关键是让每种单位用在合适的场景。
按场景选择
| 场景 | 优先使用 | 理由 |
|---|---|---|
| 敏捷团队内部迭代计划 | 故事点 | 估算快、便于团队内比较和速率跟踪 |
| 跨团队比较、外包计价、行业对标 | 功能点 | 与技术和人员无关，规模基准统一 |
| 排期、预算与人力配置 | 人天 | 直接对应时间与成本，便于计划和核算 |
敏捷团队做内部迭代计划时，优先用故事点，估算成本低，也便于团队持续跟踪速率。当管理目标转向跨团队比较、外包计价或行业对标时，引入功能点做规模基准更合适，因为它不受团队和技术差异影响。排期、预算与人力配置最终要以人天表达，但人天应基于团队速率或行业生产率折算得出，而非凭感觉直接给出。
常见误用清单
- 把故事点当人天直接排期：故事点没有时间含义，直接按点数排期会低估或高估工期，应先通过团队速率折算。
- 用功能点考核个人产出：功能点度量的是软件规模，与个人努力程度无直接对应，用于个人考核会扭曲行为。
- 跨团队比较故事点：各团队基准不同，同样点数不代表同样难度，跨团队比较没有意义，需要比较时应改用功能点。
- 把换算系数当成固定值：功能点与人天、故事点与人天的折算都随团队和能力变化，应定期用实际数据校准。
把上述选择落到日常管理，团队可以在工作项中同时记录故事点估算和实际投入，定期对比两者偏差，逐步校准速率；需要对外承诺时再补充功能点计数。这样三种单位各司其职，估算结果也能在项目中持续跟踪和修正。
常见问题
功能点计数一定要由专业人员完成吗，团队自己数行不行？
功能点计数遵循一套明确的规则，例如 IFPUG 或 Nesma 等计数方法，需要判断功能类型、识别数据功能和事务功能，并处理边界与复杂度调整。受过训练的人员计数结果更稳定，也更容易在不同团队之间对齐。团队自行计数并非不可行，前提是计数人员系统学习过所选方法，并在团队内保持一致的计数口径；否则同一需求由不同人计数，结果可能差异较大，规模基准就失去比较意义。
故事点估算做完后，怎么判断它和实际投入的偏差是否合理？
可以在每个迭代结束后，把完成的故事点与团队实际投入的人天放在一起对照，观察单位故事点对应人天的变化趋势。偏差本身不是问题，持续单向偏移才值得关注：如果实际人天长期高于按速率折算的预期，说明速率基准需要更新，或者需求拆分粒度、验收标准发生了变化。对照的目的是校准速率，而非用实际工时去否定估算值。估算结果与实际投入的对比记录，可以在工作项中随迭代持续积累。
对外报价时用功能点，内部排期用人天，两套数据怎么衔接？
衔接点在于生产率区间。先对需求做功能点计数，得到与团队无关的规模；再结合本组织或行业的生产率参考区间，把规模折算成人天范围，作为报价与排期的共同起点。报价阶段可以取区间偏保守的一端留出余量，内部排期则结合团队当前速率和人员可用性细化。两套数据不必精确相等，但应来自同一次功能点计数和同一套生产率假设，避免报价与排期各用一套口径。
团队刚转敏捷，还没有历史速率，故事点怎么用来排期？
缺少历史速率时，可以先做一到两个迭代的相对估算和实际投入记录，用这段时间的数据建立初始速率，再逐步用于排期。过渡期内，排期可以先用基于经验的人天估算兜底，同时并行记录故事点，待速率数据积累到一定数量后再切换。需要注意的是，初始速率样本少，波动较大，排期时应保留调整空间，避免把早期速率当成稳定基准对外承诺。
估算结果在工具里怎么承载和跟踪？
估算结果通常需要落到具体的工作项上，随需求、任务一起流转，才能在迭代中持续对照实际投入。ONES 的资源与工时管理能力支持统计项目工时、多维度掌握项目和成员的资源投入情况，并可查看成员的工作量与饱和情况，辅助安排和协调资源；ONES 效能管理则从交付效率、资源效率等维度形成分析指标，帮助团队回顾估算与实际投入的偏差。估算方法本身仍由团队按自身流程确定，工具承担的是记录与跟踪环节。
