Сколько чейнджлогов в пресс-релизе, или Как «Яндекс.Трекер» помогает отделу текстов

Рассказывает менеджер отдела текстов «Яндекса» Мария Макеева.

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

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

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

Со временем количество заявок увеличилось, а отдел вырос до десяти человек. У них в работе находится в среднем около трёхсот задач — это разные тексты на русском и английском языках. При таких объёмах почтой уже не обойтись, поэтому всю работу мы перевели в «Яндекс.Трекер».

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

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

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

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

Вторая проблема — отслеживание сроков. За месяц у одного редактора в работе бывает до пятидесяти тасков разной сложности и срочности. Важно ничего не потерять и не забыть. Третья проблема — оценка загрузки. Чтобы грамотно распределить задачи, важно понимать, насколько загружены конкретные сотрудники и весь отдел в целом. Ориентироваться на количество задач в «Трекере» нельзя, так как они не равноценны.

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

Одна из первых вещей, которые мы сделали после перехода на «Трекер», — разбили все задачки по типам: письмо, пресс-релиз, баннер, промостраница и так далее. Для каждого типа составили в «Яндекс.Формах» бриф — проще говоря, опросник для заказчиков. Бриф включает вопросы, ответ на которые редактору нужно знать для написания текста.

Наши брифы «живут» во внутренней вики, но вообще «Яндекс.Формы» можно размещать где угодно, даже внутри страниц — через iframe. «Формы» интегрированы с «Трекером»: когда заказчик заполняет бриф, к нам в очередь автоматически падает новый таск с описанием задачи.

В «Трекере» можно создавать различные дашборды с информацией о задачах. Мы с помощью фильтра выбрали все задачи, которые надо сдать в ближайшие дни, и отсортировали их по статусам. Получился дашборд, на котором в любой момент можно посмотреть, какие задачи мы успеваем сделать, а какие нет. Он помогает с краткосрочным планированием: сразу понятно, кому из редакторов можно подкинуть новую задачку, а кого пока лучше не трогать.

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

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

Впрочем, идея измерять входящие задачи в Story Points показалась нам неплохой. У нас уже было распределение задач по типам — мы решили взять его за основу и присвоить каждому типу вес в SP. На коротких дистанциях такой подход не работает.

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

Agile предлагает не соотносить SP со временем выполнения задачи, но в нашем случае было непонятно, что ещё, кроме времени, можно взять за мерило «трудоёмкости».

Как узнать, сколько баннеров в одном письме? Во сколько раз сложнее написать пресс-релиз, чем вычитать биографию профессора математики из Школы анализа данных? На эти вопросы у нас долгое время не было ответов. В конечном счёте мы решили, что самая объективная метрика для любой задачи на текст — это всё же время её выполнения.

Мы выгрузили из «Трекера» статистику по датам открытия и закрытия разных тасков, подсчитали среднее «время жизни» для задач каждого типа и перевели его в Story Points. В количество SP заложено время, которое редактор тратит на уточнение подробностей, встречу с командой, написание текста и согласование c заказчиком.

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

Мы подсчитали, что на это уходит около 30% времени в месяц — то есть на самом деле один SP составляет 0,7 настоящего часа. Таким образом, нормальное количество месячной работы для одного редактора — это количество рабочих часов в месяц минус отпуск и больничный умножить на 0,7. Сравнение нормального и реального показателей демонстрирует, кто из сотрудников перегружен или недогружен.

Все данные по сумме Story Points и статусам собираются на Agile-доске. На ней можно настроить любые фильтры — у нас это фильтр по сотрудникам и неделям. Доска показывает реальную загрузку всего отдела и конкретных редакторов в любой момент времени.

Разметка новых задач, включая проставление Story Points, — рутинное занятие, которое требует внимания и усидчивости. Тут на помощь снова приходят «Яндекс.Формы». Они позволяют добавить к каждому брифу дополнительные данные — в нашем случае это количество Story Points, теги и компоненты.

Эти данные подтягиваются в соответствующие поля «Трекера». Менеджеру больше не нужно тратить время на разметку задач — она проставляется автоматически.

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

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

#инструменты