Самое короткое объяснение разницы между проектом и продуктом, которое я придумал за годы работы, звучит так: свадьба это проект, а брак это продукт. У свадьбы есть дата, бюджет, список гостей, подрядчики, план рассадки и чёткий критерий завершения: гости разошлись, значит, всё. Брак так не работает. У него нет даты окончания в плане, его нельзя сдать по акту, и если отнестись к нему как к проекту, который успешно завершён в день торжества, последствия будут предсказуемы.
Шутки шутками, но путаница между этими двумя понятиями стоит компаниям огромных денег. Я вижу её почти в каждом втором новом обращении, и почти всегда она проявляется одинаково: систему сделали, сдали, команду распустили, а через полгода всё развалилось, потому что жить с этим продуктом никто не планировал.
Проект заканчивается, продукт живёт
Проект это временное предприятие с конкретной целью. У него есть начало и конец, ограниченный объём работ, бюджет и срок. Когда цель достигнута, проект закрывается. Его успех измеряется просто: сделали ли мы то, что обещали, в срок и в бюджет.
Продукт живёт, пока приносит пользу рынку. Его успех измеряется совсем другими вещами: пользуются ли им люди, платят ли за него, возвращаются ли, рекомендуют ли другим. У продукта нет финальной точки, есть только версии. Сегодняшняя версия лучше вчерашней, завтрашняя должна быть лучше сегодняшней, иначе конкуренты займут Ваше место.
В одной из своих статей я писал, что у продукта есть свой треугольник успеха: клиенты, конкуренты и технологии. Именно это предмет анализа продукта. А для создания продукта нужен проект, и у проекта свой треугольник: объём работ, бюджет и время. Это два разных треугольника, и задача хорошего руководителя не путать, какой из них он сейчас решает.
Продукт создаётся цепочкой проектов. Каждый проект заканчивается, продукт продолжается.
Две классические ошибки
Первая ошибка: относиться к продукту как к проекту. Компания заказывает систему, получает её, подписывает акт и считает, что вопрос закрыт. Бюджет на развитие не заложен, ответственного за продукт внутри нет, команда, которая всё строила, ушла на другие задачи. Первые месяцы всё работает. Потом меняется законодательство, обновляется браузер, бизнес открывает новое направление, пользователи просят то, о чём никто не думал. И выясняется, что дом построили, а жить в нём никто не умеет: протекает кран, и непонятно, кого звать.
Вторая ошибка обратная: относиться к проекту как к продукту. У работы нет чётких границ, в неё постоянно добавляются новые хотелки, срок сдвигается, потому что «а ещё было бы здорово». Проект превращается в бесконечный ремонт, который никогда не заканчивается и никогда не начинает приносить пользу. Я видел системы, которые разрабатывались годами и так и не вышли к пользователям, потому что их всё время улучшали. Это продуктовое мышление, применённое там, где нужно было проектное: сначала закончить, потом развивать.
Разные команды, разные роли
Из этой разницы вытекают и разные подходы к людям. Проектная команда собирается под задачу. В ней нужны люди, которые умеют быстро войти в контекст, сделать работу и передать результат. Руководит ею проектный менеджер, его главные вопросы: успеваем ли, укладываемся ли, всё ли учтено.
Продуктовая команда стабильна. Она годами живёт с одной системой, знает её историю, помнит, почему было принято то или иное решение. Ею руководит владелец продукта, и его вопросы другие: что нужно пользователям, что делают конкуренты, что принесёт больше ценности в следующем квартале. Это не лучше и не хуже проектного подхода, это просто другая профессия.
Небольшие компании часто не могут позволить себе отдельную продуктовую команду, и это нормально. Но кто-то внутри должен выполнять эту роль. Хотя бы один человек, который думает о системе как о живом организме, а не как о сданном объекте.
Что это меняет в договоре и в деньгах
Различие проекта и продукта прямо влияет на то, как строить отношения с подрядчиком. Проект можно и нужно оценивать фиксированно: вот объём, вот срок, вот цена. Для этого объём должен быть понятен и зафиксирован. Продукт так оценить нельзя, потому что его объём заранее неизвестен по определению. Для развития продукта лучше подходит модель постоянной команды или регулярного бюджета на итерации.
Когда клиент просит «сделать продукт под ключ за фиксированную цену», я объясняю, что мы можем сделать фиксированный первый проект: первую версию с понятным объёмом. А дальше продукт будет развиваться следующими проектами, и бюджет на это нужно планировать заранее, как планируют обслуживание автомобиля при покупке. Машину можно купить по фиксированной цене. Ездить на ней бесплатно нельзя.
Именно поэтому в Ingello мы используем Fractal: когда первая версия описана декларативно и сгенерирована, следующие проекты в жизни продукта становятся дешевле, потому что меняется описание, а не тысячи строк ручного кода.
Что сделать завтра
Посмотрите на системы, которыми пользуется Ваша компания, и для каждой ответьте на три вопроса. Это проект или продукт? Кто отвечает за его развитие после запуска? Сколько в год Вы закладываете на это развитие? Если на второй вопрос ответ «никто», а на третий «ноль», то у Вас не продукт, а свадебное платье в шкафу: красивое, дорогое и больше никогда не пригодится.
