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

Я Наташа, менеджер проектов в Selectel. Уже дважды я выносила спринты из команд ногами вперед, и хочу поделиться этим опытом с теми, кто ищет предсказуемости и результативности в сложных технических продуктах.

Это база

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

• владелец продукта тщательно приоритизирует бэклог;

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

• на планировании спринта достаточно лишь перетянуть нужное количество стори поинтов в спринт;

• у спринта есть цель: команда вместе работает над конкретной фичей или итерацией, которую можно в конце показать как завершенную единицу работы;

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

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

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

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

В чем проблема

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

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

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

Чистим карму от карго-культов

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

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Спринты вне скрама

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

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

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

Дейлики, стендапы, любименькие

Если вы менеджер, скажите честно: зачем вам нужны ежедневные якобы 15-минутные созвоны? Шарить контекст, мотивировать с утра пораньше команду, быстро снимать блокеры? А может контролировать, что все проснулись и начали работать?

Контекст, блокеры, мотивашки отлично решаются в письменном виде. Канал со стендапами — это как фоллоуап, который написал себя сам. Неочевидные бенефиты:

• пока человек пишет, он визуализирует свои планы и рефлексирует прошлый день;

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

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

Ретро

Ретроспектива как командная встреча стала наиболее популярна с расцветом скрама и преследовала конкретные цели: 

• выявить проблемы итерации, 

• предпринять действия, чтобы исключить эти проблемы в будущем.

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

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

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

Если не пытаться присобачить спринты (и вообще скрам) там, где это невозможно, и внедрить хотя бы некоторые классические подходы PM, ретроспективу можно построить вокруг работы с рисками: 

• какие риски мы предусмотрели заранее, 

• какие фактически произошли, 

• как мы решили эти проблемы,

• чему новому в итоге научись.

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

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

Грумминиги

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

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

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

А делать-то что?

Нанять аджаил-коуча или скрам-мастера! :)

Много лет назад у меня в команде был такой симптом — не закрывались спринты. И я стала думать, а как сделать чтобы закрывались. Читала про скрам, внедряла ретро, мы думали, меняли скрам на канбан и обратно. Это была ошибочная тропинка. Думать надо было, не как спринты закрывать, а как добавить в команду порядка и предсказуемости. Улучшить именно спринты – не самоцель.

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

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

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

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

1. Определяю цели на год

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

2. Выбрасываю все, что мимо кассы

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

3. Сортирую выживших

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

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

Что дальше

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

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

Всем крутой недели и порядка в проектах! Если зацепила за живое, пишите в комментарии.