История о том, как Даня дизайн-менеджменту учился
Все началось в позднем декабре. К тому времени я почти около года лидил команды на большом синем проекте в студии pinkman.ru. Суммарно в моменте со мной работало уже 5 дизайнеров. Но по ощущениям фокус с активного ведения проектов (роли ведущего дизайнера) на менеджмент команды у меня так и не переключился. Я начал рефлексировать на тему задач и своего времени в разрезе прошедшего квартала и понял — нужно что-то менять.
Эта заметка— попытка отрефлексировать прожитый опыт и рассказать историю, которая поможет другим начинающим дизайн-менеджерам не попадаться в эту ловушку
А что именно накипело?
После очередной прошедшей недели я был вымотан—из 40 рабочих часов я около 32 был на звонках по проектам. Тогда вспомнилась студийная вики по менеджменту, а вернее – иллюстрация целевого распределения времени лида (см. ниже). Далее я прикинул по неделям календаря распределение своего времени – стало страшно и я решил бежать калиброваться с ментором. Для этого нужно было составить вопросы/запросы
Распределения времени лида целевое и фактическое
Что я хотел понять перед «выходом из операционки»
Я выписал 3 категории вопросов, которые далее сформировались в запросы «во вселенную»
- Поскольку рост был быстрый из потребностей студии и лид — это в первую очередь роль, мне хотелось понять, а все ли так с моими хардами и вижном дизайн-процесса?
- К тому времени через мой лидинг прошло уже 12 человек (включая уже ушедших из студии / перешедших на другие проекты) — и все они были разные: кто-то быстрее рос, кто-то медленнее; кто-то был силен софтами и мышлением, кто-то визуальным дизайном и 3D в частности; у кого-то получалось менеджерить, а кто-то даже думать об этом не хотел. Возник вопрос — как все-таки правильно организовывать систему роста, учитывающую контекст проектов и действительные желания дизайнеров?
- Экзистенциально, но: что меня в карьере ждет дальше? Взять еще больше проектов внутри студии и увеличить команду? А зачем мне это? Пойти ведущим дизайнером в продукт, как большая часть уходящих из студии дизайнеров? А может, я потяну переход сразу на позицию лида/менеджера в продукт? А чем вообще отличается дизайн-менеджер в студии и продукте?
Думаю, тут можно даже не спорить, что сам бы не разобрался и нужно мнение со стороны от человека с опытом.
По счастливой случайности через пару дней после возникновения этих запросов я наткнулся на серию fb-постов Кирилла Романовского, VP of design Xsolla
Прочитав их и заглянув на его сайт-портфолио, я понял, мнение и опыт этого человека я хочу услышать!
Я написал Кириллу в тг и практически сразу после новогодних праздников мы начали цикл сессий-созвонов
Глава 1. Команда и ее развитие
Начали мы, конечно же, не с темы карт компетенций и подобного, а более корневых вещей.
Я всегда стремился развить команду — организовать процессы или вне рабочие активности, предложить их улучшение, наладить performance review, сделать прозрачнее грейды и т.д., но получалось далеко не все
Кирилл, послушая пару минут про это, подвесил в воздух очень резонный вопрос «Вот ты все пытаешься вырастить дизайнеров, зафреймить их как-то; они в свою очередь ждут какие-то мифические инструменты по развитию как волшебные таблетки, но ситуация давно не менялась. Ответь на предшествующий вопрос — как ты считаешь, дизайнеров нужно развивать?»
Подвиснув на 5–10 секунд ко мне конечно же пришло «В первую очередь это должно идти от дизайнеров», но мысль была куда глубже.
Вдогонку Кирилл мысль развивал — «Круто, мы поняли, что дизайнеры сами должны драйвить это. Но теперь давай представим, что у тебя не 5 дизайнеров, а 20. Как бы ты организовал развитие?»
Тут становится понятнее, что придумать универсальную таблетку не получится. Нужны две составляющие — ракетное топливо «изнутри» в виде мотивации, а также методы управления этим «кораблем развития». Далее мы выделили:
Методы управления
- ассесменты (360 оценка с постановкой целей для дизайнеров, релевантных их желаниям и целям бизнеса);
- day-by-day менторинг старшими дизайнерами или менеджерами;
- обучение (например, в виде онлайн-курсов, которое нужно заложить в бюджет)
Способы разжечь мотивацию изнутри
- совместная работа;
- привнесение новых знаний (в виде митапов, воркшопов или групповых сессий внутри команды, что требует высоко развитого навыка фасилитации от менеджера)
Глава 2. Уровень стратегии, процессы
После мы отошли от темы обучения и посмотрели чуть более глобально — а в чем же задачи менеджера.
Кирилл выделяет следующие основные:
- Задавать видение и драйвить стратегию команды
- Регулярно выравнивать всю команду по ценностям, целям и методам их достижения
- Решать проблемы и конфликты (aka troubleshooting) + развивать у себя навык фасилитации
- Организовывать процессы (причем это переходит в must have из nice to have, все больше компаний понимают ценность 1–1 и подобного, дальше выезжать в конкуренции только на этом станет невозможным)
Но именно видение — универсальный инструмент, с которого начинается любое обучение лидерству
А как составить хорошее видение команды? Расписать, какой видишь команду в течение года, а затем в рамках 2–3 лет: что ее характеризует, почему, что это дает, какими путями это достигаете, что будут уметь делать дизайнеры.
Это и есть вижн в чуть более раскрытом виде
Соответственно, я стал менять фокус своей работы именно на эти вещи, а на менторских сессиях мы разбирали затыки, которые мне были непонятны.
Так, чтобы понять, ситуацию as is и to be: какие «стадии развития команд» вообще есть, мы обратились к HyperIsland (см. скриншот далее)
Степени «развития» команды. Источник — https://www.hyperisland.com/blog/creating-effective-teams-the-detailed-curation
Далее необходимо было найти способ засинхронить цели каждого участника команды и пересечения в общих ценностях. Лучшим решением, чтобы понять, какие ценности я ищу в людях — являлось обращение к команде, ведь при найме я неосознанно скорил ребят по определенным фильтрам (как мы поняли далее). И выбранным форматом «обращения» стал Team Canvas. Провели его вместо предстоящего ретро и на удивление формат удался. Далее этот фигма-борд мне очень помог в фиксации ценностей
Комадные архивы ретро. TeamCanvas birdview
Заметка с колла, где мы разгоняли, что характеризует команду, а далее перегруппировали эту историю для описания навыков
Да, это все требовало неоднократных доуточнений, но сам факт того, что мы делали что-то новое и по-настоящему важное для меня без тормозов, прямо в режиме онлайн час в неделю — невероятный
После такой «сессии генерации идей» требовалось выделить время на рефлексию и финализацию артефактов. Т.к. по этим артефактам предстояло описать конкретнее, какие нужны навыки у дизайнеров, чтобы этого всего достичь — из них формировали «портрет целевого специалиста», который уже далее раскидывали на экспертные ветки
Драфты карьерных веток с онлайн-сессий
Также, чтобы карьерные ветки удались — необходимо их проектировать «долгими». Чтобы специалист, становясь senior’ом понимал, чего делать дальше — ибо если не поймет, то уйдет к соседям, которые ему об этом расскажут. Материалом на эту тему Кирилл также поделился и мы обсуждали, задачи какого уровня могут заинтересовать таких специалистов
Во время обсуждения этой темы мы постоянно отсылались к живым примерам, работающим в компании Xsolla
Если вы хотите прочитать подробнее об этом методе построения карьерных веток: Кирилл недавно написал статью — https://uxplanet.org/design-career-levels-principles-and-storytelling-c4fa8d87b763
Глава 3. Дизайн-процесс
Следующей темой обсуждения стал дизайн-процесс. У меня уже были наработки схемы с обозначением проблемных точек
Дизайн-процесс команды до изменений
Как только Кирилл услышал проблемы — он обозначил, что схожий путь они проходили в Xsolla. Посоветовал прочитать про design thinking и double diamond + на примерах рассказал, как это устроено у них.
Фрагменты внутренней презентации, Xsolla
Почитав про фреймворк подробнее, могу отметить, что кому-то он очень нравится (те же примеры знакомых лидов/менеджеров в продуктах xsolla, cloud.ru), кто-то его хейтит из-за сложного наложения на реальные процессы компаний. Мое личное мнение — вторая категория людей воспринимает его слишком буквально или возлагает на него слишком большие надежды. На мой взгляд, фреймворк отлично описывает процесс верхнеуровнево, какие этапы задача проходит (очень быстро скорится, каких этапов нет), а внутренние артефакты отдельных этапов — это уже лирика, которая требует уточнений и может подстраиваться индивидуально к командам / направлениям бизнесов и т.д.
Как это часто бывает, на только что пройденную теорию сразу попалась одна из текущих рабочих задач. В рамках нее мы проектировали очередную фичу уже 2–3 месяца, но результаты никак не могли согласовать, а все потому что мы на входе апеллировали «готовым запросом решения» от Product Owner’а (PO) и отдела маркетинга. После очередной неудавшейся презентации мы обнулили понимание этой задачи и пошли в уточнение гипотез, которые хотим проверить, DoD (definition of done) у PO и UX-тесты. На удивление, после того, как проблема доуточнилась (вернулись к этапу discovery), и сменилось понимание необходимого решения, в итоге мы примерно за неделю согласовали концепцию решения с руководством и далее ушли в ее масштабирование.
Выходит, что уделяя больше внимание discovery&define фазам — мы значительно сокращаем затраты (или увеличиваем ROI) на продуктовую разработку.
Сейчас прогоняем данный процесс на большем количестве задач. В случае успеха планируем масштабировать на другие команды студии.
Фрагменты внутренней презентации, pinkman
Конечно, у данного фреймворка есть развитие в виде третьего алмаза (надстройки стратегии в начале пути задачи), но эта лига пока что вне моего фокуса, в нее имеет смысл смотреть, когда в компании построена хотя бы большая часть фаз двух алмазов
Фрагменты внутренней презентации, Xsolla
Глава 4. Внедрение изменений в команду
Спустя несколько месяцев, накопился значительный багаж «предстоящих изменений». На очередной менторской сессии обсудили, как же стоит это все внедрять. Ранее я стремился каждой такой процессной историей делиться с командой в рамках демо (в чем мы кстати с Кириллом разбирались — а зачем я это делаю, действительно ли мне нужно заручиться аппрувом на каждое изменение или нет, но это отдельная история)
Сошлись на том, что необходимо искать баланс между «обсужу каждый чих с командой» и «я знаю как лучше, делаем так, комментарии не принимаются». Придумать условных 20 улучшений процессов и сразу их внедрять не ок, особенно в случае, когда команда новая. Лучше это делать постепенно. Например, быстро внедрить 2 каких-либо улучшения, которые точно покажут результат и необходимы, повысив лояльность. Уже далее презентовать остальное и даже челленджить какие-то истории с командой.
В идеале к стратегии нужно было подготовить
- Приоритеты и сложность внедрения каждого процесса
- Презентацию для стейкхолдеров
- Презентацию для команды
- Воркшопы для команды по отдельным частям стратегии (свои/приглашенных спикеров)
Заключение
- Ищите ментора или людей, которые уже решали схожие с вашими проблемы — избежите кучу подводных камней; узнаете, как делать нужно, а как – нет; и ускоритесь в 10 раз, если не больше
- Выделяйте регулярный слот под рефлексию — раз в квартал (а лучше — чаще), чтобы думать о стратегии, а далее в ежедневном принятии решений задавать себе вопрос «а ведет ли это нас к цели, а соответствует ли это нашей стратегии», или наоборот, задавать вопрос «а чего мы еще не делаем, чтобы достичь желаемой цели»
- Отрисуйте схему вашего внутреннего дизайн-процесса и поймите, все ли фазы вы закрываете. Особенно обратите внимание на фазу погружения в задачу/discovery, и транслируйте дизайнерам (это поможет им стать самостоятельнее)
- Действуйте и не бойтесь ошибиться, а не ждите волшебной таблетки, лучше вас самого проблемы в данном промежутке времени и контексте никто не решит
- Ожидайте продолжение статьи, где я попытаюсь раскрыть, а как вышеупомянутые активности отразились на работу моей команды (уже в составе 12 дизайнеров) в долгосрочном периоде
Мои контакты
Если у вас есть желание подискутировать или доуточнить какие-то моменты из статьи — добро пожаловать ко мне в телеграм, буду рад!
Персональное спасибо
Кириллу Романовскому, моему ментору, — за невероятно полезное и отрезвляющее менторство
Насте Панковой, моему дизайнеру, — за прекрасные иллюстрации-вставочки