«Разработка по Agile» не предполагает точных сроков реализации функциональности, но каждому владельцу продукта прилетает в неделю сотни «А когда будет готово...?». Даже когда продукт находится на этапе погружения команды в бизнес‑контекст и не завершены исследования, требуется определить сроки выхода MVP, ведь продукт или фича нужны «вчера» и важность стратегического планирования на квартал или год никто не отменял. Рассмотрим ситуацию, когда продукт не находится на ПРОДе и нет точного состава MVP.
Цель статьи — рассказать об оценке бэклога в полной неопределенности.
Прежде, чем выдвигать гипотезы по срокам, важно сделать ряд «приседаний» с командой после дискавери‑фазы: это декомпозировать продукт на фичи, определить MVP, составить USM и только потом с видением продукта приходить к архитекторам и команде, чтобы обсудить не просто оценки, а реализацию и зависимости. Здесь сталкиваемся с рядом проблем задач, например, если команда оценивает бэклог в SP, что невозможно и не правильно переводить в человеко‑дни, а положить SP на календарный график и диаграмму Ганта нереально (подробнее о SP туточки) или есть зависимости от фичей смежных команд и сроки их реализации еще неизвестны, или архитектура еще не готова и остается только выдвигать гипотезы, как будет реализовано. Вот здесь начинается интересный квест.
Владелец продукта вместе с командой разработки могут выбрать такой вариант: оценить риски, заложить время на дополнительные исследования и еще что‑нибудь — в таком случае мы окажемся с MVP через год‑два, что не подойдет никому. И ведь одной из важных задач продакта — это урезать функциональность на MVP по всем канонам и сделать быстро/дешево. В связи с этим рассмотрим шаги для проведения первичной оценки, когда есть понимание функциональности, но еще не проведен подробный бизнес‑анализ. Забегая вперед, это не «красная таблетка» и эти шаги не спасут от возможных изменений состава MVP, переприоритезации или влетающих новых важных задач. Ниже описанные шаги дают вектор движения и помогают сформировать ответ на вопрос «Когда?», не скатываясь в Waterfall.
Шаг 1. Декомпозиция
Когда уже есть понимание по процессу и какие существующие функциональности затрагивает продукт, дробим на фичи и функциональности в формате user story. Здесь частая ошибка — горизонтальная декомпозиция на основе архитектуры. После реализации такой фичи на графике красиво светится отметка «Done», но ценности для пользователя нет и владелец продукта, краснея, пытается объяснить на пальцах, что это важная фича, она очень нужна, а эффект в цифрах может предоставить после реализации пары‑тройки фичей. Стоит помнить, что каждая, прям каждая, фича продукта должна иметь эффект и метрики оценки — мы же строим бизнес, а не галочки на графике рисуем.
DOD: список фичей с описанием функциональности в разрезе эпиков. По описанию — хотя бы пару предложений, в идеале полноценные критерии приемки.
Шаг 2. Подготовка
До встречи с командой стоит обсудить архитектуру и иметь четкое представление о ней для рассказа команде.
Если уже понятны зависимости, не поленитесь дойти до смежных команд — хотя бы узнать их явки/пароли и зафиксировать всё для будущих взаимодействий, ведь вы уже капнули в их сторону и стоит оставить след во благо команды.
Стоит позаботиться о визуализации — буквально пару кубиков в схеме, чтобы объяснить концепцию команде.
Определите структуру, чтобы с первого рассказа сложилась вся картинка.
DOD: Схема, например, в miro (это может быть драфтом USM).
Шаг 3. Общение с командой
Это самый главный шаг при оценке бэклога. По моему мнению, оценивать бэклог без команды не стоит, даже если ранее реализовывали аналогичные фичи и стейкхолдер просит срочно назвать сроки готовности. Для получения более реальной первичной оценки до анализа объясните команде, какие пункты стоит учесть: это ревью, устранение багов, время на погружение и что это оценка первичная, а не груминг по результату системного анализа. Возникнет вопрос, стоит ли отвлекать всю команду на данном этапе. Мы проводим такую оценку в составе по одному человеку от роли, но в оценке стоит учитывать, что оценивать будет один человек, а кодить может другой. В ходе обсуждения фичи можно закопаться в деталях реализации, что на данном этапе не стоит делать, и, если есть несколько вариантов, то оценивайте средний или негативный сценарий реализации. Мы проводим оценку по ролям, чтобы определить планируемую нагрузку. Напомню, что цель первичной оценки определить сроки и очевидно что единицу измерения выбираем человеко‑дни.
DOD: долгожданные цифры по каждой фиче.
Шаг 4. Приоритизация
Существует много фреймворков, на них останавливаться не будем, быстро и на цифрах советую использовать ICE (чтобы не гуглить, расшифрую: Impact — это влияние, иначе выгода от фичи, Confidence — уверенность, кстати, здесь прям запрещено владельцу продукта единолично проставлять баллы и Ease — простота реализации), но здесь возникает вопрос как приоритизировать бэклог, если в нем всегда существуют технический долг и архитектурные задачки. Есть примеры, когда бэклог команды пилят на доли — 50% новой функциональности, 30% технический долг и 20% архитектуру, еще оставляют какой‑то процент на баги, но на практике, если соблюдать такой баланс, то мы режем сук на котором сидим и срок доставки ценности увеличивается вдвое. Часто слышу, что тех долг невозможно оценить со стороны бизнеса и всё такое. Рекомендую, составить список качественных и количественных параметров к ICE, по которым можно оценивать любую фичу и в т.ч. тех долг, например, сокращение рисков или влияние на доступность системы. Добавлю, что приоритизация нужна в том случае, если владелец продукта определяет развитие продукта, а не подписанное ТЗ с заказчиком.
DOD: лейбл приоритета на каждой фиче.
Шаг 5. Определение MVP
Каждый продакт знает все методики. Напомню лишь, что стоит учитывать технические зависимости — они могут быть как внутри бэклога команды, так и со смежными командами.
DOD: список фичей поделен на MVP и следующие итерации.
Шаг 6. Проверяем календарь
Итак, мы оценили и дальше вроде всё просто — надо лишь раскидать на календарь. Но это не так. Вспоминаем зависимости, смотрим график отпусков, учитываем время на подготовку релизов и возможные аварии. Если еще неизвестно всё перечисленное, то можно смело добавить к оценке 20–30%.
DOD: готовый график. Инструмент визуализации пока самый удобный для нас — это диаграмма Ганта.
И это еще не всё. Не поленитесь после грумингов сравнить первичную оценку «пальцем в небо» и посмотреть среднюю разницу, которую стоит учитывать в будущем.
Вместо заключения
Груминг на первых фазах — это боль для команды. Поддерживайте, благодарите и делайте паузы во встречах. Первичная оценка решает задачу на 10%-20%, а сессий груминга может быть более 2-х, и к этому надо быть готовым. Например, есть неизвестные вводные, без которых просто нереально сделать даже примерные оценки, на уточнение которых необходим 1–2 дня. А можно ли жить без первичных оценок? Наверное, можно. Но одна из задач владельца продукта — это управление ожиданием пользователей. Ответы а‑ля «возьмем в анализ и вернемся когда‑нибудь» на самый главный вопрос пользователя и стейкхолдера «Когда?» не подходят.