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