Артефакт Шредингера: пока мы его согласовываем, продукт уже мог выйти в прод

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

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

Что важнее - сначала сделать идеальные, эталонные и всеми согласованные артефакты или быстрее начать разработку, проверить гипотезу и принести результат бизнесу?

Как водится, обе стороны были правы. А значит, спор мог продолжаться бесконечно. 🙂

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

Вообще когда-то давно (на самом деле не так уж и давно) гибкий подход/Agile/Аджайл придумали во многом именно для того, чтобы перестать относиться к разработке продукта как к строительству атомной электростанции, чтобы уйти от долгих (несколько месяцев, а иногда и несколько лет) поэтапных составлений и согласований требований.

Один из принципов того самого манифеста звучит довольно однозначно:

Работающий продукт важнее исчерпывающей документации.

Не вместо документации. Именно важнее.

Потому что идеальная схема процесса, согласованная четырьмя комитетами и лежащая в Confluence/md файле/СЭДе пока еще не принесла клиенту никакой пользы.

А маленькая работающая функция уже это может.

Отсюда, на мой взгляд, правильный вопрос не:

«Документация или скорость?»

А:

«Какой минимальный объем определенности нужен нам, чтобы безопасно сделать следующий шаг?»

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

MVP/МЖП - сделать минимальную версию, которая позволяет проверить, нужна ли вообще эта идея кому-нибудь кроме участников встречи.

Prototype/PoC/Прототипирование - иногда вообще не надо сразу что-то разрабатывать. Можно сначала доказать, что технология или сценарий работает.

Walking Skeleton/Потемкинская деревня - собрать грубый, но работающий сценарий через всю систему.

Feature Flags/Тоглы/Фокус-группы - доставлять функциональность постепенно, включая ее сначала небольшой группе пользователей.

A/B-тесты - вместо двух недель обсуждения «какой вариант лучше» иногда можно показать пользователям оба и посмотреть (но сделать все таки для этого придется оба варианта для начала).

Trunk Based Development + CI/CD - маленькие изменения, частые поставки и минимум гигантских релизов формата «увидимся через три месяца».

Dual Track Agile - discovery и delivery идут параллельно (но капаситет команд не резиновый, в идеале работает там где есть отдельные rnd команды).

И вишенка на торте, мой любимый принцип:

Если решение можно относительно бюджетно отменить/изменить - не надо принимать его так, будто оно высечено в граните.

Конечно, есть банковские системы, безопасность, архитектура, регуляторка и вещи, где принцип «давайте просто попробуем на проде» может довольно быстро превратить владельца продукта в автора объяснительной СЗ.

Поэтому задача зрелой команды - НЕ отказаться от артефактов, а - не производить артефакты ради артефактов.

Хорошая документация уменьшает неопределенность, особенно на следующих этапах.

Плохая - просто откладывает момент, когда команда столкнется с суровой реальностью.

А реальность все равно наступит (и загар сойдет).

Обычно сразу после релиза. 😎

Поэтому мой девиз довольно простой:

Меньше размер первой поставки / короче обратная связь / быстрое обучение / ускоренное получение ценности для бизнеса.

Пожалуй, это и есть одна из главных идей Аджайл, которую иногда теряют за Джира, статусами, ДОРами и очередным файлом «Финальная_версия_v7_FINAL_Согласовано_точно.xlsx».🫡