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

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

В цифровом производстве мы сталкиваемся с потерями из-за лишних запасов в случае предварительной закупки или аренды неиспользуемой инфраструктуры.

Одно из решений проблемы – на моменте старта и масштабирования продукта использовать облачную инфраструктуру. Многие поставщики таких услуг, как правило, используют гибкую систему ценообразования, когда оплата производится в зависимости от актуального потребления ресурсов.

Этот вид потерь можно сравнить с потерями на транспортировку, но речь идет о временных затратах на перемещение компонентов/изделий и инструментов внутри производственной ячейки[9]. Например, перемещение рабочего от изделия к ящику с инструментами и назад.

Для минимизации отходов при перемещении создается среда, где не нужно тянуться за инструментами и тратить время на поиски.

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

Для минимизации таких отходов следует использовать:

1. Инструменты, объединяющие в себе несколько производственных этапов, например создание дизайн-макетов, их анимация и подготовка для верстки.

2. Инструменты с автоматической доставкой артефактов, например плагин для экспорта графического макета в хранилище компонентов для фронтенд[10]-части продукта.

Потери из-за дефектной продукции включают:

1. Расходы на возврат дефектного продукта или партии.

2. Расходы на утилизацию дефектного продукта.

3. Расходы в связи со снижением спроса.

Во избежание таких потерь внедряются системы контроля качества.

Подобный подход применяется и в разработке цифровых продуктов в нескольких видах:

1. Ручное тестирование, осуществляемое QA[11]-инженерами.

2. Автоматическое тестирование – когда создается ПО, имитирующее взаимодействие с пользователями.

3. Автоматическое модульное тестирование (auto unit-test) – специальный код, создаваемый самими разработчиками для проверки созданной функциональности.

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

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

2. Прогрессивная раскатка (progressive rollout) – позволяет открывать функциональность постепенно на всю аудиторию, например по 10 % в неделю, и следить за возникающими проблемами.

3. Автоматический откат (automatic rollback) – в случае возникновения проблем функциональность приложения автоматически откатывается к предыдущей стабильной версии.

На уровне инженерных практик в процессе разработки вводятся критерии стабильности и критерии производительности для приемки разрабатываемого программного обеспечения. Например: «Время недоступности системы за последние 48 часов < 1 %», «Доля доступных функций за последние 48 часов > 99 %» и др. Более подробно критерии приемки, относящиеся к качеству разработки, мы рассмотрим в и. 3.3.