Создавать что-то новое — неважно, будь то продукт или команда — интересно и сложно. Зачастую по чужим готовым лекалам действовать не получается. А если это «новое» создаётся в большой компании, изменения надо стыковать со многими элементами действующей структуры. Короче, задачка получается со звёздочкой.
Меня зовут Даша Боровик. Сейчас я руководитель команды экспертов по клиентскому опыту и доступности в RUTUBE. А пару лет назад передо мной встала непростая задача — внедрить новую роль в компанию и собрать команду с нуля. Я искала материалы, которые бы подсказали мне, что и в какой последовательности делать — но, казалось, ни одна из найденных статей и заметок не подходила мне идеально.
Сейчас, когда я набила шишки, накопила опыт и могу сказать, что эксперимент оказался успешным, я решила сама создать такой материал. И если вы стоите на пороге такой же задачи, не зная, за что взяться и с чего начать — моя инструкция поможет.
Уже давно в RUTUBE существует лаборатория UX-исследований. При создании продукта именно эта команда помогает выбрать удобное и понятное пользователю интерфейсное решение.
В 2023 году, когда я пришла в команду лаборатории, одним из важных направлений компании было повышение качества пользовательского опыта. Наша лаба, тем временем, хотела растить своё влияние на работу будущих фичей.
Чтобы влиять на пользовательский опыт, сначала надо было научиться управлять знаниями о нём: результатами UX-исследований, обращениями в поддержку, отзывами в сторах, данными продуктовой и клиентской аналитики. А главное — придумать, как сделать так, чтобы эти знания применялись при создании фичи.
Мы решили создать новую роль в компании и собрать команду, которая взяла бы управление данными о CX на себя. И включить представителей этой команды в продуктовые стримы, чтобы их руками влиять на решения о новых запусках.
Ниже вас ждёт подробная инструкция, как создать с нуля команду, которую я построила на основе этого опыта.
Краткое описание алгоритма по внедрению новой роли. Для тех, кто хочет сразу получить выжимку.
Шаг 1. Определили миссию новой роли
Для этого нужно ответить на два вопроса:
Чем моя идея поможет бизнесу?
Как можно воплотить миссию?
При ответе важно фокусироваться на общей стратегии и миссии компании на долгосрочный период.
Шаг 2. Заручились поддержкой руководства
Рассказали о миссии, которую определили на первом шаге.
Поделились видением зоны ответственности:
какие задачи новая роль может взять на себя;
каким навыкам научит команду;
как именно позволит реализовать актуальную стратегию компании.
Не забудьте к этому моменту прикинуть, сколько вам нужно человек и сколько они будут стоить. Начните с малого.
Шаг 3. Собрали свою команду
Организовали процесс найма с рекрутёром. Если роль новая или нестандартная, советую закладывать больше времени — оно пригодится, чтобы определить профиля идеального кандидата.
Мне очень помогло выписать задачи новой роли и определить список компетенций, которыми надо обладать, чтобы качественно закрывать будущие проекты. Эти ожидания я сбивала с реальностью в процессе найма.
Шаг 4. Подготовили документы
План минимум:
штатное расписание;
должностные инструкции;
задания на испытательный срок.
Без этих документов найм обычно реализовать нельзя. Штатка и инструкции, хоть и шаблонные документы, всё же потребуют тщательного анализа при их подготовке. А уж составление заданий на испытательный срок — это целая наука. Обо всех подводных камнях я написала ниже в статье.
Шаг 5. Собрали производственный процесс
Изучили, как в компании создаётся продукт. Определили, где в этом алгоритме будем подключать новую роль. Для этого оглядывались на свою миссию, чего и вам советую — она поможет не отвлекаться.
Шаг 6. Запустили пилот
По прошествии двух лет могу сказать — готовьтесь переделывать подход находу. И не забудьте запланировать оценку по критериям успешности: как понять, что новый процесс работает и помогает достигать вашу миссию.
А после пилота — долгий путь компромиссов и тесной работы внутри команды.
Шаг 1. Определили миссию
На этом шаге мечта и фантазия обрастают подробностями, структурируются, превращаются в план действий.
У меня была поверхностная идея о том, что можно сделать и как можно работать. А ещё — куча энергии, чтобы это осуществить. Скорее всего, на старте у вас есть плюс-минус такой же набор.
Решите, каким вы видите будущий продукт своей компании, когда ваша идея воплотилась. Определиться помогут два главных вопроса.
Чем моя идея поможет бизнесу?
За ответ вы поблагодарите себя позднее, когда настанет время общаться с руководством.
Для ответа на этот вопрос подумайте:
Какая у бизнеса сейчас стратегия? К чему стремится компания? Это могут быть конкретные метрики, эффекты. А может быть тоже миссия, но уже более глобальная и фундаментальная — например, усиление HR-бренда.
Как новая роль может помочь этой стратегии осуществиться? Каких компетенций не хватает в компании? Какими из них может обогатить команду новая роль?
Нашей ключевой миссией было улучшить пользовательский опыт RUTUBE, сделать наш продукт клиентоцентричным. Это, в свою очередь, растило CX-метрики продукта (CSAT, NPS) и опосредованно — усиляло бизнес-эффекты запусков.
На этом этапе стоит стойко принять тот факт, что все ответы на вопрос о помощи бизнесу — это неподтверждённые гипотезы. Чтобы проверить их, предстоит проводить пилот, но с этим вы столкнётесь сильно позже.
Как можно воплотить нашу миссию?
Ответ на этот вопрос — это хотя бы примерное представление, как, в какой момент и в какие процессы будет включаться новая роль. Алгоритм должен работать так, чтобы бизнес получал свою обещанную помощь.
На этом шаге я структурировала свои идеи — делала это в обычном вордовском файле. Можно собрать майнд-карту или набросать линейный процесс того, как будет работать новая роль внутри продукта. Найдите точки роста, которые вы можете закрыть — и не забывайте оглядываться на свою миссию, чтобы не отвлечься.
До RUTUBE у меня был опыт работы в компании, в которой CX-команда была успешно и комфортно включена в процесс создания фичи. На основе этого опыта мы собрали план-минимум: чтобы улучшать пользовательский опыт каждым новым запуском продукта, хотели производить артефакт, который:
описывает логику работы фичи в руках пользователя;
мэтчит её ценность для юзера с бизнес-стремлениями;
на основе объективных данных позволяет собрать лучший вариант из всех возможных.
Такой артефакт на самых ранних этапах производства фокусировал бы рабочую группу на пользовательском опыте и выполнял дополнительную функцию синхронизации команды. Мы хотели, чтобы артефакт учитывал все наши знания о CX в RUTUBE и предлагал конкретное решение для работы фичи. Подход направлен на то, чтобы гарантировать и выгоду бизнесу, и ценность пользователю.
Шаг 2. Заручились поддержкой руководства
Вспоминая тот период, мне кажется, что нам помогала сама судьба. Почти сразу после того, как мы определили свою миссию, к RUTUBE присоединились новые продуктовые менеджеры. У некоторых из них уже был опыт работы с ролью, которую мы хотели внедрить. И ребята, чуть освоившись, почти сразу спросили: «А где наши CJE?».
CJE (Customer Journey Expert) — роль, в задачи которой входит изучение пользовательского опыта по продукту. Именно с их помощью мы хотели достичь целей, которые ставили перед собой.
С поддержкой команды оказалось (почти) несложно убедить принимающего решение менеджера пойти на эксперимент и внедрить новую роль. Вот, что мы использовали в качестве аргументов:
Рассказали о миссии, которую определили на первом шаге.
Поделились видением зоны ответственности. Фокусировались на следующем:
какие задачи новая роль снимет с продуктового менеджера, чтобы позволить ему сосредоточиться на стратегии развития продукта;
каким навыкам научит команду;
как именно позволит реализовать стратегию RUTUBE по улучшению юзабилити.
Кстати, о важном — про деньги и ставки. В период согласований вас обязательно спросят про деньги: сколько вам нужно сотрудников и сколько они должны стоить. Не стройте Вавилон с самого начала и не отпугивайте огромными цифрами. Начните с малого: поймите, сколько человек вам нужно для пилотного запуска команды и проверки гипотезы о положительном влиянии новой роли на продукт. У меня на старте было 3 ставки, включая меня (а сейчас нас уже 8).
Шаг 3. Нашли свою команду
В мой отдел сразу выделили ставки для новой роли — а значит, нужно было найти на них людей.
Попыталась написать о том, как я составляла тестовое задание, проводила собеседования и принимала решение о найме — но поняла, что лучше хорошо сделаю это в отдельной статье. Здесь просто подскажу, с какой сложностью можно столкнуться на этом этапе и как из неё выбраться.
Непонятно, кого искать
Неизбежно при поиске нового сотрудника рекрутёр задаст вопрос: «Кто нам нужен?». Если новая роль нестандартная, и кандидатов с идеальным опытом маловато (как это было у меня) — вы с рекрутером будете нащупывать профиль кандидата совместно опытным путём.
Скажу честно — период не самый простой. Долгое время я просто проводила собеседования, изучала тестовые и нащупывала принципы, которые отличают хорошего кандидата от менее хорошего. Очень уставала от общения, когда минут через 30 вы с кандидатом понимаете, что друг другу не подходите, а время вам не вернуть. Другого пути я не нашла: если вдруг знаете более эффективный подход — напишите о нём в комментариях. Но если его и правда нет — просто будьте готовы и закладывайте соответствующее время на подбор.
Шаг 4. Подготовили документы
В зависимости от процессов в компании состав документов, подготовка которых ляжет на ваши плечи, может отличаться. В любом случае вряд ли получится избежать оформления трёх материалов.
1. Штатное расписание
На этом этапе мой руководитель уже согласовал ставки в новую команду. Нужно было сообщить о новой структурной единице ответственному коллеге — обычно это бухгалтер или кадровик.
В этот момент наступило очень приятное (лично для меня) действо — выбор названия отдела и должностей в вашей команде. Не ограничивайте свою фантазию, поищите варианты на hh.ru или поспрашивайте знакомых о том, как похожие роли называются в их командах.
Мой отдел стал называться «Отдел управления пользовательскими путями», а его сотрудники — «Эксперты по клиентскому опыту» (а сейчас к нам присоединился ещё и «Эксперт по цифровой доступности»).
2. Должностные инструкции
Это документ, в котором надо описать, чем будут заниматься ваши сотрудники. Его они будут подписывать при трудоустройстве. Если в новом отделе планируется несколько должностей (например, эксперт и ведущий эксперт), инструкцию надо составить под каждую — чтобы и вы, и новые сотрудники понимали, чем они будут заниматься.
Обычно в компаниях есть согласованный шаблон для этого документа. В первой части описываются стандартные для компании принципы взаимодействия сотрудника с нанимателем. Например, требование регулярно проверять рабочую почту 🙂
Во второй части уже описываются задачи для конкретной роли. Например, в должностную инструкцию эксперта по клиентскому опыту могут входить:
Анализ артефактов, несущих информацию о пользовательском опыте, для создания рекомендаций по улучшению клиентского опыта.
Систематизация данных из UX-исследований и других источников для формирования новых гипотез по улучшению юзабилити.
Подготовка и презентация отчётов по собранным артефактам в различных форматах (воркшопы, очные и онлайн-выступления и т.п).
3. Задания на испытательный
В моей команде для новой роли сразу был предусмотрен испытательный срок для новичков. А это значит — нужно было составить на этот период задания.
В эти три месяца обе стороны оценивают друг друга: вы — сотрудника, а он — и вас, и команду, и новые задачи. Если хоть с одной стороны мэтч не случился — скорее всего, сотрудничество провалится.
Вот принципы, на основе которых я составляла свои задания на испытательный срок:
Измеримость. Чтобы избежать спорных ситуаций, и вы, и новичок должны оба понимать четкие критерии выполнения каждого задания. Это сделает взаимодействие прозрачным: опишет ваши ожидания и образ результата, к которому надо стремиться.
Конечный срок. Я не заморачиваюсь и на все задания даю 3 месяца (столько и длится сам испытательный срок в моей команде). За это время сотрудник накосячит, исправит косяки, научится новому, поймёт правила работы в команде.
Прямая связь с задачами, с которыми сотрудник столкнется после испытательного срока.
Важно оценить, насколько вы готовы работать и развивать новичка, в чём он силен, а где его придётся подтягивать. А сотруднику надо понять, нравится ли ему новая роль, готов ли он в ней учиться новому. Поэтому задачи на испытательный срок должны быть максимально похожи на реальные боевые проекты.
Если задания на испытательный срок не придумываются
Если вы, как и я, собираетесь размещать сотрудника в «соседнюю» команду (для меня это был продуктовый стрим), составить задания может помочь уже работающий в этой команде коллега. Продуктолог, например, погрузит в бэклог на ближайший период, и это вдохновит на подбор правильных проектов.
Вот пример задания на испытательный срок у моей команды:
Задача | Срок | Критерии оценки | |
1. | Комплексная проработка продуктовой инициативы в роли эксперта по клиентскому опыту | Самостоятельно проведен анализ пользовательского опыты по инициативе. Изучены данные о клиентском опыте и юзабилити. Подготовлена, согласована и презентована карта синхронизаций. | |
2. | Изучить теоретический аспект построения пользовательского опыта и использования карт синхронизаций | Изучены книги Джима Калбаха «Путь клиента» и Джеффа Паттона «Пользовательские истории. Искусство гибкой разработки ПО». | |
3. | Изучить теоретический аспект управления качеством клиентского опыта в продуктовой команде | Прослушаны лекции интенсива по UX. Сделано и проверено домашнее задание. |
Шаг 5. Собрали производственный процесс
Одновременно с наймом первых сотрудников мы писали производственный процесс. Выше я заикнулась о том, что до RUTUBE успела поработать в команде с похожей структурой, поэтому составить видение процесса мне было легче. Я снова воспользовалась уже собранным опытом и взяла на вооружение подходы, которые там работали хорошо.
В целом же для выполнения этого шага надо хорошо понимать, как сейчас в компании создаётся продукт. Посмотрите на производственный процесс, оглянитесь на свою миссию и подумайте: «Где можно включаться, чтобы выполнять свою цель?»
В производственном процессе я указала:
Как и когда заказчику прийти к новой роли за помощью?
Сколько времени займёт подготовка артефакта работы?
Кто и когда может использовать этот артефакт?
Как он должен использоваться?
Я оформила алгоритм пошаговым списком в базе знаний. Его можно выразить схемой на онлайн-доске с общим доступом или как-нибудь иначе, как принято в компании.
Затем договорилась с командой, которая будет взаимодействовать с новой ролью, о проведении пилотного запуска нового процесса.
Шаг 6. Запустили пилотное внедрение новой роли
Пилот — это очень важно! Он нужен, чтобы понять, выполняются ли задачи, которые поставили перед новой ролью, и помогает ли в этом новый процесс.
Готовьтесь к тому, что теория не совпадёт с реальностью
После (а скорее всего и во время) проведения пилота вы обязательно поймёте, что что-то не доделали и не додумали. Я с этим столкнулась и с уверенностью говорю: с изменениями, которые затрагивают сразу десятки людей, иначе не получится. У коллег будут возникать вопросы, на которые у вас не будет ответа. Кому-то из рабочей группы будет неудобны новые правила, они будут мешать ему качественно выполнять свою задачу.
Выдохните — это нормально. Более того, нормально изначально настроить пилотную группу на то, что такие «косяки» будут встречаться там и сям. Важнее понимать, в правильном ли направлении вы движитесь — для этого заранее поставьте точки контроля, которые позволят оценивать успешность нового процесса.
На старте существования моего отдела мы столкнулись с тем, что кусочек «нашей» работы продолжали выполнять другие коллеги. Это подсветило нам недостаточное разделение зон ответственности, которое мы и вправду упустили — «соседняя» команда тоже прорабатывала флоу пользовательского пути, но в ином формате и по другим принципам. Мы заметили это, обсудили между командами и провели более четкий водораздел внутри нового процесса. А потом повторили это ещё пять раз…
Проведите оценку успешности пилота
Вот, как мы это сделали:
Оглянулись на свою миссию: на что хотели влиять, что должно было поменяться.
Провели замер «до»-«после» пилота. Проверили, случились ли изменения, которые должна была запустить новая роль.
Если на основе оценки успешности новая роль смогла достичь всех целей — это прекрасно, ваши гипотезы подтвердились.
Если не совсем (как это было у нас, что на старте нормально и вероятнее всего) — не отчаивайтесь. Редко бывает так, что по результатам пилота совершенно ни одна цель не оправдала себя, и случился кромешный провал. Более того, положительное влияние новой роли может обнаружиться не там, где вы ожидали. Например, нашим артефактом захотели пользоваться ещё и системные аналитики, которые ожидали увидеть в нём реакции системы на пользовательские действия. Поэтому по итогу пилота мы изменили методологию составления артефакта так, чтобы полноценно закрывать ещё и эту потребность.
Короче, готовьтесь копаться в результатах и много общаться с членами пилотной команды, проводить с ними интервью, собирать обратную связь. Кейсы прокола — не приговор, а лишь ранка, к которой надо приложить подорожник. Желательно — всем вместе, командой.
Заключение или жизнь после пилота
Если ценность новой роли совпала с потребностью компании, то постепенно корни вашей команды распространятся дальше и глубже. Вместе с ростом привычки к новой роли к ней будет появляться всё больше и больше «нестандартных» запросов от заказчиков.
Перед вами как руководителем постоянно будет вставать выбор: хочу ли я, чтобы моя команда занималась ещё и этим? Росла ещё и в этом направлении?
Мы начали с проектирования юзер-флоу на ранних этапах производства фичи, чтобы её финальная логика работы закрывала пользовательские потребности.
Теперь в нашу зону ответственности входят:
аудиты нашего интерфейса и оценка рыночных практик;
ревью макетов на соответствие согласованному пользовательскому пути;
управление базой юзабилити-долга;
внедрение принципов цифровой доступности многое другое.
Когда-нибудь я расскажу, как соглашалась идти на это, а пока почитайте о наших проектах в статье двух сотрудниц моей команды здесь же на Хабре.
В заключении я подготовила несколько советов от души.
Быть готовым к тому, что многие вещи придётся переделывать находу. Документы, процессы, составы команд и многое другое. Очень хотелось, чтобы всё заработало легко и с первого раза — но так не будет. Меня это сильно фрустрировало, потому что я не была к этому готова и хотела сделать всё быстро.
Собирать обратную связь с других коллег. На старте я ленилась это делать, считая свой подход почти идеальным и правильным: ведь я видела, что он работал в моей предыдущей компании. Но, как и снежинки, все команды разные. Если бы я могла вернуться на старт, я бы поставила больше личных встреч со всеми участниками пилота (не только с моей новоиспеченной командой), и чаще бы прислушивалась к их идеям.
Не бояться конфликтов. Скорее всего, они будут. Новый процесс будет кому-то неудобен, а значит — будет раздражать. Не все коллеги будут понимать ценность новой роли, многие будут открыто сообщать об этом. Не принимайте это близко к сердцу: большинство людей не имеют ничего против лично вас или вашей новой команды.
Долгое время я избегала открытой конфронтации по неудобным вопросам, потому что мне не хватало эмоциональных сил на погружение в них. По возможности выделите на это дело время и подготовьтесь морально: пару раз придётся поучаствовать в «горячих» обсуждениях.
И всё это нормально. Оно того стоило.
У вас тоже все получится :)
Подписывайтесь на этот блог и канал Смотри за IT, если хотите знать о создании медиасервисов с разных сторон — от CX и командной работы до инфраструктуры и ML в большом продакшене. Здесь специалисты Цифровых активов «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE, Yappy делятся своим опытом и тонкостями разработки видеоплатформ. До встречи в следующих статьях!
