Личный канбан и ограничение незавершённой работы

В предыдущей статье — Фокус: помодоро, deep work и защита от прерываний — речь шла о том, как защитить один блок времени. Личный канбан решает соседнюю задачу: что происходит между блоками. У вас может быть идеальная концентрация внутри двухчасового окна и при этом одиннадцать одновременно открытых задач, ни одна из которых не движется к завершению.

Это не преувеличение. Откройте свой рабочий трекер и посчитайте задачи, назначенные на вас и находящиеся в статусе «в работе». Потом добавьте ветки, которые вы начали и не домержили. Потом ревью, которые вы открыли, отписали половину комментариев и оставили. Потом задачи, которые «почти готовы, надо только тесты дописать». Типичный результат у практикующего инженера — от восьми до двадцати. Каждая из них занимает место в памяти, каждая создаёт микро-обязательство, и ровно ни одна из них не приносит ценности, пока не закончена.

Личный канбан — это два правила и одна доска. Правила: визуализируй работу и ограничивай незавершённую работу. Всё остальное — производные и вкусовщина. Ниже — откуда это взялось, почему математически работает, как выглядит у инженера, что показывают исследования и где метод честно не справляется.

Откуда это взялось

Слово «канбан» (看板) означает «сигнальная карточка» и происходит из производственной системы Toyota, которую Тайити Оно описал в книге Toyota Production System: Beyond Large-Scale Production (1978, английский перевод 1988). Смысл карточки на конвейере был инвертированным по отношению к привычной логике: карточка не приказывала «сделай ещё», а разрешала «можно сделать ещё». Пока карточка не вернулась с нижестоящего участка, вышестоящий участок не производил. Это система вытягивания (pull) вместо выталкивания (push), и её главный эффект — не скорость, а ограничение запасов между операциями.

Перенос в разработку ПО сделал Дэвид Андерсон. В 2004 году он вёл команду поддержки в Microsoft (XIT Sustained Engineering) и применил ограничение незавершённой работы к очереди задач; результаты он развернул в книге Kanban: Successful Evolutionary Change for Your Technology Business (2010) — та самая «синяя книга» (kanban.university). Ключевая мысль Андерсона: канбан не предписывает вам новый процесс, он накладывается на существующий и делает его перегрузку видимой.

Личную версию оформили Джим Бенсон и Тониэнн ДеМария Барри в книге Personal Kanban: Mapping Work | Navigating Life (2011, personalkanban.com). Их вклад — редукция до двух правил и отказ от командной машинерии: никаких классов обслуживания, SLA и совещаний по потоку, только доска и лимит.

Обратите внимание на порядок: математика (1961) появилась задолго до практики (2004). Это редкий случай в тайм-менеджменте, где у метода есть настоящая теоретическая опора, а не только удачная метафора. Правда, опора эта, как мы увидим, применима с оговорками.

Механика: доска, карточки, лимит

Минимальная конфигурация

Доска — это колонки, отражающие ваш реальный процесс, и карточки, которые по ним движутся слева направо. Минимум, который работает:

Колонка «Инбокс» — это тот же инбокс, о котором шла речь в статье про сбор задач. Личный канбан не заменяет сбор, он подключается ниже по потоку. Если вы попытаетесь вести доску без дисциплины захвата, доска будет отражать не вашу работу, а только ту её часть, которую вы вспомнили.

Формулировка карточки наследует правило GTD о физическом следующем действии (см. GTD целиком). Разница в том, что канбан-карточка живёт дольше, чем одно действие, поэтому у неё две строки:

Заголовок: Убрать N+1 в выдаче ленты
Следующее действие: снять профиль запроса на стейджинге, приложить к тикету
Начата: 2026-07-13
Ждёт с: —
Готово: —

Три даты — это весь ваш аналитический аппарат. Из них вычисляются все метрики, о которых пойдёт речь ниже. Не заводите поля, которые вы не собираетесь читать.

Что именно ограничивает лимит

Частая ошибка: лимит понимают как «не бери больше двух задач в день». Это не так. Лимит — на одновременно начатое и незаконченное, безотносительно календаря. Задача, начатая в понедельник и не закрытая к пятнице, занимает слот всю неделю. Именно эта неприятность и является смыслом упражнения: лимит делает застой видимым, потому что застойная карточка блокирует вход для новой.

Переход doing --> ready — самый недооценённый на этой схеме. Это явное решение «я откладываю эту задачу и признаю, что она не в работе». Без него карточки копятся в «В работе» как в чулане, и лимит перестаёт что-либо значить.

Почему это работает: немного теории очередей

Закон Литтла

Джон Литтл в 1961 году доказал соотношение, которое в переводе на язык доски выглядит так (Little, 1961, Operations Research; разбор для практиков — Little & Graves, 2008):

Среднее время прохождения = Среднее число задач в системе / Средняя пропускная способность

Пример. Вы закрываете в среднем 4 задачи в неделю. Если у вас одновременно открыто 12 задач, средняя задача проходит через вашу систему 12 / 4 = 3 недели. Если вы ограничите незавершённую работу четырьмя задачами — при той же пропускной способности средняя задача пройдёт за неделю.

Здесь важно понять, что именно произошло. Вы не стали работать быстрее — пропускная способность в формуле не изменилась. Вы стали раньше заканчивать то, что начали. С точки зрения количества сделанного за квартал разницы почти нет; с точки зрения того, когда именно ценность доходит до пользователя и когда вы получаете обратную связь, разница радикальная.

Оговорки, о которых обычно молчат: закон Литтла — теорема о долгосрочных средних в стационарной системе, где ничто не теряется. Ваша личная система нестационарна (отпуск, дежурство, релизный аврал) и теряет задачи (часть карточек умирает не будучи сделанными). Поэтому воспринимайте формулу как оценку порядка величины и инструмент рассуждения, а не как прогноз на конкретную задачу. Ваканти в Actionable Agile Metrics for Predictability (2015, actionableagile.com) настаивает: для прогнозов используйте распределение фактических времён прохождения (перцентили), а не среднее.

Нелинейность загрузки

Второй теоретический аргумент сильнее и хуже известен. В теории массового обслуживания время ожидания растёт не пропорционально загрузке, а гиперболически: приближение загрузки к 100% отправляет ожидание в бесконечность. Для простейшей модели M/M/1 ожидание пропорционально p / (1 - p), где p — доля занятого времени; для более общих случаев есть приближение Кингмана (J.F.C. Kingman, 1961), связывающее ожидание с загрузкой и разбросом длительностей.

Практический вывод для инженера: разброс длительностей у вас огромен. Задача «поправить валидацию» занимает 40 минут или три дня — заранее неизвестно. Инциденты приходят пуассоновским потоком. Чем выше разброс, тем раньше по оси загрузки начинается срыв. Райнертсен в The Principles of Product Development Flow (2009) формулирует это прямо: попытка загрузить разработчиков на 100% — самая дорогая из распространённых управленческих ошибок, потому что она покупает мнимую «эффективность ресурса» ценой обвала «эффективности потока».

Модиг и Ольстрём в This Is Lean: Resolving the Efficiency Paradox (2012) назвали это парадоксом эффективности: организация, оптимизирующая занятость каждого исполнителя, гарантированно получает длинные очереди, а очереди порождают дополнительную работу — напоминания, статусы, переспрашивания, — которая ещё сильнее загружает исполнителей. Личный канбан — способ выйти из этой петли на своём уровне.

Стоимость переключения

Третий аргумент — когнитивный. Классическая работа Rubinstein, Meyer & Evans (2001) в Journal of Experimental Psychology показала измеримый штраф на переключение между задачами, растущий со сложностью (APA). Полевое исследование Gloria Mark и коллег (CHI 2008) дало оценку около 23 минут до возврата к прерванной задаче (PDF).

Честности ради: связка «многозадачность вредит когнитивным способностям» популяризирована работой Ophir, Nass & Wagner (PNAS, 2009, DOI), и вот с ней всё сложнее. Wiradhany & Nieuwenstein провели две репликации и метаанализ (2017, Attention, Perception & Psychophysics, DOI) и нашли лишь слабую поддержку исходных выводов. Так что аргумент «переключаться дорого» стоит на исследованиях времени возврата к задаче, а не на утверждениях о деградации мозга. Этого достаточно: 23 минуты — уже дорого.

Доска инженера: конкретика

Что учитывать специфического

Обобщённый личный канбан из книги Бенсона предполагает, что вы контролируете свои задачи. У инженера это неверно как минимум в четырёх местах.

Ревью. Открытый вами PR — это работа, которую вы начали и не закончили, но она не в ваших руках. Если считать её в лимит «В работе», вы заблокируете себя. Если не считать вовсе — забудете о ней. Решение: отдельная колонка «Ждёт» со своим лимитом. Упёрлись в лимит «Ждёт» — значит, вы наплодили пять висящих PR, и следующее ваше действие не «начать шестую задачу», а «пойти пнуть ревьюеров или разбить PR помельче».

Чужие ревью. Ревью, которое просят у вас, — тоже карточка. Многие ведут их вне доски «потому что это мелочь», и потом обнаруживают, что мелочь съедает два часа в день. Компромисс, который работает: заводить карточку только на ревью дольше 20 минут, остальные обрабатывать пакетом в фиксированном слоте (см. Календарь как главный инструмент).

Дежурство. В неделю дежурства ваш лимит должен быть механически урезан — обычно до одной карточки. Не «я постараюсь взять поменьше», а буквально другая конфигурация доски. Инциденты — это работа с абсолютным приоритетом и непредсказуемым объёмом, и попытка одновременно тащить фичу заканчивается тем, что вы не делаете ни того ни другого.

Асинхронность и часовые пояса. Если ревьюер в другом полушарии, каждая передача мяча стоит 12–24 часа. При лимите 1 вы половину дня простаиваете. Это единственный честный аргумент за более высокий WIP: количество слотов должно примерно соответствовать количеству независимых циклов ожидания, в которых вы участвуете. Практическое правило: лимит ≈ 1 + число регулярных внешних блокировок. Для распределённой команды это обычно 2–3, для команды в одном часовом поясе — 1–2.

Как выглядит настроенная доска

Экспресс-дорожка — это упрощённый класс обслуживания из синей книги Андерсона (там их четыре: стандартный, с фиксированной датой, экспресс и «неосязаемый»). Для личной доски двух достаточно: обычные карточки и те, что вытесняют всё остальное. Смысл явного описания — договориться с собой заранее, а не решать в момент паники, что важнее.

Как измерять, не заводя инструментов

Три даты на карточке дают всё нужное:

Время прохождения (lead time)   = Готово − Инбокс
Время цикла (cycle time)        = Готово − Начата
Пропускная способность          = число карточек в «Готово» за неделю
Эффективность потока            = сумма дней активной работы / время цикла

Раз в неделю выпишите времена цикла закрытых карточек в столбик. Через месяц у вас будет 12–20 чисел — этого хватает, чтобы увидеть 85-й перцентиль. Фраза «85% моих задач закрываются за 6 дней или быстрее» практически полезнее, чем «в среднем 3,5 дня», потому что среднее прячет хвост, а именно хвост портит вам обещания коллегам.

Эффективность потока обычно шокирует при первом замере: типичные значения — 10–25%, то есть три четверти времени карточка просто ждёт. Здесь нужна оговорка: широко цитируемые «5–15%» из практики lean-консультантов — это отраслевой фольклор, не результат рецензируемого исследования. Ценность метрики не в сравнении с бенчмарком, а в динамике вашей собственной цифры и в том, что она переводит разговор с «я мало работаю» на «моя работа много ждёт». Это разные проблемы с разными решениями.

Что делать, когда упёрлись в лимит

Момент упирания в лимит — единственный момент, ради которого вся конструкция и строилась. Ниже — порядок действий; он важнее самой доски.

Отдельно про пункт A3. Нарушить лимит иногда правильно — прод горит, релиз через час. Плохо не нарушение, а нарушение без следа. Заведите привычку: каждый выход за лимит помечается в карточке одной строкой. Через месяц вы прочитаете эти строки и узнаете о своей работе больше, чем из любого руководства по продуктивности. Обычно выясняется, что «срочные» вторжения приходят из двух-трёх повторяющихся источников, и с ними можно работать системно, а не героически.

Честный разбор: что известно и что нет

Что подтверждается

Математика очередей — это теоремы, а не гипотезы. Связь между незавершённой работой, пропускной способностью и временем прохождения существует объективно, и нелинейный рост ожидания при высокой загрузке — тоже.

Малые партии сокращают время поставки. Работа Forsgren, Humble & Kim (Accelerate, 2018, и отчёты программы DORA) на выборках в тысячи респондентов устойчиво связывает малый размер изменения и частый деплой с меньшим временем поставки и меньшей долей неудачных изменений. WIP-лимит — это способ принудительно уменьшить размер партии на личном уровне.

Незакрытые задачи занимают внимание. Эффект Зейгарник (1927) в исходной формулировке про запоминание реплицируется неровно, но у него есть более современное развитие: Masicampo & Baumeister показали, что незавершённые цели вторгаются в мысли, и что составление конкретного плана снимает этот эффект, даже если цель не выполнена (Journal of Personality and Social Psychology, 2011, DOI). Карточка на доске — это ровно такой план. Это лучшее из известных обоснований того, почему сама визуализация даёт облегчение до всяких лимитов.

Что не подтверждается

Собственно личный канбан почти не исследован. Публикаций уровня контролируемого эксперимента по личным доскам практически нет. Всё, что вы читаете, включая эту статью, — экстраполяция командных и производственных результатов на одного человека плюс отчёты о личном опыте.

Командный канбан в разработке исследован слабее, чем кажется. Систематический обзор Ahmad, Markkula & Oivo («Kanban in software development: A systematic literature review», Euromicro SEAA 2013, DOI) охватил доступную литературу и констатировал: доказательная база состоит преимущественно из отчётов об опыте отдельных компаний, эмпирических исследований мало, качество их невысокое. Обзор Al-Baik & Miller в Empirical Software Engineering (2015, DOI) пришёл к схожему выводу и отдельно отметил разнобой в том, что вообще называют канбаном. Это не значит, что метод не работает. Это значит, что заявления вида «канбан повышает продуктивность на 30%» не имеют под собой ничего, кроме маркетинга.

Перенос с завода на умственный труд не бесплатен. На конвейере детали одинаковы, время операции известно, переналадка измерима. В разработке карточка «разобраться, почему падает интеграционный тест» может занять час или неделю, и никакая доска этого не изменит. Все метрики потока в разработке страдают от того, что единица работы не стандартизована.

Кому подходит и кому нет

Подходит, если ваша боль звучит как «я всё время что-то делаю, но ничего не завершается», «меня дёргают, и я теряю нить», «я не могу честно ответить, когда это будет готово». Личный канбан бьёт ровно в эти три точки.

Не подходит как основной инструмент, если у вас в неделю четыре большие задачи и предсказуемый календарь — тогда достаточно time blocking. Не помогает, если проблема во входящем потоке: доска покажет перегруз, но не сократит его. Не помогает при прокрастинации, корни которой не в организации работы (об этом — в статье про прокрастинацию). И, что важнее всего: лимит незавершённой работы не лечит выгорание. Он может снизить один из его факторов — хроническое ощущение незавершённости и потери контроля, — но выгорание относится к организационным и медицинским темам, и доска здесь не терапия. Подробнее и бережнее — в статье про выгорание и устойчивый темп; если состояние тянется месяцами, речь идёт о разговоре с руководителем и специалистом, а не о перестройке колонок.

Типичные ошибки

Десять колонок вместо пяти. Соблазн отразить каждый нюанс процесса приводит к доске, которую больно обновлять. Правило: колонка оправдана, только если карточки реально в ней задерживаются и вы принимаете решения на основании этого. «Код написан» и «тесты написаны» — не колонки, это чек-лист внутри карточки.

Карточка размером с эпик. Карточка «переписать биллинг» будет висеть в «В работе» три месяца и обессмыслит лимит. Практический потолок — примерно неделя. Не разбивается — значит, вы ещё не поняли задачу, и первая карточка называется «разобраться и составить план», с явным результатом в виде списка следующих карточек.

«Ждёт» как свалка. Колонка ожидания без лимита и без даты превращается в кладбище. Минимум: записывать Ждёт с: <дата> и на недельном обзоре трогать всё, что ждёт больше недели. Максимум: лимит на колонку.

Дубликат рабочего трекера. Вести карточку и в Jira, и на личной доске — гарантированный путь к рассинхрону. Работающий компромисс: личная доска содержит ссылку на рабочую задачу и добавляет только то, чего в трекере нет, — ваши личные шаги, обучение, административку, побочные обязательства. Личная доска отвечает на вопрос «что я делаю», трекер — «в каком состоянии продукт». Это разные вопросы.

Лимит, который ничего не ограничивает. Если вы поставили лимит 6 и никогда в него не упираетесь, у вас нет лимита — у вас есть украшение. Правильный лимит должен быть слегка некомфортным: вы упираетесь в него один-два раза в неделю. Начинать разумно с лимита, равного вашему текущему WIP минус один, и снижать по единице каждые две недели, пока не станет больно.

Доска, которую не двигают. Самая частая смерть личного канбана: карточки перестают перемещаться, доска расходится с реальностью, доверие теряется, доска забрасывается. Лечится единственным способом — привязкой обновления к существующему ритуалу: 3 минуты в начале дня и 15 минут на недельном обзоре, о котором подробно в статье про горизонты планирования.

Оптимизация личного потока в ущерб командному. Вы можете снизить свой WIP, отказавшись делать ревью, — и ваш поток улучшится, а командный ухудшится. Личный канбан оптимизирует локально; помните, что локальный оптимум в системе с зависимостями не совпадает с глобальным. Ревью коллеги, снимающее блокировку с трёх человек, важнее вашей собственной карточки почти всегда.

Инструменты

Инструмент здесь вторичен, и это редкий случай, когда физический вариант объективно неплох.

Стикеры на стене или на окне. Плюсы: нулевое трение, доска всегда в поле зрения, физическое ограничение места работает как лимит само по себе. Минусы: не работает при удалённой работе с ноутбуком в разных местах, нет истории для метрик.

Trello / Kanboard / Vikunja. Плюсы: пять минут на настройку, есть мобильный доступ. Минусы: живёт отдельно от кода и трекера, соблазн настраивать вместо работы.

GitHub Projects. Плюсы: карточки — это реальные issue и PR, статусы обновляются автоматизациями, метрики достаются из API. Минусы: личные задачи вне GitHub туда ложатся плохо.

Обычный markdown-файл или Obsidian Kanban. Плюсы: живёт в вашей системе заметок рядом с контекстом, версионируется, полностью ваше. Минусы: ручной труд, метрики придётся считать скриптом.

Минимальный скрипт для метрик, если вы храните карточки в markdown с фронт-маттером:

"""Считает время цикла и 85-й перцентиль по карточкам личной доски."""
import datetime as dt
import pathlib
import statistics

import yaml  # pip install pyyaml


def load_cards(board_dir: str) -> list[dict]:
    """Читает фронт-маттер каждой карточки-файла."""
    cards = []
    for path in pathlib.Path(board_dir).glob("*.md"):
        text = path.read_text(encoding="utf-8")
        if not text.startswith("---"):
            continue
        # фронт-маттер — между первой и второй строкой из трёх дефисов
        _, front, _ = text.split("---", 2)
        cards.append(yaml.safe_load(front))
    return cards


def cycle_times(cards: list[dict]) -> list[int]:
    """Дни от «начата» до «готово» — только для закрытых карточек."""
    result = []
    for card in cards:
        started, done = card.get("started"), card.get("done")
        if isinstance(started, dt.date) and isinstance(done, dt.date):
            result.append((done - started).days or 1)  # минимум один день
    return sorted(result)


def percentile(values: list[int], p: float) -> int:
    """Перцентиль по ближайшему рангу: просто и предсказуемо на малых выборках."""
    if not values:
        raise ValueError("нет закрытых карточек")
    index = min(len(values) - 1, int(round(p * len(values) + 0.5)) - 1)
    return values[index]


if __name__ == "__main__":
    times = cycle_times(load_cards("board/done"))
    print(f"карточек закрыто: {len(times)}")
    print(f"медиана: {statistics.median(times):.1f} дн.")
    print(f"85-й перцентиль: {percentile(times, 0.85)} дн.")

Сложность здесь неинтересна и приведена для полноты: чтение — O(n) по числу карточек, сортировка — O(n log n) по времени и O(n) по памяти. На личной доске n измеряется сотнями, так что можно не думать. Подробный разбор инструментов и автоматизации — в статье про инструменты.

Как внедрить за неделю

Пошаговый план, проверенный на практике и не требующий ничего покупать.

День 1. Выпишите на карточки всё, что вы сейчас считаете начатым: ветки, PR, тикеты «в работе», обещания коллегам, недописанные документы. Не фильтруйте. Посчитайте. Это число — ваш текущий WIP, и оно и есть главное открытие первой недели.

День 2. Разложите по колонкам как есть, без лимитов. Ничего не начинайте нового. Задача дня — увидеть картину, а не улучшить её.

День 3. Поставьте лимит «В работе» равным текущему количеству минус один и запретите себе брать новое, пока не опустится. Уточните формулировку каждой карточки до физического следующего действия.

Дни 4–5. Работайте, доводя карточки до конца слева направо. Каждый раз, когда рука тянется к новой задаче, прогоняйте её через схему решения из раздела выше. Отмечайте каждое нарушение лимита одной строкой.

День 6 или 7. Первый обзор: сколько закрыли, что застряло, сколько раз нарушили лимит и почему. Снизьте лимит на единицу, если он ни разу не упирался. Заведите привычку повторять этот обзор еженедельно — он же станет частью более общего недельного обзора.

Через месяц у вас будет статистика, а вместе с ней — возможность впервые в карьере отвечать на вопрос «когда будет готово» цифрой с указанием уверенности, а не ощущением.

Мини-итог

• Личный канбан — это два правила: сделать работу видимой и ограничить количество одновременно начатого. Всё остальное — детали реализации.
• Закон Литтла объясняет главный эффект: при неизменной производительности снижение незавершённой работы сокращает время прохождения пропорционально. Вы не работаете быстрее — вы раньше заканчиваете.
• Время ожидания растёт нелинейно с загрузкой, и у инженера разброс длительностей огромен, поэтому запас в 20–30% свободной ёмкости — не лень, а инженерное решение.
• У инженера доска обязана учитывать внешние блокировки: колонка «Ждёт» со своим лимитом, урезанный лимит на дежурстве, экспресс-дорожка для инцидентов.
• Три даты на карточке дают все нужные метрики. Смотрите на 85-й перцентиль времени цикла, а не на среднее.
• Момент упирания в лимит — не помеха, а точка принятия решения. Каждое нарушение фиксируйте: список нарушений за месяц — лучшая диагностика вашего рабочего окружения.
• Доказательная база у метода неоднородна: математика очередей строга, эмпирика по канбану в разработке слаба, по личному канбану — практически отсутствует. Это работающая эвристика, а не наука.
• Доска показывает перегруз, но не устраняет его источник, и она не лечит выгорание. Это разговор с руководителем, границы и, при необходимости, специалист.

Источники

• Taiichi Ohno. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988.
• David J. Anderson. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010. — kanban.university
• Jim Benson, Tonianne DeMaria Barry. Personal Kanban: Mapping Work | Navigating Life. Modus Cooperandi Press, 2011. — personalkanban.com
• John D. C. Little. «A Proof for the Queuing Formula: L = λW». Operations Research, 9(3), 1961. — DOI
• Donald G. Reinertsen. The Principles of Product Development Flow. Celeritas, 2009. — reinertsenassociates.com
• Niklas Modig, Pär Åhlström. This Is Lean: Resolving the Efficiency Paradox. Rheologica, 2012.
• Daniel S. Vacanti. Actionable Agile Metrics for Predictability. 2015. — actionableagile.com
• The Kanban Guide. — kanbanguides.org
• Muhammad Ovais Ahmad, Jouni Markkula, Markku Oivo. «Kanban in software development: A systematic literature review». Euromicro SEAA, 2013. — DOI
• Osama Al-Baik, James Miller. «The kanban approach, between agility and leanness: a systematic review». Empirical Software Engineering, 20(6), 2015. — DOI
• Nicole Forsgren, Jez Humble, Gene Kim. Accelerate. IT Revolution, 2018. — отчёты DORA
• E. J. Masicampo, Roy F. Baumeister. «Consider It Done! Plan Making Can Eliminate the Cognitive Effects of Unfulfilled Goals». JPSP, 101(4), 2011. — DOI
• Joshua S. Rubinstein, David E. Meyer, Jeffrey E. Evans. «Executive Control of Cognitive Processes in Task Switching». JEP: HPP, 27(4), 2001. — DOI
• Gloria Mark, Daniela Gudith, Ulrich Klocke. «The Cost of Interrupted Work: More Speed and Stress». CHI 2008. — PDF
• Wisnu Wiradhany, Mark R. Nieuwenstein. «Cognitive control in media multitaskers: Two replication studies and a meta-analysis». Attention, Perception & Psychophysics, 79, 2017. — DOI

Что дальше

Доска отвечает на вопрос «что я делаю прямо сейчас и что застряло». Она принципиально не отвечает на вопрос «а то ли я вообще делаю в масштабе квартала». Для этого нужны горизонты крупнее дня и регулярная процедура, которая эти горизонты сшивает.

Горизонты планирования: день, неделя, квартал, год и недельный обзор