Дизайнер ждёт текст, копирайтер — оффер, а маркетолог думает, что все работают

В digital-команде легко получить ситуацию, когда у каждого человека есть задача, все заняты, а рекламная кампания всё равно не движется. Маркетолог поставил копирайтеру задачу подготовить текст для лендинга, копирайтер открыл её и понял, что финальный оффер ещё не утверждён, а дизайнер уже получил задачу на макет, но начать её не может, потому что текста нет. Маркетолог тем временем ждёт от копирайтера готовый материал и не понимает, почему задача второй день находится «в работе».

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

Сначала нужно увидеть, где возникает ожидание

Первое, что стоит сделать, — перестать рассматривать задачи как независимый список. Возьмём ту же рекламную кампанию и разложим её на последовательность результатов: оффер → текст → дизайн → согласование → запуск.

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

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

Не держите заблокированную задачу в «В работе»

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

Для небольшого digital-проекта может хватить пяти этапов: Нужно сделать → В работе → Ждём → На проверке → Готово. При этом «Ждём» не должен превращаться в свалку. В карточке стоит сразу зафиксировать, чего именно не хватает, от кого это зависит и какое действие последует после получения информации.

Например: «Ждём финальный оффер от маркетолога. После получения — подготовить первый вариант текста». Такая запись полезнее, чем просто статус «Заблокировано»: руководитель видит причину остановки, исполнитель понимает следующий шаг, а остальным не приходится выяснять состояние задачи в переписке.

Не запускайте следующую работу, пока для неё нет входных данных

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

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

Это не бюрократия и не необходимость заполнять дополнительные поля. Такой фильтр просто не позволяет запускать работу, которая с высокой вероятностью потребует переделки.

Ограничьте количество задач, которые одновременно находятся в работе

Есть и другая распространённая реакция на ожидание: человек просто открывает следующую задачу. Копирайтер ждёт оффер — берёт ещё три текста. Дизайнер ждёт согласование — начинает два новых баннера. Маркетолог ждёт клиента — открывает новую кампанию.

Так количество незавершённой работы растёт быстрее, чем количество готовых результатов. Поэтому имеет смысл ограничить WIP — количество задач, одновременно находящихся в работе.

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

Так доска начинает показывать не только список задач, но и перегрузку процесса.

Формулируйте задачу через ближайший результат

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

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

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

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

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

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

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

Как проверить это на реальной команде

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

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

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

Через неделю у команды уже будет фактический материал для изменения процесса, а не предположение о том, какие статусы ей нужны.

Как повторить эту схему в Канбано

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

Для описанного эксперимента достаточно настроить доску под последовательность «Нужно сделать → В работе → Ждём → На проверке → Готово», добавить текущие задачи и договориться о простом правиле по количеству активной работы. Если в процессе станет понятно, что один из этапов не нужен или, наоборот, где-то постоянно образуется очередь, его можно изменить уже по результатам реальной работы.

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

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

Что в итоге должна показывать доска

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

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

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