Продут или проект?
Холивар нужен для того, чтобы среди множества правильных ответов найти красивый 🙂 Отличия подходов, плюсы и минусы - мой взгляд на тему.

Давайте представим, что милая барышня решила завоевать сердце мужчины, воспользовавшись народной мудростью "Путь к сердцу мужчины лежит через его желудок". Как бы она действовала, выбери проектный подход? Правильно - конечно же составила бы план. Как без него. Итак, план:
1. Узнать, что любит мужчина - мясо или брокколи (правильный ответ, конечно же, мясо! 🙂 )
2. Сходить на кулинарные курсы
3. Приготовить самое вкусное мясо, чтобы уж точно поразить в самое сердце.

А как бы поступила барышня, выбери она продуктовый подход? Да просто бы попробовала. Приготовила бы - как умела, мясо и брокколи и посмотрела бы на реакцию. Брокколи попало бы явно ниже сердца, а вот мясо вполне могло бы открыть дорогу именно к сердцу.

Думаю, этого простого примера достаточно, чтобы понять разницу в подходах. Ключевые отличия сосредоточены в двух точках:
- Способ снижения риска "сделать не то" - не попасть в желаемую цель
- Отношения к изменениям в процессе работы

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

В продуктовом подходе риски снимаются за счет быстрых и недорогих итераций разработки и получением обратной связи от рынка или ключевых пользователей. Отношение к изменениям - максимально позитивное. Собственно, в них и состоит сила продуктового подхода - показатель time2market (время от возникновения бизнес-идеи до её первого воплощения в доступном для бизнес-пользователей виде) недосягаемо выше, чем у проектного подхода. А значит, ИТ-продукт будет успевать за бизнесом, который требует постоянных изменений.

Минусы проектного подхода очевидны:
- Заведомо низкий time2market - на детальную проработку, расшитие неопределённостей и согласования решения со стейкхолдерами занимает много времени
- Следствием низкого time2market становится увеличение общего количества рисков, могущих негативно повлиять на проект (представьте, что в нашем примере пока первая барышня занималась на курсах освоением техник прожарки стейков, другая барышня просто пришла бы к юноше с тортиком 🙂 )
- Высокий риск к концу проекта получить ситуацию, когда знания на начальной фазе проекта не соответствуют той ситуации, которая окажется в конце проекта (либо знания устарели, либо собирали знания с "экспертов", а не с реальных пользователей)

Продуктовый подход тоже имеет минусы:
- Риск ухудшить ситуацию новым изменением; причём, по разным направлениям - по функционалу, по дизайну или взаимодействию, по скорости работы. Этот минус является следствием скорости выхода новых фич.
- Риск замучать пользователей постоянными изменениями. Особенно это значимо в В2В-сегменте. Люди привыкают быстро, любое изменение - время на переучивание плюс страх "а если не пойму, не освою, меня же уволят". В итоге либо не будет качественной обратной связи, либо раздувается объем спринта\релиза, а с увеличением объема спринта риск "сделать не то" растёт в геометрической прогрессии.

Ну и резюмирую рекомендациями, когда какой подход стоит применять:
- Проектный подход берём в том случае, если на входе есть достаточное количество подтверждённых актуальных данных. И в том сегменте, где конкуренты позволяют иметь низкий time2market
- Продуктовый подход рулит в ситуациях, когда делаем что-то новое, когда нет явного аналога или накопленного опыта в виде формализованных знаний. И в том сегменте, где time2market не только имеет смысл, но ещё и достижим, с учётом необходимости пользователям часто осваивать что-то новое

Делайте выбор зряче!

Похоливарить в комментах можно в моём блоге: https://itpepper.mnikitin.ru/project-vs-product