2 заметки с тегом

управление проектом

Как мы искали редактора в команду

Так получилось, что с января 2022 единая редакция в Ozon Marketplace разделилась на отдельные направления, и я возглавила подгруппу по UX-редактуре и Базе знаний — так мы называем наш портал с инструкциями для продавцов. Задач было слишком много, а людей слишком мало, поэтому мы начали активно искать UX-редактора.

В редакции вообще и в Ozon в частности устоявшаяся система найма, наш главный редактор и вовсе с первых слов чувствует людей, но я оказалась впервые по ту сторону. Поэтому решила записать свои впечатления и по ходу дела пояснить, на что обращала внимание.

Навеяно комментариями под постами с вакансиями в нашу редакцию. На самом деле мы никого не едим, просто растем очень быстро, а людей в команду отбираем тщательно. Так вакансия UX-редактора была открыта еще в 2021, а вышел человек только 15 апреля 2022

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

Этап 1. Отсеиваем неподходящих

Сначала смотрели резюме и портфолио. Хотя я все чаще слышу, что резюме — это что-то вроде пережитка прошлого, но для меня важными оказались оба документа.

В резюме я хотела увидеть:

  • структуру и акценты, ведь если редактор не может в нем грамотно рассказать о себе, то объяснить что-то в интерфейсе или инструкции не сможет и подавно.
  • релевантный опыт. В воронку попадали как совсем новички с единственным кейсом в виде диплома в «Нетологии», так и руководители отделов, которые прямо указывают, что давно не пишут сами — и те, и другие нам бы не подошли.
  • близкие компании — мне кажется, что адаптироваться будет проще, если в прошлом компании были похожи на Ozon по сфере, размеру и общим ценностям. Плюсом был опыт сложных продуктов и b2b.

А вот образование не имело значения — коммерческой редактуре как таковой в вузах не учат, поэтому все разными путями приходят в профессию. Например, в команду в итоге попала девушка, которая в прошлом была дизайнером.

С примерами работ было гораздо сложнее. Для меня важно, чтобы портфолио:

  • в принципе было у редактора. Я честно не понимаю тех, которые выходит на рынок труда без него. Даже если все под NDA, всегда можно специально сделать пару придуманных экранов онбординга или оформить как пример тестовое задание. Кандидаты без портфолио в моих глазах получали большой минус.
  • содержало тексты именно по интерфейсам. Почему-то многие присылали в качестве примеров рассылки и даже статьи в блог.
  • показывало разные форматы. Например, пуш, онбординг, тексты ошибок и подписи в рамках какого-то большого сценария — нужно посмотреть навыки со всех сторон.

Этап 2. Тестируем кандидатов

У нас UX-редакторы не только занимаются интерфейсами, но и пишут инструкции. Поэтому было два задания — это задачи, с которыми предстоит столкнуться в повседневной работе.

Тестовое задание 1: написать онбординг для новой фичи

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

Скриншот гуглдока с заданием. Ниже давали ссылку на фигму с призывом скопировать макеты к себе и сделать задание прямо в них

У кандидатов не было какого-то одного правильного способа сделать это задание. Например, можно было подготовить идеальный текст, обойдя ограничения и подсветив реальные преимущества фичи. Или сделать анализ рынка и доказать нам, что мы дураки и так делать не стоит :)

Так что мы больше смотрели на подход к работе и логику в целом. В результате хотелось увидеть:

  • минимальную аналитику — например, рассуждения о том, что доставка практически из любого города есть и сейчас, в недалеком будущем это и подавно станет нормой, а не преимуществом.
  • аргументацию — как правильно «продать» покупателям новую услугу, ведь в задании мы специально подсветили не лучшие плюшки.
  • работу в фигме — все-таки это уже почти стандарт для работы над интерфейсами.

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

Тестовое задание 2: написать инструкцию в Базу знаний

Чтобы посмотреть, как кандидаты умеют объяснять и подавать информацию, мы дали им реальный макет и попросили написать по нему инструкцию.

Это задание чисто на хард скилы. На что я обращала внимание:

  • текст — думаю, тут нет смысла долго рассказывать. Обращала внимание на структуру, разбивку по блокам, корявые фразы и прочее.
  • полнота информации. Не возьму соискателя, который проигнорировал часть настроек, которые отражены в макете — а таких было немало.
  • наглядность. Наш кабинет может показаться непростым, поэтому одной простыни текста недостаточно. Я смотрела, добавляет ли кандидат картинки, что именно иллюстрирует и как оформляет скриншоты.
  • вопросы и рассуждения. Хотелось найти человека, который действительно старается вникнуть в задачу. Тогда у него неизбежно возникнет куча вопросов о том, как у нас все работает — здорово, когда прямо в тестовом было написано что-то вроде «В задании недостаточно информации, я бы еще уточнил у заказчика вот это...». Или если кандидат говорил, из каких допущений исходил при выполнении задания.
  • выход за рамки задания. Мы просили написать статью для существующего портала. В моих глазах 100 очков вперед получали те, кто просматривали опубликованные статьи — делали перелинковки, учитывали tone of voice или стиль иллюстраций.
  • оформление. Если человек сделал все красиво — выделил заголовки, вставил картинки, использовал правильные тире и кавычки, не забыл вычитать текст перед сдачей тестового, — значит, в работе он тоже окажется аккуратным. Скорее всего, с небрежным кандидатом я не сработаюсь.

Этап 3. Собеседуем лучших

В итоге у меня было четыре собеседования. Я никогда раньше их не проводила, поэтому на трех со мной была главный редактор, на нескольких — еще HR. Так как мы удаленщики, созванивались в Microsoft Teams. Обязательно включали видео, потому что так проще наладить контакт — видишь мимику и реакции человека.

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

  • какие форматы и типы задач нравятся, а какие нет;
  • как обычно взаимодействует с заказчиками и смежными командами;
  • как строит работу над задачей;
  • куда хочет развиваться.

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

Мне было важно понять, совпадает ли опыт и ожидания кандидата с тем, что мы ему предлагаем. Особенно обращала внимание на:

  • рассказ о прошлом опыте. Следила за тем, насколько внятно человек описывает свои функции и результаты на других местах работы.
  • самооценку кандидата. Мне было важно, чтобы человек знал, чего он хочет — куда расти, какие задачи брать и сколько денег получать. Одному кандидату мы отказали как раз потому, что не увидели в нем стержня и сформированного мнения даже на такие вопросы — кажется, что и рабочие решения кандидат отстоять не сможет.
  • вопросы к нам. Считаю, что их не может не быть, какой бы подробной не была вакансия. Для меня четкие вопросы — это знак, что человеку важно понять его роль и порядок работы, что он не идет абы куда. Ну а еще это показывает, что в работе редактор будет так же дотошно приставать с уточнениями и фактурой.

Обычно после собеседования мы оставались и делились своими впечатлениями, но с нашим будущим редактором получилось иначе. Уже на середине встречи я чувствовала, что хочу работать с этим человеком — и сразу же обсудила в личке с главредом, что «да, это оно».

Что после найма: помогаем освоиться

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

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

 93   7 мес   организация работы   рефлексия   управление проектом

О доверии в команде

Когда я прихожу с работы и рассказываю мужу о своих переживаниях, он всегда удивляется, насколько мне важно доверие коллег. Я все время слышу: «Что ты переживаешь, это же не ты решила/накосячила?», «Ты свою работу сделала — какая разница что будет дальше?», «Зарплату платят, остальное не важно» и пр. Я удивлялась его легкому отношению к работе. Ему правда все равно, что о нем думают. А потом поняла — у нас просто разный опыт.

Любая задача, которую мы делаем, относится к проектам или к процессам. Проект имеет временные рамки, этапность и ведет к конкретному продукту/результату на выходе. Процесс — бесконечен.

процесс ≠ проект

В больших бюрократизированных организациях (вроде ГКУ ЦЗН, где работал муж) обычная работа сотрудников состоит из череды процессов. У них есть KPI, но они тоже завязаны на процессах — например, направить в 2019 году Х безработных на обучение. И ты изо дня в день общаешься с безработными, заполняешь одинаковые бумажки, пишешь одинаковые запросы — и так постоянно. Иногда рутина разбавляется очередным распоряжением сверху, но люди не понимают его смысла — они не видят картину целиком и поэтому не особо замотивированы в выполнении. И даже в конце месяца, квартала и года нет видимого результата, сплошная рутина.

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

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

Когда мы запускаем сайт, я как редактор работаю в команде с разработчиком и дизайнером. Иногда к задаче подключается оптимизатор и юзабилити-специалист. Каждый из нас отвечает за определенную часть проекта. Если мы не будем доверять друг другу, проект развалится: мы как лебедь, рак и щука будем тянуть его в разные стороны.

Помимо текстов я беру на себя функции проджект-менеджера и принимаю многие решения: делать фичу или не делать, релизить или не релизить. Иногда мне приходится что-то менять под давлением руководства. На первый взгляд, не моя вина, что у начальства семь пятниц на неделе. Но именно мне приходится идти к команде со старой новой задачей. И я понимаю, чем чаще я буду допускать такие ситуации, тем меньше мне будут доверять.

Доверие в команде — самое главное для успеха проекта

P.S. Компания целиком — та же команда. Поэтому не делайте, как мое начальство: принимайте решения обдуманно и берите на себя ответственность. Иначе подчиненные перестанут вам верить.

 33   2019   организация работы   принципы   рефлексия   управление проектом