项目阶段阶段状态全流程：项目负责人制度设计与一文讲清

项目阶段阶段状态全流程：项目负责人制度设计与一文讲清

2023年我帮一家做工业控制设备的公司做研发流程诊断，月度经营会上出现了这样一幕：同一个项目，研发负责人说“开发中”，测试负责人说“联调中”，PMO 报表上写的是“已进入验收阶段”。老板问了一句“那到底能不能按期交付”，会议室里安静了大约十秒，没人敢接。散会后我拉了三个人的原始记录核对，发现他们对“阶段”和“状态”的理解根本不在一个坐标系里，更要命的是，这个项目名义上有项目负责人，但没有一个人说得清他在哪个阶段该负什么责。

这次诊断之后我改了三版制度，才把阶段、状态、负责人这三件事拆干净。

这篇文章讲的就是这件事：项目阶段与状态的全流程怎么设计，项目负责人制度怎么嵌进去才不会变成一纸空文。它不是流程模板的搬运，而是我在十几个中大型研发组织里试错、返工、被业务方当面质疑之后沉淀下来的判断。如果你正打算重做项目管理规范，或者发现现有制度执行三个月就自动失效，这篇内容应该能帮你少走一到两个季度的弯路。

一、先讲核心结论

在展开细节之前，我先把最关键的四个判断摆出来，后面所有内容都是围绕它们展开的。你可以把它当成一份压缩版的决策清单。

1. 阶段是承诺，状态是事实，负责人是两者之间的翻译器

阶段（Phase）回答的是“我们承诺要交付什么、什么时候交付”，它是粗粒度的、相对稳定的、有明确进出口条件的。状态（Status）回答的是“此刻这件事实际走到哪一步”，它是细粒度的、每天都在变的、需要高频更新的。

很多团队的混乱就来自把这两件事当成一件事。把“开发中”同时当阶段又当状态，结果就是阶段没有交付物、状态没有流转规则。阶段负责对外承诺，状态负责对内协同，两者的粒度和更新频率必须分开设计。

而项目负责人制度的价值，恰恰是在这两者之间做翻译：把承诺拆成可执行的状态节点，把状态异常翻译成对承诺的影响评估，再决定是否触发阶段变更或重新基线。

2. 阶段要少，状态要窄

我复盘过的样本里，阶段数量在 4 到 7 个之间的项目，进度偏差的可解释性明显更好；一旦超过 9 个阶段，团队就开始记不住每个阶段的出口标准，实际执行会退化回“凭感觉推进”。

状态则相反，要窄。这里的“窄”有两层含义：一是每个阶段内可选的状态数量控制在 3 到 5 个，二是状态的含义边界要窄到几乎不会产生歧义。“进行中”这种可以覆盖一切的状态名，我认为是流程设计事故。

3. 负责人制度的核心是单一责任人加明确交接点

“共同负责”在实践中几乎等于“没人负责”。我在一家 400 人规模的软件公司做过一个统计：在制度改造前，跨部门协作任务的逾期率是 34%，改成每阶段单一阶段负责人之后，这个数字降到 17% 左右。当然这不是纯制度的功劳，但责任收敛确实是最直接的因素。

单一责任人不是让一个人干所有活，而是让一个人对某个阶段的交付结果负责。关键是要有明确的交接动作：交接什么、交给谁、什么条件下算交接完成、交接后原负责人还剩哪些义务。

4. 制度必须落进工具，否则活不过三个月

我见过太多写在 Word 里、贴在墙上的流程图。它们的生命周期通常是这样：发布第一周大家很兴奋，第二周开始有人跳过状态更新，第一个月末基本只剩 PMO 在维护，第三个月彻底没人看。

不是团队不守规矩，而是制度没有变成工具的默认行为。如果更新状态的成本高于口头沟通的成本，人一定会选择口头沟通。所以制度设计的最后一步，永远是把它翻译成工具里的字段、必填项、自动化规则和看板视图。

二、背景和真实场景

要讲清楚这套制度为什么这么设计，得先说我经历过的三次改版，以及每次改版暴露的问题。这些场景比任何流程图都更能说明坑在哪里。

1. 第一次改版：Excel 加周报，制度活在表格里

2016 到 2018 年，我在一家做企业软件的公司负责 PMO。当时的做法很朴素：一个 Excel 主表管全部项目的阶段和状态，项目经理每周五下午更新一次，周一出周报。

问题出在更新频率和颗粒度上。一周更新一次，意味着状态信息天然滞后五到七天。更麻烦的是，Excel 里的“状态”列是自由文本，有人填“正常推进”，有人填“开发阶段 70%”，还有人填“等接口”。同一列里混着阶段名、进度百分比和阻塞原因，做汇总统计时我只能靠人工翻译。

这个阶段的教训是：状态必须是枚举值，不能是自由文本；自由文本看起来灵活，实际是把解释成本转移给了所有下游使用者。

2. 第二次改版：上了工具，但阶段和状态还是混着用

2019 年之后，团队引入了工具化管理，看板和燃尽图都有了。但我们的设计有个隐蔽缺陷：我们把生命周期阶段直接做成了工作流状态。也就是说，一个工作项从“需求”一路流转到“上线”，中间经过十几个状态，每个状态既承担阶段含义又承担进度含义。

结果是什么？一个需求卡片在“开发”这个状态里待了三周，看板上看起来一切正常，实际上它早就卡在某个技术方案上了。因为没有独立的“阻塞”状态，也没有阶段级的出口评审，异常被状态名称掩盖了。

后来我意识到一个很关键的区分：工作流状态描述的是单个工作项，项目阶段描述的是整个项目的交付承诺，这两者的服务对象完全不同，混在一起就会出现“卡片正常、项目延期”的怪象。

3. 第三次改版：阶段门禁加状态机加负责人台账

2022 年之后，我在几个中大型研发组织里推行的是三层结构：项目层用阶段门禁管理承诺，执行层用状态机管理工作项流转，组织层用负责人台账管理权责交接。三层各有各的字段、各有各的更新频率、各有各的使用者。

这套结构上线后，最明显的变化不是进度变快了，而是会议上的争论从“现在到底什么情况”变成了“我们该不该接受这个延期”。前者是信息问题，后者才是决策问题。把信息问题解决掉，会议效率至少提升一半。

三、拆解常见误区

下面这七个误区，是我在评审别人流程文档时出现频率最高的。它们单独看都不算大问题，但组合起来会让整套制度失效。

1. 把阶段名直接当状态名用

最典型的表现是状态列里出现“需求阶段”“开发阶段”“测试阶段”。这类命名的直接后果是状态无法反映进度差异：一个刚刚进入开发阶段的项目和一个开发了两个月即将完成的项目，状态完全一样。

正确的做法是阶段独立定义，每个阶段内部再定义状态集合。同一个“开发交付”阶段里，可以有“未开始、进行中、待评审、阻塞、已完成”这样一组状态，这样进度和风险才有地方表达。

2. 状态越多越精细，实际越没人用

我见过一个状态列有 23 个选项的项目模板，设计者的初衷是“让每个环节都有对应状态”。实际情况是，团队记不住，填的时候随手选，数据质量比只有 5 个状态时还差。

我的判断是：状态数量超过 7 个，就需要为每个状态配一句不超过 15 字的判定说明，否则一定会出现理解分歧。如果配不出这句说明，说明这个状态不该存在。

3. 项目负责人被当成背锅侠而不是决策者

很多组织任命项目负责人时只给责任不给权力：要他对交付负责，但他既不掌握排期优先级，也不能调动跨部门资源，甚至无法参与需求变更的决策。这种任命的结果是，负责人很快学会“向上汇报而不是向下推进”。

我判断一个负责人制度是否有效的第一个信号，是看这个负责人能不能独立做出至少三类决策：阶段内任务的优先级调整、阶段内部的资源再分配、阶段出口是否放行的初判。

4. 一个负责人从头管到尾

项目周期超过半年、涉及多个专业领域时，让一个人从立项管到上线，通常会导致后半程管理质量断崖式下滑，因为他的知识结构不可能覆盖所有阶段。

更现实的做法是“项目负责人 + 阶段负责人”双层结构：项目负责人对整体承诺负责，阶段负责人对本阶段的交付结果负责。这里的关键是交接机制，而不是任命数量。

5. 制度写在文档里，没写进工具

我前面说过，这是最致命的。补充一个具体细节：制度落进工具时，至少要落三样东西，阶段字段的必填校验、状态流转的自动化规则、负责人字段的权限绑定。少任何一样，制度都会在两个月内退化。

6. 忽略回退路径

几乎所有团队都会设计正向流程，但很少有团队设计回退。测试阶段发现设计缺陷要不要退回？退回到哪个状态？谁批准？回退后阶段出口时间怎么算？

没有回退路径的流程，实际执行时会变成“表面通过、私下返工”。我在一个项目里见过，测试阶段发现的严重问题被标记为“遗留问题”直接进入上线，因为流程里没有合法的回退通道。

7. 用同一套阶段模板管理所有类型项目

研发项目、实施交付项目、预研项目、运维优化项目的生命周期差异极大。用同一个模板套，结果就是预研项目永远卡在“需求评审”阶段，实施项目永远缺“客户验收”这个关键阶段。

四、专业判断逻辑

这一节讲我实际使用的设计方法。它不是唯一正确的答案，但每一步的判断依据我都会说清楚，方便你按自己的组织情况裁剪。

1. 阶段怎么切：三类门槛决定切割点

我的做法是从“交付物所有权发生变化”的节点去切阶段。具体判断标准有三条：

1. 交付物门槛：这个阶段结束时，是否产出了一个可以被下游独立验收的交付物。
2. 责任门槛：这个阶段结束时，是否需要发生一次明确的责任交接。
3. 决策门槛：这个阶段结束时，是否需要一次投入或范围的重新决策。

三个门槛里至少满足两个，这个节点才值得切一个阶段。只满足一个的，通常应该降级为阶段内的里程碑而不是独立阶段。

按这个标准，一个典型的中大型交付项目会切成 5 到 7 个阶段：立项与可行性、方案与设计、开发与集成、测试与验证、上线与切换、稳定运行与移交。预研类项目会压缩成 4 个，实施交付类会扩展到 7 到 8 个。

2. 状态怎么定：三态收敛加例外态

每个阶段内部，我建议用“三态收敛”做基础：未开始、进行中、已完成。再根据阶段特性增加一到两个例外态，最常见的两个是阻塞和待评审。

“阻塞”这个状态的价值极高，它把“进行中但没进展”从正常态里分离出来，让异常可以被统计。我在一个 200 人规模的研发中心做过对照：增加独立的阻塞状态后，阻塞项的平均解除时间从 9.4 天降到 5.1 天，因为阻塞项一旦被单独统计，就自然进入了每日站会的视野。

“待评审”的价值在于它制造了一个显式的等待点。很多团队的状态里没有这个，导致评审等待时间被藏在“进行中”里，最后表现为莫名其妙的延期。

3. 负责人制度四要素：任命、授权、交接、退出

一个完整的负责人制度必须回答四个问题，缺一个都会在执行中出问题。

（1）任命：谁定、按什么标准定、什么时候定

我的建议是阶段负责人必须在上一阶段中期就确定，而不是到了阶段开始才找人。原因是交接需要时间，临时任命会导致信息传递断层。任命标准上，我通常看三条：对该阶段交付物的专业判断力、可投入的时间比例、在跨部门协调中的可信度。第三条经常被忽略，但它在实际推进中的权重往往最高。

（2）授权：能决定什么、不能决定什么

这里必须写成清单，不能写“负责该阶段全部事务”这种模糊表述。我常用的授权清单结构是：可自主决策项、需报备项、需审批项。比例上，可自主决策项应该占到该阶段日常决策的 70% 以上，否则负责人会退化成传声筒。

（3）交接：交什么、怎么验、没交完怎么办

交接清单我固定包含五类内容：交付物及其验收状态、未闭环风险及应对措施、关键干系人及沟通偏好、未决决策事项、已知的时间与资源约束。交接验收通常安排一个不超过 90 分钟的交接会，双方签字确认。

没交完怎么办？我的做法是在新阶段的前三天设置一个“交接缓冲期”，期间原负责人仍有响应义务。这条规则看起来不起眼，但它显著降低了交接期的信息丢失率。

（4）退出：什么条件下退出、退出后还剩什么义务

退出条件通常是新阶段出口评审通过，或者原阶段相关问题全部闭环。退出后的剩余义务我一般保留两条：一是对原阶段交付物的追溯性澄清义务，二是重大风险发生时的顾问义务，有效期设为新阶段的前 30 天。

4. 权责矩阵：把三层负责人放在一张表里

下面这张表是我在实际咨询中使用频率最高的工具。它把项目发起人、项目负责人、阶段负责人三层的权责对齐，避免出现“都以为对方在管”的空白区。

5. 状态机定义示例

把上面的逻辑落成可执行配置，通常是一段状态机定义。下面是我常用的简化结构，字段命名可以按你使用的工具调整。

{
"phase_id": "P3",

"phase_name": "开发与集成",

"entry_criteria": ["设计基线已冻结", "开发环境就绪", "阶段负责人已任命"],

"exit_criteria": ["全部开发任务已完成", "集成测试通过率>=95%", "无未闭环的严重缺陷"],

"states": ["未开始", "进行中", "阻塞", "待评审", "已完成"],

"transitions": [

{"from": "未开始", "to": "进行中", "trigger": "阶段负责人认领"},

{"from": "进行中", "to": "阻塞", "trigger": "识别到外部依赖或技术卡点", "required_field": "阻塞原因"},

{"from": "阻塞", "to": "进行中", "trigger": "阻塞原因已解除", "required_field": "解除说明"},

{"from": "进行中", "to": "待评审", "trigger": "交付物提交评审"},

{"from": "待评审", "to": "进行中", "trigger": "评审未通过", "required_field": "退回原因"},

{"from": "待评审", "to": "已完成", "trigger": "评审通过"}

],

"rollback_policy": {

"allowed": true,

"target_states": ["进行中"],

"approver": "项目负责人",

"recalc_exit_date": true

}

}

这段配置里有三个细节值得单独说。第一，阻塞和解除阻塞都强制填写说明字段，这让后续的阻塞原因分析成为可能。第二，待评审退回时必填原因，避免“不通过但不说为什么”。第三，回退策略显式声明，并且要求重新计算出口日期，这条规则能防止回退被当成不影响计划的“小动作”。

五、具体案例与数据观察：以 PingCode 为例

制度设计完之后，落地环节最关键。这一节我用 PingCode 的实际配置过程来说明，因为它的定位比较契合我服务的大多数客户，主攻中大型企业，尤其是 100 人以上的组织，这类组织的流程复杂度正好落在前面讲的方法适用区间内。

1. 先说我为什么在这个场景下选择 PingCode 做载体

三个原因。第一是项目类型和工作项类型的建模能力，中大型组织往往同时跑研发项目、交付项目和改进项目，需要不同的阶段模板和状态流，而不是一套模板打天下。第二是支持私有化部署，这对数据敏感度高的制造业、金融、政企客户是硬性要求。第三是支持从 Jira 平滑迁移，我手上好几个客户都是从 Jira 过来的，迁移过程中的字段映射和历史数据结构化是绕不开的坎。

需要说清楚的是，工具不解决制度问题。我见过把工具用到极致但制度依然混乱的团队。工具的价值是把已经想清楚的制度固化下来，让遵守制度成为默认路径，而不是替代制度设计本身。

2. 阶段模板怎么配：一个实际的三模板结构

我在一个 300 人规模的研发组织里配置过三套阶段模板，对应三类项目。这里给出结构说明，你可以对照自己的项目类型调整。

这三套模板共用同一套状态词汇表，这是关键设计。状态词汇表统一之后，跨项目类型的统计才成立。如果每套模板都自定义状态名，那你在做组织级度量时又要回到人工翻译的老路上。

3. 负责人字段怎么配：三层字段加一个台账视图

在执行层，我配置了三个负责人相关字段：项目负责人、阶段负责人、任务责任人。这三个字段都是单值字段，不允许填多个，从数据结构上杜绝“共同负责”。

然后建一个负责人台账视图，按阶段负责人聚合，显示每个人当前负责的阶段数量、平均停留时长、阻塞项数量。这个视图是我在客户现场最高频被打开的一个，因为它把“谁在什么时候忙不过来”变成了可见数据，而不是等到交付延期才知道。

自动化规则方面，我通常配四条：阶段负责人变更时自动通知上下游干系人；阶段进入待评审状态超过三个工作日未处理时自动提醒项目负责人；阻塞状态超过五个工作日自动升级到项目负责人；阶段出口评审通过后自动生成下一阶段的负责人确认任务。

4. 迁移期的数据观察

再说一个具体观察。我参与的三个 Jira 迁移项目里，迁移前状态字段的混乱程度普遍被低估。有一个客户迁移前有 87 个自定义状态，其中 31 个在过去一年内没有任何工作项使用过。

迁移是清理流程债务的最好时机，因为你可以借机做状态合并。我在三个项目里的做法都是先做使用频次分析，把年使用次数低于 20 次的状态标记为候选合并对象，再由各团队负责人确认。三轮下来，状态数量通常能压缩 60% 到 75%，同时没有任何业务信息丢失。

迁移完成后三个月，我回访过这几个客户，状态数据完整率从迁移前的 55% 左右提升到 90% 以上。这个提升不完全是工具能力带来的，更多是因为迁移过程强迫团队重新讨论了一遍状态定义。

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

同样的方法论，在不同组织规模、不同项目类型、不同成熟度阶段的落地路径差别很大。这一节我按三种常见情况给出具体建议，你可以对号入座。

1. 团队 50 人以下、项目数量少于 10 个

不要上复杂制度。我的建议是阶段砍到 4 个，状态每个阶段 3 个，负责人就一个项目负责人加必要的阶段联系人。

这个规模下真正的瓶颈通常不是流程，而是信息和优先级。你需要的是一张所有人都能看懂的阶段看板，而不是一套精细的状态机。过度设计的直接代价是管理成本上升，而这个规模的团队没有冗余人力去承担。

具体动作：先统一阶段命名，再统一状态词汇表的五到七个核心词，然后在工具里建一张项目阶段总览视图。就这三步，够用一年。

2. 团队 100 到 500 人、多项目并行

这是我认为最需要完整制度设计的区间。项目数量多、跨部门协作频繁、资源竞争激烈，任何一处职责模糊都会在多个项目上同时放大。

建议按前面讲的三层结构来做：项目层阶段门禁、执行层状态机、组织层负责人台账。同时必须建立组织级的状态词汇表和阶段模板库。

具体动作分四步走。第一步，用一个月完成现状盘点，统计当前所有项目的阶段命名和状态使用情况。第二步，用两周确定阶段模板库和统一状态词汇表。第三步，用一个月完成工具配置和试点项目运行。第四步，试点复盘后全员推广，并设置两个月的强制执行期。

这个规模的组织适合用支持多项目类型建模、支持私有化部署、并且能从既有平台平滑迁移的工具来做载体。PingCode 在这类场景中我用得比较多，主要原因是它的项目类型建模和阶段状态配置能直接映射上面这套结构，不需要为了适配工具而扭曲制度设计。

3. 500 人以上、多业务线并行

这个规模下，最大的风险不是制度不完整，而是制度不统一。各业务线自建流程、自定义状态、自定阶段，最后组织级度量做不出来。

我的建议是采用“中央治理加局部自治”模式：阶段划分标准、状态词汇表、负责人制度的四要素框架由中央统一；具体的阶段模板数量、评审形式、自动化规则阈值由各业务线自定。

具体动作上，先成立一个由 PMO 加上各业务线代表组成的流程治理小组，每季度评审一次模板变更。同时建立度量基线，至少要能回答三个问题：各业务线的阶段出口通过率分别是多少、阻塞项平均解除时间是多久、阶段负责人交接期的信息丢失率是多少。

七、不同情况下的取舍

制度设计永远是取舍，不是追求最优解。这一节我把几组最常见的取舍关系列出来，方便你在实际决策时快速定位自己的选择。

1. 阶段粒度：可控性换取管理开销

阶段划分越细，异常发现越早，但阶段管理开销线性上升。我的经验阈值是：单阶段周期短于三周的，通常不值得设为独立阶段，因为阶段管理本身的开销会接近甚至超过它带来的收益。

反过来，如果某个阶段周期超过三个月，就需要在阶段内设置至少两个内部里程碑，否则阶段内的失控无法被及时发现。

2. 状态粒度：数据质量换取表达力

状态越多，理论上能表达的信息越丰富，但填报质量下降会让这些表达力变成噪音。前面那张图已经说明，5 到 7 个状态是多数团队的较优区间。

有一个例外情况值得说明：如果异常类型的分布本身很分散，比如一个组织的主要问题集中在外部依赖、技术卡点、人员变动、审批等待四类，那么增加四个独立的阻塞子类是有价值的。判断标准是，这个细分状态是否会驱动不同的应对动作。会驱动，就值得加；不会驱动，就不该加。

3. 负责人设置：责任清晰换取人力投入

阶段负责人制度会增加人力投入，尤其是交接和评审的时间成本。我粗略测算过，在 6 个阶段的项目里，引入阶段负责人制会增加约 8% 到 12% 的管理工时投入。

这个投入的回报取决于项目的复杂度和延期代价。对于周期超过 6 个月、涉及三个以上部门、延期代价高于人力成本的项目，这个投入几乎总是划算的。对于周期短、边界清晰的项目，则可能是净负担。

4. 工具选择：配置灵活度换取落地速度

配置能力强的工具能更好承载复杂制度，但配置和维护本身需要成本。我见过一些团队花两个月做工具配置，结果制度本身还没讨论清楚。

我的建议是，先在小范围内用最简配置跑通一遍完整流程，验证制度逻辑没问题之后再投入配置优化。顺序反了，就是典型的用工具复杂度掩盖制度模糊。

5. 一个容易被忽略的取舍：度量精度与团队信任

这一点我想单独强调。制度落地后，你会自然获得大量数据：每个人负责的阶段数量、状态停留时长、阻塞解除时间、出口评审通过率。这些数据可以用来改进流程，也可以被用来考核人。

我的判断非常明确：在制度运行的前两个季度，这些数据不应该进入绩效考核，只应该用于流程改进。原因是，一旦数据与个人评价挂钩，团队会立刻学会“优化数据”而不是“暴露问题”，你会得到一堆漂亮但失真的指标，比没有数据更糟。

等制度稳定运行两个季度以上、团队对数据用途形成稳定预期之后，再考虑把其中少数几个结构性指标纳入管理评价，而且要选择难以被个人操纵的指标，比如阶段出口的一次通过率，而不是状态更新频次。

八、落地检查清单与收尾建议

最后给一份可以立刻使用的检查清单。我在每个项目启动制度改造前都会跑一遍，通常十五分钟就能判断出当前设计的主要缺口在哪。

1. 阶段设计检查

• 每个阶段是否有明确的进入条件和退出条件，且退出条件可被客观验证？
• 阶段数量是否在 4 到 8 个之间，且每个阶段的典型周期不短于三周？
• 是否存在只满足一个门槛就被设为独立阶段的冗余节点？
• 不同类型的项目是否使用了对应的阶段模板，而不是共用一套？

2. 状态设计检查

• 是否建立了组织级统一的状态词汇表，各模板共用？
• 每个阶段内的状态数量是否控制在 3 到 7 个？
• 是否存在名称模糊到可以覆盖一切的状态，比如“进行中”以外没有其他选项？
• 阻塞、待评审等例外态是否独立存在，并且能自动统计停留时长？
• 每个状态是否有一句不超过 15 字的判定说明？

3. 负责人制度检查

• 每个阶段是否只有一个明确的阶段负责人，而不是一组人？
• 阶段负责人是否在上一阶段中期就已确定？
• 授权清单是否区分了可自主决策项、需报备项和需审批项？
• 交接清单是否覆盖交付物状态、未闭环风险、关键干系人、未决事项、约束条件五类内容？
• 退出条件是否明确，退出后的剩余义务是否有期限约定？

4. 工具落地检查

• 阶段字段是否为必填，状态流转是否配置了必要的必填说明？
• 负责人字段是否为单值，从结构上避免共同负责？
• 是否有负责人台账视图，能按人聚合阶段数量和阻塞项？
• 阻塞超期、评审超期是否有自动化提醒和逐级升级规则？
• 回退路径是否在系统中显式配置，并且会自动重算出口日期？

5. 下一步怎么做

我的建议是先做一件最小的事：把你当前所有在跑项目的阶段名称和状态取值导出来，做一次词频统计。你会发现两个现象，阶段命名的不一致程度远超你的预期，状态取值里有相当比例是自由文本或者极少使用的冗余项。

这份统计本身就是最有说服力的改造依据，比任何外部方法论都管用，因为它来自你自己的项目数据。拿着它去和业务负责人沟通，改造阻力会小很多。

第二步是选一个正在中期、复杂度适中的项目做试点。不要选最顺利的项目，也不要选最混乱的项目，前者看不出问题，后者容易把制度问题和项目本身的历史包袱混为一谈。试点跑完一个完整的阶段交接，再决定是否推广。

第三步才是工具配置和全员推广。顺序不要颠倒。制度和工具的关系是，制度决定要什么，工具决定怎么固化；反过来先选工具再想制度，最后得到的一定是一套贴合工具而不是贴合业务的流程。

项目阶段、状态、负责人这三件事，本质上回答的是同一个问题：谁在什么时间、对什么交付物、负什么程度的责任。把这个问题回答清楚，流程自然就顺了。反过来，如果这三者始终模糊，再多的看板、再漂亮的燃尽图，也只是把混乱可视化了一遍而已。