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

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

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

MVP — это:
1. минимально достаточная версия продукта ⚙️ (критерий 1),
2. позволяющая получить обратную связь от реальных пользователей 👥 (критерий 2),
3. дающая бизнесу 💼 и пользователям ценность 🙌 (критерий 3).

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

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

Если коротко, то, конечно, есть. Но я бы не писала об этом, если бы все было так просто.

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

Сделаем шаг назад и попробуем описать термины «продукт» и проект» и их связь. Вот и все 😊. Собственно, на этом шаге и стала очевидна первопричина всех споров.

В классических стандартах PMBOK, PRINCE2, ISO 21500, ICB «продукт» рассматривается как конечный результат проектной деятельности под запрос. Например, нам заказали строительство дома. Проект – это вся деятельность: планирование, закупка материалов, работа строителей, контроль сроков и бюджетов. Продукт - сам дом, который мы получаем в конце целиком или по частям (кухня, гостиная и т.д.).

В Agile-методологиях Scrum, Kanban, SAFe, Lean «продукт» - это ценность, которая развивается и поддерживается итеративно, понятие «проект» почти исчезает.  Например, продукт – дом пригоден для жизни уже после первых итераций, но со временем только улучшается. Проект – работа с итерациями (Scrum), поток задач (Kanban), оптимизация процесса строительства (Lean). То есть в классических стандартах проект «больше» продукта, в Agile – наоборот. Важно, что здесь мы не говорим об однозначном соответствии классических стандартов со способом реализации, то есть сравнение классические стандарты vs Agile‑методологии это не то же самое, что и Waterfall vs Agile, ведь и в классических стандартах, например, PMBOK, описывается управление проектами через «гибкие» методологии.

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

Очень давно я чувствовала, что меня распирает от разных мыслей о профессии. Мои друзья больше не хотят слушать мои идеи о работе, и поэтому у меня созрел план поделиться мыслями с профессиональным сообществом и единомышленниками.

Скорость чтения публикации — 10 минут (но, я надеюсь, вы проведете время с удовольствием).

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

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

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