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

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

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

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

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

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

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

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

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

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

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

2. Требуется много ресурсов для минимизации юридических и финансовых рисков при взаимодействии заказчик – подрядчик, что приводит к длительному циклу реакции на изменения. В заказной разработке преобладают два подхода: по техническому заданию и подход «Время и материалы» (Time and Material, Т&М), при котором разработчики нанимаются на выработку определенного количества часов. Первый подход требует прогнозирования всех возможных рисков и высокой экспертизы в технической реализации этапов работ. Составитель ТЗ должен смоделировать заказываемое ПО «в голове» с учетом особенностей реализации, потенциальной нагрузки и внешних изменений (изменения в стороннем ПО, законодательстве и т. д.). Часто это чревато тем, что по окончании работ формируется второе, не менее увесистое ТЗ на доработки. Предсказуемость и ритмичность вносимых изменений в ПО может значительно меняться. Т&М – более оперативный подход, разработчики практически находятся в штате у заказчика, но обходятся они как специалисты, которые на ступень выше и эффективнее (см п.1).