Зачем планировать на квартал, если есть цели на год?
Последнюю неделю сентября я каждое утро проводил на трехчасовых встречах Q4. На одном созвоне - до 20 продактов и много идей, что команды хотят сделать в следующем квартале.
Но главная задача таких встреч - не придумать побольше задач.
Мы смотрим, где пересекаются проекты, что стоит добавить, а что, наоборот, лучше убрать из планов. И отдельно проверяем формулировки: какого результата мы действительно хотим добиться?
Раньше в Т-Бизнесе OKR в основном ставили на год. Сейчас переходим к сочетанию годовых и квартальных целей.
Не потому, что любим чаще переписывать планы. Просто за несколько месяцев реальность может сильно измениться. Новые данные появляются, приоритеты сдвигаются, а некоторые ключевые результаты, увы, протухают, даже если год назад казались правильными.
Годовая цель задает направление, а квартал помогает решить, какой следующий результат действительно имеет смысл получить сейчас.
Например, один из наших OKR - адаптировать метрику Bad CX под специфику среднего и крупного бизнеса. Само направление за три месяца никуда не исчезнет. Но конкретный фокус меняется по мере того, как мы узнаем больше: сначала исследуем потребности клиентов, потом определяем критичные триггеры, затем решаем, где именно нужны новые «градусники» на клиентском пути.
То же самое работает с задачами. Если у нас уже есть несколько сильных гипотез из исследования, возможно, сейчас полезнее проверить их, чем начинать новое исследование с нуля.
Для меня хороший квартальный план - это не список того, что команда обязуется сделать. Это договоренность, куда она должна продвинуться за три месяца и почему именно туда.
А еще возможность честно сказать: «Мы собирались это делать. Но сейчас это уже не самое важное». Кажется, именно эта часть планирования часто сложнее всего.
Поделитесь в комментариях, как вы решаете, какие задачи стоит взять на следующий квартал, а какие пересмотреть с учетом новых приоритетов?
· 19.10
Андрей, у меня при планировании один фильтр: у цели должна быть защита от дешёвого способа её выполнить — и считается это в деньгах, а не в тикетах.
Например, цель — чтобы меньше клиентов доходило до второй линии поддержки. Самый быстрый способ «выполнить» её — перенести темы на первую линию и отчитаться. На бумаге поток ушёл, по факту причина осталась, а стоимость обслуживания темы на всех линиях вместе выросла: обращений не меньше, просто обрабатывает их больше людей. Поэтому в цель засчитывается только снижение за счёт устранения причины или self-service; перенос — отдельно и через процедуру: доступы, инструмент, скрипт, решение в первом контакте.
Проверки две. Стоимость обращений по теме на всех линиях вместе падает — и клиент это чувствует: повторных обращений по той же теме меньше, оценка решения не хуже. Если первое да, а второе нет — это сэкономили на клиенте, и оно вернётся следующим обращением.
После этого отбор на квартал почти механический: что снижает стоимость причины и не портит опыт — берём; что только двигает цифру между линиями — нет. И «мы собирались, но это уже не самое важное» говорить проще: такие задачи отпадают сами.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 19.10
Это очень крутой поинт 🔥
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 19.10
Станислав, а это чисто Ваш опыт и наблюдения или есть какая-то условная методология проверки решений? 🤍
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 19.10
Это комбинация подходов, к которой я пришёл опытным путём.
Три основы: Джон Седдон - Failure demand Билл Прайс - Лучший сервис это отсутствие сервиса Закон Гудхарта
Мне близка такая философия: "Если клиенту пришлось обращаться - это недоработка продукта."
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· вчера
Спасибо огромное 🙏🏻 🤍 ✨
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён