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

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

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

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

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

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

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

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

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

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

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

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