• Излишняя обработка: любые дополнительные задачи, выполняемые в рамках процесса, но не добавляющие ценности для клиента. Это может включать в себя написание документации, не используемой на рабочих местах нижнего уровня, или обзоров и утверждений, не добавляющих результирующей ценности. Излишняя обработка требует дополнительных усилий и увеличивает время.
• Излишняя функциональность: «фичи», встроенные в продукт, но не востребованные ни самой организацией, ни клиентами (так называемые блестяшки или украшательства). Излишние функции преумножают сложность продукта и усилия, требующиеся для тестирования и управления функциональностью.
• Переключение между задачами: когда сотрудник задействован в нескольких проектах и потоках создания ценности, необходимость переключаться между различными контекстами и зависимостями требует дополнительных усилий и затрат времени.
• Ожидание: любые задержки, требующие ресурсов: приходится ждать, пока они не освободятся. Задержки увеличивают время цикла и не дают клиенту получать ценность.
• Лишние движения: количество усилий, чтобы переместить информацию или материалы с одного рабочего места на другое. Лишние движения могут появиться, когда люди, нуждаются в частом общении, располагаются далеко друг от друга. Задержки также могут вызывать лишние движения и часто требуют дополнительных коммуникаций для устранения неясностей.
• Дефекты: неправильная, отсутствующая или неясная информация, неподходящие материалы или продукты создают потери, поскольку необходимы значительные усилия для решения этих вопросов. Чем больше времени проходит между появлением дефекта и его обнаружением, тем труднее устранить дефект.
• Ненормированная или ручная работа: расчет на ненормированную или проведенную вручную работу, которую должны сделать другие, — например, использование серверов, сред тестирования и конфигураций без функции восстановления. В идеале любые зависимости от отдела эксплуатации должны быть автоматизированы, находиться на самообслуживании и быть доступны по требованию.
• Геройство: чтобы организация могла достичь своих целей, отдельные лица или группы вынуждены порой выполнять чрезвычайные действия. Они могут даже стать частью повседневной деятельности (например, устранение проблем с производством, возникших в два часа ночи, создание сотен заявок на поддержку как обычную составляющую часть каждого выпуска ПО в производство)[29].
Наша цель — сделать прозрачными затруднения и потери везде, где требуется геройство, и систематически осуществлять все необходимое для их смягчения или устранения, чтобы достичь цели — ускорить поток создания ценности.
Улучшение процесса протекания технологического потока создания ценности много значит для получения результатов с помощью DevOps. Это достигается за счет того, что деятельность становится прозрачной, ограничивается НзП, уменьшаются размер партии и количество передач от сотрудника к сотруднику. Затем, в ходе повседневной работы, они устраняются.
Конкретные рекомендации, обеспечивающие быстрое течение потока создания ценностей DevOps, будут даны в четвертой части. В следующей главе мы расскажем о втором пути — принципах обратной связи.
Глава 3. Второй путь: принципы обратной связи
Первый путь — принципы, обеспечивающие быстрое протекание потока создания ценности слева направо. Второй путь включает принципы, позволяющие обеспечить быстрый и непрерывный поток обратной связи в противоположную сторону, справа налево, на всех этапах потока создания ценности. Цель — создать более безопасную и более устойчивую систему.
Это особенно важно при работе в сложных системах, где необходимо использовать первую же возможность, чтобы обнаружить и исправить ошибки, обычно тогда, когда возможны катастрофические последствия — производственная травма или активизация атомного реактора.
В технологических отраслях мы действуем почти исключительно внутри сложных систем с высоким риском катастрофических последствий. Как и в материальном производстве, мы часто обнаруживаем проблемы только при больших неудачах, таких как массовое производство неработоспособной продукции или нарушение безопасности в результате кражи данных клиента.
29
Хотя Мэри и Том Поппендики не включили геройство в категории потерь, мы это сделали в связи с высоким уровнем распространенности таких ситуаций, особенно при эксплуатации в случае систем, обслуживающих много клиентов.