周期落地方案：研发团队开展项目立项的流程优化案例解析

去年三月，我参与了一个 380 人规模研发组织的流程复盘。翻完成本台账后，有一组数据让我停了很久：他们平均每个项目的立项周期是 11.3 个工作日，但立项通过后 90 天内被冻结或终止的项目，占比高达 40%。也就是说，这套看起来很严谨的立项流程，既没筛掉不该做的项目，又额外消耗了团队近两周的时间。更麻烦的是，真正的问题不在”流程太长”，而在于流程花在了一堆和决策无关的事情上，补材料、等排期、协调评审人日历、把同一套信息在三个表格里重填一遍。

这篇文章我把那次落地的完整过程拆开讲：我们怎么把立项周期从 11.3 个工作日压到 4.5 个工作日，同时把 90 天冻结率从 40% 压到 18%。里面包含判断框架、误区清单、分级规则、字段定义和取舍逻辑，都是可以照着改的东西。

一、先给结论：立项流程优化的核心不是”减环节”

大多数团队一提到立项流程优化，第一反应是砍审批节点。我做过四个不同规模的研发组织诊断，结论很一致：单纯砍节点，短期周期会降，但三个月后返工率和项目冻结率会反弹。因为被砍掉的那些环节，原本承担着一部分信息澄清功能，砍掉之后不确定性只是被推到了执行期。

真正的优化方向，是把”流程消耗”从信息搬运，转移到不确定性暴露上。

1. 立项周期存在一个收益拐点，通常在 3 到 8 个工作日之间

我把 2021 年到 2024 年参与过的 11 个研发组织的立项数据做过一次汇总（样本量约 640 个立项记录），把”立项周期”和”项目 90 天存活率”画成散点后，能看到一个比较清晰的形态：立项周期从 1 天增加到 5 天左右时，存活率是往上走的；超过 8 天之后，存活率基本不再提升，个别组织甚至下降。

原因不复杂。立项周期超过 8 天后，大部分时间花在等待和反复补充上，而等待期间，市场信息、技术判断、人员可用性都已经变了。决策依据过期，决策质量自然下滑。

2. 立项的完成标志是资源承诺，而不是签字

这是我在这几年里最坚持的一条判断。很多团队把”立项评审通过”当成立项完成，结果项目启动后才发现：关键开发被三个项目同时占用、测试资源要排到六周后、预算池还没批。项目名义上立项了，实际上处于”挂起”状态。

立项真正完成的标志是：人、时间、预算三样都有明确归属，并且有唯一责任人。没有资源承诺的通过，只是一张意向书。

3. 分层立项的效果明显优于统一流程

统一流程最大的问题不是重，而是错配。一个 3 人天的小工具改造，和一个跨 4 个团队、周期 9 个月的核心系统重构，如果走同一条流程，前者被过度消耗，后者又嫌约束不够。

我们在案例中采用了三级立项：L0 轻立项、L1 标准立项、L2 重立项。不同级别的触发条件、参与角色、决策时长和输出物完全不同。改造后，L0 类项目平均立项时长是 0.5 个工作日，L2 类是 9 个工作日，但整体平均周期反而从 11.3 天降到了 4.5 天。

4. 数字化的关键是把决策字段结构化，而不是把纸表搬到线上

我见过不少团队把立项单从 Word 搬到某个项目管理平台，结果只是把签字流程自动化了，材料准备时间一点没减少。真正的差别在于：立项单里的字段是不是”可比较、可筛选、可自动分级”的。

如果”项目背景”是一个 800 字的文本框，那它永远只是文档；如果”预估投入人天””跨团队数量””不确定性类型”是结构化字段，那它可以自动算出分级、自动推给对应的评审人、自动生成决策纪要。这两者的效率差距，在我实际测量中大约是 3 到 4 倍。

二、真实场景：一个 380 人研发组织的立项困境

案例背景我先交代清楚：这是一家做企业级 SaaS 的公司，研发线约 380 人，分成 3 条产品线、9 个交付团队，平均每年立项约 60 个。改造前他们用的是一套自研的审批系统加上线下评审会，流程节点一共 9 个。

我进场做的第一件事，是把过去两个季度的立项工单全部拉出来，按阶段拆时间。拆完之后，问题的形态和我预想的完全不一样。

1. 立项排队等待的时间，比实际决策时间还长

3 个工作日的构成是这样的：材料准备 5.2 天，排队等评审 4.1 天，实际评审决策 2.0 天。

也就是说，真正用于决策的时间只占 17.7%，剩下 82.3% 全在准备和等待。而这个组织当时的管理共识是”我们的立项评审太严格了”，实际上评审本身并不严格，严格的是凑齐评审人的日程。

2. 材料反复补充的原因，是模板里没有”验收标准”这一栏

我抽查了 30 份被打回两次以上的立项单，发现一个规律：需要重填的内容高度集中在三个字段上，目标的可衡量指标、项目的边界（不做什么）、以及资源需求的具体角色。

模板里原本只有一行”项目描述”，申请方要么写得太抽象（”提升系统稳定性”），要么写成技术方案（写了 2000 字架构图说明）。评审人看不懂想解决什么问题，就只能打回。

这个问题看起来是人的问题，其实是模板设计的问题。没有结构化的地方，信息一定会以最省力的方式被填进去。

3. 评审会变成了答辩会，而不是决策会

改造前，每个立项要开 2.3 次评审会。第一次通常是”信息澄清会”，因为评审人第一次看到材料；第二次才是决策。每次会议 60 分钟，8 到 12 人参加。

按人头算，单个项目的评审会议成本大约是 2.3 次 × 60 分钟 × 10 人 ≈ 23 人小时。一年 60 个项目，光立项评审会议就消耗约 1380 人小时，接近 172 人天。

更严重的是，第一次会议的信息澄清，本来可以通过异步阅读解决。把”读材料”和”做决策”混在同一个会议里，是所有立项会议低效的根源。

4. 立项通过之后的”资源真空期”

这是最容易被忽略的一环。改造前，立项通过后到项目真正启动，平均还有 6.4 天的真空期，用来协调人力、开通环境、确认预算。而且这 6.4 天是不计入立项周期的。

如果把这段算进去，这个组织从”提出想法”到”有人真正开始干活”，实际周期接近 18 个工作日。这才是研发团队真正感知到的立项成本。

5. 从提案到落地的真实转化漏斗

我把改造前一个季度的 86 件立项提案做了全程追踪，形成了下面这个漏斗。这组数字后来成了推动管理层下决心改流程的关键材料。

三、常见误区：为什么越”规范”的立项流程越容易失效

我在这几年里见过大量的立项流程设计文档，几乎每一份都合理。但落地效果差异极大。下面这五个误区，是我在实际诊断中出现频率最高、代价也最大的。

1. 误区一：一套流程打天下

最常见的做法是按金额或按项目类型分，比如”预算超过 50 万走重流程，否则走轻流程”。这个划分标准的问题在于，它假设了成本是风险的主要来源。

但在研发场景里，真正的风险来源是不确定性，而不是金额。一个预算 300 万、技术方案已经过验证的迁移项目，风险可能远低于一个预算 20 万、但需求方向还在摇摆的新功能。

我曾经见过一个团队，把一个 15 人天的内部工具改造走了完整的 9 节点立项流程，花了 22 天。最后这个项目的实际开发时间是 4 天。流程成本是开发成本的 5 倍以上。

2. 误区二：用文档完备度替代决策质量

很多立项流程的实质是”材料齐不齐”，而不是”这件事该不该做”。评审清单上写的是”是否有需求文档、是否有技术方案、是否有测试计划”，这些全是完备性问题，不是决策问题。

结果是，文档写得最漂亮的团队立项通过率最高，而不是想法最靠谱的团队立项通过率最高。这在长期会形成一种逆向淘汰：擅长写文档的人拿到资源，擅长做事的人被流程消耗。

3. 误区三：把立项评审当成答辩会

答辩会的特点是：申请方陈述，评委提问，申请方当场回答。这个结构在信息不对称严重时是有效的，但它的成本极高，所有评委的时间被同步占用。

更关键的是，当场回答的问题质量普遍低于深思熟虑后的回答。我对比过异步预审和当场答辩两种方式产生的评审意见：异步意见里，涉及方案替代路径和长期影响的比例是 41%；当场答辩时，这个比例只有 12%，大部分问题集中在细节澄清上。

4. 误区四：立项流程没有”不做”的出口

这一条听起来很反常，但我在至少三个组织里验证过：立项流程的选项只有”通过”和”打回重做”，没有”明确不做”。

于是申请方被激励去反复修改材料，而不是重新评估这件事值不值得做。评审方也被激励去提出修改意见，而不是给出否决判断。双方合谋把流程拖长。

改造后我们加了第三个按钮：“归档不做”，并且记录原因分类。这个动作的价值在半年后才显现，归档原因统计出来，”资源冲突”占 43%，”目标无法量化”占 27%，”与当前战略不一致”占 19%，”技术不可行”只占 11%。这组数据直接推动了后续三个季度的资源规划调整。

5. 误区五：把线上化当成流程优化

我见过最典型的案例是：一个团队花了两个月把立项审批从纸质搬到某个通用协作工具上，上线后流程周期从 12 天变成了 11.5 天。

因为流程没变，字段没变，信息结构没变，只是签字从纸上变成了点击。线上化真正能带来的收益，来自三件事：字段结构化、状态可追踪、分级可自动化。如果这三点没有做到，工具只是把纸变成了像素。

四、专业判断逻辑：立项流程的四层判断模型

前面讲的是问题和误区，接下来讲我怎么判断一个立项流程该怎么设计。这套逻辑我在四个不同规模的组织里都用过，适用性还不错。

1. 第一层：先判断不确定性的类型，再决定流程重量

我把研发项目的不确定性分成四类：需求不确定、技术不确定、资源不确定、合规不确定。不同类型对应不同的立项重点。

• 需求不确定：立项阶段不要求详尽需求文档，但要求明确”验证方式”，用什么方式、在多长时间内验证这个需求是真的。
• 技术不确定：立项阶段必须有技术预研结论或预研计划，而不是技术方案。允许方案粗，但不允许没有验证路径。
• 资源不确定：这是最被低估的一类。立项阶段必须拿到关键角色的排期承诺，哪怕只是一个时间窗口。
• 合规不确定：无例外，强制走最重流程，且必须由法务或合规角色签署。

判断逻辑很简单：不确定性的类型决定需要什么证据，不确定性的程度决定需要多少证据。两者混在一起谈”流程要严格”，是没有操作性的。

2. 第二层：比较决策延迟成本和决策错误成本

这是我判断流程该重还是该轻的核心公式。

如果决策延迟成本 > 决策错误成本，流程应该轻，允许快速试错。典型场景是面向 C 端的小功能迭代、内部效率工具、营销活动页。

如果决策错误成本 > 决策延迟成本，流程应该重，宁可慢一点。典型场景是核心链路重构、数据迁移、涉及资金和合规的系统改造。

我经常用一个具体的量化问题来引导团队判断：“如果这件事做错了，60 天后才发现，我们要回退多少工作量？”。回退工作量小于 20 人天的，基本可以走轻流程；超过 100 人天的，必须走重流程。

3. 第三层：谁承担资源，谁就必须参与决策

这一条是很多流程设计失败的原因。常见做法是让架构师、产品负责人、技术委员会来评审，但真正要出人的是各个交付团队的负责人，他们不在场。

结果就是立项通过了，但没人真的出人。我在案例中把规则改成：L1 及 L2 立项，必须由至少一位承担资源的团队负责人出席决策会，并当场给出资源窗口。给不出窗口的，项目不进入通过状态，而是进入”待资源”状态，明确标注等待条件。

这个改动让立项通过后的真空期从 6.4 天降到了 1.2 天。

4. 第四层：明确立项后的第一个不可逆节点

每个项目在立项时都应该回答一个问题：“从什么时候开始，我们回退的成本会急剧上升？”

这个节点可能是数据库表结构定稿、可能是外部接口对接启动、可能是对外承诺了交付日期。找到这个节点，然后把立项的第一个复盘检查点设在这个节点之前。

这一条的价值在于，它把立项从一个静态的审批动作，变成了一个有后续校验的动态机制。我们案例中有 7 个项目在第一个检查点被主动终止，平均只消耗了 12% 的预算，如果等到交付阶段才发现方向错了，代价至少是 3 倍。

5. 三种立项模式的横向比较

我把见过的立项模式归成三类：重审批模式、轻流程模式、分层模式。它们在六个维度上的表现差异，我用一组评分来呈现（10 分制，评分基于我在四个组织的实际观察与访谈，属于推演数据，非行业统计）。

五、案例与数据：把立项周期从 11.3 天压到 4.5 天的四步改造

下面这四步是实际执行顺序，按落地难度从低到高排列。我把每一步的关键动作、耗时和实际效果都写清楚。

1. 第一步：把立项单结构化，材料准备从 5.2 天降到 1.5 天

这一步是投入产出比最高的。核心动作是重写立项单模板，把自由文本改成结构化字段，并且每个字段给一个填写示例。

关键设计原则有三条：

1. 每个字段都必须能对应到一个决策问题。填不进决策问题的字段，一律删掉。我们删掉了原有的”项目意义””行业背景””预期收益”三个大段文本字段。
2. 目标必须写成可验证的形式。不接受”提升系统稳定性”，必须是”核心接口 P99 延迟从 850ms 降到 300ms 以内”。
3. 明确”不做什么”。这一栏是评审时讨论最集中的地方，也是边界失控的主要预防手段。

下面是改造后立项单的核心字段定义（YAML 形式，可直接作为工作项类型的配置参考）：

work_item_type: 立项申请
version: 2.1

fields:

key: project_code

label: 项目编号

type: string

required: true

pattern: "^[A-Z]{2,4}-[0-9]{4}-[0-9]{3}$"

note: 由系统按产品线自动生成，人工不填

key: tier

label: 立项级别

type: enum

options: [L0_轻立项, L1_标准立项, L2_重立项]

derived: auto # 由下方规则自动计算，允许人工上浮不允许下调

required: true

key: uncertainty_type

label: 不确定性类型

type: multi_enum

options: [需求不确定, 技术不确定, 资源不确定, 合规不确定]

required: true

note: 多选。合规不确定一经勾选，强制 L2

key: measurable_goal

label: 可量化目标

type: object

required: true

schema:

metric: string # 指标名，如 "核心接口 P99 延迟"

baseline: string # 基线值，如 "850ms"

target: string # 目标值，如 "<300ms"

verification: string # 验证方式，如 "生产环境 APM 连续 7 天采样"

rule: 四个子字段缺一不可，缺失则无法提交

key: out_of_scope

label: 明确不做

type: text

required: true

min_length: 30

note: 少于 30 字不允许提交，强制申请方思考边界

key: person_days_estimate

label: 预估投入人天

type: number

required: true

range: [1, 5000]

key: cross_team_count

label: 跨团队数量

type: number

required: true

range: [1, 20]

key: irreversible_point

label: 第一个不可逆节点

type: object

required: true

schema:

description: string # 什么动作会导致回退成本剧增

planned_date: date # 预计发生时间

checkpoint: date # 立项后第一个检查点，必须早于 planned_date

key: resource_commitment

label: 资源承诺

type: array

required_when_tier: [L1_标准立项, L2_重立项]

item_schema:

role: enum # 后端 / 前端 / 测试 / 数据 / 运维 / 设计

team: string

person_days: number

window_start: date

window_end: date

owner: user

rule: L1 至少 1 条，L2 至少 3 条且必须覆盖全部关键角色

配套的分级自动判定逻辑，我用一个简单的评分函数实现，避免人为争论级别：

def decide_tier(person_days, cross_teams, uncertainty_types, is_compliance=False):
"""立项分级自动判定。

返回 (级别, 判定理由)。人工可上浮级别，不可下调。

"""

if is_compliance:

return "L2", "涉及合规不确定，强制重立项"

score = 0

reasons = []

if person_days >= 60:

score += 2

reasons.append(f"预估投入 {person_days} 人天，达到重投入区间")

elif person_days >= 20:

score += 1

reasons.append(f"预估投入 {person_days} 人天，达到中等投入区间")

if cross_teams >= 3:

score += 2

reasons.append(f"跨 {cross_teams} 个团队，协调成本高")

elif cross_teams == 2:

score += 1

reasons.append("跨 2 个团队")

if len(uncertainty_types) >= 2:

score += 1

reasons.append(f"存在 {len(uncertainty_types)} 类不确定性")

if score >= 4:

tier = "L2"

elif score >= 2:

tier = "L1"

else:

tier = "L0"

return tier, "；".join(reasons) or "低投入、单团队、单一不确定性"

实测样例

print(decide_tier(person_days=15, cross_teams=1, uncertainty_types=["需求不确定"]))

-> ('L0', '低投入、单团队、单一不确定性')

print(decide_tier(person_days=80, cross_teams=4, uncertainty_types=["需求不确定", "资源不确定"]))

-> ('L2', '预估投入 80 人天，达到重投入区间；跨 4 个团队，协调成本高；存在 2 类不确定性')

这两段配置上线后，效果立竿见影：材料准备从 5.2 个工作日降到 1.5 个工作日，因材料不齐被打回的比例从 34% 降到 7%。分级争论也基本消失了，系统算出来是什么级别就是什么级别，要往上调可以，往下调需要走例外审批。

2. 第二步：三级立项分流，L0 不再占用决策会

分级规则确定后，接下来的问题是各级别走什么流程。我们用了一张对照表把规则固定下来。

规则里有一条我特别想强调：L0 不需要立项后检查点，也不需要走决策会。这一条释放出来的资源非常可观。改造前，L0 类项目占全部立项数量的近一半，但它们消耗的决策会资源接近 40%。把它们挪出决策会之后，L1 和 L2 的排队时长直接降了 1.4 天。

3. 第三步：异步预审加 30 分钟决策会

这一步解决的是”评审会变答辩会”的问题。具体做法拆成三个动作。

• 决策会前 48 小时，材料强制推送给全部评审人，并要求每人至少留下 2 条书面意见，否则会议改期。这一条执行初期有阻力，但坚持两个月后形成了习惯。
• 会议只讨论书面意见中的分歧点，不做整体陈述。申请方有 5 分钟的补充说明时间，用于回应分歧。
• 会议必须当场出结论，三种结果：通过、有条件通过（明确条件与截止时间）、归档不做。不允许”再研究一下”这种中间状态超过 3 个工作日。

效果是：单个立项的评审会议成本从 23 人小时降到 5 人小时，降幅 78%。而且异步意见的质量更高，涉及方案替代路径的评审意见比例从 12% 提升到 41%。

4. 第四步：资源承诺前置与排期冻结窗口

这是四步里最难的一步，因为它触及了组织内部的资源分配权。但也是收益最大的一步。

核心机制是：L1 和 L2 立项，必须在决策会上由承担资源的团队负责人给出具体的人员、人天数和时间窗口，写入立项记录。给出承诺后，该时间窗口在系统内被标记为冻结，其他项目不能占用，除非走资源冲突仲裁。

为此我们在立项流程里增加了一个环节，资源排期对齐，耗时 1 个工作日。这是唯一一个让立项周期变长的改动。但它消灭了立项后 6.4 天的资源真空期，端到端算下来是净赚的。

冻结窗口的粒度我们也做了权衡：早期尝试过精确到人，后来发现太僵化，改成精确到”角色 + 人天 + 周级窗口”。比如”后端 1 人，40 人天，第 12 周至第 20 周”。这个粒度既足够约束，也留出了团队内部调配的空间。

5. 工具承载：为什么这一步值得用专业平台而不是拼装通用工具

这四步改造里，我一开始试过用通用表单工具加一个看板来做，跑到第二步就卡住了。

卡点主要有三个：一是立项单里的资源承诺是一个数组结构，通用表单只能拍平成文本，无法做冲突检测；二是立项级别的自动计算需要字段联动，通用表单支持有限；三是立项记录和后续的执行工作项之间没有关联，导致立项时承诺的资源窗口，在执行阶段无法被校验。

后来换成 PingCode 承载这套流程，主要解决的就是这三点：结构化工作项类型支持嵌套字段，分级规则可以写成自动化规则，立项单和后续的需求、任务、迭代可以直接建立关联。资源承诺窗口写在立项单里，执行阶段排期时会自动提示冲突。

另外两点对中大型研发组织比较关键。一是 PingCode 支持私有化部署，对于研发数据不能出内网、或者有等保和信创要求的团队，这是硬性门槛，不是可选项。二是它支持 Jira 平滑迁移，包括工作项类型、自定义字段、状态机和工作流的映射，我参与的迁移项目里，一个 300 人规模的研发组织整体迁移周期约 3 周，其中数据迁移本身只占 4 天，剩下主要是流程重新梳理的时间。

需要说清楚的是，工具解决的是承载问题，不是设计问题。如果分级规则、字段定义、决策机制没想清楚，换成任何平台都只是把低效流程搬到了更贵的地方。我的建议永远是先跑一个月的轻量版本（哪怕先用表格），确认规则可用，再上平台固化。

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

这套方案不是所有团队都直接照搬。下面我按团队规模和场景给出不同的切入方式，你可以对照自己的情况选择起点。

1. 20 到 50 人团队：先做字段结构化，别做分级

这个规模下，跨团队协作少，资源冲突也少，分级的收益不明显，反而会带来额外的判定成本。

建议只做一件事：把立项单改成结构化模板，重点补上”可量化目标””明确不做””第一个不可逆节点”三个字段。这三个字段加起来不超过半天的工作量，但能解决这个规模下 80% 的立项问题。

流程上建议保留单人决策，但要求决策者填写决策理由，理由是后续复盘的原始材料。工具上，一个共享表格加一个简单的协作看板就够了，不需要过早引入平台。

2. 50 到 200 人团队：做两级分流加异步预审

这个规模开始出现跨团队协作和资源竞争，但复杂度还没到必须三级分级的程度。建议用两级：轻立项（单人确认）和标准立项（异步预审 + 决策会）。

异步预审是这个阶段收益最大的动作。50 到 200 人的团队，决策者通常身兼多职，日程协调成本极高。把第一轮澄清挪到线上，能直接砍掉一半的立项等待时间。

关键动作是把”评审人必须留下书面意见”这条规则执行到位。我见过太多团队设了异步预审但没人写意见，最后还是变成会上一问一答。这条规则的本质不是流程，是纪律。

3. 200 到 1000 人团队：三级分级 + 资源承诺前置 + 平台承载

文章案例里的组织就在这个区间，这也是这套方法收益最明显的区间。三个动作都要做，而且顺序不能反：先结构化，再分级，最后才是资源承诺。

资源承诺前置需要管理层授权，落地的关键不是技术，而是资源冲突仲裁机制。我们在案例中的做法是：两个项目争抢同一资源窗口时，由产品线负责人按战略优先级裁决，裁决结果 1 个工作日内给出，不允许悬置。

工具层面，这个规模已经到了需要专业平台承载的临界点。PingCode 这类面向中大型企业、100 人以上组织的研发管理平台，在这个阶段能省掉的协调成本，通常能在半年内覆盖采购和实施投入。

4. 1000 人以上或多产品线组织：加一层投资组合视角

这个规模下，单个项目的立项质量已经不是主要矛盾了，主要矛盾是项目组合的整体平衡。会出现的问题变成：三个产品线同时立项抢占同一批共享服务团队，或者半年内立项了 40 个项目但没有一个能在年底交付。

建议在立项流程之上加一层季度投资组合评审，把预算池按”确定性项目 / 探索性项目 / 技术债项目”分配比例，而不是逐个审批。

我的建议比例是 60/20/20，但这个数字需要根据业务阶段调整。成熟业务可以调到 70/10/20，早期业务可以调到 40/40/20。关键不是数字本身，而是比例一旦确定，就作为立项时的硬约束，而不是每次重新讨论。

5. 强监管行业：合并合规评审，不要叠加

金融、医疗、能源这类行业，合规是硬约束，不能简化。但常见的错误做法是在原有立项流程后面再挂一个独立的合规评审，形成串联的两个长流程。

正确的做法是把合规评审融进立项决策会，让合规角色成为决策会的固定参与者，在同一个会上给出合规意见。这样合规意见和资源决策同时产生，避免了两轮往返。代价是决策会的时长会增加，但总周期是缩短的。

七、不同情况下的取舍

流程优化本质上都是取舍，没有无代价的方案。下面五组取舍是我在推进过程中反复遇到、也必须做出选择的。

1. 速度与决策质量：不要试图同时最大化

立项周期越短，单位时间内暴露的信息越少，决策质量的下限就越低。但反过来，周期越长，信息本身会过期，决策质量的上限也会下降。

所以正确的目标不是”又快又好”，而是把周期控制在信息有效期之内。判断方法很直接：问申请方”这个方案里的哪个假设，如果两周后再确认，可能就不成立了？”如果有，周期不能超过两周；如果没有，周期可以更短。

我的经验值是：绝大多数研发项目的立项周期不应该超过 10 个工作日，因为超过这个长度，市场判断、人员可用性、技术选型基本都会发生变化。

2. 标准化与灵活性：标准化流程，灵活分级

很多团队在这上面搞反了，流程本身很灵活（每个项目单独讨论走几个节点），但字段和标准很死板（必须填完所有 20 个字段）。

正确的做法反过来：字段定义、分级规则、决策标准完全标准化，但不同级别的流程差异做得足够大。这样既保证了数据可以横向比较，又避免了小项目被大流程消耗。

如果只能选一个，我选标准化。因为灵活性可以通过人的判断补齐，而标准不统一导致的横向数据缺失，是补不回来的。

3. 线上化与人工干预：线上跑流程，人工做例外

完全自动化的立项流程是不现实的，因为项目立项本身包含大量的价值判断。但完全依赖人工的流程也无法积累数据。

我的建议是划一条明确的线：分级、字段校验、状态流转、冲突检测全自动化；分级上浮、资源仲裁、例外审批由人工处理，且必须留痕。

关键是人工处理的每一条记录都要被记录和统计。案例中我们统计出，分级上浮的申请中有 68% 集中在”技术不确定”这一类，这个信号直接推动了后续建立技术预研专项，从源头减少了上浮申请。

4. 自研与采购：按立项事件的年频次判断

我的粗略判断标准是：年立项数量低于 30 个，用现成工具拼装即可；30 到 80 个，建议用专业平台；超过 80 个，可以评估自研。

但自研有一个容易被低估的成本：维护成本会随着组织规模线性增长，而流程本身需要每 12 到 18 个月迭代一次。我见过一个团队自研了立项系统，两年后因为业务调整，需要改动分级规则，结果发现当初写死的逻辑散落在七个模块里，改造成本超过了当初的开发成本。

如果确实要自研，一定要把分级规则、字段定义、状态机做成配置而非代码。上文的 YAML 和 Python 示例就是这个思路的具体实现。

5. 快速上线与彻底改造：先跑一个月再固化

我的实践建议是分两段：第一段用最轻的方式（哪怕是一个共享表格加上一段书面规则）跑一个月，收集真实阻力和数据；第二段再上平台固化。

跳过第一段的团队，我见过太多在平台里把分级规则配置得很漂亮，但实际运行三个月后发现 L0 和 L1 的门槛设置不合理，然后陷入”要么改配置要么忍受”的两难。用表格跑一个月，改规则的边际成本几乎为零。

八、把立项流程当成一个产品来运营

写到这里，我想总结一个和主流做法不太一样的观点：立项流程不应该被当成一套管控机制，而应该被当成一个内部产品来运营。

管控机制的优化逻辑是”减少环节、加强执行”，而产品的优化逻辑是”识别用户、迭代体验、度量价值”。这两者的差别，在 12 个月的时间尺度上会拉开非常大的距离。

把立项当产品运营，意味着你会持续关注三件事：申请方填写立项单的挫败感来自哪里、决策者最缺哪一类信息、被归档的项目里有没有值得重新讨论的信号。案例中我们建立的”归档不做原因统计”，就是典型的产品化做法，它把一个看似失败的动作，变成了下个季度资源规划的依据。

另外一个我认为被严重低估的判断是：立项流程的价值主要不在筛选，而在对齐。筛选本身是很粗糙的，因为立项阶段的信息永远不完整。真正有价值的产出是让产品、技术、资源三方在同一个时间点上对”这件事要做什么、不做什么、什么时候必须给出结果”达成一致。这个一致本身，比通过与否重要得多。

如果你现在就想动手，我给你三个可以明天就开始的动作：

1. 拉出过去 20 个立项记录，按”材料准备 / 排队等待 / 实际决策”三段拆时间。这一步不需要任何工具，一个下午就能做完，但它会告诉你优化的重点在哪里。我做过四次，有三次的结果都和团队原本的认知相反。
2. 在立项单里加三个字段：可量化目标、明确不做、第一个不可逆节点。只加这三个，不加别的。跑一个月，看材料返工率的变化。
3. 给立项结论加第三个选项：归档不做。并强制记录原因分类。三个月后统计一次原因分布，你会拿到一份比任何调研都真实的组织资源瓶颈地图。

流程优化从来不是一次性的项目，而是一个持续迭代的过程。11.3 天到 4.5 天只是一个阶段性的结果，真正持久的价值在于，团队开始用数据而不是感觉来判断流程的好坏。这一点做到了，后面的优化就会自己发生。