Хватит пилить слонов под видом MVP

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

Рождение слона или хотели как лучше, а получилось...

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

Но потом начинается самое интересное — сбор требований. И вот тут начинается магия: один из заказчиков заявляет, что ему нужна сверху ещё одна дополнительная функция, второй заявляет, что его процесс тоже необходимо включить в скоуп работ, ну а третьему обязательно нужна дополнительная интеграция, «ведь всё равно уже начали, давайте уж всё доделаем». Если разбирать, то всё по отдельности звучит разумно, да и делать не так уж много, но в сумме стартовый запрос разрастается до огромного кросс‑департаментного взаимодействия, с кучей требований, энным количеством стейкхолдеров, ну и сроки, конечно же, растут в геометрической прогрессии. При всём при этом все упорото упорно продолжают называть эту махину MVP.

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

Хорошо ещё, если заказчик не решит постоянно раздувать scope новыми требованиями. А если решит? Уныние → героизм → выгорание → варианты спасения тонущего корабля. А ведь всей этой набившей оскомину цепочки можно избежать. Как? Да просто сказав «Нет» в определённый момент — на этапе, когда scope только начинает раздуваться. Не просто нет, а обоснованное цифрами: сколько это стоит, сколько времени займёт, какие риски принесёт. Именно это и должно отделить настоящий MVP от того слона, в которого его превращают.

Почему в жизни работает, а в работе не как в жизни)

Давайте добавим немного метафор в наш обыденный разговор. Чтобы понять, почему настоящий MVP работает, а раздутый — нет, давайте рассмотрим привычную для всех аналогию — формирование привычки. Вот в одно из обычных воскресений вы просыпаетесь после субботнего «отдыха» и решаете начать новую, лучшую жизнь. Вы решаете, что будете ложиться спать в 22:00, вставать в 6 утра, правильно питаться, ну типа «нет» добавленному сахару и ультрапереработанной еде, в зал будете ходить минимум 2 раза в неделю, ну и, конечно, утренние пробежки, куда же без них в идеальной жизни, сердце нам нужно крепкое и здоровое. Ну всё — решено, делаем, с понедельника!

Я надеюсь, что в 2026 году не осталось людей, которые свято верят, что, засунув это всё в первый же понедельник, не растеряют мотивационный запал уже в четверг — ну или максимум в воскресенье с утра. Мы же взрослые, мы понимаем, что причина неудачи в этом случае будет не в слабовольности, а в том, что методика формирования привычки сломана, ваша внутренняя система не в состоянии переварить столько изменений за один раз, это — стресс для неё, а к стрессу необходимо адаптироваться, понемногу, со временем внедряя новые и новые привычки. Закрепилась одна — внедряй следующую, научился ложиться в 22:00 — добавляй зал один раз в неделю, ну и так далее, чего я объясняю, все тут в курсе, как это работает.

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

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

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

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

Ну, а где профит‑то, ради чего всё это?

На этом этапе у вас может возникнуть резонный вопрос: «А почему мы вообще должны этим пользоваться? Нормально внедряли и раньше, ну не попадали иногда в сроки, иногда в бюджет, иногда по качеству бывали вопросы, но это же классическая проблема проектного треугольника, у всех же так». Причин существует несколько, и каждая из них закрывает конкретную проблему, знакомую любому, кто хоть раз посещал проектный комитет.

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

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

• Гибкость изменения контекста. В ходе большого проекта, за полгода‑год всё может поменяться, да ещё и не один раз: приоритеты пересмотрели, ситуация на рынке поменялась, стейкхолдеры пришли или ушли; итерации позволяют работать с этим более гибко, по ходу, а не сокрушаться в итоге, что разработанная функциональность не решает текущих проблем или не соответствует требованиям новых ключевых людей в компании.

• Реальная вовлечённость пользователей. Что мы обычно слышим после того, как год что‑то разрабатывали и принесли пользователям уже готовый результат своих трудов? Ну, скорее всего, это будет что‑то типа «а это не то, что мы имели в виду»; работая итерационно, мы стараемся избежать данных коллизий, демонстрируя заказчику тот результат, который он просил недавно, а не два квартала назад.

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

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

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

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

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

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

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

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

На самом деле решение здесь довольно простое, но в этом‑то и состоит его сложность: нам просто надо разговаривать с бизнесом на его языке — языке денег, сроков и рисков. Итерационный подход — это не мода и не тренд, это инструмент, который позволяет уменьшить риски, сократить расходы, а сроки достаточно явно контролировать. Именно такой разговор, а не борьба, определяет, получится у вас MVP или очередной слон; вопрос в том, готовы ли они вас услышать, но это уже из другой статьи, как мне кажется.

Вместо заключения

Возвращаясь к аналогии с привычкой — MVP это не урезанная версия финального продукта, это первый шаг, после которого становится понятно, куда идти и с чем работать. Как первое утро вашей будущей привычки. Оно не должно быть идеальным, оно должно случиться и начать жить, жить и продолжать совершенствоваться. А дальше — по шагу за раз, каждый из которых опирается на реальный опыт предыдущего.

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

Давайте честно, MVP — это не про размер, это про подход, и начинается он с одного простого вопроса: какая минимальная работающая версия нашего решения принесёт пользу — уже через месяц?

Если было интересно, забегайте в ТГ, там тоже иногда бывает интересно — Система или имитация