周期落地方案：产品经理开展项目立项的制度设计案例解析

很多产品经理把立项制度理解成一道闸门：材料写全、ROI 算出来、评审会开完，就算完成立项。我在一家 800 人规模的 SaaS 公司里参与过三次立项制度重构，前两次都栽在同一个地方，制度是按”最坏情况”设计的，执行成本却由”最常见情况”承担。结果是小需求被卡了 45 天，大项目依然在评审会上靠嗓门大小决定资源。第三次我们换了思路：不设计流程，设计周期。这篇文章会把这套周期落地方案完整拆开，包括我们踩过的坑、改出来的制度结构、以及在项目管理平台里怎么把它变成可执行、可度量、可迭代的系统能力。

一、先说结论：立项制度的本质是给不确定性定价

如果只让我留一句话给正在设计立项制度的产品经理，我会说：立项制度的本质不是审批，而是给项目的不确定性定一个价格。价格定高了，团队不敢做任何有探索价值的事；价格定低了，组织就被一堆低质量立项消耗掉研发产能。

1. 立项不是审批节点，而是资源承诺的定价动作

一个立项被”通过”，组织实际承诺的不只是一份文档，而是三样东西：一段独占的研发排期、一笔可量化的预算、以及若干关键角色未来数月的时间注意力。这三样都是稀缺资源。

所以立项评审真正在回答的问题不是”这个需求好不好”，而是”我们愿意为这个不确定性付多少资源”。前者是价值判断，后者是定价判断，后者才需要制度。

我见过太多团队的立项会变成需求宣讲会：产品经理讲 40 分钟背景，评委问 5 个问题，最后主持人说”方向没问题，回去细化吧”。这场会开了 2 小时，没有对任何资源做承诺，也没有拒绝任何东西。没有被拒绝可能的立项会，等于没有立项制度。

2. 周期落地方案的核心是把项目分进三个周期带

“周期”在这套方案里有两层含义，两层都必须同时成立，否则制度会畸形。

第一层是项目自身的周期带：探索周期、验证周期、交付周期。这三类项目的不确定性相差一个数量级，用同一套评审标准必然一边过松一边过严。

第二层是制度本身的迭代周期：立项制度不应该一次设计到位，而应该按季度滚动修订，每季度用真实数据回看一次规则的有效性。我们第一版制度两年没改，最后变成一份没人读的文档。

3. 制度的第一约束是决策成本不能大于决策价值

这是我在第二次重构时才想明白的。一个立项决策的价值，大致等于”如果这个决策做错了，我们会损失多少”。如果这个损失预期是 5 人天，那么花 3 个人开 2 小时评审会去决策，加上材料准备时间，决策成本已经超过决策价值本身。

用这个约束反推，我们的制度里出现了这样一条硬规则：预计投入小于 20 人天的项目，不允许开评审会，只允许备案。评审会这种高成本决策形式，只能用在值得开的项目上。

这条规则刚推出来被质疑得很厉害，最常见的反对意见是”那小需求乱做怎么办”。实际跑了两个季度，小需求造成的事故数是 0，因为小需求的风险不在”做不做”，而在”做完之后有没有人负责验收”，我们把这个控制点后移到了验收环节，成本低得多。

二、真实场景：一个 800 人研发组织的立项制度重构

先交代清楚背景，不然下面的判断会显得悬空。这家公司主营 B 端 SaaS，研发体系约 800 人，下辖 6 条产品线、3 个平台组、1 个交付实施中心。产品经理 47 人，平均每人每季度提交 6 到 9 个立项申请。

1. 改造前的立项流程长什么样

改造前我们用的是典型的五级审批链。产品经理提需求 → 产品线负责人初审 → 产品委员会评审 → 技术负责人评估资源 → 研发总监排期。每一级都有独立的表单和材料要求。

表单字段多达 32 个，其中必填 21 个，包括市场规模测算、竞品分析、财务 ROI、技术风险等级、跨部门依赖清单。填一份完整立项材料，产品经理平均要花 2.5 天。

这个流程在 2019 年设计出来时是合理的，当时公司只有 200 人，一个季度立项不到 30 个，走重流程扛得住。问题在于人员规模翻了 4 倍之后，流程没有跟着变，而立项数量涨到了每季度 400 个以上。

2. 我们踩到的三个具体坑

第一个坑是”材料完备度”被当成了质量代理指标。评审会上评委最先看的是材料齐不齐，而不是内容对不对。结果是产品经理把大量时间花在把 21 个必填字段填满，而不是想清楚这件事该不该做。

第二个坑是评分制让所有项目都变成 70 分。我们一度引入 100 分制评分卡，五个维度加权。跑了三个季度发现，92% 的项目得分落在 65 到 78 之间，区分度几乎为零。原因是所有人都学会了在评分卡的维度上做表述优化。

第三个坑是立项通过之后没有”复审点”。项目立项时承诺 3 个月交付、投入 8 人，实际做到第 5 个月、投入 14 人，中间没有任何机制触发重新决策。立项变成了一次性授权，而不是分段承诺。

3. 重构的目标与约束条件

第三次重构前，我们把目标写死成三条，不允许中途加戏。

• 决策周期目标：80% 的立项申请从提交到拿到结论不超过 10 个工作日，其中低不确定性项目不超过 3 个工作日。
• 决策成本目标：单个立项的平均评审投入不超过 6 人小时，材料准备不超过 0.5 人天。
• 可追溯目标：任何一个在研项目的立项依据、资源承诺、复审记录都能在 1 分钟内被调出。

第三条是这次重构和之前最大的区别。前两次我们只盯着”流程是否顺畅”，这次把”可追溯”作为硬目标，直接决定了制度必须落进工具而不是文档里，因为人工维护的可追溯性，三个月内一定会烂掉。

三、常见误区：产品经理设计立项制度时的五个惯性动作

这一节我想说得直接一点，因为这五个动作我全部亲自犯过，而且每一个都有看起来很合理的理由。

1. 用一套流程覆盖所有项目类型

最常见的理由是”公平”。如果小项目走轻流程、大项目走重流程，会不会有人故意把大项目拆小来规避评审？

这个担心是真实的，但用一套重流程去防它，代价是所有人一起变慢。正确的解法不是统一流程，而是把”拆项目规避评审”本身定义成违规，并对拆包行为做后置审计。我们把审查从”前置防所有人”改成”后置查少数人”，制度成本一下子降了一个量级。

2. 把立项做成一次性事件而不是周期过程

一次性立项的隐含假设是：立项时刻掌握的信息足够支撑整个项目周期的决策。这个假设在探索类项目上几乎必然破产。

我们统计过改造前 60 个中大型立项，从立项到结题，需求范围平均变更 2.7 次，其中 41% 的项目在变更后与初始立项文档的核心假设已经不一致。立项文档不是合同，它是一份有时效的假设集合。既然是假设，就必须有失效检查点。

3. 用财务 ROI 校准早期产品决策

这不是说 ROI 没价值，而是说 ROI 的适用区间比大多数人以为的窄得多。在探索周期，你能拿到的收入预测误差通常在 ±300% 以上，用这种精度的数字做决策，本质是在用假精度制造共识。

我们做过一次回溯：改造前 38 个被驳回的项目中，有 11 个的理由是”ROI 不达标”。这 11 个项目后来有 6 个通过其他渠道重新启动并上线了，其中 2 个成为当年收入贡献前 10 的功能。被 ROI 拦下来的，往往不是不重要的项目，而是最难被量化的项目。

4. 把”立项通过”等同于”资源到位”

这是最容易被忽视的一个。立项审批和资源排期在大多数组织里是两套独立系统：立项会决定了”可以做”，排期会决定了”什么时候做”。两者之间隔着几周甚至几个月。

这中间的时间差制造了一个管理黑洞：项目状态显示”已立项”，但没有任何人在做。我们改造前统计，处于这个状态的项目平均停留 34 天，最长的一个停了 147 天。

5. 制度只写成文档，不落进工具

文档型制度的衰减速度比我预想的快得多。第一版制度发布时，我们做了全员培训、发了流程图、还配了 FAQ。三个月后抽查，规则执行一致率只有 57%；六个月后降到 31%。

衰减的原因不是大家不认可制度，而是执行制度需要额外的认知负担。凡是需要人记住的规则，都会衰减；凡是工具自动执行的规则，才会稳定。

四、专业判断逻辑：按不确定性和不可逆性分档

前面讲了问题，这一节讲我们最终采用的判断框架。整个框架只有两个维度、三个档位，我刻意控制了复杂度，因为超过三个档位的制度，执行时一定会退化成”凭感觉判断”。

1. 两个判断维度：不确定性 × 不可逆性

不确定性衡量的是”我们现在对这个项目的认知有多不牢靠”。判断方法不看需求文档写得多详细，而是看三个具体问题：目标用户是否已经明确到可指名、解决方案是否存在已验证的同类先例、成功标准是否可以用一个可观测的行为指标描述。三个问题答不上来两个以上，就属于高不确定性。

不可逆性衡量的是”如果这个项目做错了，退回来的代价有多大”。判断依据包括：是否涉及数据迁移或对外承诺、是否占用独占性资源、是否会产生需要长期维护的技术资产。不可逆性高的项目，即使不确定性低，也应该走更严格的评审。

这两个维度组合出四种情况，但只有三种需要不同的制度档位，第四种（低不确定性 + 低不可逆性）直接归入备案即可。

2. 三个周期带的定义与准入条件

这张表的关键在于：分档的依据不是投入金额，而是不确定性等级。投入金额只是结果，不是依据。我在实际推行时发现，如果只按金额分档，产品经理会习惯性地把估算压低来走轻流程；按不确定性分档则很难操纵，因为三个判断问题需要具体回答。

3. 每个周期带的决策人与退出条件

制度里最容易含糊的两个字段是”谁拍板”和”什么时候算结束”。这两个字段不写死，前面所有的分档都会失效。

探索周期的决策人是产品线负责人，不需要委员会。因为这类项目不占用跨部门资源，风险被限定在 20 人天以内，由最了解业务的人快速拍板效率最高。退出条件写死为：连续两个迭代未产出可观测的验证数据，自动关闭，不允许续期。

验证周期的决策人是产品委员会的一个三人小组，异步评审。三人小组实行轮值制，避免固定成员成为瓶颈。退出条件是达到预设的成功指标（进入交付带）或触发止损条件（关闭）。止损条件必须在提交时写清楚，不接受”看情况调整”。

交付周期的决策人是产品委员会全体加技术负责人。这类项目的不可逆性最高，退出条件是里程碑完成或触发重新评估。这里有个特殊规则：交付带项目在中期如果范围变更超过 30%，必须重新回到评审环节，不能由项目经理自行吸收。

五、案例与数据观察：把周期落地方案搬进 PingCode

制度设计的最后一步，也是最容易被跳过的一步，是把它变成工具里可执行的规则。我们最终选择在 PingCode 上承载这套方案，理由和落地效果我完整说一下。

1. 为什么选择 PingCode 承载这套立项制度

我们的约束条件有三个：第一，公司规模 800 人，跨 6 条产品线，需要能支撑中大型组织的权限与流程复杂度；第二，涉及收入与客户数据的立项信息，必须支持私有化部署；第三，我们原本用的是 Jira，历史项目和需求数据不能丢，迁移过程不能中断业务。

这三个条件筛下来，可选范围其实不大。PingCode 支持私有化部署，对我们的数据合规要求是硬性满足的；同时它提供了从 Jira 平滑迁移的能力，这一点在我们后来实际执行迁移时价值极高。对于正在做国产替代的团队来说，这是一个不需要反复权衡的选择。

更关键的是它的配置能力能直接表达我们这套分档制度：不同项目类型可以绑定不同的工作流、不同的必填字段、不同的审批节点，而审批节点的通过条件可以写成规则而不是靠人判断。这正好解决了我们前面说的”文档型制度会衰减”的问题。

2. 具体配置：把三个周期带变成三条工作流

我们在 PingCode 里建了三个项目模板，分别对应探索、验证、交付三个周期带。每个模板绑定了不同的字段组和流转规则。下面是我们探索周期模板的核心配置结构，字段名做了简化。

project_template: 探索周期备案
fields:

required:

核心假设 # 一句话，不超过 80 字

验证指标 # 必须可观测，例如"7 日内激活率提升 5%"

验证窗口 # 最长 2 个迭代

预算上限 # 默认 20 人天，超出自动升级到验证周期

optional:

关联需求

关联客户反馈

workflow:

状态: 草稿

状态: 待备案

触发: 提交后自动通知产品线负责人

时效: 24 小时未处理则自动生效并抄送负责人

状态: 执行中

自动检查: 每迭代结束时校验验证指标是否填写进展

状态: 已关闭

触发: 验证窗口到期 或 连续两迭代无进展

这段配置里最重要的两条规则是”24 小时未处理自动生效”和”连续两迭代无进展自动关闭”。前者防止备案变成隐性审批，后者防止探索项目变成无法关闭的僵尸项目。没有这两条自动规则，探索周期带会迅速退化成”随便报随便做”。

3. 迁移与上线的真实节奏

我们在 Jira 上积累了 4 年多的数据，包括约 1.2 万个需求条目和 900 多个项目。迁移不是一次性切换，而是分了三批：先迁平台组（影响面最小），再迁两条试点产品线，最后全部切换。

第一批迁移用了 6 个工作日，主要时间花在字段映射上；第二批用了 9 个工作日，因为涉及两个产品线的自定义工作流；第三批全量迁移用了 14 个工作日，这里面有 4 天是并轨运行期的双写验证。整个过程中业务没有中断，历史项目的状态和关联关系都保留了。

4. 数据观察：上线前后三个季度的对比

制度切换完成后，我们连续追踪了三个季度。下面这组数据是内部统计口径，来自项目管理平台导出的立项记录与研发工时系统，样本覆盖 396 个立项申请。

有一项数据我需要特别说明：立项数量下降了 7.5%，但交付带项目的数量反而上升了 12%。这个变化说明分档制度做的不是”减少立项”，而是把资源从低价值的重复立项里挪到了真正需要投入的项目上。

另一个值得关注的数据是”已立项未启动”项目从 63 个降到 11 个。这部分改进主要来自工具层的规则，立项通过后如果没有在 5 个工作日内绑定迭代，系统会自动提醒产品线负责人，超过 10 个工作日未绑定则自动回到待排期状态。这是纯靠文档制度做不到的。

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

前面讲的是一套在 800 人组织中跑通的方案。但我知道大多数读者所在的团队规模和管理成熟度都不一样，所以这一节按规模给出差异化建议。需要提前说明的是，分档制度在越小的团队里收益越低，因为沟通成本本身就很低，制度带来的边际价值有限。

1. 100 人以下的团队：不要建制度，建清单

这个规模下我最不建议做的事就是搞审批流程。100 人以内的研发组织，产品经理和研发负责人基本在同一个物理空间或同一个群里，一次对话就能完成的决策，不值得用三份表单代替。

你真正需要的是一个立项清单，而不是一套立项流程。清单上只放四个字段：这件事解决谁的什么问题、我们怎么知道做成了、需要谁投入多久、什么时候回看。四个字段写不满，说明这件事还没想清楚。

唯一值得自动化的规则是”什么时候回看”。可以在团队使用的项目管理工具里给每个立项条目设一个复查日期，到期自动提醒。这一条规则的成本几乎为零，但能避免大量”做着做着忘了为什么做”的情况。

2. 100 到 500 人的组织：建立两档制度

这个区间是分档制度收益最明显的阶段。团队已经大到无法靠对话同步，但还没大到需要复杂的委员会结构。我建议只建两档：轻档和重档。

轻档对应探索与验证周期，走异步评审，决策人是一个明确指定的角色，不是一群人。重档对应交付周期，走评审会，参与者控制在 5 人以内。三档制在这个规模下往往会导致规则数量超过执行能力。

这个阶段最值得投入的是工具配置而不是制度文本。把两档制度的准入条件和必填字段写进项目管理平台的项目模板里，让规则自动生效，比写一份 20 页的制度文档有效十倍。如果团队正在从 Jira 迁移，这恰好是一个把立项规则一起重做的时机，不要只是把旧流程原样搬过去。

3. 500 人以上的多产品线组织：三档加季度回看

到了这个规模，制度的稳定性比灵活性更重要。三个周期带的划分基本够用，不要继续细分，因为每多一个档位，边界判定的争议就会成倍增加。

这个阶段真正需要新增的机制是季度回看。每季度用平台导出的数据回看三件事：各档位的实际决策时长是否符合目标、止损机制触发了多少次、有多少项目在变更后没有重新评审。

回看的目的不是考核，而是修正规则。我们就是通过季度回看发现”拆包规避评审”这个漏洞的，某个产品线连续三个季度提交了大量 19 人天的立项申请，刚好卡在 20 人天的备案线上。这个模式在单个季度的数据里看不出来，拉到三个季度就很明显。

4. 正在做工具迁移的团队：借迁移做一次制度重构

如果你所在的团队正在做国产替代，从原来的工具迁移到 PingCode 这类支持私有化部署的平台，我认为这是做制度重构成本最低的窗口期。原因很简单：迁移本身就要重新梳理字段、工作流和权限，这套梳理工作和立项制度设计高度重叠，分开做等于做两遍。

具体做法是在迁移前先完成制度分档设计，然后按新制度定义迁移映射关系。我们当时的顺序就是这样：先用三周时间确定三个周期带的字段与流转规则，再开始数据迁移。如果反过来先迁数据再改流程，会面临大量历史数据与新规则不兼容的问题。

七、不同情况下的取舍

这一节写的是这套方案里我没有标准答案、只能给出取舍建议的部分。制度设计里真正难的不是知道该做什么，而是知道在什么条件下应该放弃什么。

1. 制度粒度与执行成本的取舍

粒度越细，控制力越强，但执行成本和规则维护成本也越高。我们的经验值是：当一条规则的实际触发频率低于每月 3 次时，它带来的控制收益通常抵不上团队记住它和理解它的成本。

按这个标准，制度里应该只保留高频触发的规则。低频但重要的场景，改用后置审计而不是前置审批，比如前面提到的拆包规避评审，我们没有加前置规则，而是放在季度回看里查。

这个取舍的代价是：你必须在事后处理一些本可以在事前避免的问题。收益是：99% 的正常立项不会被为 1% 的异常情况设计的规则拖慢。对绝大多数组织来说，这个交换是划算的。

2. 审批层级与决策速度的取舍

审批层级每增加一级，平均增加 1.5 到 3 个工作日的等待时间。但这个数字不是线性的，第一级审批加的是最快的，第三级之后每加一级带来的延迟会显著上升，因为跨层级沟通和材料重新组织的成本更高。

我的建议是把层级控制在两级以内，多出来的判断尽量转化为”分权 + 后置审计”。如果确实需要更高级别的把关，用”知情不拦”的方式处理：高级别管理者收到通知但不需要签字，只有主动提出异议才进入审批。

这个机制的代价是不签字的人也要承担结果责任，需要在组织文化上配合。如果所在组织的问责文化比较重，这一条可能推不动，那就只能接受多一级审批带来的速度损失。

3. 工具统一与团队自治的取舍

统一到一套项目管理平台能带来可追溯性和数据一致性，代价是某些团队会觉得自己原有的工作方式被改变。我们迁移时遇到的最大阻力不是技术问题，而是两个产品线坚持要保留自己的字段命名习惯。

我们的处理方式是分层：立项层的数据结构必须统一，执行层的工作流允许在模板范围内自定义。也就是说，立项申请表、决策记录、资源承诺这三类数据在全公司用同一套字段；而具体到迭代怎么开、任务怎么拆、看板怎么摆，各产品线可以有自己的配置。

这个取舍的边界是清晰的：凡是需要跨产品线比较和汇总的数据，必须统一；凡是只在一个团队内部使用的视图，允许自治。如果反过来做，会出现”立台账时数据对不上、做看板时团队不配合”的双输局面。

4. 制度稳定性与季度迭代的取舍

最后说一个容易被忽略的取舍：制度本身要不要频繁改。改得太频繁，团队会形成”等下次改完再说”的观望心态；改得太慢，规则会与实际情况脱节。

我们的做法是分层迭代：周期带的划分边界一年不动，评审的具体规则每季度可以调整，字段和自动化规则随时可以改。前面两层的稳定性给团队安全感，最后一层的灵活性保证制度不会僵化。

判断一个规则该不该升到更高层级去改动，我用的标准是：这条规则的变化会不会影响产品经理对”我需要准备什么”的预期。会影响，就走年度变更；不影响，季度或随时改都可以。

回到最开始那句话。立项制度不是把项目管住的工具，而是给不确定性标价的机制。价格定得对不对，不取决于制度写得多完整，而取决于它是否与项目类型匹配、是否被工具自动执行、是否有周期性的回看机制来纠正偏差。

如果你现在正准备动手，我建议的下一步是：先不要写制度文档，而是把过去两个季度的立项记录拉出来，按”不确定性”和”不可逆性”重新分类，看看实际分布是几档。大多数的第一反应是三档，实际数据往往会告诉你只需要两档，甚至一档。