Как я выстраивала работу продуктовой редакции
Всем привет! Я Даша, работаю старшим продуктовым редактором.
Полгода назад мне нужно было перестроить работу редакции. Я искала примеры других команд, но задачи большинства решались канбан-досками и гуглдоками. Компании такие инструменты не подходили, а мне хотелось больше автоматизаций. Рассказываю, как решала типичные задачи редакции, какие инструменты выбрала и что получилось.
Немного контекста. В команде 4 человека, мы готовим тексты для b2b-сервисов. Пишем релиз ноутсы, пользовательскую документацию, тексты для интерфейсов, сервисные и маркетинговые письма, кейсы. Большинство задач получаем от заказчиков — продактов и маркетологов.
Проблема. У нас были задачи без вводных, которые терялись в почте.
Когда я пришла в команду, заказчики часто направляли задачи без контекста и вводных. Чтобы разобраться, мы ставили встречи и начинали работу с одинаковых вопросов: «что?», «кому?», «зачем?». Такой процесс всех устраивал, потому что задач было немного.
Все задачи заказчики присылали письмом на почту. Иногда ветки писем распадались, сообщения терялись, вести дела было неудобно. Дело в том, что продакты, маркетологи и юристы работают в разных системах. Почта — единственное место, где можно подключить всех смежных коллег.
Чтобы отслеживать нагрузку и статусы хотя бы внутри редакции, мы организовались в Ноушене. Здесь же расположили базу знаний и архив материалов.
Со временем коллег стало больше, количество задач выросло в 3 раза. На встречи по каждой задаче времени не хватало, а поиск писем в почте продолжал его отнимать.
1. Провела опрос, чтобы учесть пожелания всех сторон
Перед тем, как что-то изменить, я решила ответить на два вопроса:
- Чего хочет редакция? У редакции есть еженедельные встречи, где мы обсуждаем задачки, шутим шутки и делимся наболевшим. Из этих встреч стало понятно, что всем хочется улучшить качество вводных и уменьшить количество писем в почте.
- Чего хотят заказчики? У меня была гипотеза: хотят видеть дашборд со статусами своих задач, потому что с такими вопросами часто приходят в мессенджер. Чтобы проверить предположение, я составила короткий опрос для коллег. Вот пара ответов:
Ответ 1.
Ответ 2.
Гипотеза подтвердилась: большинство заказчиков хотят видеть сроки, стадию, исполнителя. Также коллеги не всегда понимают, что нужно знать редактору для работы над задачей. И еще несколько людей отметили неудобство писем.
Когда появились четкое понимание проблем всех участников процесса, сформулировала решения:
- Организовать работу с заказчиками в едином таск-трекере. Заказчики смогут видеть статусы задач, а количество писем уменьшится.
- Составить брифы, которые заказчики будут заполнять перед постановкой задачи. Коллеги будут сразу давать базовые вводные, а редактор сможет быстрее погрузиться в задачу.
2. Продумала и зафиксировала новый процесс работы
Перед выбором и настройкой единого трекера задач, я набросала в Фигджеме новый процесс работы. В нём описала роли, действия заказчиков и исполнителей, прописала этапы работы над текстом: что, где и как происходит. С тимлидом внесли немного правок и получили схему ниже:
3. Составила брифы и страницу для заказчиков
В нашей команде за каждым уже закрепились свои зоны ответственности. Например, у нас есть отдельный человек, которые отвечает за сайты и весь контент для них. Я попросила редакторов составить список базовых вопросов, которые они задают заказчикам для решения своих задач. Полученные списки перенесла в Яндекс Формы. В результате получилось шесть форм-брифов под разные задачи.
Брифы и описание процесса собрала на одной странице, чтобы любой из коллег мог поставить задачу.
4. Настроила трекер задач
Выбор трекера обсуждали с заказчиками. Вместе решили остановится на Яндекс Трекере. Трекер проходил по массе требований внутренних служб, а ещё большинство заказчиков уже когда-то работали в нём. Но вообще такой процесс можно реализовать в Джире и Асане.
Примерно за неделю я создала очередь, добавила команду, настроила интеграцию с Формами. На встрече с командой я познакомила ребят с системой и показала, как всё работает. Еще несколько дней мы вместе тестировали интеграцию и исправляли мелкие косяки. Если коротко, процесс получился таким:
- Заказчик заходит в Трекер, заполняет нужную форму и нажимает «Отправить».
- Задача с данными из формы автоматически попадает в бэклог редакции.
- Автоматически проставляются сроки, нужные теги, исполнитель, проект.
- Заказчик и исполнитель могут общаться и обмениваться файлами внутри задачи, призывать друг друга, менять статусы.
5. Презентовала процесс заказчикам
Когда всё было готово к запуску, позвала всех коллег на встречу. На ней рассказала про новый процесс, показала Трекер и как поставить в нём задачи, ответила на вопросы, собрала первую обратную связь.
6. Запустила в работу
Появилась единая система. В назначенный день мы отправили коллегам напоминание о переходе в трекер и начали получать задачи. За первый месяц в очередь редакции поступило больше 70 задач. Всё общение по задачкам тоже перетекло в трекер.
Заказчики стали давать больше информации при постановке задачи. Коллеги не всегда подробно заполняют брифы, но даже так мы получаем больше информации. Если раньше могло прийти письмо с файлом и комментарием «сделать вкусно», то теперь мы всё чаще видим описание ца, цели, каналы публикации, ключевые тезисы. Это не идеальное ТЗ, но оно позволяет быстрее понять заказчика, задать вопросы по сути и начать предлагать решения.
Работа редакции стала прозрачнее. Все заказчики и редакторы могут видеть свои задачи, их статусы, исполнителей и сроки. Например, так выглядит список задач, которые создала я:
Спустя несколько недель после запуска я настроила аналитику, чтобы было удобнее отслеживать загрузку редакции и равномерно распределять задачи.
7. Подвела промежуточные итоги
На весь процесс ушло около двух месяцев. Сейчас могу сказать, что на 90% получилось:
- Сделать работу команды прозрачнее — все видят сроки, статусы и исполнителей, заказчики не забрасывают письмами с вопросами.
- Уменьшить количество писем в почте — редко проскакивают весточки в мессенджер, но только если что-то очень срочное. В остальном всё общение по задачам проходит внутри трекера.
На 50%:
- Улучшить качество брифа на входе — стало лучше, но есть большой потенциал. Брифы не всегда подробные, часть полей заказчики могут пропускать и нам приходится возвращаться к вопросам из брифа в обсуждении.
Бриф — не волшебная таблетка. Мы изначально понимали, что нужна более глобальная работа по развитию культуры хороших текстов и работы с редактором. Нужно рассказывать, что это за люди, почему они вообще задают вопросы, а не отдают текст быстрее. Брифы стали маленьким шагом в нужном направлении.
Что дальше
Хочу провести повторный опрос заказчиков. Нужно посмотреть, как изменится удовлетворенность качеством и скоростью подготовки текстов. Пока только предполагаю, что показатели вырастут, т. к. они связаны с качеством брифов, которые стали информативнее. Также хочу замерить, как изменения отразятся на скорости выполнения задач и пропускной способности редакции.
Автоматизировать отдельные кейсы. Сейчас заказчик может в одной задаче попросить написать статью и опубликовать на сайте. Для редакции это две разные задачи — на текст и на верстку, за них отвечают разные люди. Чтобы задачи не терялись и грамотно учитывались, планирую сделать так, чтобы заказчик по-прежнему заполнял один бриф, но в трекер бы приходило две отдельные задачи.
Сделать фидбечницу. Планирую сделать общедоступную форму, в которую заказчики смогут в любое время написать свои идеи по доработке процессов. Будем брать наиболее популярные, обсуждать на общих встречах и внедрять.
Если было полезно, буду рада лайку :) И, конечно, отвечу на вопросы и присмотрюсь к советам по делу.