Привет! Меня зовут Олег Игнатов. Сейчас я руковожу продуктовой аналитикой в Garage Eight. До этого я строил продуктовую аналитику в Литрес. Параллельно преподаю продуктовую аналитику в ВШЭ, менторю аналитиков и руководителей и веду свой канал.
За это время я проходил похожий путь: от небольшой группы аналитиков, где многое держится на личной вовлечённости руководителя, к многоуровневой аналитической функции. И оба раза наблюдал одну и ту же историю. Человек становится лидом и продолжает действовать как самый ответственный аналитик в команде: берёт больше задач, помогает всем, закрывает сложные вопросы и старается держать всё под контролем. Какое‑то время это работает. Затем бэклог продолжает расти, сроки становятся менее предсказуемыми, команда перегружается, а сам руководитель постепенно превращается в главное узкое место системы.
В этой статье я разберу практические инструменты, которые помогли мне перейти от ручного управления к более автономной команде: регулярные 1–1, ревизию бэклога, командные ритуалы, приоритизацию, Focus Factor и развитие аналитиков через реальные задачи. Я не буду пытаться описывать идеальный процесс из учебника. Это скорее набор подходов, которые я проверял на практике и которые помогли мне уйти от хаоса.
Блок 1 — с чего начать?
Первое с чего бы я начал — с людей и с восстановления базовой управляемости. Самый простой и часто недооцененный инструмент на этом этапе — регулярные 1–1 встречи с аналитиками. Если вы только начинаете, разумный старт — раз в 2 недели, далее частоту можно адаптировать.
Важно понимать — цель 1–1 не просто поговорить (хотя я иногда это практикую, полезно). Это способ перестать управлять командой вслепую, и получить реальное представление о том, в каком состоянии вы находитесь. На этих встречах имеет смысл обсуждать не только текущие задачи (даже больше — им стоит уделять меньше времени, ведь для этого есть другие встречи), но и ограничения, в которых работает человек: что ему мешает, чего не хватает, какие вопросы остаются без ответов.
Лично у меня на практике именно в таких разговорах всплывают вещи, которые напрямую влияют на работоспособность. У кого‑то банально не хватает ресурсов и инструментов (реально, у аналитика был старый ноут, который просто не тянул запросы к базе данных и обсчет кода в юпитере). Кто‑то не до конца понимает как устроена компания и кто за что отвечает. А иногда у сотрудника просто тяжелый период, из‑за которого его фактическая доступность сильно ниже ожидаемой.
Пока у вас нет этого понимания, любые разговоры про приоритеты, оценки задач и предсказуемость будут опираться на иллюзии, а не на реальную пропускную способность команды. Регулярные 1–1 помогают выстроить доверие и дают вам (лидеру) базовую картину по:
реальной доступности и нагрузке команды
текущему уровню навыков и зонам роста
ожиданиям команды от вас и от компании
состоянию и готовности брать на себя новые задачи
скрытым ограничениям, которые невозможно увидеть в таск‑трекере
Разумеется, это не решает все проблему сразу, но без этого шага дальше тяжело двигаться системно.
Блок 2 — бэклог
Когда появляется понимание реального состояния команды, следующим узким местом для меня является бэклог. Почему? Люди у нас есть? Есть. Ограничения понятны? Ну вроде да. А перегруз остается))
Что вообще такое бэклог? Когда он для меня был списком задач. С опытом мое понимание расширилось. И теперь для меня бэклог — это список ожиданий, изменений и возможностей. А еще он динамичный, потому что он постоянно меняется. Задачи устаревают, чьи‑то ожидания так и остаются ожиданиями, новые возможности не появляются. А устаревшая задача — признак ложных ожиданий, давления и будущего перегруза. Команда может работать на пределе, а беклог продолжает расти. Вы смотрите на график задач, уходящий вправо и вверх и напряжение нарастает.
Ну хорошо, это все понятно. А чего делать то? Ответ — проводим ревизию беклога, «чистку». Возвращаем управляемость и предсказуемость. Очистка беклога — это необходимость и адекватность по отношению к команде и стейкхолдерам. Очистка беклога — не просто удаление задач и наведения порядка (хотя это приятно), не отказ от ответственности. Тут я больше имею ввиду некую «пересборку» ожиданий, то есть вы таким процессом и действиями выравниваетесь между своими стейкхолдерами в рамках ожиданий и возможностей друг друга.
Для ревизии можно использовать разные подходы. Я пользуюсь логикой «устаревания». Если задача лежит больше года — это странно. Мир динамично меняется, поэтому исходные условия для задачи год назад явно не будут соответствовать текущим. Для таких задач я предпочитаю жесткую позицию — удаляем и одновременно сообщаем об этом стейкхолдеру, лучше даже со своим мнением по этой задаче. Если задача важная — он вам скажет и вы ее обновите заново с учетом новых реалий.
Задачи давностью от 3 месяцев до года проговорите — это вопрос прозраности и управляемости. Наверянка у каких‑то задач изменился статус или ситуация для их реализации. Заодно, так вы показываете, что есть движение и происходит рост доверия.
К задачам младше 3 месяцев вернемся в следующей серии через регулярные командые ритуалы, сейчас важнее сделать этот процесс регулярным. Одна пересборка даст вам кратковременную передышку, но на этом все. Смотрите, регулярность важнее идеальности. Беклог нельзя почистить один раз, помните, он динамичен. Его нужно регулярно пересобирать.
Тут у меня есть просто парочка советов:
ставьте в календаре регулярный «focus time» на пересборку, одного раза в 2 месяца хватит
у задач бывают дубли, причем более интересны «косвенные» дубли — это задачи про одно и тоже, но от разных стейкхолдеров, аналитика может закрывать несколько ожиданий одним решением
Блок 3 — командные ритуалы
Проверяем, что на это этапе у нас:
есть 1–1 с сотрудниками
есть беклог, синхронизация со стейкхолдерами по ожиданиям
Давайте разберемся с командными встречами (или ритуалами или мероприятиями). Проще говоря со всеми дейликами, PBR, Retro, грумингами, планированиями. Может есть еще что‑то, но я ограничиваюсь 4, давайте разберем их:
PBR (кажется раньше это было грумингом) — просто разбор задач. Задачи ставятся всегда по‑разному. Можно от всех требовать порядка и аккуратности в заполнении задач, но такое происходит редко. На PBR (Product Backlog Refienment) вы уточняете задачу, декомпозируете ее на составляющие, понятные вашим сотрудникам, указываете оценку, приоритет, исполнителя, DoD (описание полученного результата) и делаете ее готовой к выполнению.
Daily standup или дейлик. Он должен быть коротким (минут 15) и ежедневным. Сейчас у меня он 25 минут, но из‑за кучи встреч бывает не регулярным. Пожалуйста, не делайте дейлики длинными и с кучей людей, очень быстро теряется контекст, люди устают и смысл встречи теряется. А он как раз в быстрых и легуряных синхронизациях, что бы быть в курсе апдейтов по задачкам.
Планирование — тут все просто. По сути после PBR, задачки готовы к взятию в спринт (мы же любим спринты). И вот на планировании мы еще раз обговариваем приоритеты, и финально уже ставим точку в треугольнике исполнитель‑срок‑результат. То есть, после планирования всем должно быть однозначно понятно:
кто делает задачу
когда ожидать результат
какой будет результат
Retro. Для меня это встреча, на которой мы с командой проходимся по результатам (задачи, спринта, квартала, чего угодно) в 3 этапа:
обсуждаем, что у нас получилось хорошо
обсуждаем, что у нас не получилось или к чему есть вопросы
решаем, что делаем с возникшими вопросами, в каком приоритете и кто что будет делатьЗнаю что у многих команд эта встреча идет раз в спринт, но я вообще этого не понимаю. Не верю что за две недели можно собрать какие‑то вопросы, решить что делать, а главное успеть решить вопросы за короткий срок. Для меня раз в квартал/полгода кажется это вполне адекватным.
Ну вот, собственно эти 4 процесса и нужно внедрить в своей команде на регулярной основе. Как? Поставить встречи. Если не можете сами, попросите скрам мастера (процессного менеджера) или можете другого лида попросить, у которого эти процессы уже поставлены. И постепенно будете через процессы оттачивать ваше командное взаимодействие.
Разумеется, это не все! Блоки 4–7 рассмотрим через неделю!
