Привет! Я — Лиза, тимлид группы продуктовых редакторов в Авито. Ещё год назад никто из нашей команды не планировался по неделям. А сейчас уже больше половины редакции — 14 человек из разных продуктовых направлений — перешли на спринты.

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

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

1. Перегруз

Год назад я была редактором в Авито Работе. Количество и объём задач постоянно росли: запускались новые и менялись существующие продукты, и для всех я писала интерфейсы и маркетинговые тексты. До найма второго редактора оставалось ещё несколько месяцев, и нужно было придумать, как справиться с потоком задач. Если сократить его нельзя, то можно хотя бы приручить.

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

Всё началось с эксель-таблички

Я ввела простую систему: задачи на следующую неделю принимаю до пятницы текущей. Так образовались недельные спринты.

Каждую задачу я стала оценивать в сторипоинтах (SP). Оценка основана на количестве рабочих часов. На каждый спринт я выделила 30 SP — это работа над задачами. Оставшееся время можно тратить на встречи, редакторские гайды, помощь коллегам с текстами или обучение.

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

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

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

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

Отдельно радуюсь, что Лиза улучшила процесс планирования своей загрузки, создав приятную инструкцию для заказчиков и правила приоритизации тасок.

Отлично налажен процесс взятия задач в спринт. Собственная табличка на которой видны оценки и порядок задач — топ! Всегда укладывается в обозначенные сроки. По качеству и скорости работы с задачами чат-бота нет никаких нареканий.

Здорово, что Лиза начала работать по спринтам — это делает работу ещё более прозрачной. Теперь есть понимание, какие задачи «влезли» в спринт, а какие — нет. И какие, при необходимости, можно подвинуть, чтобы сделать что-то срочное.

Онбординг в новые правила

В ревью мне написали и о том, что можно улучшить:

Пожелания:

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

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

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

2. Работа с разными командами и приоритизация

У меня было несколько продуктовых команд, каждая из которых планируется по двухнедельным спринтам, а ещё маркетинг. Ходить на такое количество встреч-планирований и обсуждать приоритеты невозможно.

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

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

1. Редактор подсказывает, какая из задач выглядит менее приоритетной и с кем есть шанс договориться.

2. Продакт смотрит спринт редактора и сам определяет, кто из его коллег согласится подвинуться.

3. Продакт двигает другую свою задачу ради более срочной.

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

Второе решение такое. В каждом спринте 5 из 30 SP забронировано на срочные непредвиденные задачи. В идеале это время нельзя занять заранее. Но если ни одну задачу перенести не получается, я отдаю эти сторипоинты на новую таску ещё до начала спринта.

3. Поздно пришли к редактору

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

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

С планированием ко времени редактора начинают относиться внимательнее. Больше никто (разве что иногда) не прибегает за текстом в последний момент. Ваша работа становится прозрачнее для других. У коллег не будет повода думать, что вы из вредности отказываетесь посмотреть три строчки текста прямо сейчас.

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

Так мы делаем поток задач более контролируемым.

4. Неравномерная нагрузка

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

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

5. Неадекватная оценка своих сил

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

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

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

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

6. Нет статистики по времени на задачу

Если не оценивать задачи, у вас будут данные только об их количестве. Но они не очень полезны: например, 30 задач на тексты за месяц — это много или мало для одного редактора?

Над одной задачей можно работать и 30 минут, и 2 недели. Логичнее смотреть на сторипоинты. Если у редактора их стабильно больше 600, это повод задуматься о его нагрузке. А статистика пригодится, чтобы обосновывать новые ставки.

Мы фиксируем сторипоинты в трёх видах. Вот как они описаны в гайде по составлению спринта:

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

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

Когда такое планирование не сработает

— Если у вас короткие сроки запуска продукта и никто не будет ждать неделю, чтобы занять ваше время. Тогда, возможно, надо синхронизировать спринт с продуктовыми командами, планироваться чаще (например, раз в 2 дня) или придумать другие способы обуздать поток задач.

— Задач много, но никто не согласен их переносить в пользу других. В этом случае я иду искать более свободного редактора, который сможет подхватить часть работы. Если такой опции нет, а проблема возникает постоянно, можно подумать о более долгосрочном планировании. А также договориться внутри, какой процент времени редактора занимает каждая команда.  

Предыдущая статья: Как и зачем тестировать код на бэкенде: рекомендации для новичков