Джира, доски, два спринта — как дизайнерам планировать дизайн-задачи

Привет, я Филипп Лях, руковожу отделом дизайна операционных сервисов в Т-Банке. В дизайне я 16 лет, в менеджменте 4 года. В этой статье для канала #ФФДД2Д я расскажу про часть своего опыта в организации процесса работы дизайн-команды. Погнали

Говорить сегодня мы с вами сегодня будем о том, как брать кучу задач на команду и, по возможности, не умереть. Представим себе начинающего лида (это я таким был года 4 назад). Он начинает лидить дизайн-команду и под напором среды с большой вероятностью задается вопросами «что-то мы как-то не так с задачами работаем, надо как-то получше с ними работать — больше брать, или там считать эффективность, или приоритизацию какую-нибудь намутить, планирование». Много интересного можно сделать с дизайн-командой, когда ты лид. Сегодня поговорим про самую базовую историю — процесс работы с задачами и краткосрочным планированием.

Какие вопросы чаще всего задают лиду постановщики задач из продуктовых команд? Вот список самых популярных:

• Когда возьмете мою задачу?
• Когда задача будет готова?
• Почему взяли задачу Пети, а не мою? У нас разработка стоит
• Какие еще 2 недели? Там две кнопки вставить
• Можно мы без дизайна протащим? Фронты свободны

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

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

• Понимание общего объема работ. Когда вы собираете все задачи в одном месте, становится понятно, не нужен ли вам еще ресурс — может надо еще дизайнера нанять?
• Возможность определить самые приоритетные задачи. Когда ты разговариваешь с постановщком один на один, любая задача легко может стать самой важной. Но в сравнении оказывается, что есть поважнее
• Возможность предсказать срок выполнения. «Смотри, у нас есть три задачи с более высоким приоритетом и твоя. Если у твоей приоритет определен правильно, то я бы рассчитывал на середину следующего месяца»
• Бонусом идет возможность сравнения пропускной способности команды. Сможете определять, все ли ок с темпом работы дизайнеров

Рассмотрим самые распространенные подходы к планированию в дизайн-командах

Процесса нет

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

Канбан

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

Суть в том, что дизайнер, когда доделал одну задачу, берет следующую из общего мешка. По какому принципу? Смотрит на приоритет. Кто ставит приоритет? Постановщик, исходя из потребностей продукта. Что делать, если несколько задач с одинаковым приоритетом? Дизайнер спрашивает у постановщиков что важнее (чаще всего пишет в общий командный чат)

На скрине мы видим одну из досок в моем отделе. Что на ней происходит?

• Новые задачи, которые пора делать, собираются в колонке Planned. Они могут быть сразу назначены на дизайнера, или остаться неназначенными. Чаще всего у нас дизайнер подвязан к продукту или какой-то части продукта, поэтому задачи сразу назначаются на дизов, но это опционально
• Дизайнер периодически заходит расчистить задачи в Planned — перетаскивает их в Specification и смотрит, насколько они ему понятны и есть ли у задач бизнес-ценность. На этом этапе задача может отправиться на доспецификацию или трешнуться, если поняли что ее делать не надо
• Если все ок, дизайнер перетаскивает задачу в To Do. Это как раз тот мешок, из которого он берет задачи в работу (предыдущие статусы не означают непосредственную работу над задачей)
• Когда у дизайнера появляется ресурс, он берет самую приоритетную задачу из To Do — перетаскивает ее в In Progress и работает над ней
• Когда есть предварительный результат, нужно его утвердить с продуктовой командой — тащим задачу в Customer Review (здесь появляется пространство для автоматизации — например можно сделать отбивку в специальный чат с продуктовой командой, в которой будет тегаться постановщик)
• После утверждения задача уходит на ревью дизайнерам в Design Review (отдельный большой процесс, тянет на отдельную статью)
• Дальше у нас идут два статуса дизайн-спецификации, не будем на них подробно останавливаться
• И, наконец, задача добирается до финала в Done

За этим всем наблюдает лид — смотрит статус, не подвисла ли задача где-либо, и оперативно разруливает разные вопросы. Обычно это происходит на дейликах дизайн-команды. Лид должен быть поверхностно в курсе всех продуктов в команде, чтобы знать по каким задачам пушить, что можно захолдить, должна ли задача висеть в одном статусе так долго и т.д.

Скрам

Классно, когда дизайнер работает с одним продуктом, аналитики могут договориться о приоритетах на своей стороне, а разработчики не ставят жестких дедлайнов. Но бывают ситуации, когда за внимание дизайнера конкурируют несколько продуктов, либо команда требует четких коммитов по срокам (например, если дизайнеры с разработкой идут «ноздря в ноздрю» и от работы дизов зависит что пойдет в разработку в следующий спринт)

В этом случае процесс усложняется и есть смысл использовать так называемый скрам. Что это такое? В общем случае скрам — это методология, по которой продуктовая команда целенаправленно и сконцентрированно фигачит в сторону одной конкретной цели определенный отрезок времени (спринт). Задача скрама в продуктовых командах — не распыляться и поставить за нужное время необходимую ценность. Команда дизайна сама по себе ценность поставить не может, она поставляет только ее маленький кусочек (дизайны). Поэтому дизайнерский скрам — это фейковый скрам. Мы не поставляем пользователю финальную ценность, но берем из скрама работу по спринтам.

Отличия от канбана:

• Есть отдельная встреча-планирование, на которой собираются постановщики с дизайнерами и решают, какие задачи будем делать в следующем спринте
• Есть оценка задач по объему, чтобы коммит по срокам был обоснованным

Теперь в деталях

Встреча-планирование

На эту встречу приходят все постановщики, которым нужна задача от дизайнеров и вся дизайн-команда. Ведущий встречи последовательно идет по новым задачам и вместе с командой определяет размер каждой задачи, ее валидность и приоритет. После этого он смотрит, поместились ли все новые задачи в общую емкость команды на спринт, или нет. Если не поместились, то задача участников встречи — понять, какие из задач могут подождать. Тут важно, чтобы участники встречи определились между собой — что действительно важнее. Лид при этом задает контрольные вопросы, которые помогают это понять. Примеры: «Когда разработка готова взять эту задачу?», «Если задачи не будет, разработке будет чем заняться?», «Есть ли по этой задаче коммиты перед бизнесом?», «Что случится, если мы не сделаем задачу в ближайшие две недели?»

Оценка размера задачи

В традиционном скраме оценка задач ведется в относительных величинах, а не в абсолютных. Мы оцениваем задачи в стори-поинтах. Стори-поинт — это такая мифическая единица, которая не говорит о том, за сколько ты эту задачу сделаешь, а говорит о том, насколько она кажется непонятной. На самом деле это очень классная концепция — задача оценивается не с точки зрения точного времени выполнения (вы знаете, что во многих случаях это невозможно — даже у самых простых задач могут возникнуть подводные камни), а с точки зрения относительной величины «Предполагаемый объем работ × степень неопределенности». И в эту степень неопределенности мы закладываем риски наткнуться на что-то более сложное, чем ожидали. По методологии оценка в сторипоинтах строится на шкале Фибоначчи 1, 2, 3, 5, 8, 13, … SP — то есть чем выше неопределенность, тем больше размах оценки. Пример раскладки величин SP из инструкций в одной из наших команд:

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

Иногда команды оценивают задачи в других относительных единицах (популярна также «маечная» система — XS, S, M, L, XL). В целом можно оценивать в чем угодно, лишь бы не в часах/днях — такая оценка не закладывает степень неопределенности, ошибки анализа, время на коммуникацию и всякие другие моменты, которые возникают при работе с задачами

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

Ниже на скриншоте показан процесс наполнения спринта в джире

Статистика

Еще один приятный бонус оцифровки вашего процесса работы над задачами — статистика по нему. Тут можно смотреть много разных показателей, приведу один пример. На скриншоте ниже можно увидеть статистику времени нахождения задачи в статусе дизайн-ревью по всему моему отделу за все время. По ней видно, что весной 2023 время в ревью уменьшилось (синяя линия). Если навестись то мы увидим такие изменения — в начале графика среднее скользящее было 4,6 дней. После некоторых наших действий оно уменьшилось до 2,8 дней (а в лучший период до 2,2 дней). Это значит, что:

1. Продуктовые команды в среднем стали получать задачи почти на два дня раньше. В масштабе одной задачи это фигня, в масштабах сотен задач — хорошее ускорение
2. Лид может сказать постановщику, сколько еще ждать его задачу, в зависимости от статуса. «Задача ушла на ревью, скорее всего через три дня вы сможете взять ее в работу»

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

Личный опыт

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

Я пришел к выводу, что чем проще ваш процесс, тем лучше. Усложнять процесс нужно только когда вы понимаете, что простой подход не решает ваших проблем. Объяснение тут простое: любые процессные приколы тратят время дизайнеров и лида, и конкурируют со временем на рабочие задачи. Поэтому чем больше бюрократии, тем меньше времени на работу. Однако бывают ситуации, что без нее никуда. Задача лида — постоянно балансировать, переизобретать и оптимизировать процессы, чтобы и дизайнеры с продуктами были довольны, и оставалось время на что-то полезное

Заключение

Напомню, в начале статьи мы собирались ответить на вопросы «Хватает ли нам ресурса?», «Что важнее всего делать сейчас?» и «Когда будет готов дизайн?». С помощью описанных подходов вы сможете ответить на них. Начните с самого простого и усложняйте при необходимости. Не забывайте каждый раз спрашивать себя, решает ли процесс вашу задачу. Переосмысливайте существующие подходы, придумывайте новые. Не будьте рабом процессов, но и не недооценивайте их. Делайте хорошо, а плохо не делайте 😘

А также подписывайтесь:

Официальный канал дизайнеров и редакторов Т-Банка с кейсами, внутренним опытом, красивыми картинками и мемами

Мой личный канал с редкими постами про вот это все