🗓 Квартальное планирование
На этой неделе у нас в Яндекс 360 прошло очередное планирование. На нем примерно 150 человек и 20 команд пытаются понять, что они будут делать следующие три месяца. Процесс сложный, немного выматывающий, но очень интересный.
🗂 Сбор бэклога и капасити
Примерно за 2 недели до планирования начинает формироваться бэклог — список задач, которые мы потенциально можем взять. Задачи приносят продакт, техлид и другие команды. Плюс к этому часть задач можем переехать с предыдущего квартала.
Чтобы не забивать на техническое развитие, в бэклоге должно быть определенное соотношение продуктовых и технических задач.
Каждую задачу нужно оценить в днях дизайна, разработки и тестирования. Точность оценки зависит от степени проработки задачи — где-то уже есть дизайн и описание API, а где-то только тех. задание.
Еще у команды есть ограниченные ресурсы дизайна, разработки и тестирования. Для них рассчитывается капасити (емкость) с учетом отпусков, дежурств, созвонов и т. д. Объем бэклога больше, чем команда реально способна переварить — просто потому что часть задач может отвалиться на следующих этапах.
🤝 Согласование бэклогов
Когда бэклоги команд сформированы, начинается самое интересное — нужно согласовать их друг с другом. Происходит это на общем созвоне, где десятки курсоров бегают по доске в Miro и раскладывают стикеры на табличке со спринтами (скрин выше). У каждой команды своя комната в зуме — по ним можно ходить и разруливать связанные задачи.
Кроме задач прописываются риски — факторы, которые влияют на выполнение задачи. У каждого риска есть причины, последствия и возможные решения. К примеру, это может быть нехватка каких-то ресурсов, из-за чего могут поехать сроки и команда не уложится дедлайн. Для такого случая можно придумать разные решения — нанять новых людей, взять на время из других команд, взять аутстафф, изменить ТЗ — и у каждого такого решения есть свои плюсы и минусы.
В финале команды представляют свои планы стейкхолдерам, получают фидбек и могут скорректировать их по этому фидбеку.
🎯 Удается ли уложиться в сроки?
Квартал состоит примерно 6 спринтов, из которых планируется в норме только 5. Шестой спринт нужен для того, чтобы добить хвосты и подготовиться к следующему планированию.
Часть задач так или иначе съезжает на следующий квартал, либо целиком, либо в виде доработок, но с каждым разом процесс совершенствуется и, надеюсь, попадание будет более точным.
Например, в первом квартале мы допустили ошибку, запланировав на меня задачи наравне с другими разработчиками, из-за чего мне не удалось уделить достаточно времени найму и работой над процессами. Во втором квартале мы это пофиксили, благодаря чему удалось нанять троих разработчиков и немного улучшить процессы.
Также теперь мы чуть раньше начинаем проработку задач, запланированных на квартал — сразу после планирования я смотрю какие вопросы можно решить в самом начале, чтобы потом это не стало блокером — согласовать контракты API, доступы и т. д.
Если интересна тема, можно погуглить про PI-планирование и Scaled Agile Framework (SAFe).