Рассмотрим два из трёх принципов, которые, по мнению Gene Kim, определяют DevOps. Они сформулированы в его статье «Три пути: Принципы, поддерживающие DevOps» («The Three Ways: The Principles Underpinning DevOps») и подробно описаны им в книге «The DevOps Handbook». Так называемые второй и третий пути DevOps:
- создание постоянного быстрого потока обратной связи, что позволяет максимально рано выявлять проблемы и устранять их максимально быстро, не допуская передачи дефекта по потоку создания ценности (в сторону эксплуатации/потребления) и предотвращая повторения проблем (рис.1 [с сайта itrevolution.com, Copyright © 2017 IT Revolution])
- создание креативной культуры высокого доверия, поддерживающей экспериментирование и извлечение уроков как из успеха, так и из неудач, а также понимание того, что практика и повторение необходимы для достижения мастерства (рис.2 [с сайта itrevolution.com, Copyright © 2017 IT Revolution])
То есть в потоке создания ценности, конвейере, включающем и разработчиков и эксплуатацию, необходимо сделать так, чтобы информация об обнаруженных на любом этапе производственной цепочки ошибках передавалась обратно максимально быстро. Чтобы эти ошибки максимально быстро устранялись.
Но для повышения эффективности работы нас, конечно, будет интересовать не только устранение ошибок в продукте (о чём чаще всего рассуждают эксперты, описывающие DevOps), но также выявление и устранение отклонений в работе нашего конвейера. Т.е. того, что является причиной возникновения ошибок в продукте. Ну, и того, что является причиной возникновения причины… (вспоминаем метод «Пять «Почему?», используемый в том числе в процессе управления проблемами [problem management в ITIL] и в бережливом производстве [Lean]). Т.е. рис.2 усложнится (рис.31).
Вопрос в том, кто и как занимается этим анализом. Post mortem, ретр
оспективы и тому подобное. Участниками могут быть руководитель или тот сотрудник/группа, которому руководитель делегировал эту задачу (в частности специально выделенные для проведения такой работы люди, например, отдел методологии/качества). Участниками могут быть все члены команды или команда, которую для решения конкретной проблемы собирает так называемый лидер, назначаемый для решения этой проблемы (методика 8D в Lean). Спектр вариантов широк и зависит в том числе от организации. Но вне зависимости от частоты проведения мероприятий и состава вовлеченных, обычно есть какой-то координатор/организатор/фасилитатор (условно – «менеджер»). Тот, кто помогает команде «подняться над потоком» и увидеть возможные причины отклонений.
А кто помогает менеджеру? Что происходит, если в деятельности вышеописанного лица есть проблемы (которые приводят к тому, что работа по анализу проблем проводится хуже, чем могла бы). Не правда ли, похоже на известный парадокс2, упомянутый в заголовке данной заметки.
Здесь очень помогло бы участие команды. Но, очевидно, сценарий, в котором руководителю указывают на ошибки, в реальной жизни реализуется не так уж часто. Похоже, это один из критериев, по которым можно судить о выходе руководителя на более высокий уровень – способность организовать качественный канал обратной связи. И по указке такой механизм не заработает – требуются регулярно прикладываемые усилия со стороны руководителя.
Но и сказать, что это какой-то высший пилотаж тоже нельзя. Мне, например, не раз доводилось наблюдать, как подобная трансформация командной работы происходила за один (!) день. Правда, такой режим «быстрой перемотки» наблюдался в рамках деловых игр (например, в особенно популярной в последнее время игре, посвящённой DevOps). Да, игра отличается от жизни тем, что обеспечивает лабораторные условия, в которых можно экспериментировать более безопасно (в том числе без риска быть уволенным за критичные ошибки). Да, ведущий помогает выявить и попробовать новые практики, стимулируя эксперименты и поиск. Но, с другой стороны, в реальной жизни такая плотная череда задач и препятствий как в игре встречается довольно редко. И с учётом того, что в течение дня группа проходит через несколько кризисов, видеть, как некоторым командам удаётся реализовать такую трансформацию, доставляет отдельное удовольствие. Это внушает веру в то, что и в реальной жизни задача решаема в разумные сроки при соответствующих усилиях.
В любом случае, если мы заинтересованы в повышении эффективности, заниматься этой задачей нужно.
Вспомните, как обычно проходит и чем заканчивается подобный анализ у вас. Получает ли всегда руководитель достаточную для улучшения обратную связь? И, если да, то как он[а] этого добивается?
1 кстати, получилось очень похоже на, пожалуй, одну из самых философских картинок в ITIL про контуры управления («The ITSM monitor control loop» Figure 5.4 в книге «ITIL Service Operation» или Figure 7.6 в книге «The Official Introduction to the ITIL Service Lifecycle») {вернуться к тексту}
2 Может ли бриться цирюльник, ограниченный правилом «брить тех и только тех, кто не бреет себя сам»? {вернуться к тексту}
