Представьте ситуацию: вы приходите в новую компанию, погружаетесь в проект, но с первого же дня не успеваете в сроки. Вы собираетесь с мыслями: формализуете бэклог, выделяете MVP, но все равно не успеваете даже с минимальным жизнеспособным продуктом. Через пару спринтов получаете среднюю скорость команды, делите сумму оценок задач бэклога на скорость и высчитываете реалистичную дату реализации проекта. Готовите внушительное обоснование руководству, «посыпаете голову пеплом» и согласуете новый срок его сдачи. Продолжаете работать, но всё равно не успеваете. Очевидно, что-то идет не так, отсюда зреет вопрос «доколе?»
Меня зовут Алексей, я IT product manager, занимаюсь развитием внутренних систем в ВТБ Лизинг. В ситуации выше смешались проекты, продукты и agile, но так даже интереснее и жизненнее. В этой статье я расскажу, как мы выходили из подобной ситуации.
Постановка задачи
Нашей команде поставили цель разработать лизинговый калькулятор для расчета сделок с корпоративными клиентами.
Практически все корпоративные сделки заключаются с клиентами на индивидуальных условиях. Предметом сделки могут быть буровые установки стоимостью 47 млн рублей (ссылка), морские суда за 420 млн рублей (ссылка) или телекоммуникационное оборудование на 5 500 млн рублей (ссылка). В таких крупных сделках крайне важно корректно рассчитать ежемесячные лизинговые платежи с учетом всех их особенностей. Для сравнения, в графике платежей по кредиту каждый платеж содержит основной долг и проценты, а в лизинговом платеже может быть до 7 различных составляющих.
Для расчета платежей наша компания использует специализированное ПО. У этой программы есть преимущество – необыкновенная гибкость. Но этот плюс может работать и в противоположную сторону. Каждый расчет мы выполняем в отдельном файле, а значит сложно выработать единую методику расчетов, провести анализ портфеля сделок и их условий по договору. Ещё файл с расчетом можно потерять в иерархии сетевых папок или запутаться в его версиях.
В 2020 году разработку нового калькулятора начал подрядчик. Планировалось, что он позволит рассчитать все числовые параметры сделки: от сумм в графике платежей для клиента до данных, используемых во внутренней отчетности компании. Также необходима была интеграция с другими системами, используемыми в корпоративном блоке, в первую очередь, с бухгалтерскими. В качестве техстека для нового калькулятора были выбраны 1С и конфигурация типовой лизинговой компании.
Примерно через год проект решили перевести на инхаус-разработку (подробнее про наш выбор инхаус или аутсорс можно узнать в статье хабр). Внутренней команде необходимо было только доделать оставшиеся 10% требований технического задания, которые не сделал подрядчик. На доработку нам дали 3 месяца.
Из электронных писем, документов и таблиц со статусом по проекту мы составили список задач. Достаточно ли отведенного времени для их выполнения? Отвечать мы решили гибко: стартовали итерационную работу.
Задачи в первые спринты выбирались произвольно: мы не боялись взять слишком мало или слишком много для двух рабочих недель. Через пару спринтов на базе выполненных задач мы составили шкалу оценки из 6 значений в стори пойнтах, где значения от 1 до 5 – это задачи от исправления опечатки до значительной доработки, а 6 – задача, в которой вообще ничего непонятно, и требуется выделить дополнительное время для её разбора. Забегая вперед, мы до сих пор оцениваем задачи по этой методике, при этом по мере роста компетенций периодически пересматриваем шкалу, ёмкость спринта и сами оценки будущих задач.
Мы дали оценку всем открытым задачам проекта и посвятили следующие 2 спринта определению скорости команды. Имея приблизительное количество стори пойнтов в спринт, мы рассчитали время, за которое закроем все задачи. Итог: 6 месяцев, в срок не успеваем…
Гонка до дна бэклога была проиграна в самом её начале. Исправить ситуацию решили так: попробовать договориться с бизнесом о новых сроках завершения разработки калькулятора и скоупу. Скоуп сократить не удалось, так как при любом удалении функций не получалось жизнеспособного продукта. Переговоры по новому сроку прошли успешнее, поскольку можно было не угадывать его, а рассчитать, зная скорость команды и объем работы.
Каждый месяц работы по проекту прибавляет ещё месяц
Мы согласовали новый срок запуска калькулятора, работа продолжилась. Чтобы не допустить повторного изменения дедлайна, мы стали внимательнее следить за динамикой бэклога: каждые 2 недели оценивали количество выполненных текущих и новых задач. Но через 2 месяца стало понятно, что за каждый месяц работы по проекту прибавляются задачи ещё на месяц вперед.
Доработка 10% технического задания заставляла нас переделывать результаты и по ранее реализованным 90%. Пользователи сообщали о новых проблемах, которые нельзя было обнаружить в неполном решении. Каждая задача была оценена, но если задач становится больше, то при сохранении скорости команды сроки необходимо увеличивать.
Мы опять задаем себе вопрос: что делать? Перестать работать с изменениями, но освоить бэклог в срок? Найти другие способы улучшить ситуацию? Первый вариант отдалял нас от цели сделать что-то полезное для бизнеса: формально мы закроем задачи, сформируем список доработок для второй очереди, потом, вероятно, третьей, но всё это время пользоваться результатом будет невозможно. Следующей идеей было предложить альтернативный вариант реализации функций, который позволил бы бизнесу начать работать с калькулятором. В ходе этого обсуждения возникла более радикальная идея пересмотреть цель команды: от «реализовать все задачи» перейти к «достичь определенного важного для бизнеса показателя».
8 из 10 сделок стали рассчитываться в калькуляторе
Первоначальная постановка цели – создать лизинговый калькулятор – не описывала, зачем он нужен бизнесу. Находясь в цейтноте, мы забыли, что разрабатываем только первый модуль будущей системы. Получалось, что от нас требовалось скорее создать фундамент для цифровизации процесса, чем разработать замену текущего инструмента. У будущей системы есть свои бизнес-цели и ожидания, но, возвращаясь к калькулятору, мы выделили одну ключевую метрику, которая описывает успешность его внедрения в долгосрочной перспективе. Алгоритмы калькулятора должны подходить для расчета 80% сделок, или, иными словами, после внедрения калькулятора не больше 2 сделок из 10 будут рассчитаны в старом ПО.
Чем цель «8 из 10 сделок через новый калькулятор» качественно отличается от «реализовать 20 функций»? Предварительной подготовкой, приоритетом работ и ответственностью участников. Новая постановка цели требует анализа бизнесом самого себя. Он позволяет обоснованно ограничить скоуп и сфокусировать работу, корректно расставляя приоритеты. При этом ответственность участников расширилась: мало разработать какую-то функцию, необходимо чтобы она дала бизнес-эффект. Цель перестала звучать формально: «сделать, пройти приемку, забыть», теперь необходимо качественно внедрить результат, проводя обучение и собирая обратную связь.
С расширением ответственности и объединением интересов бизнеса и ИТ нам стало особенно важно говорить на одном языке.
На помощь приходят попугаи
Всё это время мы активно использовали новые для бизнеса термины: бэклог, спринт, стори пойнты. Коллеги постоянно нас спрашивали, а что они означают? Мы собрали интересующие вопросы и провели презентацию «Agile в нашей команде». После этой встречи каждый ритуал спринта мы начинали с рассказа о целях мероприятия и готовности принимать обратную связь как по разработанным функциям системы, так и процессу разработки.
Самым сложным было объяснить, каким образом мы оцениваем срок выполнения задачи. Поначалу при обсуждении мы использовали дни. Если сумма оценок задач соответствовала ёмкости 4 спринтов – мы говорили, что потребуется 2 месяца. При росте вовлеченности участников в проект потребовалась более точная коммуникация, и мы решили рассказать бизнесу о стори пойнтах. Точнее, о «попугаях», поскольку не хотели пугать англицизмами.
После презентации попугаев начались обсуждения такого рода: «Нет, оценка этой задачи не 3, а 1». Мы продолжили подробно рассказывать про нашу шкалу, приводить примеры задач, регулярно демонстрировать результаты работы. Со временем пришли к общему пониманию, что оценка дается не бизнесом, а командой разработки. Планирование спринта стало проходить по принципу «набери задач на 25 попугаев». Если в спринте необходимо выполнить задачи нескольких заказчиков – мы делим попугаев между ними. Параллельно оценивали, как меняется наша скорость при пополнении команды, в периоды отпусков или когда половину спринта составляют выходные праздничные дни.
В итоге даже задачи на предварительный анализ или консультации пользователей получили оценку и место в бэклоге. Это сделало нашу работу максимально прозрачной и помогло избавиться от систематического перегруза, когда одни задачи были в спринте, а другие выполнялись за кадром. Обратной стороной прозрачности стала необходимость разбираться с хвостами, т. е. задачам, которые не выполнялись к концу спринта. Если мы недооценили задачу (первоначальная оценка оказалась ниже итоговой, например, копали задачу на 3 стори пойнта, а у нее оказалось второе дно) – мы в любом случае подводим по ней итоги в текущем спринте и открываем задачу-продолжение со своей оценкой для нового спринта. Если пользователь занят и не может дать обратную связь, то мы оставляем задачу в определенном статусе: при наличии замечаний мы откроем продолжение с новой оценкой и включим в бэклог одного из последующих спринтов.
Бизнес достаточно быстро включился в новый процесс, получив новые механизмы контроля задач в работе, но из-за того, что мы перестали давать оценку в днях, перестал получать привычный ответ на вопрос: «А когда будет выполнено?»
Попугаи + приоритет
Совсем без сроков работать нельзя. Для задач, от выполнения которых зависит старт работ смежных команд, нужна хотя бы примерная дата готовности. На базе оценённого бэклога у нас появилась методика планирования на несколько спринтов вперёд. В её основу легли разделение общего списка задач на группы, образующие направления работ, определение приоритета направления и квоты в процентах для каждого направления в спринте. Как пользователи определяют, какие задачи важнее? В первую очередь, отталкиваясь от целей разработки, транслируемых команде, включаются любые важные сейчас для бизнеса критерии, и тогда мы получаем плоский список ранжированных направлений работы. Направлениям наверху списка отводится больше внимания в спринте. Как это работает? Из недавних примеров можно вспомнить переработку пользовательского интерфейса.
За время нашей работы в калькулятор был добавлен ряд новых алгоритмов, но количество параметров, используемых в расчетах калькулятора, перевалило за 400. Некоторые из них вычисляются под капотом, но большинство вводится пользователем. Пользоваться калькулятором становилось все сложнее, и возникла необходимость рефакторинга. Когда новый интерфейс будет в продуктивной среде? Мы выделили и оценили задачи для нашего бэклога по этому направлению. Если бы эта задача возникла в проекте раньше – мы бы назвали оценку в днях, но теперь совместно с бизнесом мы определили её приоритет и какую долю стори пойнтов в спринте мы можем выделить. Получили предварительный номер спринта, в котором задача будет выполнена. После этого каждый спринт мы оценивали результаты работы и сработавшие риски, а затем совместно решали, изменять или нет приоритет данного направления.
Процесс стал более прозрачным: сейчас мы можем наглядно показать, откуда берется срок разработки и как можно на него повлиять. Приоритет стал важным дополнением к оценке задач в стори пойнтах и подсчету скорости команды: пара «оценка + приоритет» заменила поверхностные и непрогнозируемые сроки в днях, которые ранее использовались в ответе на вопрос: «А когда?».
Признайтесь, вы не успеваете
За год работы мы получили опыт эджайл-трансформации и работающий процесс внутренней разработки с прозрачными механизмами его модернизации. Но успели ли мы сделать калькулятор, который может рассчитать 80% сделок? Нет, итогом стало значение в 60%.
С точки зрения разработки у нас отличные результаты: бэклог доработок, оставшийся при переходе на инхаус-разработку, мы реализовали и в несколько раз перевыполнили. В первом квартале 2021 года мы имели медиану по lead time задач в 60 дней, а к третьему кварталу сократили ее до 25. При этом в данную метрику мы включаем и приемку задач пользователями, которая из-за их загрузки по основным рабочим обязанностям может затягиваться. Согласно джире, командой в 4 сотрудника за год мы реализовали 250 задач на 600 стори пойнтов при средней скорости 25 стори пойнтов в спринт. Но самое важное достижение 2021 года — выход из гонки до дна бэклога.
В нашем случае освоение бэклога прошло следующие этапы: отрицание, гнев, торг… Шучу. На самом деле мы:
Сформировали список задач.
По результатам первых спринтов получили шкалу оценки.
После ещё пары спринтов получили скорость команды.
Сформулировали цель в терминах бизнеса (разумеется, в будущем это надо делать в первую очередь).
Договорились с бизнесом о способах управления приоритетом задач.
Мы постоянно дорабатываем свой продукт, не забывая про цель — 80% сделок. Достигнутые результаты в процессе разработки уже сейчас позволяют двигаться дальше. Калькулятор сложно использовать вне бизнес-процесса. У нас большие планы по автоматизации всего жизненного цикла корпоративной сделки: от инициации, сбора документов и подписания до сопровождения и закрытия сделки. Часть активностей реализуется в синергии с системами банка ВТБ, а это новые дорожные карты, вехи и процессы разработки.
Расскажите, а как вы справляетесь с гонкой за сроками на своих проектах и продуктах? Как устроена система оценки и планирования? Похожа ли она на нашу, видите ли у себя похожие на наши проблемы?