和少数派的许多读者一样，GTD 思想和实践让我获益匪浅，在它的帮助之下，真的搞定了很多事情。当我的任务管理流程已经固定成「搜集、处理、组织、检查、做」这五步以后，我慢慢发现搜集和做越来越容易，但是中间的三个环节渐渐变得耗时和吃力。原因是我的任务管理系统之中，几乎包含了我所有想要完成的事情：从工作里的大事小情，到业余写作的各个选题，再到想看的书籍、文章，想在生活上作出的改进等等。总的任务数量过于庞大，维护起来就变得十分吃力。

我在某一次做回顾的时候，发现了一个现象——比起学习、副业、生活、娱乐之类的分类，工作相关的任务完成的最多，剩余的任务数量最少。要知道，作为一名全职工作者，每周消耗在工作上的时间比例是超过一半的，是其它几项之和。完成的任务多于其它并不奇怪，但是剩余的任务难道不应该同样较多吗？

在那次回顾以后，我找到了问题的答案：因为我所在的工作环境，还有另一套管理系统，这套系统明确了每个人的目标、约束了各自工作的范围。从系统的角度，保证了信息的流动通畅与整体的工作效率。这样，与工作相关的目标与任务就会比较收敛，不像自己拟定的学习、生活任务那么发散。

这套系统就是「看板方法」。我开始思考，这套方法是否能够应用到个人的任务管理体系中。在对「看板方法」做了研究与思考，以及在个人任务管理中的实践以后，我得到的答案是肯定的。看板方法给予项目的效率提升，同样可以作用在个人的任务管理上。

什么是「看板」？

说起「看板」，很多人的第一反应就是 Teambition、Trello 之类的团队协同工具，或者是新晋的有 Airtable、Notion 等更多被用于个人的应用，它们都在组织内容时提供了看板（Board）模式。不过这些应用展示的看板只能算是一种实践，还不能称之为一种方法。

看板开发方法，由 David Anderson 创立，脱胎于丰田生产方式（TPS）及约束理论（TOC），结合了统计质量控制（SQC）、排队论（QT）等多个领域的知识。它是过去十年来最热门的敏捷和精益开发方法；越来越多的案例表明，它能够改善协作、优化管理，显著提高交付速度、质量和灵活性。看板开发方法的规则简单，但其有效实施依赖于对原理的理解、对原则的坚持和实践的应变。

看板（Kanban）一词来自日文，本义是可视化卡片。看板工具的实质是：处于工作流后方的工序在需要时，通过看板向前方工序发出信号：「请给我需要数量的输入」，前道工序只有得到看板后，才按需生产。看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流动。拉动的源头是最下游的客户价值，也就是客户订单或需求。

这样基于看板来生产的好处有两个：

1. 降低成本：库存减少，直接降低了仓储开销，而且调整生产的计划也更加容易
2. 缩短周期：缩短产品在工序间的等待时间，也就缩短了从开始制造到交付产品的周期时间。

我们来具体看看，看板方法是如何实施的：

看板方法的形式

首先要说明的是，看板方法并不是破坏式的，它几乎不改变原来做事情的流程。例如我们打算开发一个应用软件，即便不用看板方法，也需要经过一个流程：

调研 → 设计 → 开发 → 测试 → 交付

使用看板方法以后，只是把这个原本藏在大家心里的流程可视化了。

如上图，「看板」方法从形式上来说是一块公共的白板，可以称为「看板墙」，上面划分了若干列竖直的区域，用于表示项目的不同阶段，往往也区别了不同工种的职能。在看板上，每个任务会以便签书写，然后粘贴在对应的区域。习惯上：

• 从右往左看是从目标倒推生产过程，当目标被提出时，从右边开始向左边的环节确定所需要的交付内容。例如想要测试，那就先得开发出来；想要开发得先知道要开发什么。
• 从左到右代表了不同工作环节的先后顺序，任务每经过一个环节，都获得了加工，增加了价值，也就体现了价值流动的方向。一个想法经过调研、分析、设计到开发测试通过以后最终交付，价值才完整。

在操作的时候，后续环节有空余时，将便签从前一个环节移动过来，表示了任务当前所处的阶段发生了变化。对于远程协作的团队，例如少数派的编辑与世界各地的作者们，或者像我这样用于个人管理的人来说，用应用软件来实践看板方法会更加便利。

看板的三原则

任务在看板墙上流转的过程十分容易理解，但是和任务管理一样，如果没有一些基本原则作为指导：无节制的添加任务在看板上，同样容易产生堆积；或者是在任务流转过程中，出现问题而不及时解决，就会导致堵塞。这里我们虚构一个应用从开发到上线的过程，来解释一下三原则在实践中的应用。

注：应用开发过程涉及的环节可多可少，这里为了说明方便，只保留「开发中」和「测试中」两个环节。同时假设每个环节相同时间可以处理相同的任务数量，例如，同时可以开发 2 个功能、测试 2 个功能。

1. 可视化的工作流

看板墙最显而易见的特点就是可视化，在软件开发未完成之前，已经完成的工作往往是不可见的；使用看板方法时，各个环节的正在进行的任务对于所有人来说都是具体可见的，这让工作流的管理和优化成为了可能。

任务在流转的过程中，可能会十分顺利，也有可能（往往）会遇到阻碍。例如上图，Emoji ⚠️ 是对问题和阻碍因素对可视化。我们一眼就能看出，「技术缺陷E」导致了阻塞，让后续的技术调研、次要功能等 4 个任务没法进入它们的后续环节。将阻碍因素标识出来以后，就应该优先解决这个问题，促进整个工作流运转正常。

不难注意到，上图中的测试中的队列明显长于其它队列，因为各环节的处理速度一样，所以测试环节是这个工作流程里的瓶颈。现有测试人员无法提高工作效率的情况下，要考虑引入新的测试人员，来加快工作流的流动。

2. 限制在制品数量

限制在制品数量（Work In Progress Limited）是看板方法的核心机制。「在制品」，原意是制造中的物品，等同于「正在处理的任务」。经过一段时间磨合以后，每个人在单位时长能够完成的任务数量会趋于稳定，就可以以此作为标准；也就是说，如果要求他比标准多做一些就得加班加点，少做一些就会浪费产能。

前面我们提到，能够同时开发两个任务、测试两个任务，这个就是我们所限制的在制品数量。这个数字一般写在看板流程的标题右侧，下图使用括号中的数字来表示。只有在制品的数目小于限制时，才可以从前一阶段承接新的任务。

限制数量，不止是限制工作中的数量，也要限制备选（收件箱）的数量。要知道，如果放在一个很长的队列的底部，和没有放在那里是差不多的，甚至还更糟，因为你总是要看到它。必须强调的是，限制在制品是看板方法的核心，如果不做此限制，看板就不能反映当前的真实情况，也就没有了指导意义。

3. 测量和管理流量

快速、顺畅的价值流动是看板开发方法的目标。快速流动带来快速的价值产出和快速反馈，它对业务成功至关重要；顺畅流动，意味着稳定和可预测的价值交付能力，这与流动的绝对速度同等重要。

度量为改善价值流动提供方向参考，同时为改善的结果提供反馈。就像我们选用手机的资费套餐，需要以实际用量作为参考，使用「看板方法」的过程中，同样需要了解实际的流量情况，以便之后调整各个环节的在制品数量限制。这样才能更好的预测以及改进一个工作流程的耗时。

通过对任务的实际起止时间的记录，定期绘制「完成任务数量」与「持续时间」的关系图，就能看出我们使用看板方法以后，工作流程流转的速度是否有提升。

专门的看板管理工具往往会提供配套的流量监测报表，方便使用者来改进它们的流程。上图是我工作中的一个项目，横轴是时间、纵轴是任务的数量，不难看出，在红色圆圈前后，折线的斜率增大了很多，但是「待处理」的任务数量比「已完成」的数量增加的还要快的多。

原因是临近春节，为了赶进度，团队增加了人手，自然就可以处理更多任务了。但是因为刚刚开始磨合，所以比起原来已经形成习惯的成员，新成员的达成率会差一些。看到这个趋势的时候，作为团队管理者就应该及时进行干预，让价值流动回归顺畅。

以上三个原则就是我理解的看板方法的核心了，以此作为基础，可以在实际的任务管理当中循序渐进，提升团队的工作效率。

个人看板实践：短期目标

解释完看板方法如何在我的工作中发挥效果，该看看它如何在个人任务管理中发挥效果了。实践过任务管理的人都知道，在任务管理系统里记录一堆目标，不做任何拆解，它们是不会自己实现的。与任务管理不同的是，看板方法中，在各个环节流转的恰恰是目标。

如果你在看板的右侧，你不会教你左侧的人要怎么做事情，你只会告诉他你需要什么。你需要的某个东西，对于左侧的人来说，这就是个目标。至于怎么做，那是他的专业范畴，不应该由你来干涉。区分了任务与目标，我们在做个人的任务管理时，也可以引入「看板」这个外部系统，用于管理目标。

分析任务管理的目标

前面说过，工作以外的任务很容易堆积。之所以容易堆积，正是因为目标不够明确。例如我在 Todoist 里找到了之前想学编程语言的时，在「学习」的分类下建立的好几条任务（目标）：

• 学习 Swift
• 学习 Python
• 学习 JavaScript
• …

除非这就是我生活的全部，否则我不大可能同时进行把他们都学下来。那么，为什么我想要学习这些编程语言呢？

• 想学 Swift 是因为可以利用 Xcode 制作应用的可交互原型，以后也许还能开发自己的独立应用。
• 想学 Python 是因为它用来处理大量数据时很方便，而且我也想了解机器学习领域的应用。
• 想学 JavaScript 是因为它在 LaunchBar 中，可以很方便的编写功能强大的脚本。

综合考虑了一下，处理数据是我日常工作里极其频繁要做的事情，往机器学习领域发展是我的职业目标，相比之下，其它两者的应用场景就次要了很多，而且也不难找到替代方案。那么我在学习编程这块的首要目标就是拿下 Python，直到我不再需要投入大量时间来学习，而是可以在日常使用中边用边学为止。其它两者，则可以从任务清单里移除了，毕竟在对比中他们已经落败。

在看板上添加目标

经过这样的对比，我们确定要学习 Python 了，但是这个目标还是难以量化，我稍微将其拆分，可以在看板上添加这么三个目标：

• 入门 Python 3 的基础使用
• Python 在数据科学领域的应用
• Python 在机器学习领域的应用

入门 Python 的基础使用是学习后两者的基础，所以它必须先达成。因为用于处理数据是我较为急切的需求，所以把它安排在稍后；机器学习作为一个更远的目标，就可以先等着。

同样，出于工作效率提升、扩充个人视野、增加生活趣味等目的，我将原本记录在 Todoist 里几个大分类下的任务拿出来逐一 PK 了一番，最后留下了这些目标：

为目标设置在制品限制

指导这个过程的首先是个人的价值判断，对我来说，构成整个生活的私生活、工作、学习和副业几个部分。他们之间确实是存在先后顺序的：

1. 私生活，不对外输出什么价值，但它是其它价值的基石也是动力，所以一定要持续投入生活质量的改善
2. 工作，为其它价值提供经济基础，同时也是社会价值的体现，占据了超过一半的时间
3. 学习，持续保持在工作中竞争力的唯一手段，也是个人的爱好，可以充实自己的精神
4. 副业，作为工作学习以及私生活的补充，相对次要

所以同时进行的任务必须依据「限制在制品」的原则。我目前对 In Progress 、 Not Started（待办） 和 No Status（收件箱）的列表数量限制都是 6。看板进行流转的周期是一到两周。如果你的目标设置的更长远，那就要进一步限制这个数量。如果后续的目标堆积太多，不仅不可能完成、无法灵活调整，而且看着压力也很大。

最后还是要转化为任务

完成前述流程以后，每周还要调整一次看板的流转，根据实际的流量调整在制品的限制。在具体执行的层面，还是应该把目标拆解成具体可执行的任务，否则还是无从下手。

这里我就把入门 Python 用一个独立的看板做了拆解，处理中的在制品永远只能有一个，因为同时只可能学习一个部分，而且每个部分都是后面的基础。这些子任务既也可以用看板来管理，也可以放在任务管理软件里，根据个人的习惯即可。

把目标拆解为任务以后，应该尽量保持在制品数量的一致性，并且每天上午再次确定当周的目标和当天的任务。一天之中，服务于不同目标的任务的比例，应该与目标本身的比例相当。这样才能保证每个目标都在推进当中。

看板方法本身的规则很简单，实践起来也不难，重点在于理解了规则给自己或者团队度身定制，经常根据流量情况做调整。我个人的习惯是把信息集中在 Todoist 之中，并且保证所有的任务都有其触发条件，对我来说，看板完全是用来管理目标的。

结合现代化的看板软件，看板可以承载的内容比起物理的白板丰富了许多，例如 Notion，就能支持看板、清单相互之间的嵌套，完全有潜力同时做好目标与任务管理。

写在最后

我还记得几年前我第一次了解到团队协作、任务管理、日程管理、GTD 等概念时，知道了有一些「高效能人士」会通过这些方法配合工具有效率的过好每一天，产出很多有价值的成果，让我心生向往。

但是很长时间里，我都处于不得要领的状态，即便反复把知名的 Todo、GTD、日历应用下载下来，我还是不知道要管理些什么。当时的我和很多人的想法一样——有个「提醒事项」足矣。

随着离开校园参加工作，许多大小事纷至沓来，很多塞爆了提醒事项。这才开始实践起 GTD 来，那个阶段几乎做什么都觉得自己有收获、在成长。但是经过几年工作，自己想达成的目标慢慢清晰起来，变得更加目的导向，做任何一件事情，最好都能带来很明确的收益。

实践了 GTD 以后其实节奏已经蛮好了，但是在每天回顾的时候，还是会有些许茫然，看着几件同样想做的事情，不知道应该怎么分配他们的优先级。当然，不排除我对 GTD 的研究不够深入的可能性。不过在我结合了「看板方法」以后，无论是工作还是生活里，几块看板就把我为之努力的目标给囊括了，让我在给自己排期的时候，少了很多阻碍。

看板并没有改变我们原来做事的流程，只是将其可视化。同样重要的是，它限制了当前投入的目标（任务）数量，从而达到明确目标、提升效率的效果。已经在实践 GTD 的人可以把看板方法当作是一种补充；还没有开始做任务管理的，也可以试着从看板开始，新年正是一个开始转折的绝好时间点。

本文的例子只是「看板」的一种经典实践而已，在少数派还有很多关于 Teambition、Trello、Notion 等工具的使用，都有涉及到看板的其它常见用法，也推荐各位阅读。

参考阅读

• 解析精益产品开发（一）—— 看板开发方法
• 向 Trello 团队学习使用 Trello 的正确姿势
• 加入表格、看板和日历，更全能的数字笔记工具：Notion 2.0
• 少数派是如何用 Teambition 进行项目管理和团队协作的？

注：本文题图由 @咕毛 设计。