Как дизайн-менеджеру не зашиваться с проведением дизайн-ревью
Когдая пришëл на работу в Домклик ведущим дизайнером, у меня в подчинении оказались 12 продуктовых дизайнеров. Каждый из них работал на своей Kanban-доске в Jira, а некоторые — на общих досках с разработчиками. Также каждый из дизайнеров ежедневно заканчивал делать макеты по 1–2 продуктовым задачам и присылал их мне на проверку и согласование лично в Telegram. Думаю, понятно, что через неделю работы в таком режиме я начал зашиваться, и мой мессенджер стал выглядеть как бермудский треугольник, в котором терялись сообщения от коллег, родителей, семьи, начальника. Я целый день только и делал, что разгребал сообщения, отвечал ребятам-дизайнерам на сообщения по задачам и проверял их работы. Нужно было что-то менять, и я первым делом составил список процессных проблем, которые хотел решить.
Вот этот список:
Мне сложно отслеживать бэклоги моих дизайнеров, приходится всё время переключаться между их Kanban-досками.
Нет четкого процесса проведения проверки.
Некоторые важные макеты могли уходить в разработку без моей проверки. Только постфактум я узнавал, какое дизайн-решение пошло в эксплуатацию.
В Telegram я терял сообщения, слишком много времени тратил на переписку по задачам и погружение в их контекст.
Некоторые продуктовые команды по ошибке или специально ставили меня в исполнители задач, ждали моей реакции, а я эти задачи банально не замечал.
Стало понятно, что нужно исправить процесс работы дизайнеров над задачами и взаимодействие со мной.
Процесс задач
У нас в компании в Jira ранее уже был встроен единый процесс для всех дизайн-задач во всех продуктовых командах. Вот он:
На своих Kanban-досках дизайнеры уже корректно перемещали задачи по статусам. Мне оставалось только начать отслеживать назначение тех или иных статусов и агрегировать информацию в удобном для меня виде.
Единая панель
Я создал панель для сбора задач всех моих дизайнеров. Там же отдельно фиксируются задачи со статусом «ревью», на которые мне стоит обратить внимание.
Единая панель
Из чего состоит эта панель:
Design_Ivanov. Справа в колонке идут один за другим блоки с задачами каждого дизайнера, с указанием продуктовой команды, даты создания, статуса и названия задачи. Фильтр этих блоков выглядит так:
Project in (Команда№1, Команда№2, Команда№3) AND issuetype = Дизайн AND assignee = Ivanov AND statusCategory != DoneС помощью этих блоков я всегда вижу в одном месте бэклоги всех дизайнеров.
Design_not_ok. В этом блоке выводятся задачи, которые перешли из статуса «дизайн» в статус «груминг», но в которых я не отписался в комментариях и, соответственно, не проверил их. Так я минимизирую «проскальзывание» задач в разработку, минуя меня. Это может выглядеть как «микроменеджмент», но для меня важно быть в контексте всех задач, над которыми трудятся мои дизайнеры, чтобы сохранять согласованность дизайна между соседними продуктами, не дублировать ранее созданные дизайн-решения в других командах и понимать, какими задачами загружают дизайнеров.
Project in (Команда№1, Команда№2, Команда№3) AND issuetype = Дизайн AND status = Груминг AND issue not in updatedBy(aatalaluev) AND created >= 2023-12-27Назначенные на меня без leads. Это задачи, которые были назначены на меня.
project != leads AND assignee in (currentUser()) AND statusCategory != DoneDesign_All_Review. Тут отображаются все задачи, у которых стоит статус «Ревью». Как выглядит процесс: дизайнер разработал макеты и ему нужна моя проверка. Он ставит статус «ревью». В панели я вижу эту задачу в этом блоке и возвращаюсь к ней, когда нахожу время для проверки. Просматриваю макеты или решение задачи, пишу в комментариях, всё ли хорошо, и далее возвращаю дизайнеру задачу в статусе «дизайн».
Project in (Команда№1, Команда№2, Команда№3) AND assignee in (Дизайнер№1, Дизайнер№2, Дизайнер№3) AND issuetype in (Задача, Дизайн) AND status = РевьюDesign_All_backlog. В этом блоке я вижу все задачи для всех своих дизайнеров по мере их постановки в Jira. Это бывает нужно, если необходимо восстановить хронологию событий в контексте постановки задач и т. д.
Project in (Команда№1, Команда№2, Команда№3) AND assignee in (Дизайнер№1, Дизайнер№2, Дизайнер№3) AND issuetype in (Задача, Дизайн) AND status = Бэклог
В результате
Я в любой момент времени знаю, какими задачами загружены дизайнеры, в каком статусе они находятся, и вижу бэклоги ребят на одном экране.
Мои дизайнеры понимают процесс движения задачи, и он у всех в каждой команде одинаковый.
Все задачи проходят через меня, и я в курсе всех решений, предлагаемых моими дизайнерами. Держу руку на пульсе в своих продуктовых командах.
В Telegram не спамят ежеминутными сообщениями по задачам, я не теряю запросы на проверку. Я могу планировать свой рабочий день и, например, проверять по вечерам и за раз проходить по всем накопленным задачам.
Я вижу все задачи, которые на меня ставят не в моей рабочей области, и могу оперативно на них реагировать.
