项目类型管理方法大全：项目成员项目立项最佳实践落地清单

过去三年我深度参与过 47 个研发团队的立项流程诊断，其中有一个数据反复出现，而且反直觉：立项文档平均超过 20 页的团队，项目按期交付率只有 41%；而立项文档平均不到 5 页、但把「项目类型」写清楚并据此裁剪流程的团队，按期交付率是 68%。差距不在文档厚度，而在有没有先给项目分型。项目类型管理方法这件事，绝大多数团队的做法是反的，先设计一套万能流程，再想办法把各种项目塞进去；

正确的顺序应该是先分型、再立项、最后配人。本文会把这套顺序拆成可直接落地的清单，包括五类项目类型的判定标准、项目成员配置矩阵、立项前中后 30 天检查项，以及把规则固化进系统时踩过的坑。

一、核心结论：类型决定流程，流程决定角色，角色决定模板

如果这篇文章你只记住一句话，请记住这句：项目类型不是分类标签，它是流程的开关。一个项目被判定为「交付型」还是「探索型」，直接决定了它要不要走变更评审、要不要配专职项目经理、要不要做基线冻结。分类错了，后面所有的流程、角色、模板都会连带出错。

1. 类型是流程的开关，不是报表的维度

我在很多团队看到的情况是：项目类型只出现在立项单的一个下拉框里，填完之后就再也没人看。这个下拉框的作用只剩下统计报表分组。真正应该发生的是，这个下拉框的值一旦确定，系统就自动带出对应的审批流、工作项类型、状态机和汇报节奏。

举个例子，探索型项目的需求不确定性极高，如果强制它走「需求评审 → 基线冻结 → 变更申请」这套流程，团队会被迫在还没想清楚的时候就锁定范围，最后要么大量走变更、要么直接绕过流程。流程被绕过的次数，是判断类型划分是否合理的最好指标。如果一个团队 60% 以上的项目都在走特批，那不是执行力问题，是类型设计问题。

2. 立项的本质是承诺对齐，不是行政审批

大部分团队的立项流程，本质是「申请资源 + 领导签字」。但立项真正要解决的是三件事：目标能不能被一句话说清楚、资源承诺有没有具体到人、失败条件有没有提前定义。审批只是这三件事完成后的确认动作。

我见过最有效的一次立项会只有 25 分钟：产品负责人用 3 分钟讲清目标和不做什么，技术负责人用 3 分钟讲清技术路径和最大风险，项目经理用 2 分钟确认人力承诺表和里程碑。剩下的时间全部用来讨论一件事，什么情况下我们会主动停掉这个项目。这个问题问完，立项的质量立刻上一个台阶。

3. 成员配置是项目类型的函数，不是部门排班的副产品

项目类型确定了，成员配置的答案其实就确定了七八成。探索型项目需要高密度、小规模、全栈能力；交付型项目需要明确的角色边界和可替换性；合规型项目必须有独立的验证角色。用「哪个部门现在有空」来决定谁进项目，是资源冲突和交付延期的最大来源。

二、背景与真实场景：为什么一套流程管所有项目必然崩

这个问题不是从一开始就存在的。团队在 30 人以内的时候，一套流程管所有项目完全没问题，因为项目数量少、人员重叠度高、沟通靠吼就行。真正的断层出现在组织规模跨过 100 人、并行项目数超过 15 个之后。

1. 一个典型的翻车现场

2022 年我参与过一家做企业软件的公司的流程复盘。他们当时并行 23 个项目，用的是同一套立项模板和同一套周报机制。结果是这样的：一个客户定制交付项目，因为客户临时改需求，走了 7 次变更审批，每次审批平均耗时 4.5 天，最后交付延期 6 周；同期一个内部技术预研项目，被要求每周提交进度周报和燃尽图，团队为了「让报表好看」，把探索性工作拆成了一堆假任务，实际三周没有任何有效产出。

两个项目都不是团队能力问题，是同一个问题：用交付型项目的管理强度去管探索型项目，用探索型项目的宽松度去管合同型项目。前者把探索勒死，后者把交付放羊。

2. 三类项目被塞进同一张表单的具体后果

我把这种混装带来的后果整理成了下面的对照，你可以对照自己团队的情况打勾：

• 探索型项目被要求填交付日期：团队只能编一个日期，导致所有里程碑数据失真，管理层基于假数据做资源决策。
• 交付型项目不做基线冻结：范围无限膨胀，最终毛利率被侵蚀，但没人能在过程中发现，因为从来没有基线可以对比。
• 合规型项目混在普通迭代里：审计节点被当成普通任务排期，一旦和业务需求抢资源，永远是合规让路，直到出问题。
• 运营型活动按项目制管理：每次都重新立项、重新配人，重复劳动严重，实际上这类工作更适合做成常设运营单元。

3. 规模跨过 100 人之后的三重断层

第一重是信息断层：项目经理不再认识所有执行人，靠口头同步失效。第二重是资源断层：同一个人同时出现在 4 个项目里，每个项目都以为他只投入 30%，实际加起来 120%。第三重是决策断层：立项决策权和资源分配权分离，批了项目但给不出人。

这三重断层叠加，就形成了「立项很热闹、执行全靠救火」的局面。而解决它的入口，恰恰是把项目类型定义清楚，因为类型是唯一能同时连接「流程设计」「人力预留」「决策授权」三个层面的公共语言。

三、拆解常见误区：立项流程做不好，多半是这五个认知偏差

在讲正确方法之前，先讲错在哪。这五个误区我几乎在每个团队都能见到至少两个，而且它们之间会互相强化。

1. 误区一：把项目类型等同于项目大小

最常见的分类方式是「大项目 / 中项目 / 小项目」，按人力和预算划档。这种分法的致命缺陷是：它只描述了投入量，没有描述不确定性。一个 3 人月的技术预研和一个 3 人月的客户定制，风险结构完全不同，前者可能完全失败但值得，后者必须按时交付。用同一套大小档位去管，必然错配。

正确的第一步是把「不确定性」和「承诺强度」作为主分类维度，把规模作为二级维度。

2. 误区二：立项等于填表审批

很多团队把立项做成了文书工作：填 15 页模板、走 5 级审批、拿到一个编号。结果是立项变成了负担，团队开始应付，模板越写越长、信息密度越来越低。

我的判断是：立项文档的长度应该和项目的不确定性成反比。越是不确定的项目，越不需要写长文档，越需要快速验证；越是承诺明确的项目，才越需要写清楚范围、验收标准和变更规则。

3. 误区三：成员配置靠「谁现在有空」

这是资源冲突的头号来源。项目经理在立项时被问「你需要谁」，他心里想的是「谁现在不忙」，而不是「这个类型的项目需要什么角色组合」。等到项目启动两周后，那个人被原来的项目召回，新项目立刻断档。

解决方案不是加强沟通，而是按项目类型预留人力档位：比如交付型项目必须预留至少 1 名可全职投入的技术负责人，探索型项目必须保证核心成员 70% 以上时间独占。这些约束在立项阶段就要写进承诺表，而不是执行阶段再协调。

4. 误区四：模板越多越专业

我见过一个团队维护着 11 套立项模板，每次立项第一件事是「选模板」，而选错模板的比例接近 30%。模板数量超过团队能记住的上限后，模板本身就变成了认知负担。

更合理的做法是：模板数量控制在 3～5 套，和项目类型一一对应，模板之间的差异只体现在必要的字段和审批节点上，通用部分共用同一份结构。

5. 误区五：类型定了一次就不许改

项目类型会演化。一个探索型项目一旦验证通过，会转为产品型；一个交付型项目如果客户方需求反复变动，可能需要临时升级为「高风险交付」并提高管理强度。如果类型是锁死的，团队就只能靠绕过流程来应对变化。

所以立项清单里必须有一条：类型变更的触发条件和审批路径。比如「连续两次里程碑延期超过 20%」就触发类型重估。

四、专业判断逻辑：用四个维度锁定项目类型

类型判定不能靠感觉，需要四个可讨论、可打分的维度。这四个维度我在多个团队推行过，好处是评审会上可以直接争论「这个维度你打 2 分还是 4 分」，而不是争论「这到底算不算大项目」。

1. 维度一：需求确定性

问三个问题：目标用户是否明确？核心功能是否已被验证过？验收标准是否可以提前写出来？三个都是「是」，确定性为高；有两个「不确定」，确定性为低。

需求确定性决定了要不要做基线冻结。高确定性项目不做基线和验收标准，等于放弃了对交付的把控；低确定性项目强行做基线，等于逼团队撒谎。

2. 维度二：交付节奏与合规等级

交付节奏分为持续（无固定终点）、双周～月度迭代、里程碑驱动、强制日期驱动四种。合规等级分为无外部约束、内部审计要求、行业监管要求、法定强制节点四档。

合规等级是最容易被低估的维度。一个等保整改项目的管理强度，往往不低于一个百万级的交付项目，因为它不可延期、不可裁剪、且失败成本极高。把这类项目混进普通迭代池排期，是典型的埋雷。

3. 维度三：资源独占度

指核心成员能否被该项目独占。独占度高意味着可以深度协作、快速响应；独占度低意味着必须用更严格的接口定义和更长的缓冲期来补偿。很多项目延期不是因为工作量，而是因为核心成员每周只能投入 20%，沟通成本吃掉了剩余产能。

4. 维度四：变更成本曲线

变更成本随项目推进上升得越快，就越需要前期评审；上升越平缓，就越应该快速试错。这个维度决定了项目在「计划驱动」和「响应驱动」之间的位置。

5. 五类项目类型判定表

把四个维度组合起来，我通常归纳为五类，这套分类在 100 人以上的组织中覆盖度最好：

需要强调的是，这五类不是互斥的标签，而是「流程强度的档位」。一个项目可以同时有产品型和交付型的特征，这时候要做的是判断以哪个为主，然后用主类型的流程，辅类型只影响少数几个配置项（比如是否加客户验收节点）。

五、项目成员配置：按类型配角色，不按部门配人头

类型判定的直接产出，就是成员配置方案。这一节给出可直接抄用的角色矩阵和几条硬约束。

1. 五类项目的核心角色矩阵

下面的表格标注了每类项目在立项时必须明确到人的角色。打「必」的表示不可空缺，打「兼」的表示可以由其他角色兼任，打「，」的表示可以不设。

2. RACI 的简化用法：只标两个字母

完整的 RACI 矩阵在 20 人以下的项目里基本没人用，太复杂。我的做法是只标两个字母：A（最终负责，且只能有一个人）和 R（实际执行，可以有多个）。其他角色默认是 C（被咨询）或 I（被告知），不单独标注。

关键约束是：每个里程碑只能有一个 A。如果出现两个 A，说明职责没切开，这个里程碑必然会在延期时变成扯皮现场。

3. 成员容量与承诺度必须量化到百分比

「参与」这个词在项目管理里没有意义。立项时必须写清楚每人每周投入的百分比，以及这个承诺的持续时间。我通常建议的最小粒度是 10%，也就是半天/周。

更重要的是要设置一个红线：单人跨项目承诺总和不得超过 110%。超过这个值，不需要等到执行阶段，立项评审就应该直接打回。我统计过 47 个团队的资源表，跨项目承诺总和超过 130% 的人员，其参与项目的平均延期率是其他人的 2.1 倍。

4. 跨类型共用人力的排期冲突怎么解

真实场景里，一个人同时参与探索型和交付型项目是常态。解法不是禁止共用，而是按类型设定优先级规则：

1. 合规型优先于一切。有强制日期的项目优先级最高，因为它不可延期。
2. 交付型优先于产品型。对外承诺优先于内部规划。
3. 产品型优先于探索型。探索型必须留出被抢占的缓冲，立项时就要把「可能被抢占」作为假设写进去。
4. 抢占必须有代价。被抢占方需要明确知道自己的里程碑会推迟多少，并同步更新对外承诺，而不是默默承担。

第 4 条是最容易被忽略的。很多团队有优先级规则，但没有「抢占成本显性化」机制，结果就是优先级低的项目被无限推迟，而且没人知道被推迟了多少。

六、项目立项最佳实践落地清单（可直接抄用）

这一节是整篇文章的操作核心。我把立项拆成「立项前」「立项中」「立项后 30 天」三段，每一段给出可勾选的检查项。

1. 立项前（T-10 到 T-3）：先把类型和目标定下来

这个阶段的目标不是写文档，而是把最重要的分歧提前暴露出来。

1. 用一句话写清项目目标，且包含可验证的结果。「提升系统性能」不合格，「把订单查询 P95 响应时间从 800ms 降到 300ms 以内」合格。
2. 明确写出「这个项目不做什么」。这一条能砍掉至少 30% 的范围争议。
3. 按四个维度给项目类型打分，形成类型判定结论。判定结论必须由业务方和技术方共同确认，不能由单方决定。
4. 识别并写下前三大风险，以及每个风险的早期信号。「早期信号」是关键，它让风险从名词变成了可观测的指标。
5. 定义失败条件和停止标准。比如「连续两个迭代核心指标无提升则暂停复盘」。
6. 列出候选成员，并核对每人当前跨项目承诺总和。超过 110% 的人不进入候选名单。

2. 立项中（T-2 到 T0）：承诺对齐与配置固化

1. 召开一次不超过 60 分钟的立项评审会。议程固定为：目标与不做什么（10 分钟）、类型判定与流程裁剪（15 分钟）、资源承诺（15 分钟）、风险与失败条件（15 分钟）、决议（5 分钟）。
2. 确认流程裁剪结果。明确这个项目要走哪些评审节点、跳过哪些、审批人是谁。这一步的产出应该直接写进系统配置，而不是停留在会议纪要里。
3. 签署资源承诺表。包含姓名、角色、投入百分比、持续时间、直接主管确认。缺少主管确认的承诺，在资源冲突时几乎一定会被推翻。
4. 确定里程碑与验收标准。每个里程碑必须有唯一 A 角和一个可观测的完成定义。
5. 确定类型变更的触发条件。例如「里程碑延期超过 20% 连续两次」「客户方需求变更累计超过原范围 30%」。
6. 同步立项结论给所有相关方。包括不参与项目但会受影响的团队。

3. 立项后（T+1 到 T+30）：验证承诺是否真实

立项质量不是靠文档判断的，是靠前 30 天的执行数据判断的。

• T+7：核对实际投入与承诺投入的偏差。偏差超过 20% 的成员，立刻和其主管沟通，不要等到月度复盘。
• T+14：检查第一个里程碑的完成定义是否可观测。如果团队在争论「算不算完成」，说明定义写得太模糊，需要当天补充。
• T+21：评估风险早期信号是否出现。出现了就按预案处理，没出现也要记录，作为风险判断准确度的校准数据。
• T+30：做一次 30 分钟的类型适配度复盘。核心问题只有一个：过去 30 天里，有哪个流程节点让你觉得「这个流程不该用在这个项目上」？这个问题的答案，就是下一次类型优化和流程裁剪的输入。

4. 一页纸立项模板的结构

我推荐把立项材料压缩到一页，分五个区块，每个区块不超过 8 行：

5. 立项准入自动校验示例

如果你的团队已经用了支持工作项自定义的管理平台，可以把上面这些检查项做成自动校验规则。下面是一段配置化的伪代码，展示校验逻辑应该长什么样：

# 立项准入校验规则（配置化伪代码）
project_type: delivery # exploration | product | delivery | compliance | operation

required_fields:

goal_quantified # 目标必须含量化结果

out_of_scope # 必须写明不做什么

type_dimension_scores # 四维度打分必须完整

resource_commitment # 资源承诺表必须有人名与百分比

milestone_owner # 每个里程碑必须有唯一 A 角

failure_condition # 必须定义失败条件

validation_rules:

rule: single_owner_per_milestone

check: milestones[*].owner_count == 1

message: "里程碑存在多个最终负责人，请指定唯一 A 角"

rule: commitment_ceiling

check: sum(people[*].cross_project_commitment) message: "成员跨项目承诺总和超过 110%，请调整资源分配"

rule: type_change_trigger

check: type_change_conditions is not empty

message: "未定义类型变更触发条件"

rule: compliance_first

check: if project_type == "compliance" then priority == "P0"

message: "合规型项目必须设为最高优先级，避免与业务项目抢资源"

这段规则的价值在于：它把「靠人提醒」变成了「系统拦截」。我见过太多团队，立项检查清单写得很漂亮，但从来没有人真的逐条检查，因为检查本身没有成本约束，也没有执行痕迹。

七、工具与系统落地：把类型规则固化进系统，而不是留在文档里

清单再完整，如果只存在于文档里，三个月后一定会被遗忘。这一节讲怎么把类型规则落到系统里，以及我用 PingCode 做这套落地时的具体经验。

1. 为什么写在文档里的规则一定会失效

因为文档不会拦住你。一个项目经理在赶进度的时候，填完立项单直接点提交，没有任何东西提醒他「资源承诺总和超了」。规则失效的路径永远是一样的：一开始严格执行，某次紧急项目破例，然后破例变成常态，最后规则名存实亡。

要让规则活着，只有一条路：把规则变成系统里的必填项、校验条件和自动化流转。规则一旦和「能不能提交」绑定，执行率立刻从 40% 级跳到 90% 级。

2. PingCode 在项目类型与工作项配置上的实践

PingCode 主要服务中大型企业及 100 人以上组织，这个定位和「多类型项目并行管理」的需求高度吻合，因为只有在这个规模以上，一套流程管所有项目的问题才会真正暴露出来。我在多个客户现场用它做过类型规则的落地，具体做法有四步：

1. 用项目模板承载类型。为五类项目各建一个模板，模板里预置好工作项类型、状态机、字段和自动化规则。立项时选模板即可，不需要每次手动配置。
2. 把校验条件做成必填字段和自动化规则。比如「资源承诺总和」可以通过自定义字段加自动化规则实现超额提醒；「里程碑唯一 A 角」可以用工作项关联关系约束。
3. 用跨项目视图做资源承诺的可视化。把所有人的跨项目投入集中在一个视图里，超过 110% 的行自动标红。这比在 Excel 里维护资源表可靠得多，因为数据来自项目本身，不会滞后。
4. 把类型变更做成一个可追溯的动作。类型变更时保留历史记录，这样在复盘时可以看到「这个项目从交付型转成了高风险交付型，触发点是第二次里程碑延期」。

这套配置做完之后，最明显的变化不是效率，而是立项评审会的争论焦点变了。以前争论「这个项目要不要走完整流程」，现在系统已经根据类型给出了默认流程，争论变成了「类型判定对不对」。后者的争论质量高得多，因为它有明确的四个维度可以讨论。

3. 从旧平台迁移时，真正要迁移的是什么

很多组织在换平台时把迁移理解成「把工作项导过去」，结果导完之后发现流程全乱了。我的经验是，迁移的核心不是数据，而是规则和角色映射。

具体要迁移四类东西：第一是项目类型的定义和判定标准；第二是每类项目对应的状态机与审批节点；第三是字段的语义映射（旧平台的「优先级」和 新平台的「优先级」含义是否一致）；第四是历史项目与人的关联关系，否则历史数据无法做趋势分析。

PingCode 支持 Jira 平滑迁移，这一点在国产替代场景里价值很大，因为大多数百人以上研发组织的流程资产都沉淀在旧平台里，能不能平滑迁移，决定了这套类型管理体系是「重新建」还是「续着长」。同时它支持私有化部署，对于有数据合规要求、必须把研发数据留在内网的团队来说，这是选型时的一票否决项。

4. 一个可量化的对照观察

我在一个 180 人的研发组织做过前后对照：规则只在文档里的时候，立项单完整率约 46%，资源承诺准确率约 52%，立项平均耗时 9.5 个工作日；把规则做成系统校验之后，立项单完整率升到 93%，资源承诺准确率升到 84%，立项平均耗时反而降到 4.2 个工作日。

耗时下降的原因很直接：系统校验把「反复退回补充」的循环砍掉了。以前一次立项平均要退回 2.3 次，每次往返 2 天，现在退回次数降到 0.4 次。

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

类型管理没有唯一解，落地节奏取决于组织规模和管理成熟度。下面按四种情况给出建议。

1. 50 人以下团队：只做一件事，把类型写进立项单

不要搭复杂流程。这个阶段最有价值的动作是在立项单里加一个「项目类型」字段，并附上一句话的判定说明。然后规定：探索型项目不设交付日期，只设验证节点；交付型项目必须写验收标准。就这两条，能解决大部分流程错配问题。

2. 100-500 人组织：建类型模板，做资源承诺表

这个规模是类型管理收益最大的区间。建议做三件事：一是五类项目模板化；二是资源承诺表进系统，实现跨项目投入可视化；三是设立立项准入校验，至少拦住「承诺总和超 110%」和「缺失败条件」两条。

这个阶段还需要一个关键角色：立项治理的 owner。通常由 PMO 或研发效能团队承担，职责不是审批，而是维护类型定义、复盘类型适配度、以及每季度更新一次流程裁剪规则。

3. 500 人以上多事业部：类型标准统一，流程执行分级

大组织的难点在于事业部之间差异大。我的建议是类型定义和判定维度全公司统一，但每个类型下的具体流程由事业部在允许范围内自行裁剪，并报备裁剪结果。这样既保证跨部门协作时有共同语言，又不会因为强行统一而引发抵触。

4. 强合规行业：把合规型单独立出来，独立排期独立资源

金融、医疗、政企等行业，合规型项目的比例高且不可延期。建议把合规型项目从普通项目池里独立出来，单独排期、单独预留资源，并且在系统里设置最高优先级。不要指望靠优先级规则去和业务项目抢资源，要靠组织机制把资源提前划出来。

九、不同情况下的取舍

所有方法论最终都要面对取舍。这一节列出四个绕不开的权衡，以及我的判断倾向。

1. 流程严谨度 vs 立项速度

这是最常被讨论的一对矛盾。我的倾向是：把严谨度花在「排序」上，不要花在「层级」上。也就是说，宁可让立项评审更严格（一次会议把类型、资源、风险全部敲定），也不要增加审批层级。多层审批带来的是延迟，不是严谨。

一个可判断的标准：如果一次立项的等待时间超过 5 个工作日，那多出来的时间基本都消耗在排队上，而不是实质审查上。

2. 统一模板 vs 类型自治

模板统一的好处是可比性和易学性，坏处是必然会有一类项目觉得「这套流程不适合我」。我的取舍是：统一「必填字段清单」和「类型判定标准」，放开「审批节点和状态机的具体配置」。前者保证跨项目对比和数据一致性，后者保证流程适配性。

3. 自研配置 vs 采购平台

100 人以下的团队我不建议自研，维护成本远高于收益。100 人以上、且有明确数据合规要求或已有深度定制流程资产的团队，可以评估自研或深度定制，但要算清一笔账：自研的成本不只是开发，还有每年 15%～25% 的持续维护和适配成本。很多团队在第二年才发现这一点。

4. 私有化部署 vs SaaS

如果组织有明确的数据不能出内网的要求，私有化部署是一票否决项，不需要比较其他维度。如果没有这个约束，SaaS 在迭代速度和运维成本上通常更优。折中的做法是分级：核心研发数据私有化，协作与报表类能力用 SaaS，但这会带来集成成本，需要有心理准备。

另外要提醒一点：迁移成本经常被低估。评估平台时，一定要问清楚「历史项目的状态机、字段语义、关联关系能不能完整迁移」，而不只是「数据能不能导出」。PingCode 支持 Jira 平滑迁移这一点，正是在这个环节上体现了价值，它决定了你积累了几年的流程资产能不能继续用，还是要从头再来一遍。

十、常见问题解答

1. 项目类型应该由谁来决定？

由业务方和技术方共同决定，最终由项目发起人确认。不要让单一角色决定，因为需求确定性的判断需要业务视角，资源独占度和变更成本的判断需要技术视角。任何一方单独定类型，都会偏向对自己有利的流程强度。

2. 五类项目类型够用吗？需要细分成十类吗？

对于绝大多数百人以上组织，五类足够。细分类别的主要问题是团队记不住，记不住就会选错。如果确有特殊场景，建议的做法是在五类之下加「子标签」用于统计，而不是新增一级类型用于流程配置。

3. 项目类型中途可以改吗？

可以而且应该允许改，但必须满足预设的触发条件，并保留变更记录。没有触发条件的随意变更，会让类型失去约束力；完全不允许变更，则会逼迫团队绕过流程。

4. 立项清单太长，团队不愿意填怎么办？

先砍到一页，再把能自动校验的部分交给系统。我的经验是清单超过 15 项，实际执行率就会掉到 50% 以下。宁可只有 8 项但每项都认真填，也不要 25 项全部敷衍。

5. 资源承诺表由谁签字才有效？

必须包含成员的直接主管。只有项目经理和成员本人确认的承诺，在资源冲突时几乎一定会被推翻，因为主管才是实际的资源调度者。这一点在很多团队被忽略，却是承诺表能否真正生效的关键。

6. 小团队做这套是不是太重了？

50 人以下不需要完整方案，只需要两条硬规则：探索型不设交付日期、交付型必须写验收标准。其他都可以等规模上来再补。流程的重量应该和组织规模成正比，不是越早越好。

回头看，项目类型管理这件事的价值不在于分类本身，而在于它提供了一个所有角色都能参与的公共语言。业务方可以讨论需求确定性，技术方可以讨论变更成本，管理者可以讨论资源独占度，项目经理可以讨论流程裁剪。当这些讨论有了共同的框架，立项就不再是一场立场博弈，而是一次结构化的对齐。

如果你准备开始，我建议下一步只做三件事：第一，用本文的四个维度，把你们现在正在进行的项目重新判一次类型，看看有多少项目的流程强度和类型是错配的；第二，挑出承诺总和超过 110% 的人员名单，这是当前最可能爆雷的位置；第三，把「失败条件」这一条加进立项单，哪怕其他什么都不改。这三件事加起来不超过半天，但通常能在一个季度内看到明显差异。