Квантовый эджайл: разработка продукта в условиях высокой неопределённости

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

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

В какой-то момент мы поняли, что находимся в состоянии, которое лучше всего описывает квантовая суперпозиция: неопределённость достигла такого уровня, что казалось — может произойти буквально что угодно. Любое техническое решение, любое требование, любой рынок. Всё одновременно возможно и невозможно, пока не посмотришь. Именно тогда и появилось это название — квантовый эджайл. И именно тогда стало понятно: чтобы работать в такой среде, команда должна быть готова ко всему. Не в смысле «предусмотреть все сценарии» — это невозможно. А в смысле внутренней готовности: не паниковать от неизвестности, а работать с ней как с нормальным рабочим условием.

Почему стандартный agile здесь не работает

К agile у нас не было принципиальных претензий — для большинства продуктовых задач это работающий подход. Проблема в другом: даже гибкие методологии молчаливо предполагают, что у вас достаточно понимания на старте. Достаточно, чтобы написать User Story. Достаточно, чтобы backlog имел смысл хотя бы на горизонте спринта.

Да, в agile-семействе есть инструменты для работы с неизвестностью — Discovery-спринты, Dual Track, Lean UX. Они помогают, когда неопределённость локальна: непонятна конкретная фича, не проверена гипотеза, нужен UX-эксперимент. Но у нас неопределённость была системной — менялось всё одновременно: рынок, регуляторика, аппаратная платформа, сама предметная область.

Когда понимания нет на таком уровне, спринты начинают работать вхолостую. Задачи пишутся с пониманием, что завтра изменятся. Velocity теряет смысл, потому что часть сделанного приходится выбрасывать. И главное — команде сложно ощущать прогресс, потому что единица прогресса в agile — «сделанная фича», а у вас нет определённых фич.

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

Cynefin и домен, в котором мы оказались

Есть полезный фреймворк — Cynefin Дейва Сноудена. Он делит рабочие ситуации на несколько доменов. В сложном домене работают эксперты с проверенными практиками — это большинство нормальных IT-проектов. В комплексном домене причинно-следственные связи видны только постфактум, и единственный работающий подход звучит как probe → sense → respond: сделай что-то небольшое, посмотри что происходит, скорректируй.

Наш проект с самого начала был в комплексном домене. Мы это не сразу поняли — и поэтому несколько недель пытались применять инструменты для сложного домена к задаче, где само определение «что нужно сделать» менялось быстрее, чем мы успевали реагировать.

Принципы вместо планов

Ответ, к которому мы пришли: управлять не планами, а принципами.

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

Это не новая идея — её можно найти у Сарасвати в теории Effectuation (как предприниматели принимают решения в условиях радикальной неопределённости), у МакКристала в «Team of Teams» (как распределённые команды действуют без центрального командования), у Альтшуллера в ТРИЗ (как решать изобретательские противоречия без заранее известного решения). Но в контексте управления разработкой эта идея сформулирована редко.

Суть такая. В условиях высокой неопределённости план — это иллюзия контроля. Вы тратите время на его составление, а потом — на его обновление. И снова. И снова. Команда начинает воспринимать планирование как бессмысленный ритуал.

Принципы работают иначе. Это не «что делать», а «как принимать решения». Они остаются стабильными даже когда всё вокруг меняется. И — это важно — они позволяют команде действовать автономно, не ожидая указаний сверху на каждый шаг.

Вот принципы, которые сложились у нас в процессе работы над этим проектом (и которые мы с тех пор уточняем).

Семь принципов квантового эджайла

1. Быстрый ответ важнее правильного ответа.

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

2. Проблема пользователя важнее проблемы разработчика.

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

3. Хороший код — не перфектный код.

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

4. Если рынок не определился — мы готовы к 10, 20, 100 итерациям.

Это звучит дорого. На самом деле это дешевле, чем сделать «окончательное» решение на основе непроверенных гипотез. Когда мы сменили установку с «давайте сделаем правильно с первого раза» на «давайте сделаем быстро и узнаем», темп проекта вырос — несмотря на весь хаос вокруг.

5. Исследование — это тоже работа.

Самый трудный принцип для объяснения стейкхолдерам. Когда мы потратили две недели на погружение в предметную область, с точки зрения традиционного проекта мы «ничего не сделали». С точки зрения квантового эджайла — мы устранили критическую неопределённость, которая иначе уничтожила бы продукт на этапе клинической валидации. Незнание — это тоже задача. И у неё есть Definition of Done.

6. Команда должна понимать «зачем», не только «что».

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

7. Прозрачность неопределённости — это не слабость.

Когда мы перестали делать вид, что знаем ответы, и начали явно маркировать задачи как «известное», «неизвестное, но исследуемое» и «неизвестное неизвестное» — управление проектом стало честнее и эффективнее.

Что нужно от команды — и почему это сложно

Принципы — не магия. Они работают только если у команды есть определённый базовый уровень.

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

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

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

Риски, о которых стоит знать

Квантовый эджайл — не для всех проектов и не для всех команд.

Клиент с фиксированным бюджетом. Если финансирование требует зафиксированного скоупа, это не повод отказываться от подхода — но повод честно поговорить на берегу. Заранее договоритесь о допустимом проценте изменений и о том, как вы будете их обосновывать. У нас это выглядело так: раз в месяц мы пересматривали baseline, фиксировали, что изменилось и почему, и согласовывали с клиентом скорректированный скоуп. Это убирает ощущение хаоса и даёт клиенту контроль — не над каждым шагом, а над общей картиной.

Команда без самодисциплины. Отсутствие детального плана требует высокой личной ответственности. Если команда привыкла работать по тикетам и ждать указаний — переход будет болезненным.

Иллюзия движения. Постоянные изменения могут создавать ощущение продуктивности при отсутствии реального прогресса. Здесь критически важны метрики не процесса, а устранения неопределённости: что мы узнали? Какие гипотезы проверили? Что отпало?

Что почитать

• Dave Snowden, «Cynefin» — фреймворк для понимания, в каком домене находится ваша задача
• Eric Ries, «The Lean Startup» — Build-Measure-Learn в условиях неизвестности
• Stanley McChrystal, «Team of Teams» — автономные команды, работающие по общим принципам без централизованного управления
• Saras Sarasvathy, «Effectuation» — как эксперты принимают решения в условиях радикальной неопределённости
• Генрих Альтшуллер, «Творчество как точная наука» — ТРИЗ в оригинале; логика работы с противоречиями универсальна

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

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

Для нас это и есть определение успеха в комплексном домене.