看板如何做好进行中？PMO入门指南与操作步骤

看板如何做好进行中？PMO入门指南与操作步骤

项目看板上有 20 个项目都标着“进行中”，但其中 6 个在等决策、4 个缺关键资源、还有几个已经两周没有更新，这时，看板呈现的不是项目进展，而是组织无法辨认的工作堆积。PMO 要做好“进行中”，重点不是多加几列，而是说清楚什么工作可以进入、如何识别停滞、谁来推动退出，以及超过承载能力后要做什么。

一、核心结论：把“进行中”从一个状态，变成一套运行规则

1. 看板不是进度墙，而是工作流的控制面

我判断一张 PMO 看板是否有效，不先看颜色够不够丰富，也不先看统计图做得是否漂亮，而是看它能否回答四个问题：哪些工作正在被实际推进？哪些工作被等待或阻塞？当前瓶颈在哪里？谁需要在什么时候采取什么行动？如果这些问题答不上来，“进行中”就只是一个标签。

一套可执行的“进行中”规则至少要包含四部分：进入条件、在制容量、停滞识别和退出条件。进入条件控制工作何时开工；在制容量避免团队同时启动过多事情；停滞识别区分“正在做”和“名义上在做”；退出条件保证工作完成、暂停或转入下一阶段时及时改变状态。

最重要的判断是：状态表达事实，规则推动行为。把“进行中”拆成“执行中、等待评审、等待外部依赖、阻塞、暂停”等不同含义，只有在这些差异会触发不同处理动作时才有价值。若只是增加标签，却没有对应责任人和下一步行动，拆分只会让填报更复杂。

2. PMO 先确定看板服务哪一种决策

PMO 看板通常面对多个项目、多个业务部门和共享资源，主要支持项目组合层面的优先级、资源、风险和决策管理。团队任务看板则面向具体工作流，追踪设计、开发、测试、评审等工作项。两者可以关联，但不能把“任务卡有多少张”直接解释成“项目有多少个”或“项目健康度如何”。

在搭建前，我会先写下看板要支持的三到五项决策。例如：是否批准新项目进入执行、是否需要调整关键岗位资源、哪些项目要升级处理、哪些工作应该暂停或降级。决策问题越明确，看板字段越容易精简；如果目标只是“让所有项目都能展示出来”，最终很容易得到一张信息很多、行动很少的状态墙。

二、真实场景：为什么“全部进行中”会让管理更困难

1. 项目很多，不代表工作真的在流动

设想一个有 12 个业务项目的组织：7 个项目显示“执行中”，3 个显示“测试中”，2 个显示“待启动”。表面看项目状态一目了然，但进一步询问后发现，7 个执行中项目里有 2 个等待业务确认，1 个缺少关键岗位，另有 1 个因依赖系统尚未准备好而停了十天。项目数没有变，真实可推进的工作却远少于状态标签所暗示的数量。

这类差异会造成两种管理误判。第一，管理层以为团队正在处理大量工作，于是继续批准新项目；第二，项目负责人为了避免被认为落后，倾向于维持“进行中”，而不是主动报告等待或阻塞。结果是资源被分散，真正需要决策的问题反而被埋在普通状态里。

因此，PMO 不应把“进行中项目数量”当成唯一核心指标。至少还要观察工作项在状态间的流动、停留时长、阻塞原因和待决策数量。若项目组合的状态长期不动，应该先追查流动受阻的环节，而不是要求所有负责人把进度百分比再更新一遍。

2. 把项目层状态和任务层状态分开看

项目层的“进行中”通常意味着项目已经通过启动治理，正在向阶段性交付推进；任务层的“进行中”则更接近某个具体工作项正在被团队处理。一个项目可以处于执行阶段，同时内部有任务处于待评审、测试、等待输入或阻塞状态。因此，项目状态不能简单等于项目内所有任务状态的平均值。

如果只做项目组合看板，卡片可以代表项目，并展示阶段、负责人、目标节点、风险、下一步和需要的决策。如果还要管理团队执行，就需要关联更细的工作流视图。PMO 的职责是确认两层口径一致、异常能够上卷，而不是把所有任务都塞进项目组合页面。

一个实用检验方法是：随便选一张“进行中”的项目卡，请项目负责人用 30 秒讲清“最近一次完成了什么、下一步是什么、当前最大阻碍是什么”。如果只能回答“整体大约完成 60%”，说明状态信息还没有转化成可管理的工作信息。

三、常见误区：看板看起来完整，为什么还是没人用

1. 把“正在推进”和“没有结束”混为一谈

项目还没完成，不代表它正在推进。工作可能正在等待审批、等待客户反馈、等待资源，也可能已被暂时搁置。把这些情况全部留在“进行中”，看板就会把活动、等待和停摆混成一个状态，管理者无法判断该提供支持还是调整计划。

解决办法不是无限增加状态列，而是先把工作流主状态与异常原因分开。主状态说明工作走到哪一步；阻塞标记说明为什么无法继续；等待责任人说明由谁推动；下次检查日期说明什么时候重新确认。这样既保留流程的可读性，也能让异常被及时处理。

2. 认为 WIP 上限是一个可以照抄的固定数字

限制在制工作，也就是 WIP 限制，核心不是规定所有团队最多只能做几件事，而是让组织看见容量约束，避免持续启动新工作、却没有足够能力完成已有工作。不同团队的工作复杂度、协作方式和关键岗位配置不同，同一个上限数字可能对一组团队太宽松，对另一组团队则过于严格。

PMO 可以先试行而不是宣称找到“标准答案”：选一个边界清晰的团队或项目组，观察当前并行工作量、等待时长和资源冲突，再设置一个可复查的试行上限。若超过上限，要有明确的处理方式，例如暂停新工作、先清理阻塞、重新排序，或升级资源决策。没有超限动作的上限，只是看板上的装饰线。

3. 只更新百分比，不更新下一步和阻碍

“完成 70%”容易让人误以为项目已经接近结束，但不同项目的百分比算法可能并不一致：有的按任务数量，有的按预算，有的只是负责人主观估算。若没有共同口径，百分比看似精确，横向比较时却可能失真。

对于 PMO 的日常管理，下一步交付物、目标日期、阻塞原因和决策需求往往比单一百分比更能指导行动。百分比可以保留，但必须说明它的计算口径，并避免把它当作项目健康度的替代指标。

4. 把数据更新责任全部交给 PMO

PMO 可以制定口径、组织复盘、检查异常和汇总决策，但如果所有项目字段都由 PMO 代填，数据很容易变成二次转述。项目负责人不再对状态负责，管理人员看到的是“已经被整理过”的信息，却不一定是最新事实。

建议采用“责任人维护事实，PMO 维护规则”的分工：项目负责人更新状态、下一步和风险；依赖责任人更新交付时间；PMO 检查逾期、口径冲突与升级事项。PMO 不必追求每个字段都由自己录入，而要保证信息有明确来源和责任链。

5. 只展示风险，不指定行动和截止时间

红色风险卡如果没有责任人、行动项和复查日期，通常不会自动解决问题。看板上的每个异常至少应能回答：谁负责下一步？要完成什么动作？什么时候检查？需要谁提供支持？如果需要管理层决策，决策请求是什么、最迟何时需要答复？

真正的异常管理不是给项目涂红色，而是让红色对应明确的升级路径。项目负责人可自行处理的问题不必层层上报；跨部门依赖需要 PMO 协调；超出授权范围的优先级或资源取舍则应进入组合治理会议。

四、专业判断逻辑：状态、容量、时间和责任要一起设计

1. 先用最小状态流，而不是追求完整流程图

PMO 初次建立组合看板时，可以从“待启动、执行中、待验收、已完成”这类最小主流程开始，再根据治理需要补充“暂停”或“取消”。具体状态名称应对应真实的管理节点，而不是把每个部门的操作步骤都搬到项目组合层。

“阻塞”通常更适合作为异常标记，而不是与主流程状态并列的长期阶段。因为一个项目可能仍处于执行阶段，但同时被外部依赖阻塞；若把阻塞设为主状态，项目解除阻塞后还需要人为判断应回到哪一步。可以在卡片上同时保留“当前阶段：执行中”和“异常：外部依赖阻塞”。

状态是否需要拆分，可以用一个问题判断：不同状态是否需要不同的责任人、不同的处理动作或不同的管理节奏？如果答案都是否定的，就没有必要再增加一列。状态过细会增加维护成本，也会让跨项目汇总更难比较。

2. 把进入条件写成可检查的准入清单

一个项目进入“执行中”之前，至少应确认负责人、目标交付物、优先级、关键里程碑、主要依赖和必要资源。不是每个组织都要填写同样多的字段，但缺少负责人或目标交付物时，项目通常不具备真正开工的条件。

准入清单不应沦为审批文书。PMO 可以把字段分成“必须具备”和“后续补充”两类：必须项决定是否允许进入执行；补充项允许在启动后按约定时间完善。这样既能避免信息不足的项目过早占用资源，也不会因为追求表单齐全而拖慢合理启动。

3. 同时设定离开条件，防止卡片长期挂在一个状态

进入条件解决“什么时候开工”，退出条件解决“何时算完成当前阶段”。例如，项目从执行转入待验收，应明确需要提交什么交付物、由谁验收、验收未通过时回到哪个流程。若退出条件含糊，卡片就会长期处于“差不多做完”的状态。

退出“进行中”不一定只意味着项目完成。项目可能转入待验收、暂停、取消或重新规划。每一种变化都应保留原因和批准依据，避免团队通过直接改日期或把卡片移出视图来掩盖问题。

4. WIP 上限要按层级设计，避免项目数和任务数混算

PMO 的项目组合 WIP 和团队任务 WIP 是两个不同的容量问题。项目组合层关注组织能够同时有效治理多少项目、关键岗位能支撑多少优先事项；团队层关注某一工作流中同时处理多少任务。项目数上限不能直接替代任务数上限，任务数增加也不必然意味着项目组合失控。

如果组织缺少历史数据，我建议先从瓶颈岗位入手，例如架构评审、业务验收或安全审核。统计这些角色手头的并行工作和等待队列，比一开始给所有项目设置相同上限更有解释力。只有当具体瓶颈可见，PMO 才能判断是减少新工作、调整优先级，还是增加临时支持。

图表中的示意数据不是行业基准，只用于说明 WIP 试验如何评估。若试行后交付周期缩短，但返工率明显上升，不能简单宣称上限有效；如果在制数量降低、等待时间却没有变化，就应检查真正瓶颈是否在外部审批或共享依赖环节。

5. 用停留时间和老化工作识别“名义进行中”

项目或任务的停留时间，是识别看板失真的重要线索。PMO 可以为不同工作类型设定复查阈值，例如某类审批超过约定时限就提醒责任人，而不是对所有项目套同一条天数规则。这里的阈值是组织内部的管理约定，不是行业标准。

“老化工作”是指已经进入某个状态较久、但没有新的进展记录或下一步变化的工作项。它不一定已经延期，却值得被检查。相比只看红黄绿状态，定期查看最长停留项，往往更早暴露依赖、资源冲突或决策等待。

五、案例与数据观察：用一个试运行组合检验规则是否有效

1. 情景案例：12 个项目先试运行六周

下面是一组为了说明操作方法而构造的情景模拟，并非来自某家企业的真实运营数据，也不能当作行业平均值。设定一个由 PMO 管理 12 个项目的组合，试运行开始时发现 7 个项目标为执行中，但有 4 个项目的下一步不清晰，3 个项目存在等待或资源阻塞，负责人更新频率也不一致。

PMO 没有立刻引入复杂的健康度评分，而是先做四件事：统一主状态；增加阻塞原因与下一步字段；要求项目负责人在固定节奏前更新事实；每周复盘最长停留和待决策项目。六周后，重点不是宣称“效率提升了多少”，而是比较异常是否更早显现、问题是否有人接、状态是否能对应实际交付。

在这个模拟中，PMO 发现项目总数没有减少，但被标记为“需要管理层决策”的事项从 5 项变为 3 项，其中两项已通过优先级调整得到处理。等待中的项目没有全部被“解决”，但责任人和复查日期变得可见。这样的变化比看板上绿灯数量增加更有管理价值。

2. 试运行期间看哪些指标，避免用单一数字讲故事

我会把指标分成流动、质量和治理三组。流动指标观察工作是否在状态间推进，例如周期时间、停留时间和在制数量；质量指标观察交付是否稳定，例如返工或验收退回；治理指标观察异常是否进入处理闭环，例如待决策时长、逾期未更新数量和责任人明确率。

指标不必一开始就全部自动化。试点阶段可以人工抽样核对定义是否一致，特别要确认“周期时间从哪天开始算”“阻塞时钟是否继续”“项目级状态的分母是什么”。如果口径尚未统一，图表看起来再精确也只会让团队更快地争论数据。

3. 会议节奏要围绕异常，而不是逐张卡片做口头汇报

周会如果从第一张项目卡念到最后一张项目卡，通常会消耗大量时间，却没有留下清晰决策。更有效的做法是提前从看板筛出阻塞、延期、关键依赖、资源冲突和待决策事项，会议只讨论需要协作或授权的部分。状态正常的项目保留在看板上即可，不必每次都口头复述。

每条会议行动项都应回写到看板或关联记录中，包括责任人、动作、截止时间和所需支持。下次会议先检查已承诺事项是否完成，再进入新异常。这样看板就不只是会前汇报材料，而成为会议决策的输入和会后跟进的依据。

会议频率要按变化速度决定。项目组合变化快、跨部门依赖多，可以采用较短周期检查异常；项目稳定、治理节点较少，则不必为了形式而每天开会。关键是数据更新节奏、会议节奏与决策权限相匹配。

六、操作步骤：从空白看板到可运营的 PMO 机制

1. 第一步：写清楚看板要支持的决策

列出看板使用者和他们要做的决定。项目负责人可能需要解决下一步执行问题；PMO 需要协调共享资源、追踪跨项目依赖；管理层需要批准优先级变化或重大资源调整。先限定决策范围，避免一张看板同时承担项目汇报、任务管理、绩效考核和预算审计等所有用途。

可以把看板目标写成一句可验证的话，例如：“每周识别需要跨部门协调的项目，并明确责任人与决策期限。”这比“提升项目透明度”更容易判断是否有效，因为可以抽查会议纪要和异常卡片，看决策是否真正形成闭环。

2. 第二步：确定看板的管理对象和信息层级

明确每张卡代表一个项目、一个阶段交付物，还是一项工作任务。PMO 组合看板一般以项目或治理事项为对象；团队工作流看板则可以细到具体任务。若组织需要同时管理两层对象，应让它们通过项目编号、关联关系或共同字段衔接，而不是混在一个列表里。

同时确定谁会看这张板。项目团队需要足够细节来推进工作；管理层需要聚合信息和异常摘要。可以采用不同视图呈现同一套数据，但不要为了管理层简洁而删掉异常证据，也不要把所有执行细节堆到高层视图中。

3. 第三步：定义最小状态流、进入条件和退出条件

先画出实际发生的阶段，再删除不影响责任、动作或决策的状态。对每个状态写一句定义，并附上进入和离开条件。例如“待验收”意味着交付物已提交且验收人已确认；“暂停”意味着项目暂不消耗执行容量，并且有复审日期和批准依据。

状态说明要能让不同负责人做出相同判断。若两位项目负责人看到同一个项目，却会分别把它标成“执行中”和“等待中”，通常说明定义缺少可观察条件，而不是负责人不够认真。将争议案例记录下来，用它们校准口径，比反复要求“按规范填报”更有效。

4. 第四步：设置最少但够用的卡片字段

一张 PMO 项目卡可以从项目名称、负责人、优先级、当前阶段、下一里程碑、目标日期、风险或阻塞、下一步动作、更新时间和决策需求开始。字段越多，维护成本越高；字段过少，又无法支持异常处理。新增字段前先问：谁会使用它做什么判断？如果没有明确用途，就先不加。

对于不同类型项目，可以保留共同字段，再加少量类型字段。比如产品研发、系统实施和合规改造的里程碑不同，但负责人、优先级、阶段、下一步和风险通常仍可保持一致。共同字段是组合比较的基础，类型字段则负责保留必要的专业信息。

5. 第五步：约定更新责任和更新节奏

为每类信息指定来源。项目状态和下一步由项目负责人更新；依赖事项由对应责任人确认；组合优先级由有授权的治理角色维护；PMO 负责检查缺项、逾期和异常闭环。若一项数据没有明确的事实来源，管理者应把它标为待核实，而不是让 PMO 根据印象补齐。

更新频率不应照搬固定模板。变化快的执行事项可能需要更频繁地更新；稳定项目可以围绕里程碑或固定治理周期更新。无论采取何种频率，都要定义“超过多久未更新需要提醒”和“谁负责升级”，否则更新时间字段存在也不会产生管理动作。

6. 第六步：小范围试点，并记录规则带来的副作用

先选一组项目试行，而不是一开始就要求全组织一次性迁移。选择标准可以是项目负责人愿意配合、工作流相对典型、跨部门依赖足够明显。试点期间记录状态争议、字段缺失、等待原因、超限情况和会议决策，定期检查规则是否改善了可见性，还是只是增加填报工作。

若项目负责人需要花大量时间重复录入同一信息，优先解决数据重复问题；若 PMO 仍要靠私下询问才能知道阻塞，优先检查责任链和更新机制；若管理层看板只显示红黄绿而无法追问原因，优先补充异常证据，而不是继续增加仪表盘。

7. 第七步：按结果调整 WIP 和指标，不要先追求自动化

试运行后，先看哪些工作流动了、哪些节点仍在排队、哪些状态定义容易产生分歧，再决定是否调整 WIP 上限、复查阈值和更新节奏。自动化适合减少重复动作、提供提醒和汇总，不适合替代尚未统一的管理定义。规则不清晰时，自动化只会更快地产生口径不一致的数据。

当团队已能稳定维护状态、责任和下一步，再考虑自动提醒、数据汇总或组合视图。选工具时应验证字段配置、权限、数据导出、部署方式、历史数据迁移和审计要求是否满足组织实际需求。不要因为工具功能多，就反过来让业务流程迁就工具菜单。

七、不同情况下的行动建议与取舍

1. 如果组织刚开始做 PMO：先求口径一致，再求指标丰富

刚起步时，优先维护少量核心信息：项目负责人、状态、优先级、下一步、目标节点、阻塞原因和决策需求。先让不同部门对“执行中、暂停、待验收”形成共同理解，再逐步补充风险分类、资源负荷和趋势指标。

此阶段不建议一开始就建立复杂评分模型。若项目健康度由多个主观字段加权得出，却没有统一定义，最终评分只会把分歧藏在一个总分里。PMO 可以先用明确的异常规则，例如逾期、阻塞、关键依赖未确认，再观察这些规则是否足以支持管理行动。

2. 如果项目数量多、共享资源紧张：优先管理瓶颈和组合取舍

当多个项目竞争同一批专家、审批人或基础设施时，PMO 应把共享资源负荷和优先级冲突放在突出位置。此时看板的价值不只是告诉大家“有多少项目”，而是支持回答“如果不增加资源，哪些工作必须后移或暂停”。优先级应能形成实际顺序，不能所有项目都被标为最高优先。

取舍可能是减少同时启动项目，也可能是为关键阶段集中资源，还可能是把低价值需求延后。WIP 限制并不意味着拒绝所有新工作，而是要求新工作进入时说明它将替代什么、占用什么容量、对现有承诺有什么影响。

3. 如果团队跨部门、依赖关系复杂：把等待作为独立管理对象

跨部门项目中，真正拖慢交付的可能不是执行能力，而是确认、审批、数据提供和接口依赖。此时只看项目阶段不够，需要记录依赖事项、提供方、承诺日期、当前状态和升级路径。等待事项如果长期没有责任人，项目团队即使每天更新看板，也无法推动依赖方采取行动。

PMO 可以建立依赖队列，定期查看等待时长和重复出现的阻塞类型。如果同一部门、同一审批环节反复成为瓶颈，问题就不再只是单个项目的问题，而可能需要调整服务流程、授权或资源安排。

4. 如果组织已有很多图表和系统：先检查数据可信度，不要再叠加一套

已有工具并不意味着数据可以直接用于组合决策。先抽样核对项目状态与实际交付记录，检查状态更新时间、字段含义、历史变更和数据来源。如果项目负责人维护一套表、PMO 汇总另一套表、管理层另有汇报表，先处理口径重复和数据责任问题，再决定是否新增系统或仪表盘。

对于项目工具选型，PingCode 可以作为候选平台之一评估。按产品定位，它面向中大型企业及 100 人以上组织，支持私有化部署，并提供 Jira 平滑迁移能力；但这些产品能力是否适合具体组织，仍应通过实际试用、迁移演练、权限测试和数据核验来确认。“国产替代”不应仅凭宣传语决定，关键是流程适配、历史数据完整性、运维责任、成本和长期可控性。

评估迁移时，不要只检查卡片能否导入。还要抽查状态映射、字段值、评论附件、历史记录、用户权限、自动化规则和报表口径。先用一小批代表性项目做演练，再对比源数据与目标环境的记录完整度，并确认业务人员能否按新规则持续维护。

5. 如果管理层只关注红黄绿：用事实链补足判断依据

颜色可以帮助快速筛选异常，但不能代替解释。一个项目标红，至少应能打开看到风险事实、影响范围、当前应对措施、责任人、下一检查日期和需要的决策。若同一种颜色对应延期、预算超支、资源不足和目标变更，管理者就无法判断应该如何介入。

可以把健康信号设计为触发提醒，而不是形成未经解释的综合分数。例如，关键里程碑已逾期、重大依赖超过约定期限、风险责任人缺失时触发关注；每个触发条件都说明计算口径和处理方式。这样既能保留摘要视图，也能追溯到可核验事实。

6. 不同方案的取舍：先解决问题，再决定复杂度

最稳妥的选择不是功能最多的方案，而是能以可接受的维护成本，持续支撑责任人更新、PMO 识别异常、管理层做出取舍的方案。若目前连状态定义和数据责任都没有统一，先用轻量方式试点通常比立即迁移全量系统更容易控制风险。

八、结尾：先让卡片流动，再让看板变大

1. PMO 可以用五个问题检查当前看板

• “进行中”是否有一致定义，项目级与任务级是否分开？
• 每张卡是否有负责人、下一步动作和可检查的日期？
• 等待、阻塞、暂停是否能被区分，并对应不同处理方式？
• 是否知道当前在制工作由哪些关键岗位承接，超限后如何处理？
• 看板上的异常是否能进入责任分配、升级和复查闭环？

如果其中有两项以上回答是否定的，优先修规则，不要先做更多图表或扩大系统范围。选一组项目，统一最小状态流和更新责任，连续观察状态争议、老化工作、阻塞闭环和待决策事项。数据能被核验、行动能被追踪之后，再逐步扩展到更多项目和自动化能力。

看板做好“进行中”，不是让所有工作都显示为正在推进，而是让组织清楚看见哪些工作正在流动、哪些工作被卡住、哪些新工作暂时不该启动。下一步就从抽查十张进行中卡片开始：要求每张卡都能说清最近进展、下一动作、责任人和阻碍。说不清的卡片，就是 PMO 最值得先处理的信号。