Ситуация: в Scrum-команде процессы работают как по книжке — задачи закрываются за 1–2 спринта, метрики отличные, все работают. Но, как говорится в анекдоте, есть один нюанс: продукт не приближается к заветному релизу. Что делать? Посмотреть на процессы с точки зрения пользовательских задач и оптимизировать контроль метрик.
Меня зовут Артур Нек, я управляющий партнер Kaiten, а в прошлом Scrum-мастер команд разработки. Расскажу, как простая ошибка в интерпретации метрик может сильно тормозить работу команды и как нам всё-таки удалось ускорить развитие продукта, пересобрав текущие процессы.
Intro: как команда работала раньше
Ситуация произошла с командой разработки, которая выпускала интернет-магазин по продаже интеллектуальной собственности. Когда я присоединился к команде в качестве Scrum-мастера, внешне всё выглядело так, будто ребята отлично справляются с работой. У них были выстроенные Scrum-процессы, большинство задач закрывалось за 1–2 спринта, что было нормально.
Но две проблемы явно бросались в глаза:
Фронтенд-разработчики сильно обгоняли бэкэнд по срокам и количеству выполненных задач.
За полтора года так и не получилось предоставить минимально работающий продукт пользователям.
В это же время на совещании руководства генеральный директор намекнул, что пора выходить на рынок, иначе придется отказаться от продукта. Это подстегнуло команду пересмотреть процессы.
Анализируем ошибки
Первое, что стоит сделать в такой ситуации, — проверить, а правильно ли мы считаем метрики. Мы посмотрели на текущую процессную аналитику, которая автоматически собиралась по задачам в Kaiten, и увидели, что время производства (lead time) действительно неплохое — задачи выполняются за 1–2 спринта.
Тогда стали анализировать, какие элементы работы включаются в аналитику. Оказалось, что каждый участник команды заводит отдельные таски под свои функциональные задачи. Получалась такая картина:
есть разные фичи продукта;
для их реализации нужно выполнить ряд подзадач, которые делают фронт и бэк;
эти подзадачи не связаны друг с другом и с общей фичей;
фронтенд выполняет свои задачи быстрее и берется за новые подзадачи от других фич, пока бэкэнд доделывает свою часть работы;
фичи выкатываются медленно;
lead-time считается не по выполнению фич, которые несут ценность для пользователя, а по выполнению функциональных задач.
Вот и причина проблемы: команда считала lead time по завершенным функциональным задачам вместо того, чтобы собирать данные по выполнению пользовательских историй. Так у команды сложилась иллюзия эффективной работы.
Прокачиваем метрики
Нужно было перейти к другому рабочему элементу для расчета lead-time. Мы выделили 20 пользовательских историй, над которыми работала команда, а функциональные задачи пересобрали в формате чек-листов внутри этих историй.
Например, пользовательский сценарий — это возможность покупки интеллектуальной собственности в онлайн-магазине. А функциональные подзадачи внутри этой истории — это внешний вид страницы для фронта, внутренние алгоритмы для бэка, система оплаты для отдельной биллинговой команды.
Чтобы посмотреть lead time по выполнению пользовательских историй, мы взяли время от старта самой первой подзадачи из истории до окончания последней.
Результат был неутешительным. Оказалось, что реальное время производства фичи — примерно 9 месяцев.
Итак, мы сломали иллюзорную стену, за которой жила команда. Поняли, что реальный lead time сильно отличается от того, на который мы опирались раньше. Дальше нужно было придумать, как улучшить процессы и доделать текущие фичи, чтобы получить работающий продукт.
Прокачиваем команду
Поскольку к моменту изменений фронтенд-разработчики уже закрыли все свои функциональные задачи, для выполнения пользовательских историй оставалось закрыть только бэкенд-задачи. Ребята из фронтэнда решили перенаправить свои усилия на помощь коллегам.
Несмотря на сомнения со стороны бэкенд-специалистов, ребята из фронтенда смогли справиться с новой для себя задачей и прошли ревью. Стало понятно, что можно работать вместе. Фронтенды стали брать всё более сложные задачи бэкенда.
Таким образом постепенно внедрили классную инженерную практику, когда вся команда включена в работу над проектом. И за 2–3 месяца реализовали все пользовательские истории, которые были нужны на тот момент.
Кроме внутренних задач, ребята обратили внимание вовне: для сервиса нужна была система оплаты, которой обычно занимается биллинговая команда, и ждать их нужно довольно долго, так как есть очередь от других заказчиков. Тогда команда совместными усилиями изучила новую для себя область и самостоятельно реализовала систему биллинга за полтора месяца. В результате прошли ревью с минимальными комментариями.
На уровне компании это был нонсенс. Началась волна внедрения новых инженерных практик: общего владения кодом, объединения в пары и мини-команды, чтобы совместно практиковаться на конкретных задачах и перенимать опыт смежных специалистов. Это дало сильный буст развитию инженерной культуры как внутри команды, так и на уровне компании в целом.
Смотрим на результаты
Правильный подход к аналитике данных и развитие новых скилов у команды дали результаты: за пару месяцев продукт стал ближе к выходу на рынок. Мы реализовали все необходимые на тот момент функции и сократили lead time от невероятных 6–9 месяцев до нескольких спринтов. Тем не менее до релиза мы так и не дошли: поменялась ситуация на рынке, для компании продукт стал менее актуальным.
Эта история о том, что компания не будет вечно вливать силы в ваш продукт, поэтому короткие lead time и time to market очень важны. К тому же важно следить не просто за какими-то метриками, а знать, что именно они показывают и как считаются. Иначе можно жить в уверенности, что команда работает отлично, а по факту оставаться в мертвой точке.
Тем не менее финал позитивный: команда сильно прокачалась на этом опыте. Дальше, когда ребята разошлись по другим продуктам, они смогли сами развивать инженерную культуру и многофункциональность специалистов, а еще смотреть на продукт с точки зрения бизнес-задач.