项目立项优先级教程：实施团队实操方法，避坑指南

去年 Q2 的立项评审会上，我们手上有 11 个待启动项目，但真正能干活的资深实施顾问只有 4 个人。会议室里每个人都在证明自己那个项目”更急”，讨论了两个半小时，最后的排序依据是，谁的客户先打了投诉电话。散会时一位同事说了句话我记到现在：“我们不是不会排序，是排完之后没人认这个结果。”

这件事后来逼着我们做了一次彻底的复盘。我们把前后 63 个立项项目拉出来，重新算了一遍”当初如果按另一套逻辑排，结果会怎样”。结论有点反常识：当年排错的项目里，超过一半不是”选错了项目”，而是”用错了计量单位”。我们用合同额排、用老板重视程度排、用打分卡总分排，唯独没有用实施团队真正稀缺的那一样东西排，瓶颈角色的人天。

这篇文章把我踩过的坑、改过的表、吵过的架都摊开讲。它不保证让你的立项零失误，但能让你在下一次评审会上，拿出来的不是”我觉得”，而是”我算过”。

一、核心结论：立项优先级排的不是项目，是瓶颈资源的人天

1. 第一性问题被问错了

大部分团队在立项会上问的是”这个项目值不值得做”。但实施团队真正要回答的是另一个问题：”下个月我这 4 个顾问，一共 320 个人天，应该投给谁。”前者是价值判断，后者是资源配置。听起来像同一个问题，实际得出的答案经常完全相反。

一个 80 万的合同，吃掉两个中级顾问 45 个人天，毛利依然是正的。一个 300 万的合同，吃掉一位架构师 120 个人天，而你全公司只有两位架构师，那它其实不是在赚钱，它是在挤占另外三个项目的交付能力。

所以我一直坚持一个原则：立项优先级的计量单位是”瓶颈角色人天”，不是合同金额，不是加权总分，也不是老板的关注频次。金额是收入口径，总分是评价口径，只有瓶颈人天才是交付口径。三者排序结果不一致时，以交付口径为准，因为执行落地的是交付，不是评价。

2. 三条可以直接搬走的结论

• 先门槛，后排序。Go / No-Go 的一票否决项必须在打分之前跑一遍。把明显做不了的项目放进打分池，只会稀释真正候选项目的分数区分度。
• 统一货币。所有项目的资源需求都要换算成”瓶颈角色人天”，而不是各自用各自的单位。销售说”这个季度能签”，产品说”这个需求很关键”，工程说”这个得两周”，不统一货币就永远吵不出结果。
• 有进必须有出。一个没有退出机制的立项队列，三年后一定会变成一个只增不减的堰塞湖。能决定”不做什么”，比能决定”做什么”更能体现团队的管理成熟度。

3. 为什么单纯的打分卡会失效

我见过不少团队做了很精致的打分卡：战略价值 30 分、合同金额 25 分、客户等级 20 分、交付难度 15 分、风险 10 分。打完按总分排，结果第一个月就崩。

崩的原因不是打分卡本身错了，而是打分卡解决的是”谁更值得”，不解决”谁先做”。三个 88 分的项目和一个 85 分的项目，如果前三个都要同一位数据迁移工程师，那这三个 88 分在排队意义上是互斥的，不是可叠加的。总分把它们并列在第一位，实际上等于什么都没排。

更麻烦的是分数会掩盖量级差异。一个 88 分项目要 200 人天，一个 85 分项目要 15 人天。如果因为 3 分差距把大项目顶上去，就会把一个季度的产能全部压在同一个坑里。

二、背景和真实场景：实施团队的立项会到底在吵什么

1. 实施团队的立项来源比产品团队复杂得多

产品团队的立项来源通常单一：来自用户洞察或战略规划。实施团队不是。我们面对的立项诉求至少来自四个方向，而且每一方都有合理的理由。

• 销售侧：已签或待签合同，带着明确回款节点，天然有紧迫性。
• 客户成功侧：老客户的增购、扩容、定制需求，关系到续约率。
• 内部产品侧：需要实施项目作为新功能的验证场景，属于投入型项目。
• 合规与安全侧：等保、数据合规、国产化适配，不做不行但没有直接收入。

四类诉求的”语言”完全不同，一个讲钱，一个讲关系，一个讲产品，一个讲风险。放在同一张桌子上比，本身就容易变成嗓门竞赛。

2. 立项会上真实发生的四件事

我把过去两年参加过的立项会录音整理过一遍，发现高频出现的是这四件事，而不是数据分析。

1. 用个例替代统计。“上次那个客户就是因为晚了三周才投诉的。”，一个案例变成了通用规则。
2. 把紧急当成重要。催得最凶的项目被排到最前，跟它的价值没有关系。
3. 用承诺代替估算。销售在客户面前承诺的工期，被直接当成实施排期输入。
4. 回避取舍。没有人愿意说”这个项目这个季度不做”，于是默认全部启动。

第 4 条最致命。因为不取舍本身也是一种取舍，只不过是把风险从”决策时刻”推迟到了”交付时刻”。等到交付时刻再暴露，成本已经是立项时刻的三到五倍。

3. 被系统性低估的一样东西：切换成本

还有一个隐形成本几乎从来不进立项评估表：切换成本。实施顾问手上同时跟三个项目，从 A 项目切到 B 项目，再切回 A，真正的产出损失远高于直觉。

我做过一段时间的记录：同一位顾问连续三天做同一个项目，日均有效产出大概是 6.5 小时；如果三天里被切到三个项目，日均有效产出降到 4.2 小时左右，降幅接近 35%。这还只是一个人的数据，样本量大约 40 个工作日，属于内部观察不是学术研究，但方向足够明确。

这意味着并行项目数每增加一个，团队的边际产出不是线性增加，而是先增后减。立项优先级如果只算”有没有人”，不算”这个人还能不能连续投入”，排出来的计划一定是乐观的。

三、常见误区拆解：六个让我交过学费的判断偏差

1. 误区一：用合同额排序

这是我最早犯的错，也是最普遍的错。合同额看起来最客观、最好比较，还能直接对上销售指标。但它有一个致命缺陷：合同额是收入口径，不反映资源占用结构。

一个 300 万的项目如果占用的是通用实施顾问，同时能并行跑；一个 120 万的项目如果独占架构师，反而更可能成为瓶颈。按金额排，前者第一，后者第四。按瓶颈人天排，顺序可能完全反过来。

下面这张斜率图是我们 2023 年一次真实复盘的结果。同 6 个项目，按合同额排和按瓶颈角色人天排，名次变化非常大。

2. 误区二：把”紧急”当成”重要”

紧急和重要是两件事，但在立项会上经常被混为一谈。销售催得急、客户投诉多、老板在群里 @ 了三次，这些信号都是”紧急”，不是”重要”。

我的处理办法是给每个项目标注两个独立字段：紧迫度（由外部压力决定，1-5 分）和交付价值（由回款、续约、可复制性综合决定，1-5 分）。两者都高的项目才进第一梯队；紧迫度高但价值低的项目进”快速安抚队列”，用一个轻量动作先稳住，而不是占用完整交付资源。

3. 误区三：把整个项目当成一个原子单位

“这个项目排 Q2″，这句话在实施场景里几乎没有信息量。因为一个大项目里，不同阶段的资源需求完全不同：前期是架构师和方案顾问，中期是实施顾问和开发，后期是测试和培训。

如果只按整项目粒度排期，你会在 Q2 同时压上四个项目的”中期”，然后发现所有项目都在抢同一批实施顾问。正确的做法是把项目拆到里程碑粒度再做排队：立项评审、蓝图设计、配置开发、数据迁移、UAT、上线支持，每个里程碑单独算资源。

拆到里程碑粒度之后，你会发现原来”挤不进去”的季度，其实还能塞下两三个项目的前期工作。这就是颗粒度带来的产能。

4. 误区四：只算实施人天，不算客户人天

这是我踩过最贵的一个坑。项目工时表上写的是”我方投入 180 人天”，看起来很合理。但真正决定项目能不能按期验收的，往往是客户侧能不能按时给出关键人。

一个需要客户 IT 部门配合做接口联调的项目，如果客户方对接人只有每周两个半天可用，那无论我方投入多少，联调周期都是被锁死的。客户人天不是成本项，它是工期约束项。

所以我现在要求在立项表里必须填一个字段：客户关键人每周可用工时（估算值）。低于 8 小时/周的，自动触发风险标记，排期时按 1.5 倍工期计算。

5. 误区五：没有退出机制

立项队列只进不出，是实施团队最典型的组织病。半年前的”待启动”项目，今天还挂在池子里，占着预算名分，实际早就不具备启动条件，客户对接人走了，业务场景变了，甚至客户自己都换了系统。

我的建议很简单：每月做一次队列体检，任何连续 60 天没有推进动作的项目，自动降级为”候选池”，释放预算名分。要重新启动，走简化流程重新提交，但不占用原有排期位。

6. 误区六：一旦立项就锁死资源

很多团队把”立项通过”等同于”资源锁定”，项目一立项就必须配齐人手直到结束。这在变化速率低的项目里没问题，在实施场景里会造成大量闲置。

更灵活的做法是资源承诺分两段：里程碑级承诺（这个阶段的人必须给）和季度级意向（下个季度倾向继续投入，但可调整）。这样既保证当前阶段不被抽人，又给组合优化留下空间。

四、专业判断逻辑：四层过滤 + 一种统一货币

1. 第一层：Go / No-Go 硬门槛

门槛层不排序，只做剔除。任何一条不满足，项目直接退回，不进入打分池。这一步能过滤掉大约三成的无效立项申请，效果非常明显。

我用的门槛清单是这六条：

• 回款或预算已落实。合同未签且无预算编号的，不予立项，可进候选池。
• 客户关键人已指定且可联系。只有”我们会配合”这种口头承诺的，退回补充。
• 需求边界可界定。无法在立项阶段输出一页需求范围说明的，先做需求澄清，不立项。
• 合规与数据安全前置评估通过。涉及敏感数据的，必须有安全部门书面意见。
• 产品能力匹配度不低于某个阈值。差距过大的项目，要么走产品定制立项，要么直接拒绝。
• 有明确的验收标准草案。没有验收标准的项目，是延期的最大来源之一。

门槛层最容易被破坏的地方是”特批”。我的经验是保留特批通道，但要付出代价：特批项目必须由提出方书面承诺，在资源冲突时优先让路。这样特批依然可行，但不再是免费的。

2. 第二层：四维打分卡

通过门槛的项目进入打分。我用的不是五维十维的复杂模型，而是四个维度，每个维度 1-10 分。维度越少，团队越愿意认真打，越不容易变成走过场。

这四个维度有个隐含设计：前两个维度决定”要不要做”，后两个维度决定”怎么做”。价值确定性低但交付确定性高的项目，适合标准化交付、低成本试水；价值确定性高但交付确定性低的项目，必须先做预研，不能直接立项。

3. 第三层：把分数换算成瓶颈人天

打分之后不能直接排序，中间必须加一步换算。这一步是把抽象分数落到具体资源上。

具体做法：对每个项目，列出它需要的角色清单，然后在整个团队里找”该角色可用人数 ÷ 需求人数”最低的那一个。这个角色就是该项目的瓶颈角色，对应的人天就是它的资源成本。

举个具体例子。项目甲需要架构师 40 人天、实施顾问 120 人天、开发 60 人天。团队里架构师 2 人、实施顾问 8 人、开发 5 人。架构师侧占用率是 40/(2×22)=91%，实施侧是 120/(8×22)=68%，开发侧是 60/(5×22)=55%。那项目甲的瓶颈角色就是架构师，资源成本按 40 个架构师人天计。

只有瓶颈角色人天具备跨项目可比性。把它作为统一货币之后，排序会突然变得简单：谁的架构师人天需求小、价值分高，谁先上。

（1）换算时最容易忽略的三个修正项

第一个是学习曲线。新人第一次做某类项目，实际人天通常是熟手的 1.6 到 2.2 倍，这个系数必须在换算时显式加上，不能藏在”实施顾问”这个笼统角色里。

第二个是复用抵扣。如果项目与既有项目高度相似，配置模板、测试用例、培训材料都能复用，工作量应向下修正 15% 到 25%。我在多次项目上验证过这个区间，复用度高的项目确实能省下这个量级。

第三个是等待成本。客户侧配合不到位造成的等待，虽然不消耗我方工时，但会占住排期窗口。这个成本要算进工期，不要算进人天，否则会重复计算。

4. 第四层：按瓶颈角色排队，而不是按总分排队

这是整套逻辑里最关键的一步，也是和常规做法差别最大的一步。

常规做法是按总分从高到低排。我的做法是先按瓶颈角色分组，组内再按分数排。因为不同瓶颈角色的项目之间没有资源冲突，可以并行；同一瓶颈角色下的项目才需要真正排队。

这样一来，一个季度能容纳的项目数，等于”各瓶颈角色产能可支撑项目数的最小值”，而不是”总分前 N 名”。这个数字往往比直觉估算的更悲观，但也更接近现实。

下面这张气泡图是我们实际用过的决策视图。横轴是交付确定性，纵轴是价值确定性，气泡大小是瓶颈人天。四个象限对应四种完全不同的处理策略。

5. 权重怎么调：三种组织的不同配方

四维打分卡的权重不是固定的，它取决于组织当前的主要矛盾。我给三类组织配过不同的权重组合，效果差异明显。

注意一个反直觉的点：客户配合度在内部信息化团队里的权重应该最高，而不是最低。因为内部项目的”客户”就是业务部门，他们没有合同约束，配合全凭意愿，一旦对接人不上心，项目就会无限期搁浅。

五、案例与数据观察

1. 样本说明与可信度边界

下面所有数据来自我们团队 2022 年 7 月到 2024 年 6 月的内部复盘记录，涵盖 63 个已交付项目、18 位实施相关人员、144 次延期事件。这不是公开统计数据，样本也集中在软件实施领域，结论的可迁移性需要读者自行判断。我尽量把口径写清楚，方便你对照自己的场景做校验。

2. 案例：一个被判”高优先级”的项目怎么吃掉整个季度

2023 年 Q2，我们接了一个标记为”战略级”的项目，合同额在当季排名第一。立项评审时它拿到了最高分，资源优先配齐：一位架构师、两位实施顾问、一位开发。

问题出在第二周。客户的历史数据有 11 年，字段重复率经抽样达到 23%，而且存在三套口径不一致的物料编码。数据清洗的实际工作量远超立项时的估算，最终这个项目的实际发生工时比评审估算高出一大截。

更麻烦的是，因为架构师被这个项目独占，同期另一个可复制性更强、金额只有它三分之一的标准化项目被推迟了整整一个季度。那个项目后来在 Q4 顺利交付，两周完成，几乎没占用架构师资源。

复盘时的结论很扎心：我们不是选错了一个高价值项目，而是用错误的估算方式，把一个高风险项目放进了最高优先级，顺手挤掉了一个低风险高确定性项目。如果当初按瓶颈人天排序，那个标准化项目的架构师消耗接近于零，完全可以并行。

3. 观察：数据迁移类立项的系统性低估

63 个项目里，涉及数据迁移的 31 个，平均超估算幅度是 41%；不涉及数据迁移的 32 个，平均超估算幅度是 17%。差了一倍多。

原因其实很朴素：立项阶段大家看的是”要迁多少条数据”，而实际工作量取决于”数据有多脏”。100 万条干净数据和 10 万条脏数据，后者工作量可能是前者的三倍。

所以我后来加了一条硬性要求：任何涉及历史数据迁移的立项，必须先做一次数据体检，抽样不少于 5000 条或总量的 1%，输出字段重复率、口径冲突数、缺失率三个数字。拿不到这三个数字，不允许进入估算环节。

4. 场景：把优先级从 Excel 搬进系统之后发生了什么

我们的立项表在 Excel 里活了三年，改到第四版的时候彻底失控了，不同人手里的版本不一样，评分口径开始漂移，资源占用数据要人工汇总，汇总一次耗时两天。

后来我们把立项、需求池、项目集和资源负载搬进了一个统一平台。我们选的是 PingCode，主要原因是它能同时承载需求池、项目集视图和资源负载视图，而且支持私有化部署，能满足我们对客户数据不出内网的合规要求。

迁移到系统之后，有三个变化是立刻能感知到的。

• 评分口径被固化。打分卡写在系统里，评分项和权重由管理员统一维护，不再出现”我这份表权重是 30%，他那份是 25%”。
• 资源冲突变得可见。同一位架构师在多个项目里的占用，可以在负载视图上直接看到红色超载区，不需要人工汇总。这一步把冲突识别从”事后”提前到了”排期时”。
• 立项到交付形成了一条链。立项时的需求、范围、验收标准可以直接带到执行阶段，减少了一次信息转录和一次误解机会。

需要说明的是，工具解决的是”信息一致性”问题，不解决”判断标准”问题。门槛清单、打分权重、瓶颈角色的定义，这些依然要靠人定。把一套没有共识的流程搬进系统，只会让分歧以更快的速度被固化。

另外提一点实操经验：我们做这次迁移时，是从原有的项目管理工具批量迁移过去的。中大型组织的字段映射、权限重建、工作流重构往往比想象中复杂，所以我们把”工具迁移”本身也当成一个正式立项来做，单独排了 25 个人天，包括自定义字段映射、历史附件迁移、权限矩阵核对和两轮并行验证。如果不用立项的方式管这件事，它一定会拖成半年以上的”半迁移”状态。我认为对 100 人以上、有私有化诉求的组织来说，这类国产替代型的平台迁移值得单独立项，而不是挂在某个业务项目里顺手做。

5. 一个容易被忽略的组合级指标：瓶颈角色负载率

单项目视角永远看不到的问题，在组合视角下会非常刺眼。下面这张图是我们 2024 年四个季度的实际数据。注意 Q2：并发项目数只增加了 3 个，但架构师负载率飙到 118%，按期验收率同步从 81% 掉到 64%。

到了 Q4，我们并没有减少项目数，仍然是 7 个并发，但通过前置技术预研把返工降下来了，架构师负载率回落到 89%，验收率反而涨到 85%。这说明并发项目数本身不是问题，瓶颈角色的负载率才是。

六、不同情况下的行动建议

1. 20 人以下的小团队

不要做打分卡，不要做系统，不要做季度复盘会。你需要的是一张纸和每周 30 分钟。

具体做法：把所有待启动项目写在一张 A4 上，每行四个字段，项目名、瓶颈角色需求人天、最早可启动月份、如果不做的后果。每周一早上花 30 分钟看一遍，只做一个动作：确认这周谁在做哪个项目。

小团队的优势是信息全在脑子里，劣势是没有冗余。所以你的核心任务不是精细排序，而是避免同时启动两个需要同一个人的项目。这一个约束解决好了，80% 的混乱会自动消失。

2. 100 人以上的中大型组织

这个规模以上，靠 Excel 和人脑已经不可行了，因为信息会跨部门失真。你需要三件东西：统一的门槛清单、固化的打分口径、可见的资源负载视图。

打分口径必须固化在系统里，不能靠邮件版本。资源负载视图必须能按角色、按人、按时间段看到红线。这两点做不到，你的立项会永远在讨论”到底谁手上有空”，而不是”哪个项目更该做”。

另外，中大型组织一定要处理”部门墙”问题。实施团队、产品团队、售前团队对同一个项目的价值判断往往不同，需要有一个跨部门的常设评审小组，而不是由某一个部门单独拍板。

3. 项目制交付型公司

交付型公司的核心矛盾是现金流，所以权重要向”客户配合度”倾斜，并且必须把回款节点作为立项的硬门槛，而不是加分项。

我的建议是给每个项目标注”现金转折点”，即第一笔回款到账的里程碑。所有项目的现金转折点如果集中在同一个月，那这个月就是高危月份，必须主动调整至少一个项目的排期。这个动作比排序本身更值钱。

4. 内部信息化 / 数字化团队

内部团队最大的困难是价值难以货币化，业务方又常常”声音大但不投入”。应对办法是把业务方投入作为立项硬门槛：业务方必须指定专职对接人，承诺每周可用工时，且该承诺要由其上级确认。

拿不到这个承诺的需求，不管听起来多重要，一律进候选池。这一条看起来很硬，但它能过滤掉大部分”伪需求”，我见过太多内部项目死在业务方全程只出现两次。

七、不同情况下的取舍

1. 战略项目 vs 现金流项目

这两类项目在排序上天然冲突，而且没有完美的解法。我的处理方式是配额制而非排序制：给战略项目预留固定的产能比例，比如 20%，剩下的 80% 全部给现金流项目，两类各自内部排序。

这样做的好处是战略项目不会被日常业务无限期挤掉，现金流项目也不会被一个”战略”名义无限透支资源。坏处是总量受限，需要每季度重新校准比例。

2. 私有化交付 vs 标准化服务

私有化交付单笔金额高、客户粘性强，但不可复制、占用瓶颈资源多。标准化服务单笔金额低，但可并行、边际成本递减。

如果你的团队正在从项目制向产品化过渡，我建议用标准化项目作为产能的”填充物”，优先保证私有化项目的瓶颈资源，把标准化项目排进剩余产能。不要因为标准化项目”看起来简单”就随意插队，它会打乱现金流项目的连续投入节奏。

3. 快速启动 vs 深度评估

深度评估需要时间，而时间本身就是成本。我的经验阈值是：预计工作量超过 150 人天的项目，值得花 5% 的前置时间做深度评估；低于 50 人天的项目，超过两个小时的评估就是浪费。

中间地带的项目按客户配合度决定：配合度高的可以快速启动，边做边澄清；配合度低的必须先评估清楚，因为一旦卡住，你连推进的抓手都没有。

4. 统一平台 vs 部门自建

统一平台的代价是前期迁移和适配成本高，收益是信息一致性；部门自建工具的代价是数据孤岛，收益是启动快。我的判断标准是组织规模：100 人以下可以容忍工具不统一，100 人以上不统一就意味着资源视图必然失真。

资源视图失真之后，你的立项优先级就变成了猜谜。这也是我在上一个章节里强调”工具迁移值得单独立项”的原因，它不是 IT 工作，它是管理基础设施。

八、一页纸模板与运行节奏

1. 立项一页纸的六个必填字段

无论用什么工具，立项材料都应该控制在一页以内。字段太多没人认真填，字段太少判断依据不足。我的六个必填字段是：

1. 价值确定性评分及依据（回款节点、续约影响）
2. 交付确定性评分及依据（需求清晰度、依赖系统数量）
3. 瓶颈角色及所需人天（含学习曲线和复用抵扣修正）
4. 客户关键人及每周可用工时承诺
5. 验收标准草案（不少于三条可验证条目）
6. 如果不做的后果（用于判断是否真紧急）

最后一个字段是我最喜欢的设计。很多项目在被要求写”如果不做的后果”之后，自己就退出了。因为写下来才发现，后果只是”客户会不高兴一下”，而不是”客户会流失”。

2. 每周 30 分钟排队会的议程

会议时间必须严格控制在 30 分钟，超时就说明准备不足。固定议程三项：

• 前 10 分钟：过一遍瓶颈角色负载率，标出下周会超载的角色和时间段。
• 中间 15 分钟：只讨论需要跨项目调整的冲突，单个项目内部问题一律会后解决。
• 最后 5 分钟：确认本周启动和暂停的项目，形成书面记录。

关键纪律是：不在这个会上讨论单个项目的技术方案。一旦开始讨论细节，30 分钟必然变成两小时，而且真正需要决策的冲突没人处理。

3. 季度退出复盘的三个问题

每季度末，对所有在队列中但未启动的项目问三个问题。任何一个答不上来，转候选池。

1. 过去 90 天里，这个项目的需求有变化吗？变化是什么？
2. 客户侧的关键人还在原岗位吗？
3. 如果现在启动，验收标准还成立吗？

这三个问题的杀伤力比想象中大。我在第一次做这个复盘时，队列里有 9 个项目，走完三个问题之后只剩 5 个还能留在队列里。释放出来的 4 个名额，直接让下一个季度的排期宽松了很多。

4. 一份可以直接抄的打分配置

下面这份配置是我们现在用的版本，包含门槛规则、评分权重和瓶颈修正系数。你可以直接改数值使用。

# 立项优先级配置（示例，可直接改造）
gate:

require_budget_code: true # 必须有预算编号或已签合同

require_owner: true # 必须有客户侧指定关键人

require_weekly_hours: 8 # 关键人每周可用工时下限

require_acceptance_draft: true # 必须有验收标准草案

data_health_check: # 涉及数据迁移时强制

enabled: true

sample_ratio: 0.01 # 抽样不低于 1%

min_sample: 5000

score:

dimensions:

value_certainty:   { weight: 0.30, scale: 10 }
delivery_certainty:{ weight: 0.25, scale: 10 }
customer_support:  { weight: 0.25, scale: 10 }
strategic_weight:  { weight: 0.20, scale: 10 }

bottleneck:

currency: "person_day" # 统一货币：瓶颈角色人天

learning_curve_factor: 1.8 # 新人首次做该类项目的系数区间中值

reuse_discount: 0.20 # 高复用项目的抵扣比例中值

max_load_rate: 0.85 # 单角色负载率上限，超过则拒绝排期

queue:

granularity: "milestone" # 排队颗粒度：里程碑而非整项目

auto_downgrade_days: 60 # 无推进动作自动降级天数

quarterly_review: true # 季度退出复盘

这份配置里我认为最该保留的是 max_load_rate: 0.85 这一条。它意味着任何角色的负载率超过 85%，系统直接拒绝新的排期。把”不能超载”变成硬约束而不是提醒，比任何一次动员讲话都管用。

九、常见问题快答

1. 立项优先级和项目排期有什么区别？

优先级回答”谁更重要”，排期回答”谁在什么时候做”。两者不能合并，因为优先级高的项目未必能立即启动（资源没空），优先级低但资源空闲的项目也可以先做一部分。

我的做法是分开两个队列：优先级队列决定资源分配的倾向，排期队列决定具体的时间安排。前者月度调整，后者周度调整。混在一起的结果通常是，每次资源有波动，优先级就要重排一遍，团队疲于奔命。

2. 老板直接指定的项目怎么处理？

不要试图用流程对抗指令，那只会让流程失去公信力。我的做法是接受指令，但要求它承担代价：任何特批插队的项目，必须指明它替代了哪个原排期项目，并记录该替代造成的延期。

这条记录本身不解决问题，但它会让”插队”从无成本变成有成本。大多数情况下，两三个季度之后，插队行为会自然减少，因为没有人愿意在复盘会上解释自己造成的延期。

3. 打分卡要不要对全团队公开？

要公开，而且要把每个项目的得分和依据一起公开。不公开的打分卡会被默认为”暗箱操作”，团队的信任会迅速流失。

但要区分公开和争论。分数和依据公开，评分标准的调整由常设评审小组决定，不搞全员投票。全员投票会让标准随人数最多的那一方倾斜，而不是随业务需要倾斜。

4. 客户催得急，能不能临时插队？

可以，但要区分两种”急”。一种是真的有明确时间约束（监管期限、业务上线窗口），另一种只是情绪表达。前者应该插队，后者应该用沟通安抚。

判断方法很简单：问一句”如果晚两周，会发生什么具体的事”。能说出具体后果的，插队；说不出具体后果的，进入正常的沟通流程。这一句话能过滤掉大部分假紧急。

5. 这套流程用什么工具承载比较合适？

20 人以下用在线表格就够了，不要为了流程上系统。100 人以上建议用能同时承载需求池、项目集和资源负载视图的项目管理平台，并且优先考虑支持私有化部署的方案，因为涉及客户项目数据时，合规要求通常是硬约束。

无论用什么工具，判断标准只有一个：能不能在一个界面上同时看到”项目优先级”和”角色负载率”。看不到这两样，工具就只是电子化的表格，不会带来任何决策效率的提升。

十、总结：下一步该做什么

回到开头那个场景。11 个项目抢 4 个人，最后靠投诉电话排序，这不是执行力问题，是缺少一套能达成共识的计量方式。

整篇文章我想留下的核心观点只有一个：立项优先级的本质是把有限资源分配给无限诉求，因此它的计量单位必须是稀缺的那一方，而不是充裕的那一方。在实施场景里，稀缺的从来不是项目，也不是合同额，而是特定角色在特定时间段里的可用人天。

围绕这个观点，我给出三个和常规做法不太一样的判断。第一，打分卡要打分，但排序必须有第二套口径，也就是瓶颈人天，否则总分接近的项目无法区分。第二，客户配合度应该进入门槛而不是加权项，因为它不是”好一点坏一点”的差别，而是”能不能做”的差别。第三，退出机制和准入机制同样重要，只进不出的队列最终一定会失效。

如果你的团队现在还没有任何立项流程，下一步只需要做一件事：把手上所有待启动项目列成一张表，加上”瓶颈角色需求人天”和”如果不做的后果”这两列。就这两列，通常足以让排序结果发生明显变化。

如果你已经有流程但效果不好，下一步做一件事：把最近三个月的延期项目拉出来，逐条归因，看有多少是立项阶段就能识别的。如果这个比例超过一半，问题不在执行团队，在立项输入，改门槛比催进度管用得多。

如果你只是想知道今天下午该怎么开这个会，那就带着三个问题进会议室：这个项目占谁的瓶颈人天？客户侧每周能给多少小时？如果不做会怎样？能把这三个问题答清楚的项目，值得排进队列；答不清的，先放候选池。