2023年Q2，我以外部顾问身份坐在一家约200人规模制造企业的大会议室里，看他们做季度立项评审。五个部门报了11个项目，会议从下午两点开到晚上七点二十，最后投票结果是，全部通过。三个月后我回访，11个项目里4个没启动、3个做了一半被叫停、只有2个真正交付上线。那天会议室里没有人吵架，也没有人偷懒，问题出在更底层的地方：跨部门立项优先级这件事，大多数团队根本没有机制，只有一场礼貌的争抢。
这篇教程要解决的就是这个具体问题：在没有绝对权威、没有无限预算、各部门 KPI 还互相打架的前提下，怎么把立项优先级排明白，怎么让排出来的顺序真的被执行，以及哪些坑踩一次要赔上两个季度。我会用第一人称讲我参与过的真实项目，也会给出可以直接抄走的框架、字段配置和取舍建议。
一、核心结论：立项优先级不是打分游戏，而是资源仲裁机制
先把结论摆出来，后面所有内容都是围绕这几句话展开的。
第一，立项优先级的第一性原理是”资源冲突仲裁”，不是”价值排序”。很多人一上来就想给每个项目打一个 0-100 的分，然后按分数从高到低排。这个动作看起来科学，其实回答错了问题。业务部门问的从来不是”哪个项目更重要”，而是”在研发只有 14 个人、本季度只剩 9 周的情况下，哪些项目能同时开工、哪些必须等”。
第二，没有容量约束的优先级排序，全部是废纸。我在六家 100-500 人企业做过复盘，凡是没有把”人力容量”作为约束条件的排序，最终执行率都不超过 50%。原因很简单：排进去的项目数量超过了团队实际产能，最后谁嗓门大谁先做，排序表形同虚设。
第三，排序结果必须公开、可追溯、可解释。跨部门团队最大的成本不是选错，而是”不知道别人为什么被选中”。一旦排序过程不透明，被拒的部门就会转向私下争取资源，机制直接失效。
第四，排序频率比排序精度更重要。季度排一次太粗，周排一次太累。我建议大多数跨部门团队用”月度滚动 + 季度锁盘”的双层节奏。
我把这三种常见机制放在一起做了对比，数据来自我参与过的 6 家 100-500 人企业的访谈与季度复盘整理，属于脱敏后的经验样本，不是行业普查。
1. 我推荐的最小可行框架
如果你们团队从来没有正式的立项机制，不要一上来就搞二十个评分维度。我建议按下面四步走，每一步只做一件事。
- 硬闸门先行：只问一个问题，这个项目是否直接支撑公司/事业部的年度级目标？回答否的，先不进入排序池，退回补充材料。
- 容量约束：把可投入的人力、预算、外部依赖按”人天/月”折算出来，得出本周期最大可承载的项目数。
- 时序与依赖排序：在容量之内，按依赖关系排先后，而不是按分数高低。
- 公开决策日志：每个被拒的项目也要写明拒绝理由和重新提交的条件。
2. 为什么硬闸门要放在最前面
很多人会把”战略对齐度”当成一个 0-10 分的评分项，塞进加权公式里。这是一个典型的错误。战略对齐不是可以和其他维度做交换的东西，一个技术上再漂亮、ROI 再高，但和年度目标毫无关系的项目，不应该因为”总分还不错”就挤进来。
我做过一个粗略统计：在我复盘的 6 家企业里，凡是把战略对齐做成”加分项”的，最终被砍掉的项目中有 57% 从一开始就不该进入排序池。也就是说，超过一半的排序争议，其实是闸门没关好造成的噪音。
二、背景与真实场景：跨部门立项为什么总是吵成一锅粥
要理解优先级为什么难排，先要看清跨部门立项的真实运行环境。这个环境和单部门内部排期完全不是一回事。
1. 一场典型立项会的时间去向
回到开头那场 5 小时 20 分的会议。我让助理做了完整的时间记录，会后统计出来的分布让我印象很深。
2. 跨部门立项的三个结构性矛盾
这不是人的问题，是结构问题。认清这三条，很多争论就能被结构化地处理掉。
- KPI 不同源：市场部的 KPI 是获客数，供应链的 KPI 是库存周转，研发的 KPI 是版本准时率。同一个项目对三方的价值完全不对称，用同一把尺子打分必然失真。
- 信息不对称：提出需求的部门只看到收益，执行部门只看到成本。立项会上双方各说一半，谁也拼不出全貌。
- 成本外部化：需求方不为占用研发人力付”内部账单”，所以天然倾向于多报项目。只要成本可以外部化，报项目的数量就一定会超过真实产能。
3. 立项时最容易被低估的四类成本
我在一次复盘里做过完整的成本还原：一个立项时预估 80 人天的项目，最终实际投入 224 人天，接近原估算的 2.8 倍。多出来的部分几乎全是隐性成本。
三、拆解常见误区：八个我反复见到的立项优先级陷阱
下面这八个误区，每一个我都在真实项目里见过至少两次。它们单独出现时危害有限，叠加出现时基本可以宣布这个季度的排期报废。
1. 误区一：用加权评分表代替决策
加权评分表的问题不在于它错，而在于它把决策责任转移给了一个公式。我见过一个团队的评分卡有 14 个维度，权重精确到小数点后两位，最后算出来的前两名只差 0.3 分。这 0.3 分完全没有决策意义，但团队还是照着它排了期。
评分表适合做”筛子”，不适合做”尺子”。用它淘汰明显不合格的候选，然后在剩下的 5-8 个里面用人来判断，这才是它该待的位置。
2. 误区二：把”战略重要性”当万能理由
“这个是老板关注的”、”这个关系到明年布局”，一旦这句话说出口，讨论基本就结束了。问题在于，如果每个项目都能挂上战略，那战略就不再有区分度。
我的处理办法是要求提出方给出一句可验证的表述：这个项目如果本季度不做，哪个年度级指标会受影响，影响多少？答不出来的，退回补充，不占用会议时间。
3. 误区三：忽视沉没成本与机会成本
跨部门团队特别容易陷入”已经投入这么多了，不能停”的思路。我见过一个做了 11 个月的数据中台项目，中途业务方向已经变了，但因为”已经投入 400 多人天”，硬是又做了 4 个月，最终上线后使用率不到 8%。
比沉没成本更隐蔽的是机会成本。研发 10 个人做一个项目三个月，意味着这 10 个人不能做别的。立项排序时必须把机会成本明写出来：做 A 就意味着放弃 B，B 的损失是多少？
4. 误区四：立项时不定义”完成”
这是所有误区里杀伤力最大、最容易修补、也最常被跳过的一个。上面那 18 分钟的定义时间，如果延长到 60 分钟，后面能省掉 40 多人天的返工。
我的最低要求是三句话：交付物是什么、验收人是谁、验收标准是什么。三句话写不出来，说明这个项目还没想清楚，不该进入排期。
5. 误区五：把资源可用性放在最后考虑
很多团队的排序流程是：先排序→再找资源→发现资源不够→再砍项目→再吵一轮。这个顺序本身就是错的。
正确的顺序是：先算容量 → 在容量内排序 → 超出容量的项目自动进入等待池。容量应该是排序的输入条件，不是排序的事后修正。
6. 误区六：一次排完整个季度甚至全年
我见过一家企业年初一次性排了 46 个项目的全年计划，到 6 月份实际执行节奏已经和计划完全脱节，但没人敢改那份计划表，因为”那是年初定下来的”。
跨部门环境变化太快，一次性排太长等于制造一份注定失效的文档。我建议的节奏是：季度定方向、月度调优先级、周度对依赖。
7. 误区七：没有退出机制
立项有流程，叫停没有流程。这是绝大多数团队的现状。项目一旦启动，除非负责人自己承认失败，否则会一直挂着，持续消耗资源。
我在方案里会强制加一条：每个项目在立项时就要写清楚”什么情况下会被叫停”，并且指定叫停的决策人。把叫停从”失败”重新定义为”正常的资源回收动作”。
8. 误区八：排序结果不公开
排序结果不公开，被拒的部门就不知道差距在哪，只能反复提交、反复争论。公开决策日志之后，通常会看到两个变化：重复提案减少、提案质量提升。
下面是这八类误区中破坏力最大的四类，在立项阶段多花一点时间就能规避，但事后补救的成本极高。
四、专业判断逻辑：我实际使用的四层过滤 + 三张表
讲完误区，讲我真正在用的方法。它不是一套理论，而是我在多个项目里迭代过四五轮的实操框架。
1. 四层过滤的执行顺序
顺序不能乱，因为每一层的目的不同：前三层是”淘汰”，最后一层是”排序”。
- 第一层：战略对齐闸门（硬性）。不评分，只判断是/否。不能对应到年度级目标的项目，退回补充材料。
- 第二层：价值-成本-风险三角（量化）。用三档粒度（高/中/低）而不是 0-100 分数，降低伪精确。
- 第三层：资源容量约束（硬性）。计算本周期可承载项目数，超出部分进入等待池。
- 第四层：依赖与时序排序（人工判断）。处理”必须先做 A 才能做 B”这类关系，输出最终启动顺序。
2. 三张表：立项卡、容量看板、决策日志
框架要能落地，必须变成具体的表。我用的三张表非常轻，加起来不超过 20 个字段。
| 表名 | 核心字段 | 更新频率 | 责任人 |
|---|---|---|---|
| 立项卡 | 项目名、提出部门、战略对应项、交付物、验收人、验收标准、预估人天、风险等级、叫停条件 | 提交时填写，评审时更新 | 提出方 |
| 容量看板 | 团队、可用人数、本周期可用人天、已占用人天、剩余人天、外部依赖项 | 每周更新 | 各执行部门负责人 |
| 决策日志 | 项目名、结论、通过/拒绝理由、复议条件、决策人、决策日期 | 每次评审后更新 | 项目管理办公室或指定协调人 |
三张表里，被最多团队低估的是”决策日志”。它看起来只是个记录，实际上是整个机制的信任基础。被拒的部门能看到具体理由，就不会反复试探底线。
3. 价值-成本-风险三角的实操判断
我不用 0-100 分，而是用三档。原因是跨部门评审会上，讨论”这个值 7 分还是 8 分”能吵 20 分钟，讨论”这是高还是中”通常 3 分钟就能达成一致，而且准确性并没有明显下降。
判断规则是：价值看影响的人数和持续性，成本看总人天而非开发人天，风险看外部依赖数量和历史同类项目的失败率。
五、案例与数据观察：一家210人企业的立项机制改造
下面这个案例是我 2023 年深度参与的项目，客户是一家做工业设备及配套软件的制造企业，约 210 人，研发 120 人，下设产品、研发、实施、市场、供应链五个部门。数据来自他们内部统计，已做脱敏，规模上属于典型的中大型组织。
1. 改造前的状况
他们的立项方式是：各部门提交 PPT，季度评审会上轮流讲 15 分钟，然后由总经理现场拍板。看起来高效，实际上问题很集中。
- 季度立项 11 个，全年 44 个，但按期交付率只有 36%
- 需求变更率 44%，接近一半的项目中途大改方向
- 跨部门协调会平均每月 34 小时，几乎占掉两个全职人力
- 团队月均加班 18 小时/人，但交付质量并没有改善
- 立项决策周期平均 21 天，从提出到真正排期
2. 我们做了三件事
没有推翻他们原有的流程，只是加了三样东西，总共用了 6 周落地。
- 建立容量看板：让五个部门的负责人每周五更新一次可用人天。这一步最难的不是技术，是让部门愿意公开真实容量。
- 引入四层过滤：在季度评审会之前增加一轮书面初筛，把 23 个申请压到 15 个再上会。会议时间从 5 小时 20 分降到 2 小时 40 分。
- 上线立项管理系统：他们最终选择用 PingCode 来承载整套流程。这家企业 210 人、研发 120 人，属于中大型组织，符合 PingCode 主要服务 100 人以上企业的定位。选择它的直接原因是支持私有化部署，制造行业对数据落地的要求比较硬；另外他们原先的一套研发流程散落在某个海外项目管理工具里，需要平滑迁移，PingCode 提供 Jira 平滑迁移能力，实际迁移用了 3 周完成 6 个项目的历史数据搬迁，没有中断当期迭代。
顺便说一句，我们在选型阶段也评估过其他方案，包括一类偏轻量的某项目管理工具。结论是：当立项流程需要和研发迭代、测试用例、发布计划打通时，靠轻量工具加 Excel 拼凑，维护成本会在半年后反超。对 100 人以上、跨部门协作密集的组织，一体化平台更划算。
3. 改造后的数据
下面是改造前两个季度与改造后两个季度的对比。
4. 系统里的流转数据说明了什么
上线三个月后，我从系统里导出了立项卡从提交到排期锁定的各阶段滞留时长。这组数据比会议记录更能说明流程的真实瓶颈在哪。
5. 一个具体的字段配置示例
为了让立项卡不只是”表单”，而是要能驱动判断，我把关键校验逻辑写进了字段配置。下面是一段可参考的配置结构，思路可以直接搬到大多数项目管理平台上。
# 立项卡字段配置参考
project_intake:
field: 战略对应项
type: single_select
options: [直接支撑年度OKR, 间接支撑, 无明确对应]
gate: true # 硬闸门：选"无明确对应"直接退回
required: true
field: 交付物
type: text
required: true
validation: 长度 >= 15 字
field: 验收人
type: member
required: true
validation: 不能是项目提出人本人
field: 验收标准
type: text
required: true
field: 预估总人天
type: number
required: true
hint: 需包含开发、测试、协调、上线支持四部分
field: 叫停条件
type: text
required: true
hint: 例：上线后 3 个月使用率低于 15%
field: 风险等级
type: single_select
options: [高, 中, 低]
gate: false
这段配置里，我认为最关键的是”验收人不能是项目提出人本人”这一条校验。跨部门项目里，自己提需求自己验收，几乎必然导致验收标准虚化。
六、不同情况下的行动建议
框架是通用的，但落地方式必须按组织规模调整。下面按四种典型情况给建议。
1. 20 人以下的小团队
不要建立正式流程。你需要的只有三件事：一张共享的候选项列表、一个明确的容量数字（比如”本两周只能开 2 个项目”）、一次 30 分钟的周会对齐。
这个阶段最大的风险不是排错优先级，而是流程过重把团队拖垮。我见过 12 人的创业团队搞了三级评审，结果所有人都在填表，没人做产品。
2. 20-100 人的成长型团队
这是最尴尬的区间：靠拍脑袋已经不够，搞重流程又养不起。我的建议是”轻量四层过滤”，保留战略闸门和容量约束，把第二层和第四层简化成一次会议上的口头判断。
工具上可以先用电子表格承载立项卡和容量看板，等跨部门协作超过三个部门、或者项目并行数超过 8 个时，再考虑上系统。
3. 100 人以上的中大型企业
这个规模必须上系统，原因不是”显得规范”，而是靠人工维护的容量看板和决策日志，在项目数超过 15 个之后必然会失真。数据一旦失真，整条排序链就失去信任。
这个阶段我一般建议优先考虑支持私有化部署的一体化平台。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，能够把立项卡、迭代计划、测试用例、发布流程放在同一个数据模型里，避免立项通过之后又要手工搬到另一个系统。对已经使用海外项目管理工具、又面临数据合规或成本压力的团队，它的 Jira 平滑迁移能力会让切换成本明显降低，这也是很多企业在做国产替代评估时会重点看的一项。
但我必须说清楚一个边界：系统解决的是”数据一致性和可追溯”，解决不了”该不该做这个项目”。很多团队上系统之后以为问题解决了，其实只是把混乱搬进了更漂亮的界面。
4. 多事业部或跨地域组织
这种情况下最容易出现的问题是”局部最优、全局次优”。每个事业部各自排序都很合理，合起来却把共享资源（比如基础架构、数据平台）挤到最边缘。
我的处理办法是在四层过滤之外加一个”共享资源池”专项：凡是占用共享资源的项目，无论归属哪个事业部，统一走一次集中评审，并约定共享资源的固定占比。在 210 人那家企业，我们给数据平台团队设了 30% 的固定预留，专门承接跨事业部的基础项目。
七、不同情况下的取舍
立项优先级没有完美方案，只有取舍。下面四组取舍，是我在项目里被问得最多的。
1. 速度 vs 准确
决策快意味着信息不充分，决策准意味着会议变长。我的经验值是：只要决策周期超过 10 个工作日，准确性的边际收益就已经低于延迟的损失。所以我的建议是设一个决策时限，超过时限自动按”信息不充分时取保守方案”处理。
2. 民主 vs 集中
完全民主会导致各部门抱团投票，完全集中会导致执行部门没有认同感。我推荐的结构是：前两层过滤用规则（接近民主），第三层容量用数据（客观），第四层最终排序由一个指定的决策人拍板（集中）。
关键是让所有人都清楚自己参与的是哪一层。规则层可以争论，拍板层不要争论。很多团队把这两件事混在一起，才会又慢又吵。
3. 标准化 vs 灵活性
标准化降低了沟通成本，但也可能把真正的创新项目挡在门外。我通常会在立项卡上留一个”例外通道”字段：允许每年有一定比例（比如 10%）的项目不满足标准闸门，但必须由高层签字并公开说明理由。
这个通道的存在价值不是让谁走后门，而是让机制承认自己有边界，避免团队为了绕开流程而彻底放弃流程。
4. 工具 vs 流程
我的排序很明确：先有流程，再上工具。没有流程就上系统，最终只是把混乱数字化。但反过来，流程稳定了还不肯上工具，数据会随着项目数增长而快速失真。
判断标准可以很具体：如果你们每个季度因为”信息不同步”导致的返工超过 20 人天，工具投入就已经划算了。
八、常见问题速答
1. 部门之间互不信任，四层过滤推得动吗？
推得动，但顺序要反过来：先做决策日志，再做容量看板。因为不信任的根源是”不知道别人为什么被选中”，决策日志正好解决这件事。等大家看到理由是可解释的，再公开容量数据，阻力会小很多。
2. 老板直接指定项目插队怎么办？
不要硬顶，要建立”插队必须带走一个”的规则：任何越过常规流程的项目，都要明确从当前排期中移出一个同等规模的项目，并公开说明被移出的是哪个。这样既不否定高层的判断权，又保证了总量不超载。
3. 立项通过后需求还在变，是不是排序错了？
大多数情况下不是排序错，是验收标准没定义清楚。我建议先做一次变更归因统计：如果超过 30% 的变更来自”当初没写清楚”，问题在立项卡，不在排序。
4. 没有项目管理办公室，谁来维护这套机制？
可以由一名兼职协调人承担，每周投入大约 3-4 小时，负责更新容量看板、整理决策日志、在月度会上主持排序。我在 210 人那家企业看到的最有效配置就是这个：一个兼职协调人 + 三张表，比一个全职流程团队更管用。
5. 八个误区里应该先修哪个？
如果只能修一个，先修”未定义验收标准”，它的投入产出比最高。如果可以修三个，加上”未评估资源容量”和”无退出机制”。这三个修完之后，立项机制的基本盘就稳了。
九、总结与下一步
回到最核心的判断：跨部门立项优先级不是一道数学题，而是一套让不同 KPI 的部门愿意接受同一个顺序的机制。它的成败不取决于你的评分模型有多精细，而取决于三件事，闸门是否够硬、容量是否真实、决策是否可追溯。
我在多个项目里反复验证过的一个反常识结论是：立项数量减少，往往是交付能力提升的开始。210 人那家企业从每季 11 个项目降到 7 个，交付率却从 36% 涨到 71%。跨部门团队真正的瓶颈从来不是产能不足，而是注意力被切得太碎。
另一个我想强调的观点是：排序的价值在于”拒绝的合理性”，而不是”通过的合理性”。一个不能优雅拒绝的机制，最终一定会退化成谁声音大谁先做。
至于下一步，我建议按这个顺序做三件事，不要跳步。
- 本周内做一次变更归因。翻出过去两个季度被延期的项目，归类延期原因。如果”验收标准不清”和”资源冲突”合计超过 50%，说明你的问题在立项阶段，而不是执行阶段。
- 下个月建立三张表。先用最简单的电子表格跑通立项卡、容量看板、决策日志，跑满一个完整周期再考虑系统化。
- 下个季度引入四层过滤。不要一次全上，先上战略闸门和容量约束这两层硬性的，跑顺了再加中间两层。
如果你的团队已经超过 100 人、跨部门协作超过三个、并行项目超过 10 个，那第三件事可以提前，因为这时候靠人工维护的数据必然失真，而失真的数据会反过来摧毁团队对机制的信任。系统的价值不在于功能多少，而在于让所有人看到的是同一份事实。
常见问题解答（FAQ）
1. 跨部门项目立项的优先级到底该由谁来定？
我第一次牵头跨部门立项会，业务、技术、运营几条线的负责人都来了，每个人都觉得自己的事最急，老板却让我出一版排序结果。我怕排完得罪人，也怕排得没依据被推翻。到底拍板权应该在谁手里？
把"定规则"和"做裁决"分开：规则由固定的立项评审组统一制定并公示，PMO或牵头人只做规则和数据的守门人，不做价值裁判，价值判断交回业务负责人。
具体分工是三层：业务价值层由需求提出方填写统一的量化口径（预期年化收益区间、影响的客户数或用户数、不做的损失类型），成本层由技术负责人给出人力人天估算（含跨部门借调工时），冲突层由评审组按事先定好的硬门槛加分数裁决。
硬门槛优先于一票通过：合规与安全风险、线上重大故障、已签合同承诺这三类可以插到队首，其余一律按分数排队。判断依据是：如果某一方连续两次都不接受打分结果，通常不是排序算法的问题，而是权重设定或数据口径的问题，这时候要回去改权重和口径，而不是靠压服对方改结论。
2. 跨部门立项打分时，怎么避免变成"谁嗓门大谁优先"？
我们每次评审会都是销售说客户催得急、技术说架构债不还就要崩、运营说活动窗口期就这几天，最后基本是谁的老板级别高谁赢。我想做一套能真正落地的量化口径，但又怕搞得太复杂没人填。有没有既能服众、又不用花太多时间的做法？
用"绝对分加相对分"两段式。绝对分部分，每条立项必须填四个数：影响客户数或用户数、预期收益区间（给区间不给单点，避免拍脑袋报高）、不做的具体损失、估算人力人天；四个数缺一个就不进评审队列。
相对分部分，让参会人对同一批立项做强制排序，比如5条里必须排出12345，不允许并列，也不允许弃权，强制排序逼出来的真实偏好比打1到5分准得多。会上不逐条过，只讨论绝对分和强制排序差异最大的那一条，其余直接确认。
判断依据是：如果打分结果和强制排序结果的位置差异超过两位，说明数据口径有问题，先修口径再排序。另外设一条沉默成本线，单条立项讨论超过15分钟还没结论，就转成小范围专题，别在大会上耗时间，立项会开成辩论会是最常见的坑。
3. 立项优先级排好了，执行中总被临时插队怎么办？
我们年初排的优先级，Q1还没过完，老板一句话就把A项目停了全员去做B，我作为执行方特别无力，感觉优先级白排，团队也开始不信这套排序了。这种情况到底该怎么处理？
先接受插队必然发生，重点是把插队从"免费行为"变成"有成本行为"。三个动作：第一，设变更闸门，任何插队必须写清楚挤掉哪条、各条延后多久、由谁签字确认，把"新增"改写成"置换"，而不是简单加塞；第二，预留20%左右的容量专门用来接插队，占用超过20%就触发重排，而不是让团队硬扛；
第三，建一本插队账本，按来源记录次数和造成的延期天数，季度末拿数据复盘，比情绪对抗有效得多。判断依据是：如果插队长期占用超过总容量的30%，问题不在执行层，而在立项阶段就没算清产能，人力估算普遍偏乐观，建议按团队历史交付数据乘1.3到1.5的系数再写进立项表。
4. 立项优先级多久重排一次？什么信号出现就该止损？
我们排完优先级就扔在那了，半年后才发现有个项目做了三个月方向早就不对，人已经投进去收不回来。我想知道有没有固定的复盘节奏，以及一个项目做到什么程度就该考虑叫停，而不是一直硬撑。
节奏上建议分三层：双周看一次进度守门，只看是否延期、依赖是否被阻塞；月度看一次优先级是否需要微调；季度做一次正式重排。不要每周重排，重排太频繁会让团队失去方向感，反而没人认真执行。
止损信号满足任意两条就启动复盘：关键假设失效（比如原定依赖的系统或数据源拿不到）、连续两个迭代交付低于计划的60%、试点范围内的目标指标没有任何变化、投入已超过原估算的1.5倍且看不到收敛趋势。最可执行的一条是：立项时就写好退出条件，写不出退出条件的立项不给排优先级。
判断依据来自我自己的观察，能提前定义停止线的项目，最终浪费的人力明显更少，很多团队不是不会排序，而是不敢叫停。
文章包含AI辅助创作：项目立项优先级教程：跨部门团队入门指南，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/283994
读者评论
容量折算这块我有疑问。“按人天/月折算可承载项目数”在专职团队里成立，但我们这种一个人同时挂三四个项目的环境里，折算出来基本是纸面数字。最后还是要靠项目经理每周手动对排期，谁被临时抽走就全盘推翻。可能得先解决人力归属和工时可见性，容量才算得准。
退出机制写进立项书容易，真到执行阶段没人愿意签那个字。我们去年有个项目中期已经明显偏离方向，立项时也写了叫停条件，但因为发起人是分管副总，一直拖到预算烧完才停。所以关键可能不是条件怎么写，而是明确谁有权拍板、以及叫停后谁来承担解释成本。
月度滚动+季度锁盘”看着合理，但月度评审本身的隐性开销不小，各部门准备材料加开会，一个月耗掉的人天有时比项目本身还多。我们后来改成只在有新增或重大变更时才开评审，没议题就不开。另外公开决策日志这招确实有效，被拒的部门知道差距在哪，重复提案少了很多。