看板方法：始于可视化，成于管理机制

点击👆蓝字 关注我们

导语

很多管理者都有一个很朴素的愿望：我想直观地“看见”团队里面谁在干什么，各项工作进展怎么样。

然而在软件研发这种典型的知识工作者密集的行业和领域，最大的特点就是工作内容、工作过程可见度低，甚至不可见。看不见、摸不着的东西显然更难管理，有顾问玩笑说“看得见的叫管理，看不见的叫想象”。

所以当这些管理者接触到“看板”这样的工具时，很容易就能接纳。因为“看”板所带来的可视化效果是显而易见的。确实也是如此，可视化本来就是看板核心实践的第一条。

成也萧何败也萧何。可能由于可视化的效果太直观了，很多管理者容易忽视看板方法背后一整套理论体系的管理方法，往往陷于「只见可视化的树木，不见管理方法论的森林」的困境中。

这会带来什么问题？又该怎么解决呢？我们慢慢道来……

研发团队的看板故事

好消息：已经在用看板了；坏消息：团队觉得不好用

在某个希望提高组织级敏捷度的企业，顾问进场辅导时很多研发团队反馈：“看板？我们已经推广使用过了。你看，我们座位旁边那块大白板上就是。”

我们看到团队使用的大白板基本长成以下几种样子：

图1：开发团队分项目任务管理板

图2：团队TDD（to-do，doing，done，待办进行完成看板）看板

图3：团队简单协作看板

接下来，我们给该领域中高层管理者提出的问题是：“你觉得使用这些‘看板’后，对团队有帮助吗？”

回答如下：

“这几种看板我们都有团队使用过，一开始的时候，大家普遍反映还是有帮助的，因为能看到有哪些事情了。比如开发团队项目任务管理板上了以后，起码我就清楚的知道谁手上有什么活。TDD（待办进行完成）看板上了以后，起码所有的事情都摆上去了。简单协作板也差不多。

但使用一段时间以后我自己也能感觉到作用比较有限，对实际工作的帮助不太明显。现在我感觉团队都不愿意继续用看板了，我可以看到很多看板已经长期没有更新了。”

不难预测，这可能会引起许多管理者的共鸣。说明这样的状况在企业中是普遍存在的。

团队觉得看板哪里不好用

  总之就是工具不趁手，哪里都不好用

其实这种反馈很正常。我们先来看看大家觉得这些“看板”哪里不好用。

首先，我们看看团队成员的感受。对于团队成员而言，原来自己干活就好，现在还多了更新看板这件事。并且这件事对自己没有太大帮助，主要作用是给团队负责人报告工作进展。尤其对于使用项目任务管理看板和TDD（待办进行完成）看板的成员来说，这种感觉尤其明显。好像看板就是一个工作汇报板，更新的动力肯定不高。并且团队成员为了降低更新频次，会激发出用一张卡片装下大规模工作的冲动。

其次，对于一线管理人员来说，大家的看板汇报有用吗？即使团队成员按时更新卡片状态，对于一线管理者而言，从上面展示的几种看板，也没法回答以下的问题：

• 当前遇到了什么问题和阻碍，最大的风险是什么，需要我去协调和解决的问题是什么？

• 最重要的那些事情，到底有没有在大力推进？

同时，团队使用的“看板”本身，也会遇到新的问题：因为一张卡片涉及的工作可能很多，并且看板没有价值流（比如项目任务管理板），或者价值流阶段划分比较粗（比如团队简单协作板），导致很多卡片长期停留没有进展，看板上堆积了越来越多的卡片，管理效率越来越低。

最后，我们看看中高层管理者的感受。对他们而言，一方面小团队使用了看板，实现了一定程度的可视化，可是在他们负责管理的更大范围，并没有看板给他建立全局视角，依然是“蒙眼狂奔”。另一方面，通过使用看板，也没有产生新的数据，还是需要继续依靠经验、直觉管理。引入看板后，似乎团队运作、管理都没有太大的变化和改善。

一段时间以后，团队可能就放弃了看板。并且得出了方法不适用、工具不好用的结论。

怎么改进呢？

  虽然都叫看板，可我们说的是看板方法哦！

实际上，看板远远不止是一张「记录一些信息，让大家可以“看”」的“板”。看板方法是一种广泛应用的敏捷和精益管理方法论，有着完整的理论和实践体系。这里我们不做深入的理论探讨，重点围绕看板的五大核心实践，简要说明如何建立一套可运转的管理机制。

01

可视化价值流动

这是看板核心实践的第一条。不能只有“可视化”却没有“价值流动”。

比如项目任务管理板，需要出体现项目或者任务的价值增加过程，而不只体现项目按人头的任务分工。

为了后续更好地进行协作，就需要梳理、细化当前实际的价值流，尤其是需要特别注意跨职能交接的节点。这里我们需要强调的是，价值流的梳理要从现状出发，真正贴合团队的实际，而不是要设计一个完美的、从来没有在当前团队应用过的价值流。

对于软件研发来说，虽然工艺流程大致都是“设计-研发-测试-部署”，但在各家组织、各个团队仍然会有一些区别。细化设计出来的价值流，可能是类似下面的样子：

• 【例1】待办→已优选→待评审→评审中→待排期→已排期→研发中→待测试→测试中→待上线版→已上线

• 【例2】想法→优选→需求编写中→需求讨论中→待设计→设计中→待澄清→已澄清→开发中→已开发完成→验收中→待上线→已上线

不论是以上哪个例子，可以看到，比之前团队使用的看板都细致了许多。大家可能注意到，价值流中还有一些命名类似“待测试”或“已排期”的等待状态，这就可以支持在看板中引入拉动机制（这里不做赘述），也可以在管理工作项流动时帮助识别拥堵环节。

如果组织中需求有多层，比如需求拆分为系统功能，再拆分为任务，那需求、系统功能、任务三层都需要进行价值流梳理。

02

显示化流程规则

这是指帮助团队围绕价值流，梳理出需要遵守的流程规则，并且清晰展示出来，让所有团队成员都清楚知道并理解这些规则。

一般来说，需要给看板价值流明确重要阶段的完成定义（DoD，Definition of done）。如通过了测试对开发的桌面检查，代码提交测试环境才算已开发完成。又如每天下午4-6点进行测试部署。明确这些规则，也是促进提升开发质量的手段。

03

控制WIP数量

限制在制品数量是看板方法的核心。所谓在制品，就是进行中和已完成（但尚未流动到下一阶段）的工作项。只有当在制品数量小于在制品限制数量时，才从前一阶段拉入新的工作。

直观来说，控制WIP数量的核心是减小批量，减少工作并行，加强团队聚焦。在敏捷的语境下，减小批量也是非常重要的。但敏捷减小批量的方式是限定时间盒。团队需要拆分出在两周的时间盒内完成的工作。

如果不能减小批量，团队高并行，就会导致大量需求积压，形成拥堵。最后所有需求的交付时效都无法令人满意。

如果对阶段设置WIP数量难度比较大，首先可以先在个人层级设置WIP数量限制。比如每人的WIP是3，意味着一个人同时做的工作不要超过三项。

04

管理工作项流动

促进流动是看板方法的应用核心目标，某种程度上说，控制WIP数量、价值流动的梳理和设计都是为了促进流动。

那么在管理工作项流动时，很关键的一点就是帮助团队及时识别出过程中的阻碍项和产生积压的阶段。可惜的是，我们很少在团队自发使用的看板上看到可视化的阻碍标志。

结合看板的度量其实是非常重要的实践内容，看板对于需求前置时间（端到端耗时）、吞吐量的统计都是研发效能管理的核心内容。同时，看板比较讲求数据驱动改进，度量数据也是下一项核心实践持续改进的重要基础。但在物理看板上进行度量统计，不仅成本比较高，而且效果一般。如果有条件，我们还是建议团队使用电子看板以便度量。

05

快速反馈，持续改进

为了更及时地反馈沟通，我们一般会建议建立一些协作机制。比如站会、看板填充会（类似敏捷的迭代计划会）等。

比较好的是，很多团队已经自发地在进行站会实践，实践比较好的团队也会结合看板召开站会。

在持续改进方面，看板方法的建议是定期检视回顾，从而探索改进机会。如果一个团队的看板设计、协作实践细节，长期没有任何变化，我们基本上可以认为这个团队缺少有效的改进。如果没有有效的改进，团队可能在使用一段时间以后，觉得看板的帮助有限，浅尝辄止，放弃看板管理。

分析完上面的五点，我们可以看到，在前面的例子中，团队对看板方法的实践还停留在1-2个核心实践的浅层。而我们希望能够通过一整套核心实践的组合拳，帮助团队真正从看板管理中获益。

最后，总结一下，为了帮助组织改善研发管理水平。我们结合电子化看板知微™，在组织级做了以下几点改进：

01

明确需求体系

明确需求-功能-任务三层拆分关系，梳理多个关联的价值流，并可视化。同时实现缺陷从发现到上线的端到端可视化。并且展现各工作对象间的关联关系。

图4：需求从提出到上线的端到端可视化（非团队实际看板，仅示例）

02

明确流转规则

通过明确价值流上不同环节的流转规则，可促进不同职能的协作与工作顺畅交接。

图5：各环节流转规则（非团队实际看板，仅示例）

03

降低并行，促进聚焦

这里我们不强行要求设置阶段的WIP限制，但我们通过建立时间盒、加上个人WIP的方式来促进降低并行。

图6：降低并行的手段（非团队实际方案，仅示例）

04

管理工作项流动，围绕研发效能进行度量

管理工作项流动，这里不做赘述。重点说说度量，我们围绕时效、吞吐、版本达成率三组指标进行度量（示例如下）。其中，由于看板方法重点关注端到端时效（一般称为前置时间Lead time），这也是我们的北极星指标。吞吐量是时效的牵制指标，重点观察团队产能，同时避免只快不多的情况。而版本达成，也是我们降低并行、促进聚焦的结果性指标，更是时效的先导观察指标（如果完成率很低，时效一般不会好）。

图7：时效与版本达成率统计（非团队实际数据，仅示例）

05

建立团队活动节奏

通过一系列的管理活动（如站会、看板填充会/计划会、检视/回顾会等），建立团队快速反馈机制，促进团队自发的持续改进。团队的活动节奏包括：

• 每日召开站会，明确当天的工作重点，聚焦完成

• 每月底召开看板填充会/计划会，团队综合考虑需求紧急程度与价值、团队产能等因素，共同规划后续工作内容

• 每月初检视/回顾上月版本交付与协作情况，在过程中会大量引用度量数据帮助团队发现和聚焦问题、发现改进机会，后续将根据数据的改进基线，评价改进成效

改进效果怎么样？

  花拳绣腿，还是真才实学？

做了这些改进后，效果怎么样呢？下面我们分团队和组织两个层级来讨论成效。

团队级成效

在辅导团队建立了一整套的看板管理机制后，我们和该组织一起，围绕看板的五项核心实践内容，定义出了看板实践的五级成熟度（图4）。下面简单说明一下这五级的大致含义：

• 5级，代表团队具有非常高的实践水平，业务与研发的互相融合、协作也达到了较高水平。我们一般在头部领先的科技企业的标杆团队才有这样的成熟度。

• 4级，意味着研发内部已经非常高效和顺畅。不仅研发效能处于很高水准，用数据驱动改进也已经形成了团队常态。

• 3级，团队可以完全落实看板五大核心实践。研发内部各职能协作过程比较顺畅，能够比较高效地进行交付，开始利用数据驱动改进。

• 2级，团队实践内容能覆盖看板五大核心实践涉及的领域，但实践还不完全深入。研发内部各职能协作开始改善，团队已经开始用看板帮助改进。

• 1级，团队开始使用看板，基本能体现工作项实际流动情况，流转规则基本清晰，在个人层级能够改善工作并行。

图8：团队的看板实践成熟度模型

根据这个成熟度模型的定义，团队原来自发的看板实践大多还不能达到一级。而经过一段时间的辅导和实践，有一部分团队能够达到3级成熟度，所有的团队都能达到2级成熟度。也就意味着所有的团队协作有了一定程度的改善，同时开始建立改进机制。少数实践比较深入的团队，有效地促进了协作、提升了交付能力，提高了改进效率。这是非常值得肯定的进步。

组织级成效

在团队级成效的基础上，组织是不是就获得了1+1=2的成效呢？其实组织获得的成效远远大于2，在组织层级，结合知微™看板，我们的收益有：

• 在确保信息高效聚焦且对必要信息保密的双重约束下，构建了多视角看板管理的能力，用看板实现了：（1）可视化的一线成员跨团队交付任务合作；（2）给领域和组织级的中高层管理者建立了全局视角；（3）给业务人员建立了跨交付团队的管理视角

• 人、事，多维、统一管理。建立工作任务的多层级（需求-功能-任务）、跨类型（如需求-缺陷）统一关联管理，可以看到向上、向下各层级情况。同时，通过把成员与工作内容进行关联，从全局展现团队资源投入情况。结合一系列管理活动，让记录数据与实际情况一致。

• 统一度量，管理驾驶舱。在组织层级落实统一指标体系的度量。搭建出多层级、可配置、可下钻追溯、T+0实时的管理驾驶舱，构建数字化管理现场。

• 能力内嵌。通过打通看板与组织原有管理平台，将看板方法、理念内嵌到组织日常管理过程中。让看板管理可以在组织持续运作、促进组织持续改进。

延伸讨论

经过前文的讨论，我们延伸出一些更为深入的话题。这里先做简要探讨，如果大家有兴趣，未来我们再另行撰文，做更深入的分析。

话题1：只关注可视化的看板实践有意义吗？

以前，很多接触过看板的小伙伴会认为TDD（待办进行完成）、简单协作这样的看板都不算看板，因为过于简单，没有完全应用看板的五项核心实践。但是在现在的看板成熟度模型KMM中，把成熟度分成了0到6一共七级

图5看板成熟度模型KMM

源自https://www.kanbanmaturitymodel.com/

前面展示的几个团队实践示例中，这些相对浅层的实践被定义为成熟度0-1级，是演进的前身，是团队进行的有意义的尝试。只要持续改进，随着团队本身能力的提升，看板成熟度也可以不断提升。

话题2：是不是可以直接设计一套高成熟度的机制来落地？

管理改进，尤其是规模化的管理改进，其实是一种组织变革，过程中一定会遇到各种阻力。并且变化越大，阻力越强。所以在进行组织变革的时候，实际上有两种思路。

第一种是看板方法的温和演进思路。非常强调从现状出发，让实践内容与团队成熟度相匹配，不断寻找好改的、能改的改进机会。可能有人会质疑，这是挑肥拣瘦，挑容易的事情做。实际上，看板的思路是不断推动一些切实的改进，日积月累，形成质变。

第二种是颠覆式变革的思路。设计一套全新的目标机制，然后依靠行政手段、职权影响力或者团队的强执行力推动落地。这种类似于休克疗法的思路，过程可能会有较高的风险。在我们实际辅导的过程中，其实很少有大企业能接受这样的激烈变革。

话题3：如果想要推动看板规模化，如何应对不同团队的个性化诉求？是不是每个研发团队必须用一样的价值流？

这是一个很值得探讨的话题。下面我们用几个例子来介绍不同的实践方式，相信看完以后，读者会有自己的答案。

例1：完全个性化

在这个例子中，团队的看板管理是从线下的物理看板开始的，并且允许每个底层团队有自己看板价值流并独立演进。在多年的实践后，底层团队的看板使用已经有了比较高的成熟度，甚至在线下看板也能完成关键的度量。随着应用的深入，组织也产生了新的诉求，那就是要建立起全局、整体的视角，也要对全局进行度量。

随着组织数字化能力的提升，该组织也开始推行线上化电子看板。想要在线上化看板建立全局视角、进行全局统计，最简单直接的办法就是统一价值流。可不同团队的价值流已经有了不小的差异，这时候想要统一，何其困难！

例2：保持统一性

在这个例子中，组织在推行看板管理之初，使用的就是线上电子看板。根据组织的实际情况，团队使用统一的两层需求体系（需求拆分为系统功能）。根据两层需求体系的实际协作情况，设计了两层通用性比较高的价值流（如下），并建立了统一度量指标。

需求价值流：需求提出→需求确认→开发测试→投产上线

系统功能价值流：新建功能→分析设计→纳版排期→研发中→待测试→测试中→待投产→已投产

通过这套体系，以较快的速度在组织中形成了统一的、全局的、整体视角，并实现了统一的度量。整体保持了很高的统一性。

但随着数据的重要性日益提升，组织单独设立了大数据团队。经过一段时间的运作，组织发现大数据团队的价值流确实有其特殊性。主要是系统功能在研发中会有多个子阶段，即数据集成、数据整合、数据应用、数据服务。

那么，如何在满足大数据团队个性化要求的同时，继续保持整体的统一性呢？最后的决定是在系统功能的“研发中”这个阶段下建立5个子阶段，供大数据团队和功能研发的团队共同使用：

系统功能价值流：新建功能→分析设计→纳版排期→研发中（该阶段拆分五个子阶段，即数据集成、数据整合、数据应用、数据服务、功能研发）→待测试→测试中→待投产→已投产

这样，虽然保持了全局的统一性。但在使用系统功能价值流时，给一线的大数据团队和功能研发团队都带来了一定的困扰：价值流上有一些阶段是永远不会用到的。

例3：允许一定程度的个性化，整体保持一致性

这是一个还在实践中探索的例子。我们希望在保持整体一致性（而非统一性）的前提下，允许团队有一定程度的个性化。同时，我们依然希望保留组织统一的、全局的、整体视角，并实现统一的度量。

那么在设计的时候，我们就要思考，为了保持一致性，哪些要素要保持最低限度的统一性。经过讨论，我们达成的共识是，我们需要在“一头一尾”保持统一。“一头”是指在需求分层体系上要保持统一，比如都是两层需求体系（需求拆分用户故事），拆分规则都一致（都是一个需求可以拆分多个用户故事）；“一尾”是指在关键、核心度量指标上保持统一，比如我的前置时间统计都是从进入“需求优选”到完成“投产上线”，我的需求就绪时间都是从“提出”到进入“待研发”。

只要不影响这一头、一尾，我们希望不管是价值流设计、流转规则、WIP限制等，都可以让团队保持一定的个性化选择权利。

写在最后

在看板管理领域，必读书目里一定有大家昵称为“小蓝书”的《看板方法：科技企业渐进变革成功之道》。在这本书中，作者David  Anderson详细介绍了如何创造性地把看板方法应用在研发管理领域。

时隔13年，原书作者对这本书进行了全新的升级。从前的小蓝书未来将成为一个系列，现在第一本《Discovering  Kanban》已经完成，第二本《Implementing  Kanban》相信不久后也会面世。

我和两位同事（海浪、Leslie）一起翻译了新版《Discovering  Kanban》，目前全书已经翻译完毕，等待编审出版。我们可以明显感觉到，新版的“小白书”在以下几个方面有了非常明显的升级：

• 用更加丰富的案例，深入浅出地对看板管理思想、理念、价值观进行介绍和总结

• 不局限于小团队和研发侧的改进，而是放眼于组织、业务和规模化的改进

• 不再局限于精益，而是关注敏捷性（Agility）的提升

• 补充和引用了近年来实践中总结出的新理念、新方法、新工具，比如Fit-for-purpose（这也是我们其他同事在翻译的另一本书）、KMM（看板成熟度模型）等

• 毫不回避地讨论争议性话题（这一部分非常精彩！）：看板  VS  Scrum在减小批量上的不同思路，看板  VS  SAFe在依赖管理与规模化敏捷的不同思路等

翻译的过程，也是让我自己更进一步理解看板方法的过程。让我有机会在实际的实践中带着更深入的理解去观察团队实践，帮助团队优化。同时，David  Anderson故事化的解读方法，也让我获益匪浅。以上也是本文的缘起。

点分享

点收藏

点在看

点点赞