实施SPACE框架的持续投入，可以拆成数据采集、工具、团队三块来核算。数据采集包括数据源梳理、埋点与接口开发、清洗校验和必要的人工补录；工具包括研发管理平台、代码与流水线数据、报表看板以及存储计算资源；团队则需要度量负责人、数据工程、各团队数据接口人和评审解读角色。核算前先划定覆盖的团队与项目范围，把一次性建设投入和每周期运行投入分开，再按“人力工时×人力单价＋工具订阅或自建摊销＋数据处理与维护工时”建立可复算模型，并对数据源数量、指标数量、采集频率和人工补录比例做敏感性分析。
要点总览（TL;DR）
- SPACE框架的持续投入由数据采集、工具、团队三块构成，核算时先把一次性建设投入与每周期运行投入分开，再按季度折算年度预算。
- 成本项要落到可计量单位：数据采集按人时和补录比例，工具按席位、用量或资源账单，团队按角色工时乘人力单价。
- 可复算模型为：年度总投入＝每周期运行投入×周期数＋建设期投入÷摊销年数，示例演算中6个团队、20个项目的年度投入约29.6万元。
- 运行成本对数据源数量、采集频率、指标数量和人工补录比例最敏感，控制动作包括合并数据源、降低非关键采集频率、分批上线指标和回收低使用率席位。
- 工具费用与人力单价需区分事实和示例假设，厂商现价、合同金额与内部核算口径统一后再加总，避免口径混用导致预算失真。
核算范围与时间跨度怎么定
SPACE框架的投入核算最容易出错的地方，是把建设期的一次性投入和运行期的持续投入混在一张表里，导致第一年成本看起来很高、后续年份又显得过低。建议先确定三件事：度量覆盖哪些团队和项目、建设期多长、按什么周期统计运行投入。
覆盖范围直接决定数据源数量和接口人数量。只覆盖一个产品线的三五个团队，与覆盖多个事业部、几十个项目，数据采集和协调成本可能相差数倍。范围一旦确定，在核算周期内尽量保持稳定，否则前后两个周期的数字无法比较。
建设期通常包括平台选型、数据源接入、指标定义、看板搭建和首轮试运行；运行期则是每个统计周期的数据采集、校验、报表更新和评审会议。两者分开列示，才能看清哪些成本会随周期重复发生。
统计周期建议按月采集、按季度核算。月度数据便于发现采集异常，季度核算则减少汇总工作量。年度总投入可由季度运行投入乘以四，再加上建设期摊销得到。
需要说明的是，本文讨论的是框架运行所需的采集、工具和团队投入，不涉及具体指标口径如何设计，也不评估AI辅助分析带来的效果变化，这两部分属于相邻主题。
| 界定项 | 填写内容 | 对核算的影响 |
|---|---|---|
| 覆盖团队数 | 例如：6个团队 | 决定接口人数量和协调工时 |
| 覆盖项目数 | 例如：20个在研项目 | 决定工作项数据量和看板复杂度 |
| 建设期时长 | 例如：2个月 | 一次性投入的归集区间 |
| 运行期统计周期 | 例如：按季度 | 运行投入的重复计量单位 |
| 年度折算方式 | 季度运行投入×4＋建设期摊销 | 形成年度预算口径 |
数据采集、工具与团队的成本项清单
把三类投入拆成可计量的成本项，是后续代入公式的前提。每一项都要有明确单位和计量方式，并标注它属于建设期还是一次性、运行期还是重复发生。
数据采集投入
数据源梳理是起点：列出需求、缺陷、代码提交、流水线构建、发布记录等数据分别存放在哪些系统，字段是否可用，更新频率如何。这项工作以人时计量，通常发生在建设期，运行期只需在新增数据源时补充。
埋点与接口开发负责把数据接入度量平台。已有开放接口的系统以接口配置为主，缺少接口的系统可能需要定制开发，按人时或人天计量。数据清洗与校验是运行期的主要工作量，包括字段映射、去重、异常值处理和口径核对，按每周期人时计量。
人工补录是容易被低估的一项。满意度调研、沟通协作情况、部分流程外的工作记录，往往需要人工填报或定期问卷，按参与人数×填报时长计量，并记录补录比例。
工具投入
研发管理平台承载需求、任务、缺陷等工作项数据，通常按席位按月计费；代码仓库与流水线工具提供提交、构建、部署数据，可能按席位或按用量计费；报表与看板工具负责指标展示，可能包含在平台内，也可能单独订阅；存储与计算资源按容量或用量计量，自建时体现为服务器与运维分摊。
团队投入
度量负责人负责整体方案、指标定义和结果解读，通常为兼职或专职角色；数据工程人员负责接口、清洗和看板维护；各团队数据接口人负责本团队数据确认和补录；评审与解读角色参与周期性度量评审会。团队投入统一按人时计量，再乘以对应人力单价。
| 类别 | 成本项 | 单位 | 计量方式 | 归属 |
|---|---|---|---|---|
| 数据采集 | 数据源梳理 | 人时 | 参与人数×工时 | 建设期 |
| 数据采集 | 埋点与接口开发 | 人时/人天 | 开发与联调工时 | 建设期为主 |
| 数据采集 | 数据清洗与校验 | 人时/周期 | 每周期处理工时 | 运行期 |
| 数据采集 | 人工补录 | 人时/周期 | 填报人数×填报时长 | 运行期 |
| 工具 | 研发管理平台 | 席位/月 | 席位数×月数 | 建设期与运行期 |
| 工具 | 代码与流水线数据 | 席位/月或按量 | 订阅或用量账单 | 运行期 |
| 工具 | 报表与看板 | 席位/月 | 订阅费用或包含在平台内 | 运行期 |
| 工具 | 存储与计算资源 | GB/月或实例 | 资源用量×单价 | 运行期 |
| 团队 | 度量负责人 | 人时/周期 | 投入比例×周期工时 | 建设期与运行期 |
| 团队 | 数据工程 | 人时/周期 | 维护与排障工时 | 运行期 |
| 团队 | 团队数据接口人 | 人时/周期 | 确认与补录工时 | 运行期 |
| 团队 | 评审与解读 | 人时/周期 | 会议时长×参会人数 | 运行期 |
口径与假设：价格、席位、周期如何统一
成本模型能否复算，取决于口径是否统一。厂商现价、内部人力单价、计费周期和税费处理如果不一致，加总出来的数字就没有比较意义。建议在模型旁附一张口径说明表，逐项标注哪些是事实、哪些是示例假设。
工具费用方面，厂商公开报价或已签合同金额属于事实，应注明获取日期和适用版本；尚未询价的部分只能作为示例假设，并明确“不代表任何厂商现价”。席位计费按开通账号数乘以月数计算，适合人员稳定的团队；按量计费随数据量或调用次数波动，适合采集频率变化大的场景，两者不能直接相加比较。
币种和税费需要统一。以外币计价的订阅按核算期汇率折算，并注明汇率假设；是否含税要统一到同一口径，年付折扣按实际合同折算为月均成本，避免把折扣价和月单价混用。
人力单价按组织内部核算口径取值，例如按岗位级别设定每人时成本，并说明是否包含社保、管理费用等间接成本。工时折算假设包括每月有效工作人时、兼职角色的投入比例，这些参数应在模型中单独列出，便于替换。
| 口径项 | 处理方式 | 标注类型 |
|---|---|---|
| 工具订阅价格 | 已签合同或公开报价按实际金额；未询价部分用示例值 | 事实／示例假设 |
| 席位计费 | 开通席位数×月数 | 事实（按合同） |
| 按量计费 | 按账单用量×单价，注明统计区间 | 事实（按账单） |
| 币种 | 统一折算为本币，注明汇率与日期 | 示例假设 |
| 税费 | 统一含税或统一不含税 | 事实（按合同） |
| 年付折扣 | 合同总价÷12折算月均 | 事实（按合同） |
| 人力单价 | 按岗位级别设定每人时成本 | 示例假设 |
| 工时折算 | 每月有效人时、兼职投入比例 | 示例假设 |
可复算的投入计算模型
模型分三段：建设期一次性投入、每周期运行投入、年度总投入。所有参数集中放在参数表中，读者替换成自己的数字即可复算。
建设期一次性投入＝数据源梳理工时×人力单价＋接口开发工时×人力单价＋看板搭建工时×人力单价＋建设期工具费用＋建设期培训与试运行工时×人力单价。
每周期运行投入＝（数据清洗校验工时＋人工补录工时＋数据工程维护工时＋接口人确认工时＋评审会议工时）×人力单价＋每周期工具订阅与资源费用。
年度总投入＝每周期运行投入×每年周期数＋建设期一次性投入÷摊销年数。人均分摊＝年度总投入÷覆盖的度量使用人数，用于判断投入是否与团队规模匹配。
以下演算全部使用示例假设，仅用于演示计算过程。假设覆盖6个团队、20个项目，建设期2个月，按季度核算；人力单价示例为每人时200元；研发管理平台示例为每席位每月80元、开通60个席位；代码与流水线工具示例为每月3000元；存储与计算示例为每月800元。
建设期一次性投入示例：数据源梳理40人时、接口开发120人时、看板搭建60人时、培训与试运行30人时，合计250人时，乘以200元为50000元；建设期工具费用按2个月计，平台9600元加代码流水线6000元，合计15600元；建设期一次性投入约65600元。
每季度运行投入示例：清洗校验60人时、人工补录40人时、数据工程维护50人时、接口人确认30人时、评审会议20人时，合计200人时，乘以200元为40000元；季度工具费用为平台14400元、代码流水线9000元、存储计算2400元，合计25800元；每季度运行投入约65800元。
年度总投入示例：65800×4＝263200元，加上建设期投入按两年摊销的32800元，约296000元；若度量使用人数为120人，人均年投入约2467元。这些数字只反映示例参数下的计算关系，实际核算应替换为组织自己的工时记录和合同金额。
| 参数 | 示例取值 | 说明 |
|---|---|---|
| 覆盖团队／项目 | 6个／20个 | 决定接口人与数据量 |
| 人力单价 | 200元/人时 | 示例假设 |
| 建设期工时 | 250人时 | 示例假设 |
| 每季度运行工时 | 200人时 | 示例假设 |
| 平台席位费 | 80元/席位/月，60席位 | 示例假设 |
| 代码与流水线 | 3000元/月 | 示例假设 |
| 存储与计算 | 800元/月 | 示例假设 |
| 摊销年数 | 2年 | 示例假设 |
哪些因素最影响运行成本
运行成本的波动主要来自四个变量。识别它们的敏感程度，可以把成本控制精力放在影响最大的地方。
数据源数量与采集频率影响接口维护和数据量。每新增一个数据源，就多一份字段映射和异常处理工作；采集频率从每日一次提高到实时，存储和计算费用以及排障工时都会上升。控制手段是合并同类数据源、对非关键指标降低采集频率。
指标数量与人工补录比例影响人力投入。指标越多，清洗校验和评审解读的工时越长；人工补录比例越高，接口人和填报人的时间占用越大。控制手段是分批上线指标、优先使用系统自动采集的数据、压缩问卷频次。
工具自建与订阅的选择影响费用结构。订阅按席位和用量付费，前期投入低、随规模线性增长；自建需要服务器和运维人力，前期投入高、边际成本较低。选择时应结合团队规模和数据敏感要求，而不是简单比较首年费用。
团队接口人的投入属于隐性成本，容易在预算中遗漏。接口人通常由业务骨干兼任，其确认和补录时间会挤占研发时间，核算时应按实际工时计入，并在评审中评估是否可以减少确认环节。
| 敏感因素 | 影响方向 | 可控手段 |
|---|---|---|
| 数据源数量 | 增加则接口维护与清洗工时上升 | 合并同类数据源，按需接入 |
| 采集频率 | 提高则存储计算与排障成本上升 | 非关键指标降频采集 |
| 指标数量 | 增加则校验与评审工时上升 | 分批上线，定期清理低价值指标 |
| 人工补录比例 | 提高则接口人与填报人工时上升 | 优先自动采集，压缩问卷频次 |
| 自建与订阅 | 改变费用结构而非单纯高低 | 按规模与数据要求选择 |
| 接口人投入 | 隐性占用研发时间 | 明确确认清单，减少反复沟通 |
取数方法与成本控制动作
成本模型的可信度取决于取数来源是否可查。人力成本从工时系统、项目管理系统或团队填报记录中取数，按角色汇总人时；工具费用从合同、账单和资源用量报表中取数，注明计费周期；数据质量与人工补录情况从采集日志、校验规则命中记录和填报统计中核对。
在数据采集环节，ONES Performance 可实时同步 ONES Project 中的业务数据，减少手动整理数据源的工作；其数据集选取、自定义报表和图表展示能力，可承载度量结果的呈现。对于使用ONES研发效能管理解决方案的组织，交付效率、质量、进度和资源效率等数据可在同一闭环中展示，这有助于减少跨系统取数和重复核对。需要说明的是，外部系统数据接入仍需单独评估接口方式，具体计费与资源规格以实际合同为准。
成本控制动作建议按周期执行：每季度复盘一次各成本项的实际发生额与预算差异；对连续两个周期使用率低的指标下线；对人工补录占比高的字段评估自动采集替代方案；对席位使用率低的账号及时回收；对采集频率和存储保留周期做一次复核。每次复盘形成一页记录，写明调整项、责任人和下期目标，使运行成本随框架成熟逐步收敛。
| 成本项 | 取数来源 | 核对方法 |
|---|---|---|
| 人力工时 | 工时系统、项目管理记录、团队填报 | 按角色汇总，与评审参会记录比对 |
| 工具订阅费用 | 合同、账单 | 核对席位数量与计费周期 |
| 存储与计算 | 资源用量报表 | 核对用量峰值与保留策略 |
| 数据质量 | 采集日志、校验规则命中记录 | 抽查异常记录处理结果 |
| 人工补录 | 填报统计、问卷回收记录 | 对比补录比例与计划值 |
常见问题
SPACE框架的投入核算应该按项目算还是按团队算？
两种口径都可以，关键是核算周期内保持一致。按团队核算适合评估各团队的度量负担和接口人投入；按项目核算适合评估单个项目的采集与看板成本。如果组织同时覆盖多个事业部和共享平台，建议以团队为主口径、项目为辅助维度，避免同一份平台费用被重复计入多个项目。范围一旦确定，在核算周期内保持稳定，前后两个周期的数字才具备可比性。
数据采集频率提高到实时，运行成本会增加多少？
增加幅度取决于数据量和排障复杂度，没有统一比例。采集频率提高会同时推高存储与计算资源用量、接口维护工时和异常处理工时；如果实时采集还要求人工值守或频繁核对，人力成本上升会更明显。实际操作中可以先对关键指标保持较高频率，对趋势类、回顾类指标按日或按周采集，再观察一个周期的资源账单和工时记录，据此判断是否值得继续提高频率。
工具选订阅还是自建，成本上怎么判断？
订阅按席位和用量付费，前期投入低，费用随团队规模线性增长；自建需要服务器、运维人力和安全合规投入，前期成本高，规模扩大后边际成本较低。判断时把两类方案放在同一核算周期内比较：订阅方案取合同金额或询价后的示例值，自建方案把硬件、运维工时和扩容预留计入。团队规模小、数据敏感要求一般时，订阅的费用结构更容易预测；数据驻留要求严格、长期使用人数稳定时，自建的总拥有成本可能更低。
度量运行一段时间后，如何判断哪些投入可以压缩？
按季度复盘各成本项的实际发生额与预算差异，重点看三类信号：连续两个周期使用率低的指标和看板、人工补录占比持续偏高的字段、席位开通数与实际活跃账号差距较大的工具。对低使用率指标做下线或合并，对高补录字段评估自动采集替代，对闲置席位及时回收。每次复盘记录调整项、责任人和下期目标，使成本随框架成熟逐步收敛，避免一次性大幅削减影响度量连续性。
ONES Performance 在SPACE框架的取数环节能承担哪些工作？
ONES Performance 可实时同步 ONES Project 中的业务数据，减少手动整理数据源的工作；支持选取数据集、自定义报表和图表展示，可承载度量结果的呈现。对于采用ONES研发效能管理解决方案的组织，交付效率、质量、进度和资源效率等数据可在同一闭环中展示，有助于减少跨系统取数和重复核对。外部系统的数据接入方式、具体计费与资源规格仍需按实际合同和接口评估确认。
