Давайте рассмотрим каждую из этих причин более подробно.
1.1. Переход на собственную внутреннюю разработку
На определенном этапе цифровизации бизнеса, когда уже понятно, что разработка программного обеспечения становится постоянной статьей расходов, компании начинают переходить с внешней разработки (аутсорс) на внутреннюю (инхаус). На это есть ряд причин, которые мы и рассмотрим.
1. Стоимость внешних разработчиков обычно дороже, чем штатных. Подрядные организации, помимо расходов на оплату труда разработчиков, имеют расходы на поддержание численного состава и норму прибыли, а также риски простоя – это формирует добавленную стоимость для нанимателей. Естественно, при переводе сотрудников в штат расходы на фонд оплаты труда (ФОТ) и поддержание численного состава (рекрутмент, меры удержания) перекладываются на компанию-заказчика, но становятся более прозрачными.
2. Требуется много ресурсов для минимизации юридических и финансовых рисков при взаимодействии заказчик – подрядчик, что приводит к длительному циклу реакции на изменения. В заказной разработке преобладают два подхода: по техническому заданию и подход «Время и материалы» (Time and Material, Т&М), при котором разработчики нанимаются на выработку определенного количества часов. Первый подход требует прогнозирования всех возможных рисков и высокой экспертизы в технической реализации этапов работ. Составитель ТЗ должен смоделировать заказываемое ПО «в голове» с учетом особенностей реализации, потенциальной нагрузки и внешних изменений (изменения в стороннем ПО, законодательстве и т. д.). Часто это чревато тем, что по окончании работ формируется второе, не менее увесистое ТЗ на доработки. Предсказуемость и ритмичность вносимых изменений в ПО может значительно меняться. Т&М – более оперативный подход, разработчики практически находятся в штате у заказчика, но обходятся они как специалисты, которые на ступень выше и эффективнее (см п.1).
3. Подрядчики часто более заинтересованы в продаже большего количества часов, чем в эффективности вложений в эти часы. Идеальная ситуация, если интересы заказчика и подрядчика однонаправленны, но, к сожалению, часто можно увидеть, что подрядные организации склонны раздувать функциональность заказываемого ПО, а создаваемый код имеет высокую стоимость доработки и поддержки. Подход Т&М тоже не решает проблемы, так как в дополнение к разработчикам могут навязываться непроизводящие роли – менеджеры проектов, бизнес-аналитики и пр.
4. Защита ноу-хау. Имеют место случаи, когда подрядные организации заново используют разработки, предназначенные для других заказчиков. Это снижает их издержки, но при этом занижает конкурентные позиции первоначального заказчика.
5. Поддержка государства. Во многих странах 1Т-компании поддерживаются государством, что позволяет экономить на налогах, помещениях и иметь другие льготы.
1.2. Циклы доработки по стремительно сокращаются
Раньше можно было рассчитывать, что разработка останется неизменной в течение нескольких лет. Сейчас же можно увидеть, что крупнейшие IT-компании обновляют свои приложения несколько раз в неделю. Рассмотрим основные причины этого явления.
1. Культура копирования. В конкурентной борьбе участники активно копируют удачные решения. Это явление стало неотъемлемой частью процесса проектирования и разработки. Компании регулярно проводят сравнительный анализ конкурентов и исследования эффективности внедрений. Копировать лучшие решения становится обязательной практикой производства. (Подробнее о методах конкурентного анализа см. в п. 4.2.1.3.)
2. Ускорение технологического прогресса. Технологии развиваются и устаревают по экспоненциальному закону. То, что раньше было технологической инновацией и добавляло стоимости продукту, постепенно превращается в «гигиену» – бесплатную функциональность, без которой продукт просто не купят.
3. Изменения пользовательских технологических платформ. Устройства и операционные системы, необходимые для доступа к цифровым продуктам, постоянно обновляются, что требует регулярной актуализации ПО.
4. Изменение каналов распространения. Новые рекламные инструменты требуют дополнительных интеграций – систем отслеживания эффективности рекламных кампаний, дополнительных способов авторизации и платежей для экосистем.
5. Изменения поддерживающей инфраструктуры. Нагрузка на серверы выполнения ПО постоянно увеличивается не только из-за роста количества пользователей, но и в связи с увеличением объема вычислений на пользователя и ростом качества услуг (улучшение качества видео, инструменты на основе искусственного интеллекта и т. д.).
6. Регуляторные изменения. Интерференция волн технологических и социальных изменений заставляет регулирующие органы вводить все новые и новые требования, которые должны быть оперативно внедрены в продукт.
Все эти причины приводят к тому, что значительно сокращаются горизонты планирования. Даже месячные планы показывают, что 15 % теряет актуальность по окончании срока (табл. 1.2).
Табл. 1.2. Потеря актуальности планов в зависимости от сроков.
На основе более восьми лет наблюдений за бэклогами десяти различных команд, объемами поставленных и выполненных квартальных целей и реализации годовой стратегии
1.3. Непрерывное инвестирование и непрерывный возврат инвестиций
С точки зрения инвестора продуктовый подход к разработке можно сравнить с непрерывным потоковым венчурным инвестированием в череду микростартапов, или иначе – цифровых инициатив, которые запускаются внутри продукта (рис. 1.1).
Рис. 1.1. Каскад цифровых инициатив
Каждая инициатива – это своеобразный «продукт в продукте», который может находиться на разных этапах жизненного цикла.
Жизнь цифровой инициативы можно разделить на две фазы, каждая из которых, в свою очередь, состоит из нескольких этапов:
1. Фаза открытия (discovery phase), или фаза проектирования инициативы.
а. Концепция – этап первичной идеи цифровой инициативы, на котором определяются ее ключевые стратегические особенности:
I. сегмент потенциальных пользователей;
II. проблема пользователей, которую призвана решить инициатива;
III. совокупность решений, входящих в инициативу;
IV. источники доходов;
V. источники расходов
VI. и ряд других параметров, определяемых стейкхолдерами[5 - Стейкхолдер (англ, stakeholder – держатель акций) – в первичном понимании инвестор, вкладывающий средства в разработку. В больших компаниях – это лицо, отвечающее за эффективность инвестиций. В дальнейшем круг стейкхолдеров был расширен, и к ним стали причислять более широкий круг заинтересованных лиц, в частности пользователей-спонсоров, например представителей крупных корпоративных клиентов.] (заинтересованными лицами). Если стейкхолдеры видят инвестиционный потенциал в инициативе, то она переходит на следующую фазу проработки. (Подробнее о концепции цифровой инициативы см. в п. 4.2.)
b. Гипотеза – этап, на котором прогнозируются инвестиционные параметры цифровой инициативы: объем единоразовых инвестиций в разработку, постоянные и переменные издержки, срок выхода на прибыльность и окупаемость, доходность после окупаемости и стоимость задержки. Для моделирования используются внутренние данные компании, данные из открытых источников и отраслевые бенчмарки. В случае недостаточности данных формулируются продуктовые гипотезы – значения опережающих индикаторов, позволяющие максимально быстро определить жизнеспособность. На этой фазе принимается решение о разработке цифровой инициативы. (Подробнее см. в п. 4.3.)
2. Фаза поставки.
а. Минимальная жизнеспособная поставка – по аналогии с MVP, минимальная по затратам реализация, которая позволяет проверить продуктовые гипотезы.
b. Масштабирование – этап, на котором разработка ориентирована на то, чтобы инициатива в кратчайшие сроки охватила максимальное количество пользователей (рис. 1.2).
c. Оптимизация издержек – на этом этапе разработка сфокусирована на минимизации сопутствующих издержек поддержки инициативы.
Рис. 1.2. Зависимость дохода инициативы от этапа жизненного цикла
Подробнее о фазах открытия и поставки см. в и. 2.4.
Глава 2
Бережливое производство и бережливая разработка
Эволюционно продуктовый подход к разработке ПО опирается на гибкие подходы (Agile), самые распространенные из которых во многом базируются на бережливых подходах в разработке (Lean Development).
Особую популярность бережливый подход к разработке получил благодаря книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» Эрика Риса.
Бережливый подход базируется на концепции бережливого производства (Lean Production), которая стала переосмыслением производственной системы Toyota (Toyota Production System, TPS). На рис. 2.1. представлена схема эволюционной связи производственных подходов.
Рис. 2.1. Связь производственных подходов
Основные идеи бережливого производства – это минимизация отходов и принципы ориентации на максимальную ценность для потребителя.
2.1. Минимизация отходов
Отходы (muda) – очень большая и важная тема в бережливом производстве, включающая в себя не только прямые отходы, такие как остатки материалов или брак, но и процессы, которые не добавляют ценности конечному потребителю.
В бережливом производстве выделяют семь видов отходов:
1. Потери из-за перепроизводства.
