著名质量管理之父：戴明 说过：“如果你不能以一个清晰的过程去展示你所从事的工作，你就不会真正的了解你在什么。”

产品开发所从事的工作就是交付用户价值，从用户问题出发到交付解决方案。

我们做的就是要可视化端到端的价值流动过程工具：看板

看一个团队的看板，这是一个端到端的交付过程，蓝色的纸条从需求提出到设计到向开发团队澄清然后是就绪，就绪后我们称之为用户故事，这里的就绪是指对开发团队就绪了，开发知道验收标准了，相应的技术风险也分析了，之后一大段是实现中，这个实现中被划分成很多横向的条，这些条被称之为泳道，每个泳道里是一个需求（白色的纸条），后面的蓝色和黄色纸条是这个需求对应的任务，任务里分属不同的列和模块。

从这幅图可以看到，这是一个端到端的交付过程，最前面一段是产品，最后一段去验收交付的也是产品，中间一段是研发的过程，这是一个2B的产品，无法让用户直接参与，所以产品代表用户去发布和接收需求，一定程度上是从用户开始到用户结束的一个端到端的价值流动过程，我们也看到研发即所谓的实现阶段，反映了团队的协作，不同的模块团队协作去交付这个故事，也看到了需求分解和合并，需求分解成任务，任务完成后再合并成需求去测试。

右边需求上贴着红色纸条是bug或问题，表现缺陷、问题和阻碍。

这个看板清晰地反映了三个方面：需求的交付过程、各个团队的协作怎么去交付一个需求、需求的分解和合并。

这里能看到需求的流动，比如泳道数是有限的，团队并行开发的需求数目是有限的，这个有限有一个好处：我们要尽快地完成那些已经开始的需求，如果泳道满了，你也不应该开始更多的需求。也就是尽快交付已经开始的价值。如果这个交付过程中间有问题，因为泳道数量有限，很快能看到拥堵，问题也会及时暴露出来，及时解决。所以更加注重需求的完成，而不是需求的开始，也就是说我们是以价值交付来驱动整个过程的。

除此之外，我们还应该看到它反映的流动过程，及其背后的规则，比如一个需求从一个阶段进入到另一个阶段需要满足怎样的规则。上图给出了两个规则示例，所有进入就绪的故事必须满足：

必须完成实例化需求活动，开发、测试和业务共同澄清需求，并定义明确交互过程和验收标准；

大需求已拆分为工作量在两周以内的故事；

已与业务关联方确认相关计划；

识别大的技术风险并定义应对方案；

需求已经入库；

涉及三个（含三个）开发人员以上的需求，执行好协调人，负责进度协调。

所有移交测试的需求需要满足：

并入正式的版本，并通过持续集成环境的检验

开发对照实例化过程中的验收标准进行了自测。

其实这些流动过程加上规则就构成了团队是如何操作这些需求的，也就是戴明所说的我们以一个清晰的过程来展示我们所从事的工作。

这样一块看板

清晰全面地反映需求和需求交付的过程；

瓶颈和问题能在看板上得到即时体现；

团队可以根据看板信息协作和做决定。

但这只是一个基础，它分析了价值流，也可能会对价值流做适当的优化，但是我们还需要基于这个基础对价值流做一些管理，让其顺畅流动，这是下一步要解决的问题