Привет! Я Юля, менеджер продукта в Тинькофф Кассе. Мы делаем интернет-эквайринг для бизнеса, и в разработке продукта участвуют 30 команд. При создании новой фичи какие-то команды могут действовать обособленно, но это редкость. В большинстве случаев командам при разработке нужна помощь друг друга. Расскажу, как у нас получилось сделать так, чтобы не было очередей из команд.

Как у нас стали тормозиться задачи

Наши команды делятся на три типа:

1. Продуктовые отвечают за свой продукт. Например, Tinkoff Pay и оплата картой — два разных продукта и две разные команды.

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

3. Сервисные команды ничего не разрабатывают, но всем помогают. В такие команды выделяем маркетинг, поддержку, продажи, дизайн, риски, аналитиков.

Раньше мы, Тинькофф Касса, планировали бэклог, опираясь только на сроки своей команды. Других команд было не так много, поэтому договаривались о помощи буквально за день и блокировок не возникало.

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

Картина выглядела так: команда 1 работает по своему списку задач, а команда 2 в процессе разработки понимает, что нужна помощь команды 1. Команда 2 приходит в команду 1 и умоляет о помощи.

В итоге команды злятся — «Не могли раньше предупредить!» — и путаются в задачах из-за резкого переключения контекста. Повышается Lead Time обеих команд, а сроки разработки становится сложнее прогнозировать. Есть ощущение бурной деятельности, но при этом задачи особо никуда не едут, все всеми заблокированы.

В этот круговорот страдания вовлекались 3—5 команд. Многие задачи делались с большой задержкой. Стало понятно, что дальше так жить не получится, подход к планированию пора менять.

Как появилось выравнивание

В 2022 году мы решили попробовать фреймворк OKR, Objectives and Key Results. В нем есть регулярные встречи: вертикальное и горизонтальное выравнивание.

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

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

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

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

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

Из чего состоит выравнивание роадмапов

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

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

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

Драфт роадмапа нужен, чтобы предметно общаться на встрече. Менеджер продукта должен подготовить драфт роадмапа на следующий квартал. Изначально задачи в роадмапе располагаются так, как предполагал продакт, но после выравнивания сроки могут сдвинуться.

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

Для записи есть слоты по 15 и 30 минут. Если в какой-то из слотов команда планирует отойти, она пишет в слоте «Занято», чтобы никто не пришел в пустоту. В середине дня — общий перерыв на обед.

Выбирая, к кому записаться, команды опираются на два принципа:

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

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

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

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

Если команда работает обособленно, у нее может вообще не быть встреч в течение дня. Самая популярная команда в нашей практике проводила 12 встреч за день.

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

Раньше мы собирались в Zoom, теперь встречаемся в Толке. Для Zoom нужна платная версия, чтобы не заставлять 50—100 человек перезаходить каждые 40 минут. 

Как вариант, можно создать отдельные встречи в Skype/Meet по числу команд и прикрепить ссылки в расписании. Главное — чтобы у каждой команды было пространство, куда к ним могут прийти поговорить другие. Это важно, чтобы сэкономить время на сборы: все в одном месте и в одном контексте.

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

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

Пример: команда продукта планирует запускать новый способ оплаты, релиз в октябре. Для запуска нужна помощь биллинга, дизайна и маркетинга. Команда продукта приходит в свой слот к каждой из трех команд и говорит, что от дизайна помощь нужна во второй половине августа, от биллинга — в начале сентября + e2e-тестирование, от маркетинга — в октябре. 

Каждая команда соглашается и вносит эти активности в свой роадмап, предлагает альтернативы или отказывается. Если кто-то отказал, уже за рамками выравнивания команда продукта привлекает руководителя и занимается переприоритизацией.

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

Шаблон таблицы раньше был сложнее, но в итоге пришли к трем простым пунктам:

• Название команды, с которой выравнивались.

• Кто от этой команды был на встрече (ФИО).

• О чем договорились.

Обновление роадмапа. Все новые задачи вносим в роадмап на квартал. Обновленную ссылку добавляем на общую страницу бизнес-линии, чтобы все заинтересованные команды могли посмотреть, что договоренности учтены — и учтены правильно.

Куратор встречи отправляет участникам опрос для сбора обратной связи: 

• насколько встреча была полезна;

• что понравилось;

• что не понравилось.

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

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

Что мы поняли по следам провалов

Мы относимся к горизонтальному выравниванию как к продукту, поэтому первые версии были далеки от идеала.

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

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

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

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

Можно предлагать другой слот для встречи. Часто было так, что команды записались на 30-минутный слот, но решили вопрос за 10 минут. До следующей команды еще 20 минут, крупные задачи не начнешь, на смену фокуса нужно много сил. 

Мы пишем другой команде — спрашиваем, готовы ли они встретиться пораньше. Чаще оказывается, что да. Так высвобождается больший временной слот для непрерывной работы. Потом мы добавили 15-минутные слоты, стало еще удобнее.

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

Заручиться поддержкой руководителей. Без нее мы бы не справились. В первую очередь запрос на изменения шел от топов бизнеса, поэтому мы получили добро на встречи на весь день на 50—100 человек. Более того, топы вовлечены и готовы подключаться, если у команд не получается разобраться самостоятельно.

Выводы

Мы живем в таком цикле планирования больше года. С выравниваниями OKR прошли три полных квартала, с выравниваниями роадмапов — два и спланировались на новый.

За это время наш Lead Time по 85-му перцентилю сократился на 15%, а количество выполненных задач увеличилось на 30%. За год команда сильно выросла, но при этом время доставки ценности уменьшилось. Это очень крутой результат, потому что обычно с ростом команды растут и сроки доставки. У нас был такой тренд, но нам удалось его переломить.

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

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

Считаем практику успешной и будем продолжать развивать ее в Тинькофф Кассе. Если у вас возникли вопросы или желание что-то обсудить — заходите в комментарии. Мы рады обменяться опытом и поделиться знаниями!