项目成员怎么做？研发团队实操方法：项目立项从0到1

去年年底我做过一次不太愉快的复盘：一个 14 人的研发团队，需求评审过了、工期排了、任务系统里的 Epic 也建了，结果上线延期 26 天。追责会上大家一开始都在说”执行不到位”，直到我把立项那一周的会议记录和群聊翻出来，才发现真正的问题出在立项阶段，后端负责人压根不知道这个项目依赖他改造一个三年前的老接口，而测试负责人一直以为自动化用例由平台组提供。

这两个假设，没有一个人在任何一次会上说出来。它们不在需求文档里，不在排期表里，也不在任何一个工具的字段里。但它们各自吃掉了将近两周的工期。

这件事之后，我把 2023，2024 年我深度参与或复盘的 47 个研发项目的立项记录重新翻了一遍，试图回答一个很具体的问题：项目立项从 0 到 1 的过程中，普通项目成员到底该做什么？不是项目负责人该做什么，不是 PMO 该做什么，而是那些”被拉进项目”的研发、测试、运维、设计，他们在那短短几天里，究竟应该贡献什么。

一、核心结论：立项期项目成员的第一职责不是”领任务”

先说结论，后面再展开论证。这五条是我复盘 47 个项目后最想强调的判断，其中有三条和主流做法是相反的。

结论一：项目成员在立项期的第一职责是”把不确定性提前暴露”，而不是”确认自己能做”。大多数团队的立项会，成员的角色是听需求、认领模块、报工时。这是典型的执行者姿态。但立项期最珍贵的资源恰恰是”还没承诺之前的怀疑权”，一旦排期确认，成员再提”这个接口可能改不动”，性质就从”风险预警”变成”推诿”。

结论二：立项的产出不是一份文档，而是一组可被验证或证伪的假设。我见过写得最漂亮的立项报告有 42 页，包含市场分析、竞品对比、组织架构图，但它没有回答一个最基本的问题：这个项目成立的前提假设是什么，如果假设不成立，我们会在第几天知道。

结论三：成员在立项阶段的参与深度，与后期返工率呈显著负相关。这个结论听起来像废话，但数据比想象中陡峭。在我复盘的样本里，采用”共建型”立项（成员参与假设梳理和依赖识别）的项目，立项后返工工时占比中位数是 6%，而”缺席型”立项（成员只在排期会上出现）的项目是 27%。差了 4 倍多。

结论四：立项颗粒度必须匹配团队规模和交付周期，没有通用模板。10 人以下的团队做 21 项立项动作是自残，200 人以上的组织只做 5 项立项动作是赌博。具体怎么匹配，第四节给判断逻辑。

结论五：工具能固化流程，但替代不了判断。这一点我在后面会用具体案例说明，很多团队把立项流程搬进了项目管理系统，字段填得很齐，但风险该漏还是漏。因为工具只能校验”你填没填”，校验不了”你想没想”。

下面这张图来自我复盘的 47 个项目样本，展示的是立项阶段各个动作对后期风险下降的贡献度。需要说明的是：这是小样本回溯分析，不是严格的因果实验，属于示意性数据，用于说明结构性判断，不代表行业整体水平。

二、背景和真实场景：立项从 0 到 1 到底发生了什么

要讨论”成员该做什么”，得先看清楚立项那几天实际的时间流向。很多团队以为自己没有立项流程，其实是有流程的，只是隐性的、靠口头传递的。

1. 一个真实项目立项周的完整时间线

我跟踪过一个 9 人团队的完整立项过程，从需求触发到成员进组开发，一共用了 12 个工作日。这 12 天的时间分布，和我后来统计的其他项目基本吻合。

第 1，2 天是目标对齐，主要是业务方和产品负责人把”为什么要做”讲清楚。这个阶段最容易被压缩，因为大家都觉得目标很明确，实际上”提升用户活跃度”和”把某个入口的点击率提高 15%”是两个完全不同的项目。

第 3，5 天是范围拆解，产品出需求清单，技术做初步方案。第 6，8 天是技术预研，这部分时间经常被低估，尤其是涉及老系统改造、数据迁移、第三方对接的时候。

第 9，10 天是依赖梳理和风险识别，第 11 天是立项评审，第 12 天成员正式进组。看起来挺完整，但实际上普通成员真正参与的时间只有第 11 天的评审会和第 12 天的排期会，加起来不超过 4 小时。这就是问题所在。

2. 三类研发团队的立项现场差异

立项不是一种做法，至少是三种。我按团队规模和交付形态分成三类，它们在立项现场的表现差别很大。

第一类：10 人以下的创业型研发小组。典型场景是三五个人围在白板前，半小时把要做的事和谁做什么定下来。立项动作少、速度快，但严重依赖核心成员的记忆力。这类团队最大的风险是”人走项目散”，关键假设只存在某个人的脑子里，没有落到任何地方。

第二类：30，100 人的业务研发团队。通常有 2，5 条并行的产品线，立项需要跨小组协调资源。这个规模是最容易出现”立项形式化”的区间，流程建起来了，但大家填表是为了应付检查，不是为了想清楚问题。

第三类：100 人以上、多产品线的研发组织。这类组织的立项复杂度不在于单个项目，而在于项目之间的资源冲突、依赖关系和优先级排序。这也是我在后面会用具体案例展开的场景，像 PingCode 这类面向中大型组织的研发管理平台，主要解决的正是这个规模区间的立项协同与信息一致性问题。

下面这张图对比了三类团队在六个关键立项动作上的平均完备度。数据同样来自我复盘的样本，属于示意性基准，用于说明结构性差异。

3. 项目成员在立项期的四种真实状态

同样是”被拉进立项会”，成员的实际状态差别很大。我把它们分成四种，并追踪了各自的后期表现。

缺席型：成员根本没有参加立项讨论，只在排期会上被告知”你负责这三个模块”。这类项目的返工率最高。

旁听型：成员参加了立项会，但全程不说话，会后也不提问。表面上有参与，实际上没有贡献任何信息增量。

认领型：成员在会上确认了自己负责的模块和时间承诺，但不主动质疑整体方案。这是目前最常见的状态，比旁听型好，但还不够。

共建型：成员在立项阶段就参与假设梳理、依赖识别和方案取舍，主动提出”如果我们这样做，会不会有问题”。这类项目的后期表现最好。

下面这张图展示四种状态对应的后期表现差异。样本量不大（缺席型 11 个、旁听型 13 个、认领型 15 个、共建型 8 个），属于样本推演数据，用于说明趋势而非精确预测。

三、拆解常见误区：为什么很多立项做完等于没做

在展开判断逻辑之前，先把最常见的五个误区拆开。这些误区我在不同团队反复见到，而且它们通常不是”做错了”，而是”做得看起来对”。

1. 误区一：立项是管理层的会，成员等通知就行

这个误区的根源是把立项理解成”资源分配会议”。如果立项的唯一目的是决定给这个项目几个人、几个月，那成员确实没必要参加。但立项的另一半目的是建立共同的问题认知，这部分只能靠参与者自己形成，没法靠通知传达。

我见过一个反例：某团队的产品负责人在立项会后果断把 6 页的立项纪要发到项目群，要求所有成员回复”确认”。回复率 100%，但三周后有两位成员表示”我不知道这个项目要兼容老版本数据格式”。通知传达的是结论，不是上下文。

2. 误区二：立项文档越长越专业

文档长度和立项质量没有正相关，甚至常常负相关。原因很简单：文档越长，写的人越倾向于堆砌信息而不是暴露问题；读的人越倾向于快速略过而不是仔细推敲。

我的经验值是：面向成员的立项文档，正文控制在 6 页以内，其余内容放到附录。前 6 页必须是目标、范围、假设、依赖、验收标准和责任人，一个都不能少。

3. 误区三：先把工期定下来，再倒推范围

这是最危险也最常见的一个。业务方给了上线日期，项目负责人倒推工期，然后按工期裁剪范围。整个过程中，技术不确定性和依赖关系被当成可以压缩的变量。

在我复盘的样本里，”先定工期后定范围”的项目平均返工成本是 24.6 人天，是其他误区的两倍以上。原因也不难理解：范围可以裁，但依赖和技术风险裁不掉，它们只会在后期以更高的成本爆发。

4. 误区四：用工具把流程固化，就等于立项规范了

这个误区在已经上了研发管理平台的团队里特别普遍。立项流程配置得很完整，字段必填校验也做了，但立项质量并没有提升。

原因在于：工具能校验字段是否为空，校验不了判断是否成立。”风险描述”字段填了”技术风险可控”，系统会判定通过，但这句话没有任何信息量。工具的价值在于让信息可见、可追溯、可对比，前提是信息本身有质量。

5. 误区五：所有项目都该走同一套立项流程

一个 3 人两周完成的内部工具改造，和一个涉及 5 个团队、跨 6 个月的核心系统重构，走同一套立项流程，结果一定是前者被拖死、后者被放水。

合理的做法是按项目的不确定性和影响半径分档，不同档位对应不同的立项动作清单。具体分档方法在下一节展开。

下面这张图对比了五类立项误区造成的平均返工成本。数据来自我复盘的样本项目，属于示意性数据，用于说明误区之间的相对代价差异。

四、专业判断逻辑：项目成员该做什么，取决于三件事

前面讲了现象和误区，这一节讲判断方法。我的核心观点是：立项阶段成员的动作清单不应该由职位决定，而应该由项目不确定性、团队规模和交付周期三个变量共同决定。

1. 立项的本质是一次”假设定价”

任何项目在立项时都建立在一组假设之上：用户会需要这个功能、这个接口改得动、这个第三方会按时提供数据、这个团队能在一个月内交付。立项的价值不是把这些假设写下来，而是给每一个假设标注”如果不成立，我们会在什么时候、通过什么信号知道”。

这就是为什么普通成员必须参与。项目负责人通常离技术细节最远，而最清楚”这个接口改不动”的人，恰恰是那个要动手改的人。如果他不参与假设标注，这个假设就会一直停留在”未被证伪”的状态，直到开发进行到一半。

2. 用”三张清单”定义成员的具体动作

把抽象的”参与立项”拆成三张具体清单，成员就知道该干什么了。

第一张是边界清单。回答”这次做什么、这次不做什么”。成员要贡献的是那些”看起来该做但这次不做”的条目，比如”老版本数据兼容”、”移动端适配”、”多语言支持”。把这些明确排除，比列出要做的十件事更有价值。

第二张是假设清单。回答”我们认为哪些事会成立”。成员要贡献的是那些”我认为可能不成立”的条目。每个假设后面必须跟三列：验证方式、验证责任人、验证截止时间。

第三张是依赖清单。回答”我们要等谁、谁要等我们”。成员要贡献的是跨团队的接口约定、数据源提供时间、审批流程节点。依赖清单最容易被忽略，但它是延期的最主要来源。

3. 成员参与的”三个必须”

如果团队时间非常紧张，做不到完整的三张清单，我建议至少保住三个必须动作。

1. 必须由执行者本人确认验收标准。不是产品确认，不是测试确认，而是真正写代码的那个人确认”做到什么程度算完成”。这一步能挡掉大量后期扯皮。
2. 必须由执行者本人点名外部依赖。依赖方是谁、需要对方提供什么、最晚什么时候需要。依赖不能由项目负责人代填，因为代填的依赖往往是”看起来有”但实际不完整。
3. 必须由执行者本人给出技术不确定性判断。哪怕是”我不确定，需要两天预研”这样的回答，也比沉默有价值。立项不要求消灭不确定性，要求的是让它可见。

4. 立项粒度的判断逻辑

立项动作该做多少项，我用的判断方式是看两个变量：项目不确定性和影响半径。不确定性高、影响半径大的项目，立项动作要多；反之则要少。

具体可以粗略分为三档：不确定性低且影响局限在单个小组内，做 5 项核心动作即可；不确定性中等或跨 2，3 个团队，做 12 项标准动作；不确定性高且跨 4 个以上团队，需要做 21 项完整动作，并且必须有阶段性的重新立项评审。

下面这张图用气泡图展示不同项目类型在”不确定性”和”影响半径”两个维度上的分布，以及对应的建议立项动作数量。这是基于经验判断的建议基准，不是统计模型输出。

五、案例与数据观察：一个 120 人研发组织的立项改造

前面讲的是判断逻辑，这一节讲一个具体的落地过程。我完整参与过一个约 120 人的研发组织的立项流程改造，从混乱到相对稳定，用了大约 7 个月。这里把关键节点和数据记录下来。

1. 改造前的状态：立项信息完整度只有 52%

这个组织当时有 6 条产品线，同时并行 14，18 个项目。立项流程是存在的：项目负责人在文档系统里填一份立项表，走一轮评审，然后开始排期。

问题出在三个方面。第一，立项表由项目负责人单人填写，执行者不参与，导致依赖清单严重缺失。第二，评审会平均耗时 3.2 小时，其中大量时间花在澄清基础信息上，而不是讨论风险。第三，立项信息散落在文档系统、聊天记录和任务系统三处，查证成本极高。

改造前的基线数据是：立项信息完整度 52%（按 21 项标准动作检查）、需求变更率 34%、返工工时占比 22%、里程碑准点率 61%。

2. 改造的三个动作

第一个动作是把立项拆成”必填 6 项 + 选填 15 项”。必填项是目标、范围边界、验收标准、依赖清单、技术不确定性、单一责任人。这 6 项中，验收标准、依赖清单和技术不确定性必须由执行者本人确认，不能由项目负责人代填。

第二个动作是把立项信息从文档系统搬进研发管理平台。我们选择了 PingCode 作为承载平台，原因有三个：它面向的是 100 人以上的中大型组织，工作项模型能同时承载项目和产品两条线；支持私有化部署，满足这个组织的数据合规要求；以及它提供了从 Jira 平滑迁移的能力，因为这个组织此前大量历史项目在 Jira 上。

第三个动作是给立项信息建立”变更留痕”。立项不是一次性的，假设会变、依赖会变、范围会变。每次变更都要记录变更原因和影响评估，否则三个月后没人说得清当初为什么这么定。

3. 一个具体的立项模板落地形态

为了让”三张清单”不只是概念，我们把它做成了一份可以直接导入的结构化模板。这个模板后来被复用到其他团队，只要调整字段名就能适配。

project_kickoff:
meta:

project_name: "订单中心重构"

owner: "张工" # 单一责任人，不允许填团队名

scale: "large" # small / medium / large，决定动作清单档位

goal:

business_goal: "将订单创建成功率从 97.2% 提升至 99.5%"

measurable: true # 目标必须可量化，否则打回

boundary:

in_scope:

"订单创建主流程"

"订单状态机重构"

out_of_scope: # 由执行者补充，至少 3 条

"历史订单数据兼容（另立项目）"

"移动端下单页改版"

"多币种支持"

assumptions: # 每条假设必须有验证方式和截止时间

desc: "新状态机可兼容现有 12 个下游调用方"

verify_by: "接口兼容性预研"

owner: "后端-李工"

deadline: "立项后第 5 天"

desc: "订单量峰值 QPS 8000 在新架构下可承载"

verify_by: "压测预演"

owner: "架构-王工"

deadline: "立项后第 8 天"

dependencies: # 跨团队依赖必须点名到人

target: "支付团队"

need: "新版支付回调接口文档"

contact: "支付-赵工"

needed_by: "立项后第 10 天"

acceptance: # 由执行者本人确认，不接受代填

criteria:

"订单创建成功率 >= 99.5%（连续 7 天）"

"P99 响应时间 "回滚方案演练通过"

confirmed_by: ["后端-李工", "测试-陈工", "运维-周工"]

tech_uncertainty:

level: "medium"

items:

"老库分表键迁移方案未最终确认"

mitigation: "安排 3 天预研，未通过则降级为双写方案"

4. 改造后的数据变化

改造持续了 7 个月，中间经历过两次返工。最终稳定下来的数据是：立项信息完整度从 52% 提升到 91%，需求变更率从 34% 降到 13%，立项评审平均耗时从 3.2 小时降到 1.1 小时，返工工时占比从 22% 降到 8%，里程碑准点率从 61% 提升到 84%。

需要说明的是，这组数据来自单一组织的改造前后对比，没有对照组，因此不能断言全部提升都来自立项流程改造，同期还有人员补充和需求管理流程调整。但从时间序列看，立项信息完整度的提升明显早于其他指标的改善，两者存在合理的因果链条。

5. 从 Jira 迁移时，立项信息怎么不丢

这个组织此前有大量历史项目在 Jira 上，迁移是绕不开的。我的经验是：迁移的真正难点不是数据搬运，而是字段语义对齐。同样的”优先级”，在两个系统里可能对应完全不同的取值集合和判断标准。

我们在迁移前做了一轮字段盘点，把立项相关的字段分成四类：可以直接映射的、需要转换取值的、需要合并的、需要废弃的。这个过程花了两周，但避免了迁移后大量信息失真。

下表是当时的部分字段映射记录，脱敏后整理如下。

其中”变更历史”的完整度只有 76%，是四类里最低的。原因不是技术问题，而是部分历史项目的变更记录本身就缺失，有些状态是被人直接在后台改的，没有留下操作日志。这反过来印证了一件事：立项信息的价值不只在于当前状态，更在于变更轨迹。如果变更不留痕，半年后没人说得清当初为什么把范围缩小了。

6. 私有化部署场景下的立项数据边界

这个组织最终选择了私有化部署，原因不是安全焦虑，而是具体的合规要求：立项信息中包含客户名称、合同编号和部分业务数据，不能出内网。

私有化部署对项目成员的实际影响，主要体现在三件事上。第一是访问方式变了，外网环境下成员在家无法直接访问，需要通过内网穿透或 VPN，这会影响紧急情况下的响应速度。第二是升级节奏变了，版本更新需要内部运维排期，不能随时享受新功能。第三是集成方式变了，与外部工具的对接需要通过内网网关中转。

我的判断是：如果立项信息里包含客户标识、合同金额或个人信息，私有化部署就不是可选项而是必要条件。反过来，如果项目纯粹是内部工具开发，不涉及外部数据，SaaS 模式的运维成本和迭代速度优势更明显。

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

前面讲了判断逻辑和案例，这一节给出可以直接执行的建议。我按团队规模和场景分档，每档给出最小可行的动作清单。

1. 10 人以内团队：只做 4 件事，但每件都要做实

小团队最大的优势是沟通成本低，最大的风险是信息不落盘。我的建议是不要引入完整立项流程，但必须保住 4 个动作。

• 写下一句话目标，必须包含可量化的验收值。写在项目群的置顶消息里即可，不需要文档。
• 列出至少 3 条”这次不做”，贴在白板上或者项目描述里。这一条能挡掉后期大量”我以为要做”的争议。
• 每个执行者说一条技术不确定性，哪怕只是”我担心性能”，也要写下来并指定验证时间。
• 确认单一责任人，不要填”研发小组”，要填具体的人名。

2. 10，50 人团队：增加假设清单和依赖清单

这个规模开始出现跨小组协作，单纯靠口头沟通容易漏。建议在 4 个动作基础上增加两项。

一是假设清单，格式是”假设 + 验证方式 + 责任人 + 截止日期”。数量不用多，5，8 条即可，重点是每条都要有人认领。二是依赖清单，跨团队的依赖必须点名到具体对接人，不能只写团队名。

这个规模不建议引入复杂审批流。立项评审一次即可，时长控制在 60 分钟以内，超时就说明信息准备不充分。

3. 50，200 人团队：建立立项档位和变更留痕

这个区间是立项最容易形式化的地方。我的建议是建立两套机制。

第一套是立项档位机制，按不确定性和影响半径分轻、中、重三档，不同档位对应不同的动作清单和评审形式。轻档只需项目负责人确认 6 项必填；中档需要执行者确认；重档需要跨团队评审并设置阶段重审。

第二套是变更留痕机制，立项信息一旦确认，后续每次变更都要记录变更人、变更原因和影响评估。这条机制的价值在半年后才会显现，但那时它会成为最有用的资产。

4. 200 人以上 / 多产品线组织：把立项信息结构化和可查询

这个规模的核心矛盾不是”怎么做立项”，而是”十几个项目的立项信息怎么被同时看见”。建议把重心放在三件事上。

一是统一立项信息的结构，所有项目用同一套字段模型，否则无法横向对比。二是建立依赖关系的可视化，让跨团队依赖能被检索和预警，而不是靠人记。三是把立项与资源视图联动，让”这个项目要占用谁的时间”在立项阶段就可见。

这也是像 PingCode 这类面向中大型组织的研发管理平台的主要价值区间，它解决的不是单项目的立项记录问题，而是多项目并行时的信息一致性和资源冲突可见性问题。同时，对于此前使用 Jira 的组织，平滑迁移能力让历史立项数据可以延续使用，降低了国产化替换过程中的信息断层风险。

5. 已经使用 Jira 的团队：先做字段盘点，再谈迁移

如果你的团队已经有一套成熟的立项信息在 Jira 上，迁移前务必做三件事。

1. 盘点所有立项相关字段，按”直接映射、需转换、需合并、需废弃”四类处理，这一步至少留出两周。
2. 确认历史变更记录的完整性，如果源系统的变更日志本身缺失，迁移后也无法补全，需要提前决定是接受缺失还是人工补录。
3. 在迁移前冻结立项模板，避免迁移过程中模板还在变，导致新旧数据口径不一致。

七、不同情况下的取舍

前面都是”怎么做”，这一节讲”什么时候不这么做”。所有立项方法都有代价，认清代价才能做出合适的选择。

1. 速度 vs 完备：什么时候可以牺牲完备

如果项目满足三个条件，影响半径在单个团队内、失败可快速回滚、交付周期短于两周，那么可以大幅牺牲立项完备度，只做目标和责任人确认。

反过来，如果项目涉及数据迁移、不可逆操作或跨团队接口变更，即使周期很短，也必须把依赖清单和回滚方案补齐。判断标准不是项目大小，而是失败是否可逆。

2. 标准化 vs 灵活性：不要用一套流程管所有项目

标准化的好处是降低沟通成本，坏处是抬高轻量项目的管理负担。我的经验是：标准化字段，不标准化流程。也就是说，立项信息的字段模型可以统一，但走几步评审、需要谁签字，应该按项目档位区分。

如果发现团队开始为了填表而填表，或者立项会变成例行公事，那就是流程过重的信号，需要立刻下调档位。

3. 工具自建 vs 采购：算清楚隐性成本

自建立项系统的显性成本容易算，隐性成本容易被低估。隐性成本主要有三块：持续维护的人力、与现有系统集成的适配工作、以及每次组织流程调整时的改造成本。

我的粗略判断是：如果团队规模在 50 人以下，且没有强合规要求，自建轻量方案（文档模板 + 简单表单）通常比采购更划算；如果规模超过 100 人、有多产品线并行、或需要私有化部署和国产化替换，采购成熟平台的综合成本通常更低。

4. 私有化 vs SaaS：由数据边界决定，而不是由偏好决定

这个取舍的判断依据应该非常具体：立项信息里有没有客户标识、合同信息、个人信息或受监管的业务数据。有，就必须私有化；没有，就优先考虑 SaaS 的运维成本和迭代速度。

容易被忽略的一点是：私有化部署会改变团队的工作习惯。需要评估成员在非办公环境下的访问需求，以及移动端使用的频率，否则会出现”系统建好了但没人用”的情况。

5. 什么时候应该”不立项”

这是最少被讨论但很重要的一点。以下三种情况我建议直接跳过正式立项。

• 验证性项目：目标是验证一个技术假设，产出物是结论而不是功能，最长不超过两周。
• 明确可回滚的小改动：影响范围在单个模块内，出问题半小时能回退。
• 紧急故障修复：先修再复盘，立项流程放在事后。

但要注意，”不立项”不等于”不记录”。这三类项目也应该留下一条简短记录，说明做了什么、影响范围是什么，以便后续追溯。

结语：立项的真正产出，是一组被公开承认的不确定性

回到开头那个延期 26 天的项目。它并不缺流程，需求评审、排期、任务分解一个都没少。它缺的是一次让执行者开口说”我担心这个接口改不动”的机会，以及一个让这句话被记录下来的位置。

我在复盘这 47 个项目后得到的最反常识的结论是：立项的质量不取决于流程有多完整，而取决于有多少不确定性被公开承认。一个只写了 6 页但每页都有一句”我们不确定”的立项文档，比一份 40 页的自信心十足的方案更有价值。

项目成员在立项从 0 到 1 的过程中，真正的角色不是执行者，也不是评审者，而是不确定性的供给方。他们掌握着项目负责人最缺乏的一手判断，如果这些判断没能在立项阶段说出来，它们就会在项目进行到一半时，以延期、返工和加班的形式重新出现。

如果你现在正准备启动一个项目，我建议下一步只做三件小事：把”这次不做”的清单写下来，让每个执行者说一条技术不确定性，指定一个具体的责任人而不是一个团队名。这三件事加起来不超过 30 分钟，但它们能挡掉后面大部分的麻烦。

如果你所在的团队已经有了一套立项流程，那下一步可以做的是：挑出最近三个项目，按 21 项标准动作逐项对照，看看实际完整度是多少。大多数团队第一次做这个检查时，得到的结果都会低于自己的预期。