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

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

И проблема здесь не в терминологии. Проблема в том, как принимаются решения о том, что попадёт в первый релиз.

Как из MVP получается слон?

Сценарий по факту один и тот же каждый раз, ничего нового не происходит.

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

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

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

Ну и как вы думаете, кто же возьмёт реализацию такого слона на себя? Конечно же, героев особо не находится, и все потихоньку начинают пытаться слиться под различными благовидными предлогами. По итогу, конечно, найдут в кого впихнуть невпихуемое - но какой из этого толк, если пилиться это всё будет долго, а за то время, пока это делается, бизнес-контекст уже несколько раз поменяется. Хорошо ещё, если заказчик не решит постоянно раздувать scope новыми требованиями. А если решит? Уныние → героизм → выгорание → варианты спасения тонущего корабля.

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

А при чем тут привычки?

Чтобы понять, почему настоящий MVP работает, а раздутый - нет, давайте рассмотрим привычную для всех аналогию - формирование привычки.

Представьте, что вы решили изменить свою жизнь с понедельника. Не просто чуть-чуть, а серьёзно: вставать в 6 утра, пробегать 10 километров, есть овсянку на завтрак, медитировать 20 минут, читать час перед сном и учить английский по 30 минут в день. Всё это одновременно, с первого дня, без исключений. Я надеюсь, что в 2026 году не осталось людей, которые свято верят, что засунув это всё в первый же понедельник, их мотивационный запал не закончится уже в четверг - ну или максимум в воскресенье с утра.

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

С привычками все более-менее понимают эту логику. Никто в здравом уме не советует «просто начать жить идеально с завтрашнего дня». Все знают, что работающая методика - это одна маленькая привычка за раз. Сначала - просто вставать в 6:45. Через две недели, когда это стало нормой - добавить короткую разминку. Ещё через месяц - пробежку. И так далее. Каждый шаг закрепляется, встраивается в жизнь, становится автоматическим - и только после этого добавляется следующий.

Так вот, вопрос: почему на этапе проектирования IT-проекта мы действуем ровно наоборот?

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

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

А может начать с малого?

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

Даже когда команда согласилась не запихивать всё в первый релиз, она всё равно часто пытается спроектировать первый MVP как кросс-функциональную историю. То есть - сразу с интеграциями между несколькими департаментами, с участием нескольких команд-стейкхолдеров, с процессами, которые проходят через полкомпании. Логика понятная: если уж делать, то сразу так, чтобы приносило пользу многим. Проблема в том, что кросс-функциональный MVP - это уже не MVP, а миниатюрная копия того самого слона, от которого мы только что пытались откреститься.

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

Есть ощущение, что правильный подход - другой. Начинайте с процессов внутри своего департамента. Тех, где вы контролируете и постановку задачи, и исполнение, и приёмку результата. Где не нужно ни с кем согласовывать интеграционные API, где не нужно ждать подтверждения от смежников и где можно быстро что-то поменять, если пошло не так. Это ваша песочница. Место, где идея должна доказать свою жизнеспособность в максимально контролируемых условиях.

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

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

Почему итерационный подход выигрывает?

Разобрали, что делать не надо. Теперь давайте про то, почему итерационная модель - это не просто «модный agile», а действительно рабочий способ доводить проекты до результата. Причин несколько, и каждая из них знакома любому, кто бывал на проектных комитетах.

Быстрая обратная связь. При классическом подходе с огромным scope вы получаете результат через год. При итерационной модели - через несколько недель. И вот тут начинается интересное. Оказывается, что решение, которое казалось очевидным на этапе проектирования, в реальности работает совсем не так, как ожидалось. Пользователи используют его иначе, находят неочевидные проблемы или, наоборот, обходят функции, которые команда считала ключевыми. Раннее осознание реальности экономит месяцы бесполезной работы.

Управляемый риск. В большом проекте если что-то пошло не так, вы теряете весь бюджет и всё время. В итерационном подходе цена ошибки - один спринт. Что-то не сработало? Разобрали, скорректировали, идём дальше. Понятное дело, что все мы ошибаемся и все мы люди, при этом ошибки становятся дешевле и они менее катастрофичны.

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

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

Прозрачность прогресса для бизнеса. Один из самых больных вопросов больших проектов - «где мы сейчас?». Ответы вроде «мы работаем, всё будет» никого не устраивают, а объективно оценить статус огромного scope достаточно сложно. При итерационном подходе бизнес видит реальный, работающий результат каждый спринт. Это снимает 90% тревожных вопросов и построенных на них конфликтов.

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

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

Почему бизнес всё равно тянется к слонам?

Если итерационный подход настолько выигрышнее, возникает разумный вопрос - почему тогда компании раз за разом всё равно скатываются к раздутым MVP и монолитным проектам? Причин несколько, и большинство из них - не про технологии, а про психологию принятия решений.

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

Страх, что «маленькое не впечатлит спонсора». Внутри крупных компаний проекты часто продаются наверх - и здесь работает своя логика. Куратор проекта хочет показать генеральному большой, амбициозный результат. «Мы внедрили инструмент в одном отделе» звучит не так солидно, как «мы запустили комплексную кросс-функциональную платформу». Это ловушка, потому что первое реально работает, а второе часто существует только в презентации.

Иллюзия, что «мы уже собрали все требования». Когда команда полгода собирала требования, документировала процессы, согласовывала с десятью стейкхолдерами - психологически очень сложно потом сказать «а давайте выберем 20% из этого и сделаем сначала их». Кажется, что вся эта работа была зря. Хотя на самом деле - не зря, просто она теперь должна лечь в бэклог, а не в первый релиз.

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

Ну и чего дальше делать со всех этой информацией?

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

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

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

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

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

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