Шаблон рабочего журнала задачи: сохранить состояние работы перед перерывом
Рабочий журнал задачи - это короткая запись, которая хранит не список дел, а состояние вашего понимания работы: зачем задача существует, что уже выяснено, какие гипотезы проверены, какие направления исключены и с чего продолжать.
Список дел отвечает на вопрос "что сделать". Журнал отвечает на вопрос "почему именно это и что я уже знаю". Первое после перерыва обычно сохраняется. Второе - теряется.
Ниже готовый шаблон в двух версиях, разбор полей, заполненный пример и типичные ошибки.
Минимальная версия
Для большинства задач хватает трёх строк. Пишутся за минуту перед тем, как закрыть ноутбук.
Остановился на: Узнал: Дальше:
Это уже покрывает основное. Если завтра вы сможете по этим трём строкам начать работу за несколько минут, а не за полчаса, шаблон свою задачу выполнил.
В общем-то, всё. Конец статьи: дальше не усложняйте, когда минимальной версии хватает.
Полный шаблон
Нужен там, где задача живёт дольше одного или нескольких дней: расследование, проектирование, исследование, большой текст.
# Задача ## Цель Что должно измениться после выполнения задачи? ## Контекст Почему задача появилась? Какие ограничения важны? ## Что известно - ## Что непонятно - ## Гипотезы - ## Проверки - Проверка: - Результат: ## Исключено - ## Текущее состояние Где задача находится сейчас? ## Следующий шаг Что открыть или сделать первым делом после возвращения?
Не обязательно заполнять всё, руководствуемся здравым смыслом. Просто сознательно понимаем, какую информацию мы согласны сейчас потерять, если не запишем её.
Как заполнять поля
Цель
Один-два предложения о том, что изменится, когда задача будет закрыта. Не "разобраться с багом", а "понять, где теряется переход состояния, и выбрать способ исправления".
Формулировка цели через изменение, а не через действие, потом помогает понять, когда можно остановиться.
Контекст
Почему задача вообще появилась и какие ограничения важны: сроки, зависимости, чужие решения, то, что менять нельзя.
Это поле кажется лишним, пока вы в задаче. Через неделю именно оно объясняет, почему очевидный вариант решения был отброшен.
Что известно
Факты, которые вы уже подтвердили. Не предположения.
Важно записывать не только сам факт, но и то, откуда он взялся: лог, эксперимент, разговор, документ. Иначе потом невозможно понять, насколько факту можно доверять.
Что непонятно
Открытые вопросы в формулировке, на которую можно ответить. Не "разобраться с проблемой", а "меняется состояние этого элемента до этой операции или после".
Список непонятного - это по сути и есть маршрут работы.
Гипотезы
Версии происходящего. Полезно помечать, насколько сильной гипотеза кажется сейчас: через неделю ощущение "эта была почти наверняка верной" не восстанавливается само собой.
Проверки
Пара "что проверил - что получилось". Она защищает от повторной проверки того же самого.
Записывайте и отрицательный результат тоже. "Проверил, ничего не нашёл" - это результат.
Исключено
Направления, которые вы уже отбросили, и главное - почему. Без этого поля через неделю вы честно и старательно проверите то, что уже проверяли.
Текущее состояние
Где задача находится прямо сейчас. Это то место, которое вы прочитаете первым при возвращении.
Следующий шаг
Это должно быть довольно конкретное действие: какой файл открыть, какой запрос выполнить, кому написать.
Шаг должен быть достаточно маленьким, чтобы его можно было сделать сразу, не собираясь с силами.
Заполненный пример
Расследование плавающей ошибки:
# Баг: элемент данных иногда остаётся в несогласованном состоянии ## Цель Понять, где теряется переход состояния, и выбрать способ исправления. ## Что известно - событие приходит из системы A; - запись в базе создаётся; - связанный объект в системе B создаётся не всегда; - проблема не воспроизводится на каждом запуске. ## Что непонятно - падает ли внешний вызов; - меняется ли состояние до внешнего вызова или после него; - есть ли повтор операции. ## Гипотезы 1. Внешний вызов падает по таймауту после изменения состояния. Выглядит сильной. 2. Повторная обработка не видит промежуточный статус. 3. Ошибка обрабатывается как частичный успех. ## Проверки - Проверка: сравнил один успешный и один неуспешный сценарий. - Результат: в неуспешном виден таймаут после изменения статуса. ## Исключено - событие до обработчика доходит всегда, дело не в доставке. ## Текущее состояние Гипотеза 1 подтверждается частично. Порядок изменения состояния в коде ещё не смотрел. ## Следующий шаг Открыть обработчик и проверить, что происходит раньше: запись статуса или внешний вызов.
По такой записи можно вернуться в задачу через неделю, ничего не вспоминая.
Где хранить
Работает любое место, лишь бы оно открывалось быстро и без раздумий:
- отдельный файл рядом с задачей в репозитории;
- заметка в Obsidian, Notion или Apple Notes;
- комментарий в тикете, если задача командная;
- обычный текстовый файл на рабочем столе.
Самое важное, что журнал открывается за секунды и лежит там, куда вы и так заходите. Журнал, до которого нужно добираться, не переживёт первую загруженную неделю.
Для командных задач комментарий в тикете имеет отдельный плюс: журнал заодно становится способом передать незавершённую работу другому человеку.
Типичные ошибки
Превращать журнал в дневник. Поток сознания быстро делает запись бесполезной. Можно вести задачку "как дневник", в этом тоже есть своя польза, но для сохранения состояния нужно будет всё равно отдельно пройтись по шаблону.
Записывать только успехи. Исключённые направления ценнее подтверждённых, потому что именно их вы будете проверять заново.
Заполнять ради заполнения. Отсутствие раздела лучше раздела с водой. Удаляйте ненужное.
Писать для отчётности. Журнал пишется для себя завтрашнего. Как только он становится документом для кого-то ещё, из него исчезает честность про неопределённость.
Откладывать запись на потом. Три строки перед закрытием ноутбука работают. "Запишу утром" - нет. Напомню короткую версию: "Остановился на", "Узнал", "Дальше".
Частые вопросы
Нужно ли вести журнал для каждой задачи?
Нет. Для понятных задач достаточно обычного списка дел. Журнал окупается там, где есть неопределённость и перерывы.
Сколько времени занимает заполнение?
Минимальная версия - около минуты. Полная - три-пять минут при первом заполнении, дальше идут короткие дописывания. Но если опыта пока мало, то может занять и 10 минут, но оно того стоит.
Чем это отличается от обычных заметок?
Ничем по инструменту и многим по назначению. Обычная заметка накапливает материал. Журнал хранит состояние работы и рассчитан на то, чтобы его читали при возвращении.
Подходит ли для командной работы?
Да, и это один из сильных сценариев. Журнал в тикете позволяет передать незавершённую задачу, не пересказывая её голосом.
Что делать, если задача заброшена на месяц?
Прочитать "Текущее состояние" и "Следующий шаг", сделать этот шаг и только потом решать, актуальна ли ещё задача. Решение об актуальности из состояния "ничего не помню" почти всегда неверное.
Читать дальше
Шаблон - это инструмент. Метод, ритуалы входа и выхода, примеры и границы применимости разобраны в основной статье: Как не терять контекст сложной задачи.
Это часть серии материалов о когнитивном инженерстве - проектировании условий, в которых мышлению легче работать.