Часть 1.

Продуктовая команда в большой компании - это отдельный “биом”, вовлечённый в массу процессов. Тут тебе и задачи бизнеса, и постоянная работа по поддержанию актуальности IT-ландшафта, и профессиональные коммьюнити, и персональное развитие каждого инженера. В таком потоке действительно легко упустить что-то важное, словив подспудно вайб “лоскутного одеяла” - ресурсы уходят туда и сюда, а в рабочей неделе всё ещё 40 часов. Что делать тимлиду в подобной ситуации? Как структурировать эту лавину и опрозрачить для команды не просто список того, что нужно сделать, но и придать всему этому какую-то форму, при этом не уходя в жёсткий табличко-менеджмент?

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

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

На первом шаге необходимо кластеризовать все активности и процессы, в которые вовлечена команда. Как правило, делается это на любой интерактивной доске со стикерами (Miro, Unidraw - тысячи их). Выписываем кучкой OKR бизнеса, стратегические цели, каскадированные на команду, техдолг, зоны роста - на выходе получаем “выгрузку” всего, что команде предстоит сделать за выбранный период. Пересекающиеся по смыслу и зонам ответственности активности паркуем в один “кластер”, по ходу дедуплицируя стикеры и выделяя связи между ними - блокировки, точки приложения усилий, дающие максимальный буст в закрытии других стикеров. На этом же шаге выделяем активности, закрытие которых на уровне команды может поспособствовать закрытию целей вышестоящих подразделений - подобные задачи станут отличным вызовом для инженеров, стремящихся расширить свою зону влияния.

На следующем шаге визуализируем полученные “кластеры” в виде направлений (стримов) работы. Примером таких стримов может стать работа с надёжностью или качеством, улучшение клиентского опыта, IT-ландшафт, улучшение delivery-метрик или показателей эффективности команды. Инструментом визуализации стримов в моей команде является OnePager - разводящая страница, на которой каждый стрим представлен в лаконичном блоке, содержащем общую информацию о стриме, его целях на выбранный период, а также координаторах, ответственных за достижение целей стрима (о координаторах поговорим чуть позже). OnePager становится единой точкой входа в цели команды, отражением её планов на грядущий период.

Помимо блока на OnePager-странице, под каждый стрим заводятся вспомогательные страницы, содержащие бэклог идей по стриму, роадмап с задачами и статусом работы над ними, Meeting Notes и другие полезные источники информации, структурирующие работу и дающие прозрачную картину происходящего в стриме.

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

Подробнее о роли координатора и о том, как “продавать” её членам команды, поговорим во второй части поста.