Как изменение подхода к работе дизайн-команды помогло увеличить её результативность более чем в два раза

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

Я, Саида Малаева, управляю дизайн-командой Департамента коммуникаций и маркетинга Газпромбанка.

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

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

Как мы работали раньше

Самый важный шаг к переменам — это признание необходимости перемен. Мы это признали два года назад. Тогда наша команда работала по принципу «99% труда и 1% плана». Вот что это означало на практике.

• Отсутствие регламента взаимодействия с заказчиками

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

• Непрозрачный метод распределения новых задач

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

• Неэффективное внутреннее деление на группы

В формате групп существовали менеджеры (аккаунты), копирайтеры, дизайнеры и арт-директоры, а вся работа глобально делилась на онлайн- и офлайн-каналы, которые курировались арт-директорами по данным направлениям. Они, в свою очередь, управляли группами онлайн-дизайнеров и офлайн-дизайнеров.

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

• Медленная и негибкая практика планирования

Раз в неделю трафик-менеджер, аккаунты и арт-директоры планировали список задач, который в течение недели корректировался в 60% случаев. Еще одним еженедельным (иногда реже) видом встреч были общекомандные, на которых обсуждались проекты, настроения и организационные моменты без особой привязки к повестке.

• Малоэффективные методы коммуникации и отслеживания загрузки

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

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

Перемены: внедрение Scrum

В таком режиме отдел выполнял свои задачи: рекламные кампании успешно реализовывались, поток входящих задач отрабатывался, однако всё это делалось в хаотичном, изматывающем команду режиме. Осознав эту проблему, мы поняли, что надо что-то менять. Но что и как?

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

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

Адаптация ролей

• ПО — продакт оунэр = проджект оунэр = заказчик

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

• КМ — скрам-мастер = креативный менеджер = аккаунт

Креативный менеджер в команде дизайна выступает в качестве входного окна для ПО. Он детализирует техническое задание для дизайнеров, держит заказчиков в курсе прогресса выполнения задачи, уточняет и фиксирует поставленные по ней цели.

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

• Междисциплинарная креативная команда – скрам-команда = креативные менеджеры, дизайнеры, копирайтеры и арт-директоры

Команда разработчиков в области дизайна состоит из людей с различными компетенциями: графические дизайнеры, 3D-дизайнеры, копирайтеры и арт-директоры. Это многофункциональная команда, которая предоставляет комплексные креативные решения.

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

Адаптация процессов

• Scrumban: микс спринта и флоу

Методология Scrum полезна для структурирования работы в спринтах. Однако в коммуникационном дизайне превалирует постоянный поток (continuous flow) разных задач, которые не привязаны к конкретному спринту, поэтому нам потребовалось частичное заимствование полезного инструмента из методологии Kanban, а именно — доску задач для визуализации процесса работы.

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

• Daily Scrum — ежедневные встречи = еженедельные встречи

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

• Ретроспектива спринта — встречи по итогам = ретро проектов

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

• Регламент встреч: agenda, timing, follow-up

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

Мы определили с менеджерами, что полчаса — это максимальное время для стандартной встречи, если эффективно ее модерировать. После каждой встречи её куратор или инициатор подводит итоги: прописывает, что обсудили, о чём договорились, какие поставили сроки, кто ответственный и так далее.

• Измеримый прогресс

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

• Отчет менеджера

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

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

• Отчет команды

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

• Отчет арт-директора

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

Результат: двукратный рост эффективности

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

Если раньше мы отрабатывали около 300 задач в месяц, то после полного внедрения новой методологии эта цифра выросла до 700–800, а количество обращений к внешним подрядчикам сократилось на 30%.

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

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

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

• Общекомандная усталость и низкий моральный дух

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

• Сбой в коммуникациях

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

• Неясные роли и обязанности

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

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

• Правки — топ-вид работ

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

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

• Непрозрачность этапов согласования и принятия решений

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

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

• Перенос сроков и допустимое качество

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

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

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

• Отсутствие долгосрочных целей

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

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

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

С какими сложностями вы столкнетесь? Потенциальные проблемы трансформации

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

• Сопротивление переменам

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

• Прозрачность и открытость

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

• Мультидисциплинарность

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

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

• Динамичная среда

Дизайн — это область, требующая постоянной готовности к переменам. Тенденции, стили, каналы и форматы коммуникаций, портрет аудиторий и их поведение — всё это постоянно меняется. Развиваются технологии, такие как ИИ, и это серьёзно влияет на сферу дизайна.

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

Заключение

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

Если вы думаете, что ваша команда нуждается в переменах, то Scrum-подход может стать одной из моделей, которую стоит рассмотреть.