Оптимизация процессов

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

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

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

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

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

Также я добавил отпуска и больничные в общий таймлайн, стало проще планировать работу. Срочные незапланированные задачи мы группировали под заголовком «design duty» и учитывать потраченное на них время при прогнозе нагрузки на будущие спринты.

Я настроил Asana так, чтобы она собирала информацию о дизайн-задачах текущего спринта с досок всех остальных команд. Нагрузку дизайнеров стало видно в едином отчёте.

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

Хороший KPI измеряет качество результата, а не количество работы. Но в некоторых случаях полезно отслеживать и время. Специального инструмента для тайм-трекинга в InvestEngine не было, поэтому я начал считать, сколько стори-поинтов каждый дизайнер тратит в неделю. Обсуждая нагрузку на ретро в конце спринтов, я смог определить оптимальное число стори-поинтов и то, как распределять их между разными типами задач. Это помогало равномерно распределять нагрузку, избегая и простоев, и выгорания. Так я добился предсказуемости сроков, что положительно сказалось на планировании во всей компании. Затем я постепенно оптимизировал рабочий процесс и увеличил число стори-поинтов, которые дизайнер может закрыть без ущерба для качества.

Time-to-market как KPI ввели во всех отделах компании. Скорость дизайна никогда не была узким местом – я нанимал профессионалов, которые делают работу быстро, особенно после того, как я оптимизировал процессы в отделе. Проблема была в нехватке product owner’ов и нежелании нанимать бизнес-аналитиков. От каждого дизайнера ожидали, что он возьмёт все эти роли на себя. Расширение навыков и рост самостоятельности полезны для развития дизайнеров, но для быстрорастущей компании это означало размытую ответственность и непоследовательность в принятии решений.

Поэтому я взял на себя роль бизнес-аналитика и уточнял требования к задачам – многие из них приходили в дизайн-отдел без описания. В итоге отношение числа дизайн-задач с описанием и без стало KPI, измеряющим наш вклад в time-to-market.

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

Мониторинг – не самоцель, а средство. Когда я заметил, что продуктивность одного дизайнера упала, я собрал статистику его автосохранений в Figma и сравнил со своей. Оказалось, что на доделку его задачи я потратил больше времени, чем он сам. С этой статистикой на руках я объяснил сотруднику, что его продуктивность ниже, чем у остальной команды. Я предположил, что дело в его переезде в Азию, и убедил вернуться в Европу. Вскоре он последовал моему совету, и продуктивность пришла в норму.