上篇：价值流引领与可视化体系构建

一、前言

在快速迭代的软件项目和产品开发生态中，我们始终围绕两个核心目标：一是确保每一项工作都能为客户创造实际价值，这是产品团队的核心使命；二是确保这些有价值的工作能够高效、顺畅地执行，而价值流理念正是实现这一目标的金钥匙。价值流，作为DevOps及精益生产的核心理念，它引导我们从客户需求和价值创造的角度出发，全面审视并优化企业的业务流程。价值流映射，作为一种强大的可视化工具，能够深入剖析工作流程的每个环节，揭示潜在问题，并为优化提供明确的方向。

在产品开发领域，真正的挑战不在于资源的分配，而在于价值的流动。单纯的过程迭代和任务执行，并不能确保价值的快速交付和灵活应变。因此，我们需要将关注的焦点从资源效率转向流动效率，这是精益产品开发的根本所在。

1.1 价值流的作用与优势

• 可视化软件过程，软件项目相较于传统项目，其过程往往更加复杂且难以直观理解，尤其是当团队规模较大、职位层次较高且领导对业务理解不够深入时，更容易出现管理上的盲区。价值流通过可视化手段，将软件过程中的价值流转和项目管控等环节清晰地展示出来，帮助管理者和团队成员更好地理解项目进展和存在的问题。

• 促进跨部门协作，价值流的可视化特性使得问题瓶颈一目了然，这有助于打破部门间的壁垒，促进各部门之间的沟通与协作。通过共同分析价值流图，各部门可以明确各自的责任和角色，共同寻找解决问题的方案，从而提升整体业务运作的效率和协调性。

• 系统性优化，价值流的可视化特性使得问题瓶颈一目了然，这有助于打破部门间的壁垒，促进各部门之间的沟通与协作。通过共同分析价值流图，各部门可以明确各自的责任和角色，共同寻找解决问题的方案，从而提升整体业务运作的效率和协调性。

• 提升决策效率：价值流分析为企业的决策提供了有力的支持。通过对比现状图和未来状态图，可以清晰地看到改进前后的差异和效果，从而更加准确地判断哪些措施是有效的、哪些是需要调整的。这有助于提升决策效率和准确性。

1.2目标与原则

目标：顺畅、高质量地交付有用的价值。

原则：

1. 探索和发现有用的价值：

   1. 深入理解客户需求，确保所开发的产品或服务能够真正满足客户的期望和需求。

   2. 通过与客户的紧密沟通，不断迭代和优化产品，确保价值的持续交付。

2. 聚焦和提升价值流动效率：

   1. 可视化整个价值流，识别并消除阻碍价值流动的障碍。

   2. 减少无效等待和浪费，提升流程的整体效率。

   3. 促进团队间的紧密协作，确保价值在价值流中的顺畅传递。

接下来我会以看板为载体展开描述价值流的落地过程

二、构建可视化价值流动体系：看板系统设计与实施

在产品开发领域，价值流动往往不可见，因此其管理和优化相较于生产制造更为复杂。看板方法的首要实践便是将工作及其流动过程可视化，以更好地进行管理和优化。以下是对可视化价值流动及看板系统建模的详细阐述与优化。

1、可视化价值流动的核心要点

1. 用户价值可视化：产品开发的终极目标是交付用户价值。在看板系统中，每个蓝色卡片代表一个用户价值，通常是可验证、可交付的用户需求。这些卡片从用户视角出发，体现了团队交付的核心价值。

2. 端到端流动过程可视化：价值从提出到交付的整个过程被称为端到端流动。这个过程包含多个工作环节和等待环节，图中灰色阴影的列即表示等待环节。用户价值在这些列中流动，直至最终交付给用户。

3. 问题与瓶颈可视化：阻碍价值流动的因素（如需求不明确、技术障碍等）以及价值流动不畅的环节（即瓶颈）均需被可视化。这有助于团队快速识别并处理这些问题，从而优化价值流动。

2、可视化价值流动的设计原则

1. 体现价值：展示团队对外交付的所有价值，包括用户需求、业务及产品团队需求、技术及业务探索价值等。

2. 反映协作：清晰描绘团队协作过程，包括步骤间、环节内以及价值流动中的分解与合并过程。

3. 暴露问题：即时反映价值流动中的问题，以便团队识别并处理。

3、可视化价值流动的设计步骤

3.1分析价值流动过程

看板系统的设计应该从分析团队交付的价值类型和价值流动过程开始

2.1.1 识别团队交付的价值类型

从团队外部视角审视团队提供的服务，识别并分类价值类型，如业务需求、关联需求、技术改进等。

2.2.2 确定看板系统的基本流动单元

根据价值类型确定看板系统的基本流动单元。

2.2.3 分析流动单元的流动步骤

确定价值流动所经历的主要工作步骤，并识别出交接或等待环节。

主要工作步骤，需求分析，界面设计，架构设计，需求传递，研发，测试，发布等；在这些工作步骤之间可能会发生明显的交接或等待，如需求传递后等待开始实现，开发完成后向测试移交等。等待环节虽然没有具体的工作，却也占用了价值流动的时间，并可能产生积压，也需要识别出来。

2.2.4 识别流动过程中的价值分解和合并

在流动过程中，价值可能会被分解并由多个人完成后合并。识别这些分解和合并点，以便在看板系统中准确表达。

在流动过程中，价值可能会被分解并由多个人完成后，再进行合并。它往往发生在工作量占比较大的阶段。

在实现阶段，工作被分解为各个模块的开发和联调任务，完成后再进行合并，并将整合的需求移交测试；测试阶段发现的Bug，也会单独跟踪和处理，直到解决后需求才会移交至下一阶段。这时，价值流就会出现层级关系。

2.2选取可视化设计元素

2.2.1 队列

1. 作用：队列在看板系统中至关重要，反映工作流状态并指导团队协作。

2. 分类：根据工作流状态，可划分为工作列和等待列。同时，设置“就绪”队列表示团队即将处理的需求。

3. 细化与划分：

   1. 细化级别：根据工作停留情况和使用者关注焦点灵活调整。

   2. 起止阶段：从用户问题开始到问题完全解决，形成业务闭环。实际操作中，可从局部流程入手并逐步延伸。

“就绪”队列的设置

“就绪”队列是看板系统中一个特殊的等待队列，它位于需求池之后，团队正式承诺计划之前。这个队列的重要性在于它代表了团队的输入，即那些已经准备好进入开发阶段的需求。一个需求被视为“就绪”时，应满足以下条件：

• 用户的需求已经明确且清晰；

• 团队已经充分理解了用户的需求；

• 相关的关联系统或依赖项已经得到确认或准备就绪。

2.2.2 泳道

1. 划分依据：

   1. 处理规则：根据工作项类型和处理流程设置泳道。

   2. 关注程度：根据工作项重要性或受益方进行区分。

2. 层级表达：泳道能清晰表达工作项层级关系，如需求与子需求、需求与任务的关系。

3. 限制并行需求：泳道还起到限制并行需求数量的作用，有助于暴露问题并促进团队协作解决。

2.2.3 区域

在看板上划分出特定区域来表达特定的信息

1. 需求池区域：将需求池划分为多个区域，分别放置不同业务方和来源的需求，为就绪队列的填充和计划提供更明确的信息。

2. 就绪队列区域：将就绪队列划分为两个区域，分别放置本发布周期和下一发布周期内要完成的内容，以明确优先顺序。

3. 待发布队列区域：将待发布队列分成多个区域，分别放置要部署到不同目标系统的需求，以更好地安排发布计划。

2.2.3 卡片及标识

1. 卡片设计：卡片空间有限，设计应简洁，包含需求基本信息（如标题、负责人、ID索引）和时间信息。

2. 标识使用：

   1. 名字贴：表示谁正工作在这个需求或任务上。

   2. 阻碍项：表明遇到的问题和阻碍及其开始时间。

   3. 缺陷：与特定需求关联的bug。

2.3建模价值流动过程

1. 综合分析团队需求、工作流程、可视化效果等因素，选取合适的可视化设计元素，并建模产出反映价值流动的看板墙设计。确保看板系统能够真实、清晰地反映团队协作交付价值的过程，同时体现价值、反映协作和暴露问题。

三、明确流程规则：标准化与规范化管理

显式化流程规则，即明确并达成对价值流转和团队协作规则的共识，是团队协作的基石，也是团队持续改进的出发点。

1、组织并明确流程规则

• 价值流转规则：详细规定价值项（如用户需求）在不同阶段间转移的标准。例如，何时接收并分析需求、需求达到就绪状态的标准、代码提交和任务完成的准则、功能转入测试的标准、功能验收的标准，以及需求发布的条件等。

• 周期性事件规则：涉及团队定期活动的规则，如站会频率、就绪队列填充的规则等。这包括活动的频率、组织形式、适用规则以及处理例外情况（如紧急需求）的机制。

• 其他协作规则：涵盖团队日常运作和协作的各个方面，如看板墙的更新和维护规则、在制品数量限制、度量与反馈的收集与分析机制，以及改进行动的制定与跟踪等。

2、让团队共同拥有流程规则

团队掌握规则不仅是对团队的赋权，也是确保开发过程质量的关键。明确规则后，团队需达成对这些规则的一致理解，以便更自主地做出决策和协作，减少对上级或中央控制的依赖。

3、持续改进流程规则

显式化的流程规则为团队提供了讨论和改进的基础。基于这些明确的基线，团队可以更加客观和理性地识别改进机会。通过将改进落实为新的流程规则，可以确保改进的可靠性和有序性，避免反复和脆弱性。这样，团队就能在不断学习和迭代中不断进步。

四、控制在制品数量：优化资源利用

1、为什么要控制

• 加速交付，提升响应速度。

• 暴露问题，推动持续改进。

• 确保工作围绕用户价值展开。

2、控制什么

• 优先完成已启动工作，避免盲目启动新项目。

• 以用户价值为控制单位，而非单个任务。

• 通过组织任务、处理障碍等方式实现有效控制，不过度限制。

3、如何控制

渐进式改进,从可行但有挑战的限制值开始，逐步优化。

3.1限制原则

• 现实性：与团队能力匹配。

• 有用性：偶尔触及，提醒团队关注问题。

3.2限制在制品的常见形式

• 泳道限制：限制泳道中正在实现的需求数量。

• 阶段需求数限制：明确阶段最大并行需求数。

• 个人并行任务数限制：降低任务切换损耗。

3.3确定初始限制值

• 基于现状调整，确保符合团队实际。

• 根据团队人数和并行系数计算。

• 目标交付周期反推：当团队有明确交付周期目标时，利用利特尔法则（交付周期 = 在制品数量 / 交付速率）反推出最大在制品数。