Планирование «тетрисом». Или контроль за «впихиванием» обязательств «сделать к сроку»

Меня зовут Юлия Буланова, я работаю руководителем продукта «Сторителлинг» в Альфа-банке.

Не важно, на каком этапе Agile-пути вы находитесь: работаете по SCRUM, либо по Kanban, потому что перед вами все равно встанет вопрос, что нужно контролировать ресурсы, загрузку и процессы.

Расскажу про методику производственного планирования, пришедшую к нам из теории ограничений.

Какие проблемы в компании привели к планированию «тетрисом»

Я пришла в Альфа-банк в 2018 году. Тогда как раз был взят курс на развитие цифровых каналов и взаимодействие с пользователем через них.

Из-за этого начало активно расти количество команд – их становилось все больше и больше, как грибов после дождя.

Если в компании 5-10 команд, они еще могут жить по своим собственным процессам, При этом неважно, какой у команды воркфлоу, как она взаимодействует внутри себя. Вы даже можете успевать заниматься микроменеджментом в этих командах.

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

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

• «Сколько задач мы сделаем за полгода или за год?» С планированием на спринты у SCRUM-команд проблем, как правило, не возникает, но среднесрочное и долгосрочное планирование хромало.

• «Я пришел в новую команду, как она работает?» Нужно было повысить прозрачность процессов, так как переходя из команды в команду, либо приходя на работу в Альфа-банк, сотрудники тратили много времени на погружение. Им нужно было за короткий срок понять, как команда работает, какие у нее есть мероприятия, куда бежать, если что-то случилось.

• «Сколько нужно разработчиков, чтобы выполнить новый проект?». Попутно были вопросы о том, нужно ли добавлять мидл-разработчика в команду на проект, либо на постоянной основе.

Мы коммитились на огромное количество задач и жестко овертаймили. В результате чего сотрудники выгорали.

А если были интеграционные проекты, где были задействованы несколько команд, сроки ехали по всем проектам.

Решение

Мы не изобретали велосипед. Методика планирования «тетрисом» была апробирована в другом российском банке и очень хорошо себя зарекомендовала.

На слайде показано, как выглядит сам «тетрис» – он реализован в виде плагина к Jira.

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

Что мы видим в «Тетрисе», и как им пользоваться?

«Тетрис» – инструмент среднесрочного или долгосрочного планирования. Расскажу, как метод работает на практике:

• В левом столбце выгружен продуктовый бэклог, отсортированный по приоритету.

• Колонки таблицы – это компетенции, которые присутствуют в ваших ИТ-командах.

• Цифры в таблице отображают оценку времени, затрачиваемое конкретной компетенцией на конкретную задачу.

• В первой строке после шапки – общая временная мощность специалистов данной компетенции.

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

• Справа – график, где по оси X перечислены наши компетенции, а по оси Y – наши «ресурсные стаканы». Таблица каждого «стакана» кликабельна – подсвечивая определенный квадрат, мы понимаем, к какой задаче он относится.

В результате получаемых расчетов мы можем оценить наши ресурсные возможности на каждую задачу:

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

• Задачи, которые находятся на пересечении красной линии – это значит, что мы начнем делать задачу, но точно не закончим. Если задача не влезает хотя бы в одну из компетенций, она не влезает во всю команду.

• Задачи выше красной линии – это те задачи, к которым мы в принципе не успеем приступить.

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

Дополнительная математика, заложенная в «тетрис» – это возможность расчета мощности команды в зависимости от месяца к месяцу.

С чего начать подготовку к переходу на «тетрис»

Что нужно было сделать, чтобы в принципе начать пользоваться «тетрисом».

1. Унифицировать процессы. SCRUM-мастера считают, что каждая команда уникальна и должна жить на внутренних договоренностях, а мы не можем ей мешать и навязывать какие-то процессы. Но если вы работаете в большой корпорации, этот подход не работает, поскольку собрать статистику и проанализировать 70+ команд – это трудоемкая задача. Поэтому унифицируем процессы:

• договариваемся о том, какие статусы будут у наших сущностей;

• решаем, как будем работать с досками;

• прорабатываем статусную модель.

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

• User Story – это задача, которая приносит пользу либо клиенту, либо банку;

• Spike – это задача на исследование и т.д.

3. Оценка сущностей. Мы учим команду оценивать сущности в майках. Майки – это аналог стори поинтов для бизнес-сущностей, то есть достаточно верхнеуровневая оценка. Чтобы ее получить, мы задаем команде простой вопрос: «Сколько времени вы потратите на реализацию задачи, если вас никто не будет отвлекать?»

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

Мы составили для себя общий флоу:

• EPIC – это уровень эпиков, на котором мы фиксируем свои проекты.

• US – это уровень юзер стори, наш продуктовый бэклог, на котором мы можем мерить показатели Time to market и Time to lead. Чтобы становиться лучше, нам нужно хотя бы понимать, где мы сейчас: унифицировав процессы, мы можем получить точку отсчета.

• Sub-Task – это доска, на которой живет наша команда разработки.

Сущности декомпозируются – эпики декомпозируется до юзер сторей, а стори декомпозируются до технических тасков.

Sub-Task’и у нас типизированные – в «тетрисе» они заводятся с определенной компетенцией. Благодаря этому, мы знаем, сколько времени каждая компетенция тратит на задачу.

Нюансы

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

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

• У нас в компании спринт разделен на продуктовые задачи и задачи на развитие, либо работу с техдолгом. Мы это называем задачами центров компетенции. И на них мы тоже закладываем определенный процент времени.

• «Я только спросить». Любимая история, когда ваших сотрудников отвлекают телефонными звонками или просьбами что-нибудь показать, рассказать и так далее.

Получается, что наши сотрудники работают над продуктовыми задачами 60-70% времени. Этот расчет также учитывается в «тетрисе».

Расскажу, как мы согласовали размер маек.

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

Месяц – это максимально возможная задача.

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

Дальше необходимо было перевести их на «тетрис».

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

Чего больше всего боятся команды? Что мог показать «тетрис»? Если вспомнить «ресурсные стаканы», по ним было видно, что далеко не каждая компетенция загружена на 100%. Поэтому самый большой страх, с которым мы работали, – чтобы не происходило миграции кадров и в случае недозагрузки специалиста его не передавали в другую команду.

Процесс перехода состоял из следующих этапов:

• Мы проводили анализ процессов.

• Составляли карты перехода.

• Переводили команды на «тетрис».

• Чтобы переход происходил наиболее безболезненно, организовали базу знаний в Confluence и оперативный чат с деливери-менеджером. Если вы решите трудоустроиться в Альфа-банк, один из обязательных курсов, которые вам нужно будет пройти, – курс по «тетрису». Вы сразу будете погружаться в процессы нашей работы.

Что нам дает применение «тетриса»

С переходом на «тетрис» команда:

• декомпозирует задачи в соответствии с новыми процессами – она бьет их примерно равными инкрементами;

• оценивает задачи в майках;

• нажатием кнопки получает «тетрис» – мы сделали плагин для Jira, который нажатием одной кнопки выгружает информацию «тетриса» в Excel.

«Тетрис» – это инструмент планирования на большом объеме задач. Потому что оценка, которую мы даем в майках, достаточно верхнеуровневая: погрешность может доходить до недели.

Команда все равно какую-то задачу команда сделает быстрее, а какую-то – медленнее. На большом объеме задач у вас этот процесс сгладится.

«Тетрис» не подходит для планирования спринта.

В результате расчета «тетрисом», мы можем посмотреть:

• загрузку отдельных компетенций;

• загрузку каждой команды;

• загрузку в рамках направления.

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

В результате внедрения «тетриса», мы смогли построить обоснованный диалог между бизнесом и ИТ. Мы уже не нанимаем разработчиков субъективно – мы уже точно знаем, какие компетенции будут задействованы в новом проекте. Мы понимаем дату, к которой мы должны будем реализовать этот проект. Забивая эти данные в наш «тетрис», мы получаем количество ресурсов, которое нам потребуется.

Вопросы

Вы говорите, что «тетрис» – не инструмент планирования спринта, но есть те же самые стори поинты (вы их называете «майки»). В чем тогда прелесть «тетриса»?

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

А на каком этапе происходит оценка?

На этапе бизнес-сущности, когда мы решаем, как мы можем разбить проект на юзер стори.

То есть разработчики еще не подтвердили, что это 5 маек или 6 маек? Кто-то оценил юзер стори, и мы считаем, что этого достаточно?

Команда разработки оценивает юзер стори и да, этого достаточно. За счет того, что мы где-то профакапим, и срок у нас расширится, а где-то, наоборот, сделаем задачу быстрее. Именно из-за того, что у нас уже есть готовые компоненты, на большом объеме задач у нас сглаживается оценка.

Мне кажется, что это то же самое планирование спринта, только на юзер стори.

Если вы будете делать «тетрис» на планирование спринта, то в рамках года вы потратите сотни часов на декомпозицию и оценку вашего бэклога? А на юзер стори это займет максимум 2 часа.

Получается, что методика «тетриса» – более упрощенная для планирования спринта?

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

Какие примеры компетенций вы закладываете в «тетрис»? Что именно вы под этим подразумеваете? Как вы можете сопоставить компетенции с теми задачами, которые понадобятся? Всегда остается неопределенность. Не всегда можно точно знать потребность. Даже не всегда можно знать технологии, с помощью которых будешь реализовывать задачу – только при детальном подходе это можно оценить реально.

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

Соответственно, то, что мы сейчас закладываем, это то, что есть сейчас в команде.

Это технические знания или в общем?

Это в целом те компетенции, которые сейчас используются в команде. У нас SCRUM-команды и каждая команда обладает полным составом компетенций, чтобы приносить пользу.

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

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

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

Приведу пример. Есть компетенция, которую выполняют за 1,5 часа. Человек зная, что его измеряют, понимает, что ему нужно чуть дольше в следующий раз делать задачу, чтобы на него не давили. Он будет думать: «Сделаю-ка я помедленнее, потому что меня измеряют». Т.е. когда вы будете его действия замерять, сотрудник, зная это, будет специально делать все медленнее, чтобы увеличить оценку до 5 часов.

Когда мы строим «тетрис», то делаем его на основе ретроспективных данных. А поскольку команда работает по SCRUM-у, то, естественно, у них есть ежедневные ДСМы – т.е. каждый день задачи чекаются.

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

Эта история динамическая. От квартала к кварталу, время, затрачиваемое компетенцией на задачу, может варьироваться.

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

Компетенции у разных команд одинаковые по таймингу или нет?

Нет, от команды к команде. Мы не сравниваем команды между собой. Мы сравниваем команду с самой собой.

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

Так работает, если вы начинаете команду очень жестко контролировать. Если вы начинаете на этом акцентировать пристальное внимание команды.

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

Как часто вы пересчитываете высоту столбцов в «тетрисе»? За полгода можно очень сильно поменяться по компетенциям.

Мы пересчитываем «тетрисы» раз в квартал.

Каким образом преодолевали сопротивление снизу и сверху при внедрении «тетриса», если оно было?

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

Откуда пришла инициатива внедрения «тетриса»? Это же серьезное изменение, почти революция.

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

Мы адаптировали этот инструмент под свои процессы. Это переиспользование и адаптация положительного опыта.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.