Как дизайн-менеджеру не зашиваться с проведением дизайн-ревью

Когдая пришëл на работу в Домклик ведущим дизайнером, у меня в подчинении оказались 12 продуктовых дизайнеров. Каждый из них работал на своей Kanban-доске в Jira, а некоторые — на общих досках с разработчиками. Также каждый из дизайнеров ежедневно заканчивал делать макеты по 1-2 продуктовым задачам и присылал их мне на проверку и согласование лично в Telegram. Думаю, понятно, что через неделю работы в таком режиме я начал зашиваться, и мой мессенджер стал выглядеть как бермудский треугольник, в котором терялись сообщения от коллег, родителей, семьи, начальника. Я целый день только и делал, что разгребал сообщения, отвечал ребятам-дизайнерам на сообщения по задачам и проверял их работы. Нужно было что-то менять, и я первым делом составил список процессных проблем, которые хотел решить.

Вот этот список:

1. Мне сложно отслеживать бэклоги моих дизайнеров, приходится всё время переключаться между их Kanban-досками.

2. Нет четкого процесса проведения проверки.

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

4. В Telegram я терял сообщения, слишком много времени тратил на переписку по задачам и погружение в их контекст.

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

Стало понятно, что нужно исправить процесс работы дизайнеров над задачами и взаимодействие со мной.

Процесс задач

У нас в компании в Jira ранее уже был встроен единый процесс для всех дизайн-задач во всех продуктовых командах. Вот он:

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

Единая панель

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

Единая панель

Из чего состоит эта панель:

1. Design_Ivanov. Справа в колонке идут один за другим блоки с задачами каждого дизайнера, с указанием продуктовой команды, даты создания, статуса и названия задачи. Фильтр этих блоков выглядит так:

   Project in (Команда№1, Команда№2, Команда№3) AND issuetype = Дизайн AND assignee = Ivanov AND statusCategory != Done

   С помощью этих блоков я всегда вижу в одном месте бэклоги всех дизайнеров.

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

   Project in (Команда№1, Команда№2, Команда№3) AND issuetype = Дизайн AND status = Груминг AND issue not in updatedBy(aatalaluev) AND created >= 2023-12-27

3. Назначенные на меня без leads. Это задачи, которые были назначены на меня.

   project != leads AND assignee in (currentUser()) AND statusCategory != Done

4. Design_All_Review. Тут отображаются все задачи, у которых стоит статус «Ревью». Как выглядит процесс: дизайнер разработал макеты и ему нужна моя проверка. Он ставит статус «ревью». В панели я вижу эту задачу в этом блоке и возвращаюсь к ней, когда нахожу время для проверки. Просматриваю макеты или решение задачи, пишу в комментариях, всё ли хорошо, и далее возвращаю дизайнеру задачу в статусе «дизайн».

   Project in (Команда№1, Команда№2, Команда№3) AND assignee in (Дизайнер№1, Дизайнер№2, Дизайнер№3) AND issuetype in (Задача, Дизайн) AND status = Ревью

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

   Project in (Команда№1, Команда№2, Команда№3) AND assignee in (Дизайнер№1, Дизайнер№2, Дизайнер№3) AND issuetype in (Задача, Дизайн) AND status = Бэклог

В результате

1. Я в любой момент времени знаю, какими задачами загружены дизайнеры, в каком статусе они находятся, и вижу бэклоги ребят на одном экране.

2. Мои дизайнеры понимают процесс движения задачи, и он у всех в каждой команде одинаковый.

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

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

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

P.S. за помощь в разработке дашборда спасибо Павлу Попову :)