Как я выстраивала работу продуктовой редакции

Всем привет! Я Даша, работаю старшим продуктовым редактором.

Полгода назад мне нужно было перестроить работу редакции. Я искала примеры других команд, но задачи большинства решались канбан-досками и гуглдоками. Компании такие инструменты не подходили, а мне хотелось больше автоматизаций. Рассказываю, как решала типичные задачи редакции, какие инструменты выбрала и что получилось.

Немного контекста. В команде 4 человека, мы готовим тексты для b2b-сервисов. Пишем релиз ноутсы, пользовательскую документацию, тексты для интерфейсов, сервисные и маркетинговые письма, кейсы. Большинство задач получаем от заказчиков — продактов и маркетологов.

Проблема. У нас были задачи без вводных, которые терялись в почте.

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

Все задачи заказчики присылали письмом на почту. Иногда ветки писем распадались, сообщения терялись, вести дела было неудобно. Дело в том, что продакты, маркетологи и юристы работают в разных системах. Почта — единственное место, где можно подключить всех смежных коллег.

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

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

Перед тем, как что-то изменить, я решила ответить на два вопроса:

• Чего хочет редакция? У редакции есть еженедельные встречи, где мы обсуждаем задачки, шутим шутки и делимся наболевшим. Из этих встреч стало понятно, что всем хочется улучшить качество вводных и уменьшить количество писем в почте.
• Чего хотят заказчики? У меня была гипотеза: хотят видеть дашборд со статусами своих задач, потому что с такими вопросами часто приходят в мессенджер. Чтобы проверить предположение, я составила короткий опрос для коллег. Вот пара ответов:

Ответ 1.

Ответ 2.

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

Когда появились четкое понимание проблем всех участников процесса, сформулировала решения:

• Организовать работу с заказчиками в едином таск-трекере. Заказчики смогут видеть статусы задач, а количество писем уменьшится.
• Составить брифы, которые заказчики будут заполнять перед постановкой задачи. Коллеги будут сразу давать базовые вводные, а редактор сможет быстрее погрузиться в задачу.

Перед выбором и настройкой единого трекера задач, я набросала в Фигджеме новый процесс работы. В нём описала роли, действия заказчиков и исполнителей, прописала этапы работы над текстом: что, где и как происходит. С тимлидом внесли немного правок и получили схему ниже:

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

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

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

Примерно за неделю я создала очередь, добавила команду, настроила интеграцию с Формами. На встрече с командой я познакомила ребят с системой и показала, как всё работает. Еще несколько дней мы вместе тестировали интеграцию и исправляли мелкие косяки. Если коротко, процесс получился таким:

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

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

Появилась единая система. В назначенный день мы отправили коллегам напоминание о переходе в трекер и начали получать задачи. За первый месяц в очередь редакции поступило больше 70 задач. Всё общение по задачкам тоже перетекло в трекер.

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

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

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

На весь процесс ушло около двух месяцев. Сейчас могу сказать, что на 90% получилось:

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

На 50%:

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

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

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

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

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

Если было полезно, буду рада лайку :) И, конечно, отвечу на вопросы и присмотрюсь к советам по делу.