Кейс «Громких рыб»: как разделить потоки в управлении проектами
Рассказываем, как агентство отказалось от микроменеджмента и создало рабочую схему управления задачами
Когда креативное агентство «Громкие рыбы» выросло из команды блогеров в полноценный продакшен, управлять проектами стало сложнее. Ситуацию осложнил уход с рынка основного рабочего инструмента. В этом кейсе — о том, как команда искала замену Trello и выстроила рабочие процессы в Kaiten, чтобы справляться с десятками параллельных задач без лишней сложности.
Почему решили перестроить проектную работу
«Громкие рыбы» — креативное агентство и продакшен, которое создаёт рекламные кампании и брендированный контент. Долгое время основным инструментом для управления задачами у команды был Trello. Его возможностей хватало, чтобы фиксировать этапы и контролировать выполнение.
В 2022 году Trello ушёл с российского рынка, и перед агентством встал вопрос поиска нового решения. К этому моменту агентство уже серьёзно выросло: количество параллельных проектов, специалистов и этапов работы увеличилось в разы. То, что раньше было управляемо в Trello, стало рассыпаться: отслеживать статусы задач, загрузку людей и движение по этапам в условиях роста стало практически невозможно.
Стало ясно, что нужен отдельный инструмент для проектной работы. Команда искала сервис, который:
- останется доступным на российском рынке;
- будет похож на Trello, чтобы команде не пришлось долго переучиваться;
- позволит гибко настроить процессы под себя.
Команда пробовала использовать для задач Miro и Notion, но они не подошли для ежедневного операционного управления. Miro оказался скорее пространством для творчества, а Notion — для документов, но и он вскоре перестал работать в России.
Поискав подходящие платформы, «Громкие рыбы» в итоге выбрали Kaiten. Он оказался похожим на Trello по логике работы, что упростило переход для команды. При сервис позволял гибко настраивать структуру под собственные процессы. Задачи перенесли и начали постепенно адаптировать систему под свой процесс.
Первая ошибка: избыточная детализация процессов
После переезда команда попыталась описать в системе каждый шаг процесса. Для каждого проекта создали отдельную доску. Всего таких проектов могло быть больше 10 одновременно.
Рабочий процесс стали максимально конкретизировать и разбили на множество мелких этапов:
- заявка;
- дебрифинг;
- креатив;
- ожидание ответа и другие.
Так на каждой доске появилось до 13 колонок с десятками заполненных и активных карточек.
Но вместо управления работой сотрудники начали управлять карточками: следить за статусами, переносить их между колонками, обновлять доски. На это уходило ощутимо больше времени, чем хотелось.
Постепенно стало ясно, что система не помогает, а мешает. Быстрее было написать в чат и уточнить статус, чем разбираться в перегруженной доске. Карточки перестали быть источником актуальной информации, а структура требовала постоянного обслуживания.
Упрощение и улучшение структуры
Когда стало понятно, что в текущей системе много лишнего, команда решила изменить сам подход к управлению проектами. Вместо попыток детально описать каждый шаг работы фокус сместили на ключевые этапы, через которые проходит любой проект.
Отказались от отдельных досок для каждого проекта, создав единое рабочее пространство для всех проектов с видимыми статусами. Сократили количество этапов с тринадцати до пяти, чтобы каждый этап отражал важное управленческое состояние, а не микро-процесс команды. Это упростило структуру, снизило нагрузку и сделало доску понятной.
Новая структура стала выглядеть так:
- Заявка. Когда появляется новый потенциальный клиент, команда создает карточку и указывает контакты, даже если сотрудничество под вопросом.
- Дебрифинг. Если проект берут в работу, карточка перемещается сюда. Фиксируют ответственных, план действий и дату встречи с клиентом.
- В работе. На этом этапе карточка находится на доске «Креатив» или переходит в «Производство», если началась реализация.
- Согласование. Готовые материалы передают клиенту, и команда ожидает его ответа.
- Закрываем проект. Если у клиента нет дополнительных правок, то агентство готовит документы, Иногда задача переходит дальше и проходит этапы от производства до завершения. Если после креатива идет продакшен, карточку копируют на соответствующую доску.
Команда пробовала добавлять разные фичи и настройки. Например, создавала единый документ по производству роликов — «Production чек-лист». Но на практике оказалось, что сотрудникам он не нужен — все и так знают описанный процесс.
Принцип «убирать лишнее, а не наращивать контроль» лег в основу всей системы управления проектами «Громких рыб».
Когда команда упростила структуру, сотрудники смогли сосредоточиться на содержании работы, а не на контроле за множеством статусов.
Как была организована финальная система управления
Сейчас основная роль Кайтена — централизованная база знаний и проектная отчетность. Это помогает команде четко разделить потоки: срочные вопросы решаются в мессенджере, а вся проектная история, файлы и статусы хранятся в системе.
Команда выстроила финальную структуру из 6 досок в общем рабочем пространстве:
- Креатив — для разработки концепций и идей.
- Продакшен — для управления процессом производства.
- Документы — для отслеживания состояния договоров, оплат и актов.
- Спецпроекты — для нестандартных задач с индивидуальным циклом.
- Отгулы и отпуска — для планирования отсутствий сотрудников.
- Ньюбиз — для работы с входящими запросами и потенциальными клиентами.
Такой подход охватывает все направления деятельности компании.
В каждую карточку команда заносит ключевую информацию:
- Основные данные: бюджет, сроки, контакты, задача. Так можно быстро найти и ознакомиться с информацией.
- Все ссылки: брифы, фирменные стили, референсы, готовые работы, Сюда же прикрепляют папку с исходными и рабочими файлами в облаке.
- Дедлайны, назначенные ответственные и исполнители. Каждый знает, кто и чем занят, когда сдавать материал и у кого можно уточнить данные.
- История обсуждений по проекту в комментариях. В любой момент можно вернуться к проекту и увидеть всю картину.
Главное преимущество такого формата — экономия времени. Не нужно искать последнюю версию файла в почте или уточнять статус в чате. Вся рабочая память по проекту собрана в одном месте, что делает процессы прозрачными, а контроль — простым.
Основной вывод: важно адаптировать сервис под себя
Опыт «Громких рыб» показал, что эффективная система управления проектами строится не за счет максимальной детализации и набора инструментов, а за счет осознанного упрощения. Попытка учесть все возможные сценарии и зафиксировать каждый шаг привела к перегруженной системе, которая требовала постоянного внимания, но не помогала работать быстрее.
Основным стал отказ использовать инструмент строго «по инструкции» и с избыточными элементами — дополнительными статусами, отдельными досками и даже формально полезными чек-листами. Команда оставила только то, что действительно решает задачи: дает прозрачность, фиксирует ответственность и позволяет быстро понять текущее состояние проекта.
В результате Kaiten перестал быть инструментом повседневного контроля и стал рабочей системой проектной памяти — местом, где собрана вся история проектов, материалы, договоренности и статусы. Срочные вопросы по-прежнему решаются в мессенджерах, а вся важная информация остается в одном пространстве и не теряется со временем.
