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

Рис. 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. Потери из-за перепроизводства.

2. Потери времени из-за ожидания.

3. Потери при ненужной транспортировке.

4. Потери из-за лишних этапов обработки.

5. Потери из-за лишних запасов.

6. Потери из-за ненужных перемещений.

7. Потери из-за выпуска дефектной продукции.

Каждый из этих типов имеет свое проявление и в разработке цифрового обеспечения.

2.1.1. Потери из-за перепроизводства

В реальном производстве можно столкнуться с «затовариванием», когда готовая продукция или, что еще страшнее, ее компоненты заполняют складское пространство. Завод в этом случае сталкивается со следующими издержками:

1. Амортизация складской инфраструктуры.

2. Оплата труда персонала.

3. Учет и инвентаризация.

4. Простой капитала – «замороженные расходы» в производственных компонентах, не утилизированные в виде готовой продукции.

Распространенная стратегия оптимизации производства – это минимизация загрузки складов за счет точной по времени поставки исходного сырья и своевременной отгрузки.

Несмотря на то что в цифровом производстве нет складов, расходы на перепроизводство активно присутствуют:

1. Создание потенциально невостребованных артефактов. Избыточная документация – разработчики затрачивают часы на то, что не добавляет ценности продукту и не факт, что будет востребовано в будущем.

2. «Замороженные расходы» в промежуточных артефактах. Дизайн-макеты будущей функциональности, пока не будут утилизированы в виде поставки, остаются «замороженными» человеко-часами, которые потратила компания.

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

4. Учет движения перепроизведенных «полуфабрикатов» оттягивает внимание всех участников процесса.

2.1.2. Потери времени из-за ожидания

Тут у физического и цифрового производства много общего – час простоя сотрудника и/или производственной инфраструктуры безвозвратно утерян. В реальном производстве производственные цепочки выстраиваются таким образом, чтобы задержки между звеньями были минимальны. В цифровом производстве достаточно сложно достоверно прогнозировать длительность производства, поэтому прибегают к следующим тактикам для минимизации простоя:

1. Дробление артефактов. Большое улучшение внутри продукта разбивается на ряд «микроулучшений», разработку которых проще оценивать и прогнозировать. Более подробно об этом в главе про декомпозицию (5.2.2.7 Прояснение бэклога / Декомпозиция элементов продуктового бэклога).

2. Кросс-функциональность разработчиков. Знания в смежных предметных областях позволяют приступить к разработке, не дожидаясь бутылочного горлышка[6] – участия узкоспециализированного эксперта. (Подробнее об этом см. в п. 3.2.)

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