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