迭代流程与规范：跨部门团队迭代管理最佳实践关键指标

跨部门迭代延期，往往不是开发“做得慢”，而是同一项工作在产品、研发、测试、设计和业务之间被反复重新解释：需求进入迭代时看似明确，开发中途才发现验收口径不一致，测试阶段又补出依赖和权限问题。迭代流程真正需要管理的，不只是按期交付率，而是从需求承诺到可验证结果之间的整条链路。本文从团队实际管理中常见的断点出发，拆解一套能落地的跨部门迭代规范、关键指标和取舍方法；

文中的案例数据均为情景模拟，用于说明分析方法，不代表行业统计或任何企业的真实业绩。

一、先讲结论：迭代指标要管承诺质量，而不只是完成数量

1. 迭代管理的核心不是“把任务排满”

我判断一个团队的迭代管理是否有效，不先看看板上有多少任务，也不先问团队用了几周一个迭代。我会先问三个问题：承诺的工作是否有明确验收条件？跨部门依赖是否在开始前暴露？未完成项能否被解释为可行动的原因，而不是笼统归结为“进度延迟”？这三个问题分别对应输入质量、协作过程和交付结果。

如果只盯着按期完成率，团队可能通过少承诺来做高数字；只盯着任务完成数，又可能拆出大量价值很低的小任务；只盯着工时，则容易把复杂问题误判成个人效率问题。指标必须组成一条因果链：入口是否准备好，过程是否顺畅，交付是否可用，复盘是否改变下一轮决策。

因此，我建议先建立一组精简指标，而不是一次性铺开几十个看板字段。最小可用组合通常包括：需求准备度、迭代承诺完成率、周期时间、阻塞时间、返工率、发布后缺陷率和计划变更率。每项指标都要定义分子、分母、统计边界与责任人，否则同一个名称会在不同部门被算成不同东西。

2. 先建立基线，再设目标值

不同团队的产品形态、发布审批和合规要求不同，直接照搬某个“行业标准完成率”很容易失真。新团队应先连续观察三个迭代，记录口径一致的数据；如果迭代周期很长，可以用四至六周作为初始观察窗。目标值应根据团队自己的基线、风险容忍度和交付约束来定，而不是为了仪表盘好看随意设成百分之百。

这里有个容易忽略的判断：指标波动不等于管理变差，解释不了的波动才是管理问题。例如完成率下降，但原因是主动减少了未经验证的需求、把高风险依赖提前发现，这可能是管理改善的早期信号。需要继续跟踪后续缺陷和交付价值，而不是立刻要求团队把完成率拉回去。

二、背景与真实场景：跨部门迭代的失速，通常发生在交接处

1. 一个需求可能同时有五种“完成”

以一个常见的客户权限改造为例：业务部门认为页面上能看到新权限开关，就算需求完成；产品经理认为规则和异常流程已经说明白；设计团队认为交付了最终稿；研发团队认为代码合并且部署到测试环境；测试团队则要确认角色、数据范围、兼容行为和回滚路径都符合预期。五种定义并非谁对谁错，但如果没有在迭代开始前统一，最后就会变成多人各自做完，却没有一个人能确认需求真正可用。

这类问题在组织规模扩大后更加明显。一个跨部门工作项通常有不止一个上游输入，也可能依赖接口、数据、法务审查、客户确认或发布窗口。项目管理工具里把任务从“待办”拖到“完成”，并不能自动消除这些依赖。流程的价值，在于让团队提前看见缺口、明确下一位责任人，并保留变更依据。

2. 先区分三种延迟，才能避免错怪人

实际复盘时，我会先将延迟分成三类。第一类是工作量估算偏差：实际复杂度超过已有信息支持的估算。第二类是等待时间：任务本身没有持续执行，而是在等待决策、接口、环境或验收。第三类是返工：前面完成的工作因规则变化、理解不一致或质量问题被重新做。三种延迟需要不同的改进动作，混为一谈只会导向“以后要提高效率”这种无法验证的结论。

例如，一个开发任务拖了四天，不代表开发持续工作了四天。若其中两天等待外部接口确认，管理动作应该是将接口依赖前置并设置响应时限；若两天用于推翻原有实现，应该追查需求变更和评审缺口；若确实是估算不足，则应复核拆分粒度和未知事项。把等待时间从执行时间里单独识别出来，是跨部门团队找到系统瓶颈的第一步。

3. 管理对象应是工作流，而不只是团队成员

跨部门迭代的工作往往经历需求澄清、设计、开发、测试、验收、发布等环节。每个部门都可能完成自己的局部任务，但整体流动仍然缓慢。若管理者只查看各部门的工作量，很容易产生“我的部分已完成”的局部最优，却看不到工作项在交接处排队。

所以我会把每项关键需求至少关联三个信息：当前状态、下一责任角色和阻塞原因。状态回答“工作走到哪”；责任角色回答“谁负责推动下一步”；阻塞原因回答“为什么没走”。如果这三项里有任何一项长期空白，团队得到的不是可执行的透明度，而只是一个看起来整齐的任务列表。

三、常见误区：看起来在管理，实际在制造指标噪音

1. 把承诺完成率当成个人考核

承诺完成率适合用于观察团队计划的稳定程度，不适合直接给个人排位。若一旦低于目标就追责，团队会逐渐学会少报风险、降低任务难度、把未完成项移出迭代，或者把工作拆成大量容易勾选的小项。数字可能变好，但交付价值和风险透明度反而变差。

更稳妥的做法是把完成率当作团队复盘入口，并和计划变更、阻塞时间、需求准备度一起看。若低完成率反复出现在同一类依赖上，改进对象应是依赖机制；若经常因验收口径不清返工，应补充需求准备规则；如果变更频繁来自外部战略调整，则需要区分可控变更和不可控变更。

2. 把速度当作跨团队可比的绩效

故事点、任务数或人天都可能用于团队内部规划，但不同团队的估算习惯、工作类型和拆分方式不同，横向比较往往没有意义。一个团队的“30 点”不必然比另一个团队的“20 点”交付更多价值。把速度用于团队之间排名，还会诱发估算膨胀，削弱原本用于规划的参考价值。

跨团队比较时，我更关注周期时间的分布、交付质量和工作类型差异。周期时间可以帮助识别流程是否变慢，但也要按任务类别区分：小型缺陷、常规功能和高风险架构改造不能混成一个平均值。中位数、上四分位数和长尾案例，通常比单一平均值更能说明真实情况。

3. 把“开会更多”误当成协作更好

跨部门一有问题就增加会议，可能只是把等待变成了日历占用。每日站会如果变成逐人汇报，无法让阻塞获得明确处理；评审会若没有决策人、输入材料和待决事项，也会把讨论推迟到会后。会议不是流程本身，会议要解决的应是明确的决策或协调问题。

我通常把会前材料和会后动作作为协作质量的检验：会前是否能看到问题、选项和影响范围？会后是否有责任人、截止时间和完成定义？如果连续几次会议仍在重复同一争议，问题多半不是沟通次数不足，而是决策权限、信息口径或升级机制不清。

4. 把需求变更全都当成“违规插单”

业务变化不可能被彻底禁止。真正需要控制的是变更的透明度、成本和影响范围。若安全风险、监管要求或关键客户问题出现，临时调整是合理的；若只是优先级变化，也可以接受，但应明确被替换的工作、迭代目标受影响程度以及谁批准了调整。

因此，计划变更率不能单独用来惩罚插单，而应分层标记变更类型、提出方、批准方和替换项。没有替换项的临时加入，常常会让团队承担隐形加班；有决策记录的调整，则可以作为业务响应能力的一部分来评估。

四、专业判断逻辑：用一套可复核的规则决定什么该进迭代

1. 入口规则：准备度必须能被检查

迭代计划会不是补需求的地方。开工前至少要确认：用户或业务问题是什么，预期结果如何验证，涉及哪些系统和角色，有哪些外部依赖，风险和回滚要求是什么。不是每个需求都必须写成长文档，但关键问题必须有明确答案，或者明确记录尚未确认的事项及其负责人。

我建议为团队建立轻量级的“就绪检查”，并将其用于高风险或跨部门需求，而不是强制每个小改动填写一张复杂表单。需求准备度可以按关键检查项通过比例计算，例如：业务目标、验收条件、依赖人、风险说明和测试数据五项中已确认四项，则准备度为百分之八十。这个数字用于判断入口质量，不应替代对缺项风险的解释。

2. 承诺规则：基于历史完成能力，而非理想产能

规划时，应先扣除会议、值班、支持工作、假期和已知维护任务，再估算可用于迭代目标的容量。团队过去几个迭代的交付情况可以作为参考，但不能机械外推；若本轮存在新人加入、架构改造或重大外部依赖，承诺规模就需要相应降低。

还要明确“承诺”的对象是什么。建议承诺围绕可验收的目标或工作项，而不是用“全力支持”“配合完成”这类无法验证的表述。跨部门任务要有牵头人和协作责任人：牵头人负责端到端推进，协作责任人对自己负责的输入、交付物和响应时间负责。没有明确牵头人的共同任务，通常会变成大家都参与、没人负责收口。

3. 过程规则：限制并行工作，显露排队与阻塞

当团队同时开启太多任务时，表面上每个人都很忙，实际上每项工作都在等待。限制在制工作量不是为了让人少做事，而是让已开始的任务更快到达可验收状态。建议先从每个角色的并行任务数量开始观察，再根据工作复杂度调整；不要在没有基线的情况下直接照搬某个固定上限。

对阻塞项还应设置升级规则。例如，跨部门请求超过约定响应时间，先由工作项牵头人提醒；仍未解决，再升级到相关负责人；影响迭代目标时，必须在当天同步决策是否替换范围。时限应根据组织实际确定，关键是让阻塞有明确的发现、响应和决策路径，而不是依赖某个热心的人私下催办。

4. 出口规则：完成必须以可验收结果为准

“开发完成”“测试通过”和“用户可用”不是同一个状态。团队需要定义一套共同的完成标准，至少涵盖代码审查、测试范围、缺陷处理、文档或运营交接、发布条件和必要的监控。对不能在一个迭代内上线的工作，也要明确本轮交付的可验证成果，例如接口契约完成、关键风险验证通过或迁移演练完成。

完成标准不宜一味追求繁复。高风险支付、权限或数据迁移任务应有更严格的验证和回滚要求；低风险内部工具调整则可以采用轻量流程。标准应随风险上升而增强，而不是所有任务一律填同样多的表。

5. 复盘规则：每个指标都要连接一个可执行动作

复盘不应停留在“沟通不足”“估算不准”“加强测试”。我会要求每个主要偏差至少回答四件事：事实是什么，影响了什么，最可能的机制原因是什么，下一轮做什么试验来验证改进。行动项应有责任人、观察期限和成功判据，避免写成没有边界的长期口号。

例如，若多个迭代都出现接口等待，行动可以是“需求进入计划会前，接口负责人确认契约和测试环境；连续两个迭代统计等待时长，目标是减少未确认接口造成的阻塞”。这比“加强研发协作”更容易执行，也更容易判断是否有效。

五、关键指标设计：让每个数字都有清楚口径和使用边界

1. 需求准备度：用来识别入口风险

一个可操作的算法是：将已通过的就绪检查项数量除以适用的检查项总数，再乘以百分之百。团队应同时展示缺失项，而不是只看总分。例如，一项需求准备度为百分之八十，但缺失项恰好是数据迁移回滚方案，它的风险可能高于另一项缺少低优先级文案的需求。

因此，准备度更适合作为“是否允许承诺”的判断辅助，而不是需求质量的绝对分数。对关键缺项可以设置硬门槛；对非关键缺项则要求写明负责人和补齐时间。这样既不把流程变成繁琐审批，也不让低准备度需求悄悄进入迭代。

2. 承诺完成率与计划变更率：一对指标一起看

承诺完成率可以定义为：迭代开始时承诺且满足完成标准的工作项数，除以迭代开始时的承诺工作项数。若改用估算量计算，要保证估算单位一致，并明确中途拆分、合并工作项的处理方式。统计时应保留迭代开始时的基线，不要在期末把未完成项从分母里删掉。

计划变更率可以定义为：迭代开始后新增、移除或改变优先级的工作项数，除以迭代承诺工作项数。这个比率说明计划稳定性，但不直接等于团队控制力。应进一步标注变化原因，例如紧急缺陷、业务决策变化、需求补充或依赖中断，并识别是否存在未替换工作造成的额外负担。

3. 周期时间和阻塞时间：看交付速度的构成

周期时间是工作项从约定起点到满足完成条件所经历的时间。起点可以是“开始处理”，也可以是“进入迭代”，但整个团队必须统一口径。阻塞时间则是该周期内因等待外部输入、决策或环境而无法推进的时段。将两者分开，才能判断是工作流程本身慢，还是等待占比过高。

不要只看平均周期时间。少数特别慢的工作项会拉高平均数，而只看中位数又可能掩盖长尾风险。建议至少观察中位数和第九十百分位数，并按需求类型切分。若高风险改造天然周期更长，应该让它与普通缺陷分开比较。

4. 返工率与发布后缺陷率：衡量质量成本，而不只是缺陷数量

返工率可以按返工工时占交付总工时的比例估算，也可以按因已确认问题重新打开的工作项比例观察。两种口径反映的角度不同，不要混用。发布后缺陷率则需要明确统计窗口和严重级别，例如只统计发布后两周内发现的缺陷，或单独追踪影响核心流程的严重缺陷。

缺陷数量多，不一定代表质量变差：测试覆盖提升后，更多问题可能在发布前被发现。反过来，缺陷数量少也不保证质量好，可能只是用户量小或反馈渠道不畅。更有价值的组合是：发布后缺陷严重度、修复时间、重复缺陷比例和关键流程受影响范围。

六、案例与数据观察：用一个模拟迭代看指标如何改变决策

1. 情景设定：计划完成了，目标却没有交付

下面是一组情景模拟：某跨部门团队有产品、设计、研发、测试和业务运营共二十余名成员，进行为期两周的迭代。迭代开始时承诺二十四个工作项，期末完成十七个，完成率约为百分之七十一。表面看，问题像是估算过高；进一步查看记录后，发现四项因接口确认晚而阻塞，两项因验收标准补充而返工，一项因业务优先级变化被替换。

若只追问“为什么没完成”，团队可能得到三个不同答案：开发说需求变了，产品说接口没准备好，测试说验收口径没有锁定。这些说法都可能部分正确，但无法指导下一轮改进。把工作项按延迟类型重新分类后，管理者才看见主因并非单纯产能不足，而是入口和依赖没有被纳入计划约束。

2. 观察过程：从任务记录中还原损失在哪里

团队将阻塞和返工记录补齐后，模拟得到的七个未完成或受影响工作项中，四项关联接口等待，平均等待约两天；两项因验收口径变更产生返工；一项因业务调整退出迭代。这里的重点不是“等待一定占最大比例”，而是每类问题都能找到可核查的记录：阻塞开始与结束时间、需求变更记录、评审决定和替换项。

接下来要验证的不是“流程是否写得更完整”，而是规则是否改变行为。团队把接口负责人确认列入开工条件，要求变更必须写明被替换的工作，并让验收条件在计划会前可查。若下一轮完成率提高，但严重缺陷也上升，就不能简单宣布改善成功；如果等待减少、返工下降、质量保持稳定，才说明改动可能产生了正向效果。

3. 结果解释：数据是诊断工具，不是绩效判决

假设后续两个迭代的情景数据分别显示：承诺完成率从百分之七十一升到百分之八十四，接口等待总时长从八个工作日降到三个工作日，因验收不清造成的返工从六个工作日降到两个工作日。可以据此判断“入口确认和依赖升级可能有效”，但还不能证明这是唯一原因。还要检查需求难度、人员安排、假期和发布范围是否发生变化。

我会把这类结论称为管理假设，而不是因果定论。实际团队可以用连续迭代数据观察趋势，并选取相似工作项对照；若流程变更只持续一轮、且同期工作类型变化很大，就应保留结论的不确定性。专业的数据使用不是给数字加权威感，而是说明数字能支持什么判断、不能支持什么判断。

4. 工具的作用：让规则留下可追踪证据

工具不等于流程，但当组织需要跨部门共享状态、记录变更、追踪依赖和汇总指标时，合适的工具能减少重复沟通。对于中大型企业或一百人以上的团队，重点不应只是看板是否好看，而应检查权限、工作流配置、字段一致性、报表口径、审计追溯、系统集成和部署要求是否适配组织治理。

例如，PingCode可用于项目管理和研发协作场景，适合需要统一跟踪需求、迭代、缺陷及协作状态的团队。组织在评估时，可以具体验证能否建立符合自身定义的状态流转、字段和报表，能否支持私有化部署，以及现有工作项和历史数据如何迁移。若团队正从其他项目管理系统迁出，应把Jira平滑迁移作为评估任务之一，先选取一小批项目做字段映射、权限核对、附件与历史记录验证，再决定是否扩大范围。

任何工具的适配能力、迁移边界和部署条件，都应以供应商当前产品说明及实际验证结果为准，不宜仅凭宣传表述下结论。

工具选型时，我会要求团队拿真实流程做演示，而不是只看标准功能列表：创建一个跨部门需求，记录依赖与阻塞，发生一次范围变更，完成验收并生成复盘报表。这个过程能暴露字段是否过多、状态是否难以理解、数据是否可导出以及权限是否影响协作。工具价值的检验标准，是能否让关键事实更容易被记录、更容易被复核，而不是能否把所有流程都配置得很复杂。

七、不同情况下的行动建议：先处理最影响交付的那个断点

1. 团队刚开始建立迭代制度

刚起步时，不要同时推行复杂的成熟度模型、几十个必填字段和全员报表。先统一迭代周期、需求入口、完成定义和未完成项处理规则，挑选三至五个指标连续记录。第一轮的目标是获得可信基线，而不是追求漂亮的仪表盘。

具体可以按以下顺序推进：

1. 选定一个有代表性的跨部门团队，明确谁负责维护指标口径。
2. 定义迭代开始时间、承诺冻结时间和工作项完成条件。
3. 为需求记录验收标准、依赖人和主要风险。
4. 每周检查阻塞状态，记录开始时间、原因和解除时间。
5. 连续观察三个迭代后，选一个高频原因做小范围改进。
6. 复核改进是否降低等待或返工，同时检查质量是否恶化。

2. 完成率低，但团队已经持续加班

这种情况下，不建议先加大承诺，也不建议要求团队以加班补足数字。先检查计划容量是否扣除了支持工作、会议和维护任务，再把未完成项拆成执行时间、等待时间、返工时间和范围变化。若团队持续忙碌但工作项长期堆积，应重点观察在制工作和交接队列，而不是继续提高个人并行任务数。

如果阻塞主要来自外部部门，管理者要协商明确响应时限和升级路径；如果估算反复偏小，应增加拆分质量和不确定性评估；如果业务插单频繁，则需要建立替换机制。任何调整都应减少不可见负担，而不是把原有目标原封不动地压给执行团队。

3. 完成率很高，但线上问题也在增加

这通常提示团队可能把“完成”定义得过于宽松，或发布压力挤压了测试、审查和回滚准备。先检查缺陷严重度、重复缺陷、测试逃逸率和关键场景覆盖，再回看完成标准是否真正执行。不能仅靠增加测试人员解决问题，因为缺陷也可能源于需求歧义、设计遗漏或环境差异。

对于高风险功能，增加上线前验证和灰度策略可能比继续压缩周期更合理；对于低风险改动，则可以在自动化覆盖足够的前提下保持轻量流程。判断标准不是是否增加了检查步骤，而是风险是否被更早发现、发生后影响范围是否可控。

4. 组织分布在多个地区或业务线

分布式协作需要把隐性沟通转成可搜索的记录：决策结论、依赖责任人、验收口径和变更原因都应有统一位置。对时区差异明显的团队，不能把即时回复当作默认前提，应规定异步响应窗口和紧急事项的升级渠道。关键决策不应只存在于会议录音或个人聊天里。

如果不同业务线流程差异很大，建议统一核心字段和指标定义，同时允许局部流程有合理差别。强行统一每个状态和审批环节，可能抹平必要的业务约束；完全放任各团队自定义，又会导致管理层无法比较。可统一“意义”，不必统一所有“步骤”。

5. 受合规、审计或私有化要求约束

这类团队要把审计追溯、权限边界、数据保留、部署方式和变更审批纳入流程设计的早期评估。不要等到工具上线后才发现历史记录不可导出、跨部门权限无法细分或部署模式不符合内部要求。涉及工具替换时，还应验证数据迁移的完整性，包括历史状态、附件、评论、关联关系和用户权限。

在流程上，也要区分必要控制与重复审批。高风险变更需要完整记录和可追溯审批；低风险、可回滚的改动则可以采用轻量授权。合规不是把每个任务都变成审批任务，而是确保重要风险有证据、有责任人、有复核路径。

八、不同情况下的取舍：标准化、响应速度和透明度不可能都无限最大化

1. 统一流程还是保留团队差异

统一流程有利于跨部门协作、管理报表和人员轮换，但统一过度会让特殊业务承担不必要的摩擦。我的判断是，组织层面应统一关键概念：需求、阻塞、完成、变更、缺陷的定义；团队层面可以保留与产品风险相匹配的具体步骤。

例如，所有团队都应能说明工作项何时算完成，但金融核心流程与内部数据报表的验收证据不必相同。若一个流程差异无法解释为风险、合规或业务需要，就应考虑是否只是历史习惯；若差异有明确依据，则应保留并写清适用边界。

2. 速度还是确定性

紧急业务需要更快响应，但速度提升通常意味着要接受更高的不确定性，或投入额外资源降低风险。团队不能只接受“尽快上线”的要求，却不讨论范围、质量门槛、上线监控和回滚方案。合理决策是把速度目标和风险承受能力放在同一张桌面上。

低风险、可快速回滚的改动，可以倾向小批量、频繁交付；高风险、涉及数据一致性或关键权限的变更，则可能需要更长的验证周期。此时延长迭代不一定代表低效率，关键是等待是否用于有价值的验证，而不是重复排队和无效审批。

3. 指标透明还是避免指标被滥用

指标透明可以帮助团队共同发现问题，也可能被管理者误用为简单排名。完全不公开数据，团队难以形成共同事实；只公布排名和红黄绿状态，又会鼓励指标优化而不是实际改善。最稳妥的方式是同时公开口径、上下文和适用边界，并避免把单一迭代数字直接用于个人评价。

如果管理层需要考核，应优先评价是否建立可靠机制、是否主动暴露风险、是否完成约定改进，而非拿某个周期的完成率判定个人能力。涉及外部依赖或业务策略调整时，应允许团队说明影响因素，但说明必须有记录支持，不能变成没有证据的免责理由。

4. 轻量记录还是完整追踪

记录太少，事后无法还原问题；记录太多，团队会把精力花在填表上。可以按风险分层：普通低风险任务只记录目标、验收和责任人；跨部门或高风险任务增加依赖、风险、回滚和决策记录；涉及审计要求的工作再增加必要的审批证据和保留期限。

判断字段是否值得保留，可以问两个问题：这个字段是否会改变计划、决策或风险控制？复盘时是否有人真实使用它？若连续多个迭代无人使用，且不是合规强制要求，就应考虑删减或自动生成。流程的成熟标志不是字段越来越多，而是关键证据能以最低成本被持续获得。

九、下一步怎么做：用三个迭代验证流程是否真的有效

1. 第一个迭代只统一口径

先选定一个团队，确认工作项的起点、完成条件、承诺基线、阻塞记录和变更分类。不要一上来更换所有工具或改造整个组织流程。团队应能对同一个指标给出相同解释，否则新增报表只会让争论更多。

2. 第二个迭代只改一个主要瓶颈

根据第一个迭代的数据，挑选影响最大的可控问题。例如接口等待最突出，就完善依赖确认和升级机制；验收返工最多，就前置验收评审；并行任务过多，就试行限制在制工作。一次改太多，很难判断哪项措施有效，也增加团队适应成本。

3. 第三个迭代检验结果与副作用

复核等待时间、返工率、承诺完成率和发布后质量是否一起变化。若完成率提高但缺陷变多，说明可能只是降低了质量门槛；若等待减少但团队投入了大量额外会议，则要重新评估改善成本。一个真正有效的改进，应该让问题更早暴露、决策更快完成，且不把成本简单转移给另一个部门。

跨部门迭代管理最值得坚持的判断是：不要用一个结果指标替代整条交付链的诊断。高完成率不能自动证明流程健康，低完成率也不必然意味着团队懈怠。把需求准备、依赖等待、返工、质量和变更放在同一条链路上，才能找到真正可控的改进点。

下一步，可以从最近三个迭代中各抽取一项按期交付、一项延迟和一项返工工作，逐项还原输入、等待、决策和验收记录。先统一事实，再选一个瓶颈做小实验；等团队能用数据解释变化，再决定是否扩大流程、调整指标或引入更适配的协作工具。这样得到的规范，才是团队在真实约束下形成的工作方式，而不是贴在墙上的流程图。