看板为何有效——以及如何判断您的团队是否适合用它
大多数团队采用看板,只是因为有人读了一篇博客文章。更值得问的是:看板解决的问题,真的是您团队面临的问题吗?
大多数团队都经历过这样一个时刻,通常出现在人数超过八九个人的时候。活儿还在干——邮件照发,功能照常上线,客户也有人对接——但没有人清楚其他人都在忙什么。项目越堆越多。事情被答应下来,然后悄悄被遗忘。每次开会前,您都要花二十分钟才能搞清楚某项工作到底进行到了哪一步,而答案往往是“不知道在哪儿”。
这正是看板要解决的问题。它不负责制定战略、招到合适的人或打造文化,只解决一个具体而磨人的运营问题:弄清楚团队正在做什么,以及什么在拖后腿。
对于一个受到如此多关注的工具来说,它出人意料地朴素。看板并不声称能修好您的组织,它只是让工作可见。事实证明,把可见性持续落实下来,会改变下游的许多事情。
看板的由来
这个词来自日语,意为“标识牌”或“广告牌”,该系统由丰田在 20 世纪 40 年代末开发,用来管理制造工厂的库存。思路很简单:不按固定计划生产零件,而是只有当下游工位发出需要的信号时,工厂才生产。一张实体卡片——看板——会沿生产线向上游回传,作为请求。没有任何东西是凭预测生产的,也没有任何东西无谓地堆积。
丰田的这个洞见后来被软件团队借用:系统中的大部分低效,并非来自人们干活太慢,而是来自在错误的时间做了错误的工作。同时开工的事情太多;瓶颈直到为时已晚都没人察觉;某一环节的工作已经完成搁在那里,下一环节却在别处忙得不可开交。
软件开发者,尤其是 2000 年代初微软这样的公司,开始把这些思路改造后用于知识型工作。卡片变成了任务,工厂的工位变成了工作流中的各个阶段,标识牌变成了一块看板——起初是实体的,后来是数字的——团队里任何人都能一眼看到哪些在进行、哪些在等待、哪些已完成。
看板这块板子本身并不是体系,它只是让体系变得可见。体系是您的团队实际如何工作——以及这种工作方式对您是否有效。
一块看板究竟能让您看到什么
基础的看板有三列:待办、进行中、已完成。对许多小团队来说,这就够了,也是不错的起点。但真正的价值,出现在您开始按工作实际的流转方式——而不是您希望的流转方式——来定制这些阶段的时候。
内容团队可能用:创意、简报、撰写中、审核中、已排期、已发布。软件团队可能把“进行中”拆成开发、代码评审和 QA 几列。咨询团队可能跟踪:需求调研、方案、执行中、等待客户、已结束。这些阶段应反映真实的交接点和真实的等待时间——也就是工作换手的地方,或是工作停下来等别的事发生的地方。
注意中间那一列的卡片——仓库审计报告,已经八天,标记为受阻。在没有看板的体系里,这项任务可能再躺上两周,才有人发现它没有进展:有人在等第三方,或者需要某位经理拍板,而这位经理并不知道自己就是堵点。看板让阻塞一目了然,而这已经是大部分的功夫了。
让看板真正奏效的规则:WIP 限制
如果说有一个概念,能把正确使用看板的团队和只是拥有一份更漂亮待办清单的团队区分开,那就是在制品限制,简称 WIP 限制。意思是每一列都有一个允许同时存在的条目上限。某一列满了,在有东西移出之前,您就不能再往里加新工作。
这听起来违反直觉。同时推进更多任务,难道不是意味着完成得更多吗?并非如此。当人们同时处理太多事情时,实际的结果是每件事都要花更长的时间。上下文切换的代价高昂,做到一半的工作会带来协调成本。而当十件事都显示“进行中”时,很难分清哪些真的在推进,哪些只是卡住了却没有被标记。
如果“进行中”这一列的 WIP 限制是 3,那么当第四件事摆到某人桌上时,团队里必须有人做出决定:现有任务中哪一个先完成?这会迫使团队排优先级,迫使大家沟通。而且它往往能让单个条目更快完成,即使开启新工作的速度变慢了。
关于多任务处理的研究一致表明,在任务之间切换大约会消耗20–40% 的有效工作时间。一位在三个功能之间切换的开发者,在每个功能上的效率并不是三分之一,一旦把恢复上下文的脑力开销算进去,更可能接近五分之一。看板的 WIP 限制在一定程度上正是针对这一问题的结构性解决办法。
看板与 Scrum:团队总会问的问题
如果您接触过软件团队或现代运营管理理念,大概率遇到过 Scrum——一种把工作组织成固定两周冲刺的框架,配有规划会议、回顾会,以及 Scrum Master 和产品负责人(Product Owner)等明确角色。许多团队把 Scrum 和看板看作互相竞争的方法,觉得必须二选一。其实区别比这简单。
看板适合您,如果
- 工作到来的节奏不可预测或持续不断
- 各项任务的大小差异很大
- 您的团队跨多个职能
- 您希望轻量起步、逐步演进流程
- 最看重单个条目的交付速度
Scrum 适合您,如果
- 工作可以按固定批次来规划
- 您的团队以工程为主
- 交付节奏的可预测性是优先事项
- 您有专人负责推动流程
- 干系人需要定期收到结构化的进展汇报
许多团队——尤其是并非纯软件工程的团队——觉得 Scrum 的仪式感太重,固定冲刺的结构也很难套用到持续进行的运营工作上。营销团队、客户成功团队、运营团队,以及什么都要管的创始人,手头的工作很少能整齐地装进两周的周期。看板的持续流动模式往往更适合他们。
话虽如此,许多团队会两者结合:产品开发采用冲刺式的规划周期,同时用一块看板来处理运营和支持类工作——这些工作不管处于哪个冲刺都会源源不断地进来。这是完全合理的混合做法。
一块看板应能在三十秒内回答的三个问题
看板最有用的时候,是您看一眼就能在不问任何人的情况下,迅速回答这三个问题:团队现在在做什么?工作卡在哪里?有没有该做却还没开始的事?
如果看一眼看板,三十秒内答不全这三个问题,那它多半没有被好好维护。最常见的失败模式是:任务被创建了,却从不移动——看板成了美好意愿的坟场,而不是实际工作的实时地图。一块不更新的看板比没有看板更糟,因为它制造了可见性的假象。
维护看板所需的纪律是实实在在的。工作推进时,任务就要跟着移动;受阻的事项一停下就要立刻标记,而不是两周以后;卡片要有明确的负责人,负责人要更新自己的卡片。这些并不占用很多时间——运转良好的看板实践,每人每天大约五到十分钟——但需要持之以恒。从看板中获益最多的团队,是把看板当作唯一可信的信息来源的团队,而不是把它当作额外的记录工作。
FabricLoop 的看板视图正是围绕这一点构建的:任务、消息和笔记放在同一个实时工作空间里,因此更新卡片不必切换到另一个工具。当有人把任务标记为受阻,或移到已完成时,相关上下文会一并保留——解释为什么停滞的对话、最终交付物的文件、记录所做决定的笔记。看板能保持最新,因为更新它和留一条评论一样省力。
看板做不到的事
看板不是战略工具。它不会帮您弄清楚该做什么,只能帮您管理已经决定要做的事。如果您的组织存在优先级问题、职责授权不清的问题,或是根源在领导者行为而非流程的“旧项目没做完就开太多新项目”的问题,看板会暴露这些问题,但解决不了它们。
它也不能取代好的管理。看板不能替代一对一沟通、周到的授权,或是向团队讲清楚某些工作为何重要。团队有时引入流程工具,指望流程来完成本该由经理承担的人际和组织工作。这是不可能的。
它能做到的,是减少拖慢大多数团队的那种弥漫性的不确定感。“谁在做什么”“这个做完了吗”“我接下来该做哪件”——在没有共享、可见体系的组织里,这些问题会催生大量低价值的沟通。看板能消除其中大部分噪音。对于噪音正是主要问题的团队,差别非常明显。
如何起步——无需三天的工作坊
我见过的最好的看板实践,都是从小处起步、逐步演进的。最糟的那些则请来了顾问,搞了两天的异地研讨,设计出一块精美的看板,到第三周就没人用了。
从您团队的真实状况和手头真实的工作开始。创建三列:待办池、进行中、已完成。花三十分钟,和团队一起把当前每一项工作写成一张卡片。约定一条规则:开始做某件事时,就把它放上看板;它有进展时,就移动卡片。接下来两周,别的什么都不用做。
两周后,一起看看这块看板。哪里堆积了?待办池里哪些大家都说是优先事项却一直没动?哪些比预期推进得更快?哪些卡住了,为什么?根据观察来调整各列,并让它们更具体。也许“进行中”需要拆成“进行中”和“等待外部”。也许您需要一列“评审中”,因为这一步总是被漏掉。让看板随着实际工作暴露的情况而演进,而不是照着方法论书籍里说的样子去搭。
不要为了让看板显得高级而增加列数。每多一列就多一次交接,每次交接都是工作可能停滞的地方。从简单开始。只有当简单版本向您显示哪里需要时,才增加复杂度。
更长远的玩法:流动指标
看板运转起来之后,会产生大多数团队从未用过的数据。前置时间(lead time)——从任务创建到完成的总时长——是其中最重要的。如果一项典型任务的平均前置时间是十二天,而您希望缩到五天,那么您现在就有了一个可以努力的数字,以及一块能告诉您多出的那七天花在哪里的看板。
周期时间(cycle time)只衡量实际处理的时段,不含任务在待办池里等待的时间。吞吐量衡量团队每周完成多少个条目。只要您自觉记录卡片的创建和关闭时间,这些指标都不需要特殊软件。合在一起,它们比任何基于估算的规划流程,都更真实地反映团队的产能。
大多数中小团队从未走到这一步。他们把看板当作可见性工具——这本身就有价值——不再深入。这也无妨。但如果您发现自己想就某件事何时完成向干系人作出承诺,或想弄清为什么有些工作耗时是预期的三倍,这些指标随时都在。
在 FabricLoop 中,每张卡片都带着自己的历史——何时创建、何时在各阶段间移动、何时完成。无论您现在用不用,这些数据都在那里。从简单做起的团队,往往在六个月后回头来看,想弄明白为什么这个季度感觉如此混乱,结果发现看板已经记录了他们需要知道的一切。
