让现有工作的流程可见，减少从请求到交付的延误

## 先弄清现有服务目前从请求到交付的做法 将流动管理视为现有服务之上的改进层，而不是替换所有角色、流程或工具的理由。从人们目前实际开展工作的方式入手，包括非正式交接和例外处理。 定义服务从收到请求到交付成果被验收的完整范围。识别客户、客户期望的成果、服务提供者，以及有助于完成交付的工作。 描述当前不满的来源，但不要归咎于个人。查找请求延迟、完成时间不可预测、返工、优先级冲突、环节过载和期望未得到满足等问题。 就通过可观察、可修正的小幅变更持续改进达成共识。鼓励任何能够揭示问题、协调支援或检验更好规则的人发挥领导作用。 重新设计服务之前，确认以下事项： - 哪项客户请求标志着服务开始。 - 哪个事件代表交付成果已被验收。 - 哪些活动和依赖关系属于服务边界之内。 - 在证据支持变更之前，应保留哪些现行做法。 ## 调查进来的请求、过去的交付时间和工作等待的地方 设计控制方式之前，先研究流入的需求。将表现相似的请求分组，记录其频率和紧迫程度，并区分有价值的需求与由缺陷、输入不清或先前失败引起的可避免工作。 利用历史证据了解服务能力。检查完成的工作量、请求所需时间、工作在哪些位置等待，以及每个环节有多少工作仍在进行。 按照工作流程的实际运行方式进行建模，包括队列、评审、依赖关系、并行活动、启动承诺和交付。当正式流程与观察到的现实不同时，不得用正式流程取代现实。 让相关角色的代表参与设计。仅由一个角色构建的工作流程模型很可能遗漏约束、客户期望或运营知识。 初始模型应能回答以下问题： - 哪些类型的请求会进入服务？ - 每项请求在哪里接受评估并作出启动承诺？ - 哪些活动会修改或验证工作？ - 工作可能在哪里受阻或延迟？ - 哪些证据能够说明当前表现？ ## 把进行中的工作和推进规则集中在一处可见 创建一个共享视图，用来表示从请求到交付的当前工作流程。展示每个进行中工作项的类型、当前活动、重要风险，以及它是否受阻。 将顺序开展的活动表示为有序环节。只有当这种区分有助于人们作出决策时，才展示并行工作、特殊处理或不同工作项类型。 将运行规则放在其适用位置附近。规则应包括进入和完成标准、优先级规则、能力上限、启动承诺规则，以及推动工作向下一环节移动的条件。 规则应数量少、含义清晰且可以检验。所有受影响的人都应能够解释规则的含义、一致地应用规则，并在规则不再改善成果时提出变更建议。 出现以下情况时，应检查可视化模型： - 工作经常沿着模型中没有表示的路径流转。 - 人们对同一状态或规则有不同理解。 - 出现隐藏的队列或依赖关系。 - 某个视觉细节无助于决策，却增加了维护成本。 ## 限制同时进行的工作量，只在有空位时开始新工作 为整个服务或受约束环节的在制工作量设定明确上限。上限用于保护流动和专注度，而不是一个必须始终填满的目标。 只有在确有需求且下游具备可用能力时，才开始新工作。可用空位就是选择下一个符合条件工作项的信号。 达到上限时，停止向该区域增加工作。协助完成现有工作或解除其障碍、调查约束，或者依据证据修正规则。 为波动、协调、学习和恢复保留一部分能力。让每个人始终满负荷运转，通常会增加队列、任务切换和交付的不确定性。 补充工作时： - 确认候选工作符合就绪标准。 - 比较紧迫程度、价值、风险、依赖关系和延迟成本。 - 只选择当前能力能够支持的工作量。 - 记录特殊处理具有正当理由的原因。 - 拒绝或推迟不应进入交付流程的候选项。 ## 及时标出受阻的工作，并让插队的急件保持少见 日常协调应关注工作的流动，而不是个人活动报告。询问什么正在阻碍完成、需要什么协助，以及下一步应推进哪个工作项。 障碍一经发现就应标记。记录受阻时长、原因、解决负责人和下一步行动，以便分析反复出现的约束，而不是一次次重新发现它们。 只有当不同延迟风险确实需要不同处理方式时，才使用不同的服务类别。为每个类别定义适用资格、优先级、对能力的影响和退出条件。 例外加速应少用并予以明确说明。提前推进一个工作项会改变其他工作项的交付前景，因此必须让这种取舍可见，并由服务负责人接受。 流动恶化时： - 检查流入量是否超过交付能力。 - 查找不断增长的队列和滞留时间过长的工作项。 - 识别瓶颈、依赖关系、返工和任务切换。 - 开始更多工作之前，先完成现有工作或解除其障碍。 - 只有在理由明确时，才能更改上限或规则。 ## 统计交付时间和完成数量，同时防止数字被刷 采用少量能够支持服务决策的指标。首先衡量交付历时、单位时间完成的工作项数量、在制工作、障碍，以及适用情况下的可避免需求。 准确界定每项指标，包括起点、终点、单位、统计总体、排除条件和评审周期。当混合不同工作项类型或服务类别会掩盖重要差异时，不要将它们合并统计。 检查分布和趋势，而不是只依赖平均值。历史区间有助于估计未来的交付预期，但不能消除不确定性。 使用流动视图发现工作积压、不稳定的流入和流出，以及受约束环节。将模式变化视为改善或恶化之前，先调查这种变化。 防止指标体系被操纵： - 衡量服务，而不是个人的忙碌程度。 - 将速度指标与质量及返工信号结合起来。 - 在比较期间保持定义稳定。 - 记录会影响数据的规则或需求变化。 - 停用不再支持决策的指标。 ## 利用现有会议清除阻碍并回顾结果 只有当观察结果会带来决策或行动时，才将会议和评审用作反馈闭环。缺少响应机制的状态信息无法改进系统。 现有会议能够实现所需目的时，应继续利用。根据服务情境调整参与者、频率、时长和议程，而不是默认创建一整套新的会议体系。 将即时流动协调与更深入的改进和风险评审分开。每日或高频协调应清除障碍并选择工作；定期评审应检查表现、需求、风险、规则和实验。 让每项例行活动聚焦于工作和服务成果。只邀请理解证据、作出决策或执行后续行动所必需的人员。 为每项例行活动定义： - 决策目的和作为输入的证据。 - 承担责任的参与者。 - 预期行动或产出。 - 评审频率和时间限制。 - 追踪未解决行动的方式。 ## 尝试可撤回的小改动，只保留有效的做法 将观察到的服务问题转化为可检验的假设。说明预期效果、支持或否定该假设所需的证据，以及评估所需的时间或样本量。 优先采用负面影响有限的小幅变更。定义当变更损害交付、质量、客户成果或另一项相关服务时，如何撤回或修正变更。 实验期间收集数据，并与适当的基准进行比较。记录情境变化，避免把表面上的改善归因于错误的原因。 依据证据接受、否定或修正假设。即使实验失败，也要保留有用的经验；不要仅仅因为已经投入精力实施某项变更就保留它。 重复以下循环： - 观察需求、流动、能力和客户成果。 - 识别影响最重大的约束或不确定性。 - 提出最小幅度的规则或工作流程变更。 - 在明确的边界内实施变更实验。 - 与服务参与者共同评审结果。 - 保留、修正或撤回变更。