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