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

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

В эту колонку попадают задачи, делегированные партнёрам, заказчикам, коллегам по работе на кафедре в университете, разработчикам-исполнителям и трём личным ассистентам. Размер команды разработчиков меняется и в моменте достигает десяти человек. Один из ассистентов – главный, ещё двое находятся у него в подчинении. А ещё в этом списке иногда оказывается моя девушка.

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

Есть и более приземлённая причина: задач и контекстов стало слишком много, а память у меня и без того не идеальная – я, например, плохо запоминаю имена. При постоянном переключении между проектами быстро смешивается, кто что обещал, к какой задаче относился разговор и когда к нему возвращаться. Поэтому задачи и сопутствующую информацию я храню вне головы.

У каждого ожидания есть срок – от пары дней до месяца. И почти каждое рождает дополнительную работу: когда напомнить? Раз в неделю? Через три дня? Уже пора спрашивать статус или человек ещё укладывается? А если поручение главному ассистенту фактически выполняет один из его подчинённых – кого контролировать?

Пятьдесят пунктов «Ожидаю» – это не пятьдесят задач. Это пятьдесят открытых обещаний, каждое из которых периодически просится обратно в голову.

Содержание

• Как личная система превратилась в управленческую

• Что такое GTD и зачем она мне была нужна

• Что я попробовал и почему это не сработало

• Что я теперь храню в одной записи

• Как часто я напоминаю

• Как я научил команду работать со мной

• Разработчики: GitLab и личный контроль

• Как два ассистента превратились в иерархию из трёх

• Девушка: та же память, но не те же отношения

• Периодические задачи

• Что в итоге изменилось

Как личная система превратилась в управленческую

Я начал пользоваться GTD ещё в школьные годы, в далёком 2018 году. Тогда система обслуживала в основном мою личную сферу: подготовиться к экзамену, написать работу, купить нужную вещь, кому-то ответить. Между намерением и результатом почти всегда находился один исполнитель – я сам.

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

Раньше вопрос звучал так: «Что мне сделать следующим?» Теперь всё чаще – так: «Что должно произойти без моего непосредственного участия и когда мне снова обратить на это внимание?»

Именно на этом переходе привычный список ожиданий начал ломаться.

Что такое GTD и зачем она мне была нужна

Getting Things Done (GTD) – доведение дел до завершения. Коротко метод описан на официальном сайте, а подробный русскоязычный разбор есть в видео АР Вотякова.

Если очень упростить, это система, которая помогает разгрузить голову и ничего в ней не держать. Идеи, обещания, следующие действия и напоминания отправляются во внешнюю систему, которой можно доверять. Мозгу больше не нужно каждые несколько часов подбрасывать мысль: «Только не забудь». В когнитивной психологии такой приём называют cognitive offloading – переносом части умственной работы во внешнюю среду.

В GTD есть полезная категория Waiting For – «Ожидаю». Туда попадает всё, что должен сделать или прислать не ты: ответ на письмо, документ от заказчика, результат от сотрудника, подтверждение встречи.

Поначалу моя запись выглядела примерно так:

Ожидаю: Иван пришлёт КП до пятницы.

Пока таких записей десять – всё прекрасно. Когда их больше пятидесяти, список отвечает только на один вопрос – «чего я жду?». Но почти не помогает решить другой: «когда мне нужно снова об этом подумать?»

Что я попробовал и почему это не сработало

Отдельная доска

Сначала я попробовал вынести все ожидания на отдельную Trello-доску. Логика казалась аккуратной: личные действия – отдельно, чужие обещания – отдельно. На практике я просто забывал открывать вторую доску. Система, о которой нужно отдельно помнить, плохо разгружает голову.

Колонки по типам задач и частоте напоминаний

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

В итоге я вернулся к одной колонке «Ожидаю» на основной личной доске. Различия между карточками теперь задаёт не их положение, а дата следующей проверки.

Срок результата и дата контроля – не одно и то же

Если документ нужен через месяц, это не значит, что карточка должна мозолить глаза весь месяц. Но это также не значит, что о ней стоит вспомнить только в день дедлайна. Нужна отдельная дата следующего контакта.

Напоминания сами превратились в задачи

Фраза «напомнить раз в три дня» звучит как решение, но при пятидесяти ожиданиях создаёт бесконечный конвейер служебных действий. Фактически я начинал обслуживать систему контроля вместо того, чтобы управлять результатами.

Иерархия исчезла

Если я поручил результат главному ассистенту, а затем напрямую контролирую двух его подчинённых, то формально у меня три ассистента с руководителем, а фактически – три прямых исполнителя. Список задач незаметно разрушает структуру ответственности.

Мне пришлось изменить саму единицу учёта. Теперь я фиксирую не просто делегированную задачу, а управляемое обязательство: какой результат должен появиться, кто за него отвечает, когда он нужен и когда система должна вернуть его мне для проверки.

Что я теперь храню в одной записи

Я перестал считать единицей учёта само поручение. Поручение – это действие в прошлом: я уже попросил человека что-то сделать. Мне же нужно управлять будущим результатом.

Поэтому у каждой записи в «Ожидаю» появились пять частей:

• ожидаемый результат – что именно должно появиться;

• ответственный – один человек, с которого я спрашиваю результат;

• срок результата – когда результат нужен мне или внешнему заказчику;

• обещанный срок – когда исполнитель сам сказал, что закончит;

• следующая проверка – когда система должна вернуть ожидание в моё поле зрения.

Иногда я добавляю короткий статус или блокер (препятствие, из-за которого задача не может двигаться дальше), но не пытаюсь хранить в личном GTD всю внутреннюю декомпозицию. Иначе моя система начинает дублировать рабочий трекер команды.

Как это устроено в Trello

У карточки Trello есть встроенная дата. Я использую её не как дедлайн чужой работы, а как дату, когда мне самому нужно снова открыть ожидание, проверить статус и при необходимости написать человеку.

Если важен срок самого результата, я могу вынести его прямо в название карточки. Например:

Название карточки: «До 30 июля – получить готовый черновик отчёта от главного ассистента».

Дата карточки в Trello: 25 июля – следующая проверка.

В описании: обещанный срок от исполнителя – 27 июля; актуальный статус или блокер.

Ключевое поле здесь – дата следующей проверки. До 25 июля запись не должна тревожить меня вообще. Если всё идёт по плану, после проверки я переношу дату ближе к обещанному сроку. Если появился блокер – назначаю новую точку раньше.

В Trello есть автоматизации, которые позволяют фильтровать карточки по датам истечения. Когда наступает дата проверки, нужная карточка попадает в такую выборку. После проверки я либо закрываю её, либо сразу назначаю новую дату.

Trello у меня синхронизирован с Google Calendar и Apple Calendar. Конкретные карточки имеют даты, но не присылают отдельных уведомлений. Иначе вместо обзора я получил бы поток из десятков напоминаний.

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

У ожидания может не быть срока результата, но дата следующей проверки у него всё равно есть. Например, необязательная личная задача может вернуться ко мне через месяц.

Как часто я напоминаю

Универсального правила «пинговать всех раз в три дня» у меня не получилось. Частота контроля – свойство не человека, а конкретного ожидания и риска вокруг него.

• Критичное и близкое к сроку я проверяю ежедневно или раз в три дня.

• Обычные рабочие ожидания попадают в еженедельный обзор.

• Долгие задачи возвращаются по заранее выбранным контрольным точкам.

• Необязательные личные ожидания могут всплывать раз в месяц.

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

После любой проверки я сразу задаю следующую дату. Если оставить карточку без неё, она либо снова висит перед глазами каждый день, либо пропадает до дедлайна. Оба режима одинаково плохо разгружают голову.

Как я научил команду работать со мной

Почти вся эта конструкция выросла не из найма, а из преподавания. Когда я был студентом, я преподавал в школе программирования. Мои нынешние ассистенты и исполнители тогда были школьниками и учились у меня.

Граница между этими ролями у меня подвижна: по мере обучения и накопления контекста ассистенты постепенно перетекают в исполнителей. Сначала они помогают с небольшими операционными задачами, затем начинают брать технические задачи и отвечать уже за готовый результат.

Мы изучали не только язык программирования. Я учил их пользоваться Git и GitLab, ставить и принимать задачи, разбивать работу на шаги, показывать промежуточный результат и работать в команде. По сути, это технология программирования – способ доводить техническую задачу до результата вместе с другими людьми. Когда-то этому меня учили в университете.

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

Разработчики, с которыми я работаю, – тоже мои бывшие ученики. Это не отменяет постановку задач и контроль, но сильно сокращает расстояние между моей формулировкой и их пониманием.

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

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

Разработчики: вся работа в GitLab, в Trello – только мой контроль

Все проекты команды и рабочий трекер у нас находятся в GitLab. Там живут issues, подзадачи, ревью и вся повседневная координация разработчиков. В свой Trello я это не переношу: иначе система быстро превратилась бы в копию GitLab.

Если контроль отдельных задач называть микроменеджментом, то он остаётся в GitLab Issue Board (Work item, прости господи). В Trello я фиксирую только что-то глобальное и важное лично мне – результат, который влияет на другой проект, заказчика или мою работу, и дату, когда мне нужно вернуться к нему.

Например, в Trello может лежать ожидание: «получить готовый релиз функции к пятнице; проверить статус в среду». Но пять задач разработчика, связанных с этим релизом, останутся в GitLab.

Основная Trello-доска у меня вообще личная: разработчикам и ассистентам не нужно видеть её целиком и работать в ней. Задачи я передаю через рабочие системы, сообщения или созвоны, а в Trello оставляю только собственную контрольную карточку.

Как два ассистента превратились в иерархию из трёх

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

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

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

Потом добавился третий. Вместо дополнительной пары рук я неожиданно получил дополнительный канал управления: нужно было трижды объяснять контекст, следить за пересечениями и помнить, кому я уже что сказал.

Тогда один из ассистентов стал главным. Забавно, но это был самый говорливый и на тот момент наименее компетентный из троих как исполнитель. Для роли координатора важнее оказалось не лучше всех делать задачи руками, а постоянно быть на связи, задавать вопросы, собирать статусы и передавать контекст.

Ещё двое перешли к нему в подчинение. Теперь я передаю главному ожидаемый результат и контрольную дату, а он решает, кто выполнит работу и как её разбить. В моём GTD ответственным остаётся один человек – главный ассистент.

Это не просто красивая оргсхема. Если я продолжаю напрямую пинговать обоих его подчинённых, то главного ассистента на самом деле не существует. Поэтому внутренняя декомпозиция и ежедневная координация должны оставаться на его стороне.

Автономность начинается с доступов

Ассистент не может работать автономно, если для каждого действия ему нужно дождаться, пока я залогинюсь, перешлю файл или нажму кнопку.

Поэтому у ребят есть доступы к нужным репозиториям и отдельные аккаунты в сервисах. Это именно отдельные учётные записи, а не один мой пароль на всех. Права выдаются под конкретный контур работы: нужный репозиторий, нужный сервис, нужная роль.

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

Я не заношу деньги в Trello, поэтому многие функции для совместной работы мне недоступны. Да и главному ассистенту я не открываю свою основную доску: участник увидел бы все её колонки и карточки, а не только одну задачу.

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

Когда наступает дата проверки, я дёргаю человека: спрашиваю статус, уточняю блокер или напоминаю о сроке. Ответ заношу в комментарии к карточке. Так внутри Trello постепенно собирается короткая история: когда я писал, что мне ответили и о чём договорились дальше.

После контакта я либо закрываю карточку, либо ставлю новую дату проверки. То есть Trello здесь не общий трекер с ассистентом, а моя личная память и контур контроля.

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

ИИ как переводчик с ассистентского на человеческий

Отдельный слой этой системы – ChatGPT. Он хорош не только для кода и поиска идей, но и для общения. Ассистент может принести точное по фактам, но сухое, резкое или плохо структурированное сообщение. Модель помогает превратить его в текст, который не стыдно отправить от моего лица.

ChatGPT способен поднять корявый язык ассистента до языка относительно чуткого чувака.

Это звучит как шутка, но для делегирования коммуникации такая функция действительно полезна. Один человек собирает факты в контекст, ИИ выстраивает формулировку, а я получаю короткое саммари или уже подготовленный ответ.

Пример инструкции: «Составь короткий дружелюбный ответ от моего лица. Сохрани все факты, не придумывай новых обещаний, отдельно обозначь блокеры и следующий шаг».

У этого подхода есть ограничение: языковая модель умеет очень убедительно маскировать неопределённость. Поэтому ей нельзя разрешать додумывать факты, назначать сроки или брать обязательства вместо меня. ИИ здесь – редактор и адаптер тона, а не новый руководитель.

Ассистенты по-прежнему не ведут переписку с заказчиками. Но внутри разрешённого контура они могут подготовить сообщение, привести его к моему стилю и передать мне на отправку или использовать там, где такая автономность заранее оговорена.

Девушка: та же память, но не те же отношения

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

Девушке я не плачу, и на меня она не работает. От меня она может получить разве что поцелуй в щёку.

Поэтому у таких ожиданий часто нет дедлайна. Например, задача «Подготовить путеводитель по Турции и Греции» живёт в моей системе уже около полугода. Примерно раз в месяц система снова показывает мне эту задачку, и, если напоминание всё ещё уместно, я пишу о ней девушке.

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

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

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

Периодические задачи: рекурсия внутри GTD

Кроме пятидесяти ожиданий у меня много периодических задач. И одна из них буквально звучит так:

Пропинговать людей и проверить статус по задачам.

Получается небольшая рекурсия: чтобы чужие задачи двигались, у меня есть собственная повторяющаяся задача по их проверке.

Я не считаю это недостатком системы. Управление людьми всё равно требует внимания. GTD не отменяет эту работу – она превращает случайное беспокойство в предсказуемый процесс.

Во время такого обзора я прохожу короткий цикл:

1. Открываю только ожидания, у которых наступила дата проверки.

2. Сначала смотрю доступный статус в репозитории, трекере или документе.

3. Если информации недостаточно, отправляю короткий пинг с контекстом и ожидаемым результатом.

4. Фиксирую ответ, блокер или новую договорённость.

5. Сразу назначаю следующую дату проверки.

Если срок сдвигается несколько раз, очередного напоминания уже недостаточно. Тогда нужно менять план, снимать блокер, пересобирать объём, передавать задачу другому человеку или честно отказываться от результата. Бесконечный пинг не заменяет управленческого решения.

Что в итоге изменилось

У меня нет красивой метрики в духе «система экономит ровно N часов в неделю»: до перестройки я не засекал время. Зато есть более наблюдаемый результат. Мне больше не нужно вспоминать всех людей по очереди, чтобы понять, не забыл ли я чего-то важного.

Я вообще не считаю свою конфигурацию GTD чем-то окончательным. За это время я раз пять–семь бросал систему по разным причинам, а затем возвращался: упрощал её, модернизировал и подгонял под новую нагрузку и собственный способ работы.

Уверен, что нынешняя версия «Ожидаю» тоже не финальная. Через какое-то время ожиданий наверняка станет больше, появятся новые типы задач и связей – и систему придётся перестроить ещё раз.

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

GTD не решает проблему чужих просрочек и не заставляет людей выполнять обещания. Она решает другую проблему: возвращает ожидание в нужный момент и даёт мне возможность принять управленческое решение.

Я не перестал напоминать людям. Я перестал вспоминать о напоминаниях случайно.