Итак, мы c Димой Безуглым обсудили разницу между продуктовым и системным подходом. Впрочем, это был ход организаторов — я бы скорее говорил про реальный и декларируемый продуктовый подход, а пришлось защищать системный.

Но несколько небезынтересных идей удалось сформулировать.

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

Так вот посыл Димы, похоже — к интеграторам и внутренним отделам автоматизации, работающим по принципу "вы заказали — мы сделали". Для них продуктовый подход — это действительно открытие. Для них работает цепочка "процессный подход" - "проектный подход" - "продуктовый подход". Типа, автоматизируем отдельный процесс — что-то долго, и конца не видно. Ограничиваем результат по времени — автоматизация получается, ценности не получается, да и развитие не ограничивается однократной поставкой продукта (а контракт как раз ограничивается). Тогда перейдем на продуктовый подход — долгосрочную совместную работу по достижению бизнес-целей. Это и есть win-win, так решается "дилемма заключенного", сконструированная проектно-заказным способом организации работ.

Если очень нужно работать с внешней командой, а хочется продуктовый подход — есть способ организации работ "Retainer", вот про него в изложении Алексея Кулакова: https://speakerdeck.com/kulakov/razrabotka-produkta-vs-autstaf-vs-autsors

Ещё есть Agile Contracts: "Money for Nothing and Your Change for free" https://www.scruminc.com/agile-2008-money-for-nothing-2/

Но это всё про внешнюю разработку. Я же из другого мира. Никогда не работал в интеграторах, и редко работал на стороне исполнителя в заказной разработке. Моя сфера — внутренняя или продуктовая разработка. Конечно, внутренняя разработка может быть тоже устроена по принципам заказа и проектов, но это, в моем опыте, приводит к некачественным результатам. Развитие внутренних продуктов гораздо лучше работает, по всем параметрам. Поэтому у меня, честно говоря, даже мысли не возникает, что нужно убеждать кого-то в преимуществах продуктового подхода — а как ещё-то? И у меня вообще нет в голове разделения на заказчиков-разработчиков, как отдельных противостоящих друг-другу акторах. Когда речь идёт от win-win, мне и в голову не приходит, что это решение между бизнесом и разработкой. У вас разработка победила бизнес? Или бизнес победил разработку? Ну молодцы, что сказать. Я-то скорее думаю про win-win между бизнесом и клиентом.

И вот это меня больше всего сейчас интересует. Как изменить поведение пользователей? Наоборот, как продукт потенциально повлияет на поведение (и не навредит ли он). Как построить самораскручивающуюся систему? Как модернизировать не очень хорошо работающую систему — не ИТ, а социальную или организационную? И могут ли в этом помочь ИТ-системы?

И тут возникает тот самый "большой" системный анализ — анализ социальных, экономических и экологических систем. Правда, я так и не понял, где ему учиться, чтобы это было не сухое академическое знание, а практическое (хотя мощное влияние некоторых продуктов мы явно видим). Это как раз самое интересное, а не как какую-нибудь ещё одну программную систему создать.