Я давно работаю в крупных нефтегазовых компаниях, поэтому мой взгляд — изнутри энтерпрайза, где 5000+ сотрудников и любое изменение — это не «сделали и забыли», а «сделали, согласовали, интегрировали в инфраструктуру и в процессы».

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

Корректные и наиболее полные определения можно прочитать в респектабельных методологиях, а простыми словами:

MVP — это:

1. минимально достаточная версия продукта ⚙️ (критерий 1),

2. позволяющая получить обратную связь от реальных пользователей 👥 (критерий 2),

3. дающая бизнесу 💼 и пользователям ценность 🙌 (критерий 3).

   Раньше многие команды заявляли об успешном MVP, разработанном за 2-3 месяца. Быстрый time-to-market был очень важной характеристикой и КПЭ. Сейчас с внедрением ИИ агентов продакты начали вайбкодить и заявляют о кратном сокращении сроков – MVP за 2-3 дня.

Сидя и читая такие заявления с другой стороны экрана меня одолевают очень разные чувства. Порой мне кажется, что я работаю в отстающей отрасли, и как 🦖 динозавр юрского периода смотрю со стороны на далекие инновации 🚀. Ведь на внедрение первых работающих версии у нас уходило по 5 месяцев (в случае, если мы использовали имеющиеся платформы/технологии в компании), и по 12 месяцев для совершенно нового цифрового продукта. Да какие 12, иногда и больше, но я не буду писать ужасающие цифры :).

Да, крупные нефтегазовые предприятия неповоротливые, но неужели все настолько плохо? Давайте разбираться.

Консервативность нефтегазовой отрасли обоснована защитой данных от внешних и внутренних рисков. Неповоротливость крупных компаний и многоуровневость процессов и согласований тоже обоснованы – чем больше сотрудников, тем больше систем и процессов, тем больше дополнительных уровней менеджмента, тем больше времени на согласование, и так далее. Обоснованно ли это – да, мешает ли это – да, помогает ли это – тоже да. Поэтому эти две причины мы примем как данность, которую не можем изменить.

Как в крупном предприятии выглядит последовательность шагов при старте проекта – отображено в таблице и на графике.

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

Первая работающая версия на тесте компании – 13 шаг. Но там нет продуктивных данных, поэтому эта версия опять не приносит прямой ценности для бизнеса.

И только результат 21 шага – первая продуктивная версия с реальными пользователями. Вот теперь ценность для бизнеса появляется, вот теперь это реальный MVP, а все, что до – MVP не является.

И вот здесь и кроется разрыв в понимании терминологии. Иногда MVP называют версию на стенде подрядчика или на тестовом сервере. Но:

• нет реальных пользователей → не выполняется критерий 2 ❌👥

• нет ценности → не выполняется критерий 3 ❌💼❌🙌

 А теперь посмотрим на сроки при реализации проекта на реальном примере.

📅 План: 140 дней или 6 месяцев, можно исключить часть шагов, часть уже исключена, часть идет параллельно. Из 140 дней 100 дней запланировано на непосредственную разработку (шаг 10), остальные – на документацию и согласования. В реальности я еще ни разу не встречала проекты, которые бы укладывались в срок.

📈 Факт: 218 дней или более 10 месяцев. Да, это большое, но очень реалистичное отклонение, и это при том, что часть шагов была выполнена быстрее плана.

👉 10 месяцев с момента появления идеи до получения ценности со стороны бизнеса в виде первой версии MVP. И здесь я говорю про относительно позитивный и важный пример проекта.

 Да, на ретроспективе мы разобрали все причины, да, следующую дорожную карту мы скорректировали с учетом этих знаний, да, некоторые отклонения связаны с отсутствием ресурса, болезнями, непредвиденными рисками.

👉 Но факт остается фактом: в промышленном энтерпрайзе MVP за 2 месяца, а тем более за 2 дня — невозможен.

Правы ли вайбкодеры-продакты, делающие MVP за 2-3 дня? Думаю, правы. Но в своем контексте, где нет регламентирующих ограничений.

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

Как это можно «поженить» вместе и пользоваться единой терминологией? Сложно, но может помочь оценка уровня зрелости. Это помогает точнее синхронизировать ожидания. Вот только важно оценивать не только технологическую зрелость — TRL 🔬 (что лучше всего совпадает с продуктовой разработкой и где мы обычно говорим об этапах прототипирования, разработки MVP, доработке и интеграции). Но и оценку готовности производственных процессов и инфраструктуры — MRL 🏭 , рыночной готовности продукта — CRL 💵 и др. Подробнее об этом очень хорошо описано по ссылке 14 Readiness Level Frameworks: The Guide to TRL, MRL, SRL, and Beyond

 
📌 В заключение хочу сказать, что я одна из первых, кто ждет открытых возможностей по использованию облачных хранилищ ☁️, удобных ИИ-агентов 🤖 и новых технологий 🚀 для быстрой проверки и разработки продуктов в нашей отрасли. Надеюсь, это случится совсем скоро, предпосылки уже есть.

 Но пока этого не случилось, я возвращаюсь к своей презентации по новому продукту, где нужно объяснить почему MVP за 2 дня в нашем бизнес-процессе – это из области фантастики :).