开源项目管理软件免费版能用到什么程度：一条功能边界线讲透

项目周会上，项目经理说“完成了 80%”，可进度表、工时表和 Bug 列表三套数字对不上；管理层追问关键路径在哪、成本有没有超，没人能当场答上来。很多团队这时才发现，开源项目管理软件免费版能建任务、看板、Bug 和文档，却未必能算清计划。

免费版能不能继续用，不看功能多少，而看它能否通过五项测试：WBS 与关键路径、EVM、需求追溯、变更与风险、组合资源。 下文按这五项给出测试动作和越界信号，最后用两周试点固化成验收表。PMI 在 PMBOK 中强调，项目管理要在范围、进度、成本和质量之间做权衡；免费版能否承担管理职责，取决于这套权衡能否被工具计算和验证。

一、边界线：五项硬能力，逐项测试

1. 免费版通常覆盖的基础动作

多数开源项目管理工具能建产品、需求、任务、迭代、Bug、用例和文档，能做看板、燃尽图和基础报表。免费版通常在人数或时间上较宽松，但授权方式、可用模块和限制条件要以具体版本说明为准。

以下测试按项目管理通用方法中的 WBS、关键路径法（CPM）和挣值管理（EVM）口径设计。

2. 五项硬能力测试表

五项中有一项是刚性要求时，按该项的测试结果判断，不用功能数量替代验证。

二、WBS 与进度：任务能拆，关键路径不一定能算

1. 按 WBS 100% 原则拆到工作包

WBS 的 100% 原则：子节点范围之和必须等于父节点，不能多也不能漏。工作包常用经验值是 8～80 小时；超过 80 小时继续拆，低于 8 小时合并。每个工作包写清单一负责人、交付物和完成标准。

2. 测依赖、关键路径和基线

测试动作：建 40 个工作包；设置完成—开始、开始—开始、完成—完成、开始—完成四类依赖；找出浮动时间为 0 的关键路径；冻结基线；把关键路径上的一项任务延长 3 天，看工具是否重算完工日期并保留变更记录。

判定标准：关键路径是否自动计算、基线是否可冻结、变更后能否对比计划与实际。免费版常见组合是任务、看板、燃尽图；甘特图、关键路径和基线常被放在付费版或插件中。合同工期或阶段门是硬约束时，先确认这三项。

举例：6 个月发布项目，关键路径通常是“接口联调→性能测试→上线”，不是“需求文档”。关键路径上的任务延一天，交付日期才延一天；非关键路径任务延期，可能只消耗浮动时间。

三、成本：有工时字段，不等于能做 EVM

1. 三个数算清进度与成本

PV 是计划价值，EV 是已完成工作的预算价值，AC 是实际成本。SV=EV−PV，CV=EV−AC，SPI=EV/PV，CPI=EV/AC。SPI 小于 1 表示进度落后，CPI 小于 1 表示成本超支。

2. 用一组数算一遍

项目总预算 60 万元，第 2 个月末 PV=40 万元，EV=36 万元，AC=42 万元。SV=−4 万元，CV=−6 万元，SPI=0.90，CPI=0.857。进度和成本都不达标；只报“完成了 60%”看不出这个问题。

测试动作：建 3 个成本账户，录入 PV、EV、AC，检查工具能否自动算四项指标、保存成本基线、按变更重算。多数免费版只记录工时，EVM 要表格外挂；月度 EVM 是刚性报告时，这就是边界。

四、质量：需求、用例、Bug 要能双向追溯

1. 建需求追溯矩阵

RTM 要能正向查：一个需求对应哪些用例、哪些 Bug、哪个版本发布；反向查：一个 Bug 来自哪个需求、哪条用例。没有双向追溯，覆盖率和漏测都无法定位。

2. 用 DRE 和重开率验收

Bug 移除效率 DRE = 发布前发现 Bug 数 ÷（发布前 + 发布后发现 Bug 数）。例：发布前 45 个、发布后 5 个，DRE=90%。重开率 = 重开 Bug 数 ÷ 已关闭 Bug 数；重开率高，说明关闭标准不清。

测试动作：20 个需求、40 条用例、15 个 Bug，走完提测到上线；检查需求→用例→Bug→发布能否双向跳转，发布门禁能否阻止未关闭的阻断级 Bug。若追溯矩阵只能在表格工具中维护，发布门禁也无法由工具自动执行。选择测试管理模块时，核对用例、测试单、Bug 和测试报告能否与需求、发布关联。

五、治理：变更、风险、RACI 能不能被工具约束

1. 变更单必须带基线

变更单写清四件事：影响范围、进度、成本、质量；谁审批；批准后新基线是什么；旧基线是否保留。没有基线，变更无法对比计划与实际。

2. 风险台账与 RACI

风险分值=概率（1～5）×影响（1～5），按分值排序；策略分为规避、减轻、转移、接受；每条风险有负责人和触发条件。RACI 每项任务只能有一个 A（最终负责），R 执行、C 咨询、I 知会。

测试动作：发起一次变更、登记一条风险、配置一次审批；检查是否记录审批人、时间、意见，能否阻止未审批变更进入执行。审计要求完整证据链时，免费版加线下签字通常不够。付费版通常补的是工作流、审批流、过程定义、问题与风险管控；逐项核对实际版本，不按版本名称推断。

六、规模：多项目组合与资源负荷

1. 项目排序用加权评分

示例权重：战略匹配 30%、投资回报 25%、风险 20%、资源可行性 15%、合规 10%，每项 1～5 分，加权求和。加权总分排序后，进入资源可行性复核。

2. 资源负荷用需求÷产能

中大型企业的多项目场景，先算负荷。例：5 名工程师，每人每月 20 个工作日，产能 100 人天；三个项目需求合计 130 人天，负荷率 130%，超载 30 人天。处理方式只有四种：延后、缩范围、加人、转移。工具至少要能按人、按月显示负荷曲线。

测试动作：建 3 个项目、5 个共享成员，排同一月份任务；检查能否看到个人超载、跨项目冲突和依赖。只能逐个项目看时，组合平衡仍靠表格。免费版可能提供项目集视图，但多项目集场景仍需核对组织层级、权限和组合视图。

七、两周试点：把边界变成验收表

1. 试点步骤

选一个真实项目，不用演示数据。第 1～2 天建 WBS 和基线；第 3～4 天跑一个迭代；第 5～6 天录入成本账户和 EVM 数据；第 7～8 天走需求→用例→Bug→发布；第 9～10 天发起变更、登记风险、做一次审批；第 11～14 天做多项目负荷和复盘。

2. 验收表

下面这张表把六项验收固定下来：

验收项分成“必须”和“可选”。必须项有一项不通过，就不要让免费版承担这项职责；可选项不通过，用外部工具补。把六项跑完，免费版能用到哪一步，就有可复核的答案。