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

b7c114b2a551f0be725e857a1e17a749.png

Когдая пришëл на работу в Домклик ведущим дизайнером, у меня в подчинении оказались 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. Я вижу все задачи, которые на меня ставят не в моей рабочей области, и могу оперативно на них реагировать.

© Habrahabr.ru