Менеджмент цифрового продукта. От идеи до идеала

После того как я более шести лет проработал в детской проектной парадигме, переход на продуктовый подход оказался для меня очень болезненным. Это случилось, когда я работал в Альфабанке. Мы только начали внедрять гибкий подход, многие вещи были совершенно не интуитивны и в отсутствие опыта Scrum[2] больше походил на Scream[3]. Скорее это был проектный подход, визуально замаскированный при помощи Agile-терминологии под продуктовый. Понадобилось несколько лет практики, тренингов и множество набитых шишек, чтобы осознать эффективность продуктового подхода, и теперь я с радостью готов поделиться опытом.

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

Проектный подход эволюционно появился из процесса управления коллективами программистов научно-исследовательских институтов, где впервые начало создаваться ПО на заказ (как правило, для крупных государственных или корпоративных заказчиков).

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

Ключевые отличительные особенности двух подходов отражены в сравнительной таблице 1.1.

Табл. 1.1. Ключевые различия продуктового и проектного подходов

Современные подходы к разработке могут сочетать в себе различные элементы двух миров. Например, защитив большое ТЗ перед заказчиком, производитель может реализовывать ПО короткими итерациями, регулярно тестируя инкрементальные улучшения[4] на реальных пользователях и минимизируя тем самым риски непопадания в сроки. В то же время даже при разработке внутренних продуктов под собственные нужды вводятся элементы проектной деятельности, например документы, описывающие видение инициативы целиком, аналогично ТЗ. В обязательном порядке в продуктовом подходе генерируется нормативная документация.

Почему компании выбирают вместо проектной деятельности продуктовую:

1. Переход на собственную внутреннюю разработку.

2. Короткие циклы усовершенствований ПО.

3. Непрерывное инвестирование и непрерывный возврат инвестиций.

Давайте рассмотрим каждую из этих причин более подробно.

1.1. Переход на собственную внутреннюю разработку

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

1. Стоимость внешних разработчиков обычно дороже, чем штатных. Подрядные организации, помимо расходов на оплату труда разработчиков, имеют расходы на поддержание численного состава и норму прибыли, а также риски простоя – это формирует добавленную стоимость для нанимателей. Естественно, при переводе сотрудников в штат расходы на фонд оплаты труда (ФОТ) и поддержание численного состава (рекрутмент, меры удержания) перекладываются на компанию-заказчика, но становятся более прозрачными.