Перейти в новую дизайн-команду и наладить управление за три месяца: советы руководителя отдела дизайна Atlassian Статьи редакции

Перевод материала Аластера Симпсона.

Я поработал над всеми продуктами Atlassian: сначала над Confluence, после — над Jira, Bitbucket и Sourcetree, потом вернулся к работе над Confluence, HipChat и Stride. Сейчас же занимаюсь Confluence, Trello и облачной платформой.

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

Хотя у меня и есть базовая структура, не думаю, что под неё можно подгонять всех. Навыки руководителя следует применять гибко, ориентируясь на конкретную ситуацию. А приходить в новую команду и сразу же вносить изменения, не понимая обстановки внутри неё, — рискованно.

Структура, которой придерживаюсь я, состоит из четырёх элементов:

1. Люди.
2. Практики.
3. Цели.
4. Продукт.

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

Я приходил в команды, о которых говорили: «Эта команда — слаба и ни на что не способна, вам нужно будет её перестроить».

Но после я обнаруживал, что команда на самом деле очень компетентна, просто её неправильно сформировали. Или ставили перед ней не те цели.

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

• Что хорошего в команде?
• Что работает плохо?
  
• Как вы думаете, какие изменения я должен внести сейчас, чтобы сделать команду лучше?
  

Я внимательно слушаю ответы, задаю уточняющие вопросы. Активное слушание и дополнительные вопросы — ключ к пониманию коллектива.

Также я хочу понять, хорошо ли сформирована команда. Для этого подходят следующие вопросы:

• Насколько разные люди собрались в команде?
• Какие навыки у них есть?
  
• Каких навыков им не хватает?
  
• Сколько вакантных должностей и как долго они были свободны?
  
• Насколько вырастет команда за период от полугода до двух лет?
  
• Сколько рабочих процессов контролирует каждый дизайнер?
  
• Каким образом связаны между собой дизайнер, менеджер по продукту и инженер?
  

Получив ответы, визуализируем организационную структуру команды. Это помогает понять, устойчива команда или нет.

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

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

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

1. Что хорошего в команде?

2. Что плохо работает?

3. Какие изменения я должен внести сейчас, чтобы сделать команду лучше?
   

Хочу взглянуть на команду с разных точек зрения. Такие «взгляды изнутри» часто очень интересны.

Важно, чтобы вы уделили достаточно времени на понимание участников вашей команды и людей, которые имеют к ним отношение. Это надо сделать перед внесением изменений.

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

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

Уделяю время практикам команды, существовавшим до моего прихода, по двум причинам:

1. Возможно, я смогу научиться делать какие-нибудь замечательные вещи, которые уже делает команда.
2. Я хочу вести себя уважительно и убедиться, что хорошо понимаю, какие проблемы вижу (возможно, проблем вовсе нет). И я должен привести веские аргументы и примеры перед внесением изменений.

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

Как ваша команда узнаёт, что добилась успеха? Действительно ли она ответственна за что-либо? Какие есть механизмы обратной связи? Есть ли у каждого члена команды план развития своей карьеры?

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

В Atlassian мы используем метод OKR (цели и ключевые результаты). При этом важно убедиться, что команды дизайнеров понимают, как их реальная работа связана с метриками.

Часто бывает, что у членов команды нет плана по развитию карьеры. Это значит, они понятия не имеют, совершенствуют ли они свои профессиональные навыки. Вкладывать усилия в карьерный рост вашей команды — одна из самых важных вещей, которые вы можете сделать как менеджер.

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

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

Последний шаг на моём пути — понять продукт и проблемы, которые он помогает решать клиентам. Я пытаюсь придумать, как использовать продукт в повседневной жизни.

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

Чтобы по-настоящему понять продукт, нужно изучить клиентов и количественные данные. Прочтите как можно больше интервью с клиентами. Задавайте вопросы окружающим.

Пообщайтесь со службой поддержки или командой по продажам. Общайтесь с аналитиками и старайтесь понять, какие показатели способствуют развитию продукта. Словом, потратьте столько часов на изучение клиентов, сколько сможете. Так вы быстрее поймёте сильные и слабые стороны продукта — и как повысить его ценность и изменить будущее.

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

Убедитесь, что в следующие месяц-полтора сможете одержать несколько небольших побед. Это поможет настроиться на успех в дальнейшем.

#команда #дизайн