В ИТ-индустрии сложился устойчивый миф: «проект — это плохо и по-старинке, а продукт — хорошо и современно».
Однако в основе выбора лежит не мода, а экономическая природа системы: помогает ли она зарабатывать или создает конкурентное преимущество. В статье разбираются критерии, по которым одни системы обречены вечно существовать в проектной парадигме, а другие требуют перехода на «продуктовые рельсы».
Почему нельзя «просто взять и сделать продукт»
Любая корпоративная система рано или поздно сталкивается с развилкой: продолжать жить в рамках жестких проектных ограничений или переходить к бесконечному циклу улучшений. Однако попытка насильно привить продуктовую культуру там, где нужен четкий проект, приводит к раздуванию бюджетов и срыву сроков.
Проект по своему определению имеет начало и конец, закреплённый в паспорте проекта или договоре. У него фиксированы сроки, бюджет и рамки требований. Основные KPI здесь — срок и бюджет. Все новые требования, даже если они улучшают систему, откладываются до следующего проекта, потому что иначе не достичь базовых показателей.
А продукт — это идея, жизнеспособность которой проверяется востребованностью клиентами. У него нет четкого срока завершения в классическом проектном понимании. Команда работает над непрерывным повышением ценности, а не просто над насыщением системы функциональностью согласно техническому заданию.
Ключевое противоречие: проект стремится к завершению, продукт — к постоянному улучшению и удовлетворению возрастающих запросов клиентов
Где заканчивается проект и начинается продукт
На первый взгляд, грань размыта: любой продукт когда-то мог быть проектом, а любой проект может породить продукт. Однако существуют принципиальные маркеры, по которым они расходятся в разные стороны.
Проектный подход:
- Уникальность и конечность. Система создается под определенные задачи конкретного заказчика
- Фиксированное ТЗ. Отклонения от изначального плана оформляются через дополнительные соглашения
- Методология: каскадная (водопад) с жесткими вехами. Последовательность этапов незыблема
- Мотивация: сделать решение, удовлетворяющее потребности заказчика, в рамках установленного бюджета
Продуктовый подход:
- Масштабируемость и повторяемость. Продукт тем эффективнее, чем лучше он тиражируется, принося ценность большему количеству пользователей
- Живой бэклог. Приоритеты могут меняться, какой-то функциональностью можно пожертвовать, если она не придает продукту добавленной стоимости
- Методология: гибкая (спринты), каждое улучшение сразу проверяется на пользователе
- Мотивация: улучшать клиентский опыт, убирать лишнее, повысить удовлетворенность, минимизируя экономические вложения и повышая тиражируемость (количество пользователей или продаж)
При обучении управлению проектами тренеры прямо говорят: не надо в проект вносить архитектурные улучшения и придумывать новые фичи. Усложнение решения и введение доп. опций противоречит ТЗ, влияет на сроки и как правило, увеличивает бюджет. Поэтому, для проекта это плохо.
Когда заказчик требует «улучшайзинг» по фиксированной цене
Наиболее наглядно конфликт проявляется в госсекторе и крупных корпорациях с годовым бюджетным циклом. В качестве примера можно привести опыт разработки цифровых сервисов для одной из крупных государственных структур.
В этой организации существует более десяти функциональных областей: субсидии, сертификация, поиск партнеров, обучение пользователей и так далее. Каждое направление — это отдельный набор проектов с жестким техническим заданием. Разработка программного обеспечения стартует после заключения договора, в котором зафиксирована стоимость, этапы, сроки и требования.
В процессе реализации, когда наступает момент выхода в опытную эксплуатацию, функциональный заказчик понимает, что некоторые элементы неудобны, атрибуты нужно перенести или добавить. И это звучит разумно — такие изменения действительно улучшают систему и делают ее более комфортной для пользователей.
Возникает коллизия. С точки зрения проекта требования согласованы, работа сделана, сроки подходят, нужно принимать и оплачивать. А с точки зрения продукта требования можно изменять бесконечно.
Безусловно, последние годы прикладываются усилия для достижения высокого уровня аналитики на старте проекта, а также происходит глубокое вовлечение представителей клиента и функциональных заказчиков в ход создания программных решений, что позволяет снижать проектные риски и показывать целевой результат.
Вывод: там, где бюджет жестко привязан к календарю и перечню работ («оплата за факт»), продуктовая модель не подходит. Это чистая проектная зона.
Зарабатывает или обслуживает?
Ответ на важнейший вопрос — какие системы переводить, а какие нет — лежит в плоскости уникальности и конкурентного преимущества.
Золотое правило: те системы, которые являются ноу-хау и основой бизнес-функции, на которой компания зарабатывает, имеет смысл делать как продукты. Системы, которые обеспечивают поддерживающие функции (например, бухгалтерские), — это классические проекты.
Какие системы НЕ нужно переводить в продуктовую модель:
1. Бэкофисные управленческие системы. Подрядчику ставится задача настроить ведение учета по стандартам, скажем, МСФО. Это проект. Регулятор транслирует требования — их выполняют. Нет задачи повышать здесь конверсию или кликабельность. Продукт из бухгалтерской системы не стоит делать, если вы не собираетесь его потом тиражировать и продавать
2. Инфраструктурные системы (Active Directory, почта, файловые хранилища). Их задача — стабильно работать. Инновации здесь вредят предсказуемости
3. Узкоспециализированные доработки под одного клиента. Если доработка нужна конкретному клиенту и не повышает ценность продукта для рынка в целом — это проект внутри клиента, а не бэклог продукта
Какие системы ОБЯЗАТЕЛЬНО переводить в продуктовую модель:
1. Системы, создающие конкурентное преимущество. Например, e-commerce витрина: нужно, чтобы человек в минимальное количество кликов нашел и купил товар. Это конкурентное преимущество. Если сделать лучше других — повысится конверсия. Это продукт, а не проект.
2. Клиентские цифровые сервисы (мобильный и интернет-банк). Например, ряд крупных банков с 2024 года позакрывали последние проектные департаменты, полностью перейдя на продуктовую модель. Мобильное приложение, электронная ипотека, кредиты — это постоянная работа над UI/UX, ликвидация лишних кликов и другие конкурентные преимущества.
3. Инструменты ускорения вывода на рынок. Если идет борьба за время запуска новых сервисов (так называемый тайм-ту-маркет), проектный подход не подходит. Проект закончится — и все. Нужно постоянное финансирование и команда, которая непрерывно генерирует улучшения
Симбиоз: как использовать продукты внутри проектов
Выгодный вариант для ИТ-компании и крупных корпораций — это не выбор между «либо-либо», а симбиоз. Продукт может выступать ускорителем проекта.
Иногда проще приобрести готовый продукт («лопату»), чтобы быстрее выкопать траншею и закрыть проект, чем создавать «землеройный инструмент» с нуля. Но иногда практикуется подход, когда накопленные за годы проектной работы модули (интеграционные шины, скоринговые сервисы, виджеты и т.п.) упаковываются в продукт. И если его можно тиражировать, то стоит попробовать проанализировать рынок на предмет заполненности решениями других игроков. Если ниша не переполнена и есть понимание ЦА, то можно пробовать выводить его на рынок, транслируя уникальное конкурентное преимущество.
При этом важно постоянно проверять гипотезы и проводить аналитику, а не исходить из предположения «это же круто, все купят». Ведь создавать продукт — это всегда дорого. Надо быть уверенным, что есть спрос.
Кто становится владельцем продукта — технарь или бизнес?
Еще один важный аспект границы — ответственность. В проектном подходе есть руководитель проекта и заказчик. В продуктовом — владелец продукта.
В крупных организациях как правило в продуктовую команду обычно включают представителя бизнеса. Именно он отвечает за клиентский путь и знает, что важно для пользователя, а что вторично
Однако идеальная формула для цифрового продукта — это гибридная ответственность ИТ и бизнеса:
- Бизнес-заказчик (или выделенный Product Owner из бизнеса) определяет «что» делать и зачем (ценность, метрики, приоритеты)
- ИТ-команда определяет «как» это сделать технически (архитектура, стек, спринты)
Бизнес не знает, что будет лучше с точки зрения технологий. А ИТ не знает, какую кнопку перекрасить, чтобы выросла конверсия. В продуктовой команде функциональный заказчик должен быть полноценным участником процесса, а не внешним источником требований.
Карта принятия решений для CIO и CDO
Чтобы понять, где проходит граница в вашей конкретной системе, нужно задать себе три вопроса:
1. Является ли эта система моим конкурентным преимуществом на рынке?
- Да → Продукт. Инвестируйте в постоянную команду и непрерывное улучшение.
- Нет (это «коммодити») → Проект. Внедрите и забудьте до следующей замены.
2. Могу ли я четко и однозначно описать требования «раз и навсегда»?
- Да (регулятор, налоговая, типовой учет) → Проект. Любой «улучшайзинг» здесь навредит
- Нет (поведение пользователей меняется) → Продукт. Нужны A/B-тесты и бэклог
3. Масштабируется ли ценность этой системы на тысячи пользователей?
- Да (банк, маркетплейс, HR-портал на 10 тыс. сотрудников) → Продукт. Экономия 5% времени каждого сотрудника окупит миллионные вложений
- Нет (автоматизация конкретного цеха для пятидесяти человек) → Проект.
Главный вывод: граница между проектом и продуктом проходит ровно там, где заканчивается предсказуемость и начинается борьба за лояльность клиента. Переводить в продукт имеет смысл только те системы, от скорости и качества изменений которых зависит рост финансовых показателей. Все остальное — удел жесткого и предсказуемого проектного управления.