Что мне помогает сокращать лидтайм

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

Расскажу, что мне помогает достигать результатов в этой метрике.

На всякий случай о термине. Лидтайм (Lead Time) — одна из ключевых метрик канбан-системы. Лидтайм — время между выполнения задачи от точки принятия обязательств до их исполнения в точке завершения работы.

Определить ключевые точки

Чтобы рассчитать лидтайм, мы определили точки принятия решения по задаче и ее завершения. Сначала это были этапы «Приняли в работу» и «Готово» — когда задача вышла на прод. Но система не работала.

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

Это еще не все.

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

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

Решение не идеальное, потому что в «Очередь» попадают задачи не только из запланированного бэклога, но и из-за вынужденного — когда у нас не хватает ресурсов взять задачу в работу «сейчас», но пока остановилась на таком. Буду еще обсуждать с деливери-менеджером, как лучше перестроить систему.

Теперь о конечной точке — когда задача считается выполненной. Тут тоже есть нюансы.

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

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

В сухом остатке: мы считаем лидтайм с этапа «Взяли в работу» (из бэклога) и он заканчивается, как положили задачу в «Ожидает публикацию». Но буду еще докручивать и додумывать.

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

Регулярно разбирать процессы по кусочкам

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

• Собрать процесс, прямо каждый этап за этапом, включая самые небольшие — что в нем происходит и сколько времени занимает. Можно хоть в гуглдоке, но больше подходят сервисы типа Miro, мне нравится Unidraw от Т-Банка.
• Найти точки, где тратится много времени или усилий. Бывает, что этап проходит быстро, но он съедает много когнитивного ресурса.
• Поковырять эти точки — что именно мешает? Как это выглядит? От кого зависит? Как можно на это повлиять?
• Сформулировать шаги — что именно мы сделаем, чтобы ускориться? Что меняем в своем процессе? Что меняем для заказчиков или других участников задачи? Что нам нужно узнать или в чем прокачаться? К кому сходить с вопросами?

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

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

Держать фокус на лидтайм

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

Создавать шаблоны, гайды и процессы

Я люблю гайды и описанные процессы, потому что они помогают укрощать хаос, делают работу прозрачной и понятной, но это отдельная тема. Важно, что для лидтайма это тоже все помогает. Как мы собираем процессы в редакции.

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

Другой пример.

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

Выстраивать понятные рамки для заказчиков

У нас в Т-Банке отличные заказчики: не могу сказать за всю компанию, но токсичных или агрессивных людей не встречала. Что гуд, но проблемы все равно есть.

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

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

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

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