Чтобы обеспечить быструю обратную связь в технологическом потоке создания ценности, мы должны создать эквивалент шнура-андон и соответствующей обратной связи. Это требует также формирования производственной культуры, делающей использование шнура неопасным для того, кто за него потянул. Наоборот, поощряется сигнал, что нечто выходит из строя, будь то сбой в производстве или обнаружение ошибки, возникшей на предыдущих этапах, например, если кто-то вносит изменение, нарушающее непрерывный процесс сборки или тестирования.
Когда срабатывает триггер вышеупомянутого шнура-андон, мы собираемся вместе, чтобы решить проблему и предотвратить переход к новой фазе, пока сбой не будет устранен. Это обеспечивает быструю обратную связь для всех, кто задействован в потоке создания ценности (особенно для работника, повинного в сбое), позволяет быстро локализовать и диагностировать проблему, предотвращает дальнейшее накопление усложняющих факторов, скрывающих причину и следствие.
Предотвращая переход к новой фазе, мы осуществляем непрерывную интеграцию и развертывание — единый процесс в технологическом потоке создания ценности. Все изменения, проходящие непрерывную проверку сборки и интеграции, развертываются в производство, а любые изменения, заставляющие наши тесты «дернуть за шнур-андон», объединяют вокруг себя работников.
Продолжайте, улучшая качество кодаМы можем поневоле закрепить небезопасную систему, если не будем активно реагировать на аварии и происшествия. В сложных системах добавить проверок и этапов утверждения — значит увеличить и вероятность будущих сбоев. Полезность процессов утверждения уменьшается, если мы принимаем решение не там, где выполняем проект. Это не только снижает качество, но и увеличивает время, и ослабляет обратную связь между причиной и следствием, и уменьшает нашу способность извлекать уроки из успехов и неудач[33].
Подобное можно наблюдать даже в небольших и не очень сложных системах. Обычно иерархическая бюрократическая система управления неэффективна, когда несовпадение того, «кто должен это сделать», и того, «кто в действительности это делает», воздействует слишком сильно из-за недостаточной прозрачности и несвоевременности действий.
В качестве примеров неэффективного контроля качества можно привести следующие ситуации:
• требование к другой команде — выполнение трудоемких, подверженных ошибкам и исполняемых вручную задач, хотя их легко автоматизировать и запускать по мере необходимости, когда первая команда нуждается в выполненной работе;
• требуется утверждение результата другим человеком, занятым другими задачами и находящимся далеко от места выполнения работы, что вынуждает его принимать недостаточно компетентные решения или просто автоматически завизировать присланный документ;
• создание больших объемов документации с ненужными подробностями, устаревающими практически сразу после того, как записаны;
• раздача больших объемов работы в группы и специальные комитеты для утверждения и обработки и затем длительное ожидание ответа.
Вместо этого нужно, чтобы каждый человек, занятый в потоке создания ценности, искал и исправлял проблемы в своей зоне ответственности в рамках повседневной работы. Тем самым мы передаем исполнителю ответственность за качество и безопасность труда, чтобы работа фактически выполнялась, а не полагаемся на утверждение документов руководителями, находящимися на отдалении.
Мы используем взаимные проверки предлагаемых изменений, чтобы быть уверенными: изменения будут осуществляться как задумано. Мы автоматизируем максимальную часть проверок качества, обычно выполняемых тестировщиками или отделом информационной безопасности. Вместо того чтобы разработчики отправляли запрос на тестирование или ставили его в свой план, такие тесты выполняются по требованию, что позволяет разработчикам быстро проверить код и даже самостоятельно развернуть изменения в производственную среду.
При этом мы побуждаем каждого исполнителя, а не целое подразделение, отвечать за качество. Информационная безопасность — не просто работа отдела информационной безопасности, так же как доступность — компетенция не только отдела эксплуатации.
Если разработчики разделяют ответственность за качество систем, то они не только улучшают результаты, но и ускоряют процесс обучения. Это особенно важно для разработчиков, обычно наиболее удаленной от клиента группы. Гэри Грувер отмечает: «Разработчикам невозможно научиться чему-либо, когда на них кричат за то, что они сломали шесть месяцев тому назад, — именно поэтому нам необходимо обеспечить обратную связь для всех и как можно скорее, в течение минут, а не месяцев».
Включить оптимизацию на рабочих местах нижнего уровняВ 1980-е годы принципы проектирования для производства подразумевали разработку деталей и процессов таким образом, чтобы законченные изделия имели минимальную стоимость, максимальное качество и малое время изготовления. В качестве примера приводились чрезмерно асимметричные детали — их нельзя было установить неправильно, и проектирование шуруповертов — с их помощью невозможно слишком сильно затянуть гайки.
Это было отклонением от обычных правил конструирования. В них основное внимание уделяется внешним клиентам, а интересами изготовителей пренебрегают.
Бережливое производство определяет два типа клиентов, для которых нужно выполнять конструирование: внешний клиент (вероятнее всего, он платит за поставляемые услуги) и внутренний (получает и обрабатывает задание сразу же после нас). В соответствии с правилами бережливого производства наиболее важный клиент — это наш смежник: к нему ведет поток создания ценности. Оптимизация работы требует, чтобы мы вникали в его проблемы в целях более эффективного выявления проблем проектирования, мешающих быстрому и беспрепятственному течению потока.
В технологическом потоке создания ценности мы выполняем оптимизацию в интересах рабочих нижнего уровня потока, разрабатывая процесс, в котором операционные нефункциональные требования (например, архитектура, производительность, стабильность, тестируемость, конфигурируемость и безопасность) приоритетны так же высоко, как и пользовательские функции.
При этом мы формируем качество с самого начала, что с высокой вероятностью выразится в создании набора кодифицированных нефункциональных требований. Затем мы можем рационально интегрировать их в каждую созданную службу.
ЗаключениеСоздание быстрой обратной связи имеет важнейшее значение для достижения качества, надежности и безопасности в технологическом потоке создания ценности. Мы делаем это, обнаруживая проблемы по мере возникновения, объединяясь вокруг них и добывая новые знания, обеспечивая качество с начальных этапов и постоянно выполняя оптимизацию в интересах рабочих мест нижнего уровня.
Конкретные рекомендации, обеспечивающие быстрое течение потока создания ценности DevOps, представлены в части IV. В следующей главе мы расскажем о третьем пути — принципах обратной связи.
Глава 4. Третий путь: принципы непрерывного обучения и экспериментирования
В то время как первый путь описывает ход рабочего процесса слева направо, а второй — быструю и постоянно действующую обратную связь справа налево, третий путь протекает в постоянном обучении и экспериментировании. Для отдельных работников становится возможным постоянно создавать знания и превращать их из индивидуальных в общие, для команд и организации в целом.
В материальном производстве, где сохраняются систематические сложности с качеством и безопасностью, работы обычно жестко распределены и проводятся строго в соответствии с установленными правилами. Например, на заводе GM во Фримонте, описанном в предыдущих главах, сотрудники имели очень мало возможностей для применения улучшений и приобретенных знаний в повседневной деятельности, а все предложения что-либо улучшить «упирались в каменную стену безразличия».
В таких производственных средах зачастую существует атмосфера страха и недоверия: рабочих, допускающих ошибки, наказывают, а тех, кто предлагает усовершенствования или указывает на недостатки, рассматривают как провокаторов и смутьянов. В подобных случаях руководители активно подавляют обучение и