Привет! Меня зовут Олег Игнатов. Сейчас я руковожу продуктовой аналитикой в 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 — приоритизация

Поговорим о приоритизации. У вас могут быть супер крутые процессы, командное взаимодействие и понятные задачки, но при этом вы будете постоянно крутиться в операционных задачах и не будете влиять на развитие (продукта/бизнеса/аналитики/чего угодно). 

Для чего нужна приоритизация? Буквально — что бы выбирать, что делать сейчас, что потом, а что вообще не делать (и удалить из бэклога). По сути, задач всегда будет много, много разных — операционных, стратегических, тактических. И нужно все время между ними выбирать. Тут важно — старайтесь всегда уделять время на каждый из трех типов задач. Потому что фокус на чем-то одном, неизбежно приведет к падению остальных двух, а следовательно — к дальнейшим проблемам. Парочка примеров:

• фокус на постоянном выполнении ad-hoc задач и прочей операционки приведет к вас к отсутствию фундамента для устранения причин возникновения этих самых задач, спустя какое-то время команда погрязнет в операционке, не будет развития и качественной работы, у людей будет выгорание

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

• отсутствие системной работы с развитием ваших сотрудников (а на это нужно уделять время) ведет к дальнейшему снижению качества результатов и выгоранию (опять?) сотрудников

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

Блок 5 — загрузка и Focus Factor

Реально произошедшая ситуация — срок выполнения задач постоянно не соблюдаются. Как же так? Ведь мы все распланировали, приоритизировали… Но мы забыли про загрузку. Ведь загрузка — это не только запланированные задачи на спринт (2 недели), верно? Это еще и текучка, поддержка дашбордов, встречи, работа с алертами на данные, административные дела и много другое. А все эти действия отнимают время. Сразу скажу — это не плохо, это абсолютно нормальная ситуация. Более того — странно, если этого нет)) Правда в том, что вы не понимаете сколько времени и когнитивной нагрузки это отнимает у ваших аналитиков. А раз не знаете, надо узнать, или говоря на современном языке «опрозрачить» регулярные активности

Для этого хорошо подойдет такой инструмент, как Focus Factor. Его мне посоветовал один продакт, который был явно недоволен сроками задач)) Как все работает? Очень просто:

• составляет опрос, на тему того «сколько рабочего в спринт вы уделяете на перечисленные активности»

• добавляете основные активности, которые есть у вас в компании/команде/отделе, обязательно даете возможность написать свой вариант (вдруг еще что-то есть)

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

• отправляете на всех своих сотрудников

• просите всех пройти и потом смотрите на результаты

Первый раз, когда я запускал опрос, выяснилось, что в среднем 50% времени уходит на какие-то регулярные активности. То есть по факту, аналитики только 5 дней могли работать над задачами из спринта! Это стало важным сдвигом в нашей работе, мы всем стейкхолдерам опрозрачили загрузку, стали планировать задачи с учетом ограничения загрузки. И все действительно стало лучше, ведь это привело к тому, что заказчики знают какой объем задач будет и в какой срок.

Блок 6 — развитие и комбинации

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

• понимать, что мотивирует ваших людей и куда им хочется развиваться

• знать цели компании, вашего подразделения и команды

• изучить слабые и сильные стороны сотрудников

• следить за рынком, развитием технологий и требований к скилламЭто все позволит подходить к развитию людей как к комплексной системе, состоящей и различных узлов. Приведу пару примеров.

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

2. От руководства есть запрос на разработку определенного слоя поведенческих метрик. В таком случае кажется логичным отдать задачу сотруднику, которые идеально знает как формировать метрики. Или нет? Возможно стоит дать задачи аналитику, который неплохо понимает кор бизнес компании, то есть то, чем живут пользователи, которые находятся в нашем продукте. А работа с метриками как раз является зоной роста, которую поднять, с моей точки зрения, проще, чем разобраться в особенностях пользовательского поведения. Тут рискуем сроками (и риск случился), но в итоге результат тоже получился качественным, хоть и не быстрым.

3. Аналитик сам разбирается во всех нововведениях, связанных с AI. Компания тоже активно хочет идти в AI. Мир тоже двигается в синхронном направлении. А вот задачи у аналитика слабо связанные с ИИ. Что будем делать? Я попробовал не ограничивать в узнавании нового, взяв риск на чуть медленную реализацию задач вначале. Зато в итоге сотрудник очень круто разобрался с новыми инструментами, повысил свою скорость задач без снижения качества и бонусом поделился знаниями с другими аналитиками!В общем, как можете посмотреть, в каждом примере нет линейного прогресса «зона роста -> развитие». Есть просто система из различных факторов и состояний, в которой именно развитие конкретных навыков играет роль рычага, которые переводит решение задач и потребностей бизнеса и людей на более высокий и качественный уровень. Поэтому рекомендую именно так на развитие и смотреть — не линейно, а комплексно.

Блок 7 — как команда становится автономнее

После 1-1, беклога, ритуалов, приоритизации, загрузки и развития возникает логичный вопрос: а что меняется в роли лида?

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

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

Финальная мысль — порядок нужен не ради порядка, а чтобы у лида и команды появилось пространство для качественной и системной работы.