Каймар Кару
перевод Романа Журавлева

Чтобы ответить на этот вопрос, давайте сначала разберемся, почему вы (или ваши коллеги) уверены, что ITIL (в вашей компании) – не agile, и на что это влияет.

Те дискуссии, где слова ITIL и agile оказываются вместе, обычно ведутся о том, как бы нам научиться быстрее делать то, что мы делаем. В этих дискуссиях, как правило, меньше говорят о командах и их взаимодействии (для этого ведутся DevOps-дискуссии) и о контурах обратной связи и постоянном обучении и улучшении (эти вещи, вообще-то, описаны в ITIL, но обычно игнорируются).

Есть несколько общих трудностей, относящихся к этой теме – мне не раз приходилось наблюдать, как с ними сталкиваются организации, использующие ITIL в ИТ-эксплуатации. (Хотелось бы написать «использующие ITIL в управлении ИТ-услугами», но, к сожалению, «управление ИТ-услугами» в большинстве компаний – это деятельность внутри команд эксплуатации, и ни о каком управлении полным жизненным циклом услуг речи не идет…)

Возможно, некоторые из этих трудностей вам приходится преодолевать в своей компании. Их нередко описывают как свидетельства того, что ITIL противоречит принципам agile – и, поскольку «в ITIL так написано», с этим противоречием ничего не поделаешь.

Как мы управляем изменениями: это точно не agile

В последние семь лет, в связи с развитием практик continuous integration / continuous   delivery, пожалуй, никакая другая тема в управлении ИТ-услугами не обсуждается так горячо, как управление изменениями.  Громоздкий и нередко болезненный процесс управления изменениями обычно включает в себя:

• Ежемесячные (или пару раз в месяц) заседания совета по изменениям (Change Advisory Board, CAB), на которых рассматриваются все поданные за период запросы на изменения
• Длинные списки лиц, согласующих изменения – несмотря на то, что многие из них не слишком разбираются в том, что согласуют, и не слишком зависят от предлагаемых изменений
• Большое число экстренных изменений, используемых как способ обойти установленный процесс, чтобы хоть что-то довести до конца в разумные сроки.

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

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

Разберемся в причинах

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

Следуя этим практикам, мы поддерживаем иллюзию контроля, прикрывая хрупкость ИТ-систем покрывалом ложного спокойствия.

Если бизнес требует улучшения нашего управления изменениями (обычно – в направлении большей гибкости и более высокой скорости реализации изменений), нелишним будет обратиться назад, к проектированию процесса, и спросить себя: а какие ожидались результаты от применения всех тех правил и процедур, которые мы тут организовали?

Для чего существует CAB? Чтобы поддерживать ЧСВ его участников, или чтобы корректно решать конфликты приоритетов между продуктами, услугами, командами с учетом бизнес-контекста? И могут ли эти задачи быть решены иначе, или могут ли текущие решения быть упрощены и оптимизированы, оставаясь при этом эффективными?

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

Что можно улучшить?

Вероятно, в вашей компании есть и другие практики, связанные с ITIL, не слишком успешно вписывающиеся в парадигму agile.

Говорится ли в ITIL, что организация должна разработать идеальный процесс перед тем, как начать его использовать? Нет. Вы можете внедрять сравнительно небольшие улучшения в те практики, которые уже работают – назовем результат, например, «минимальным жизнеспособным процессом» (minimum viable process). При этом важно помнить, что для заказчика важна приносимая вами ценность, а не объем формируемой при этом документации (это не повод отказываться от документации совсем – просто не увлекайтесь ей сверх меры). Да, такой процесс скоро потребует улучшения. И отлично. Постоянное улучшение – лучше попыток «внедрить все и сразу».

Говорится ли в ITIL, что на каждую описанную роль следует назначить отдельного человека? Нет. Роли описывают области ответственности, потому что так эти области легче понять. Неважно, как вы называете человека, который анализирует требования к доступности проектируемых услуг, пока кто-то это делает, и вы знаете, кто именно.

Говорится ли в ITIL, что разные задачи, поступающие к инженеру, должны находиться в разных очередях, по очереди на процесс? Нет. Для людей, совмещающих несколько ролей и работающих над разными задачами – решением инцидентов, анализом проблем, обслуживанием систем – постоянное переключение между очередями означает потери времени и постоянный стресс. Что важнее – решить инцидент среднего приоритета или разобраться с задержкой развертывания обновлений? Отслеживание отдельных категорий задач в некоторых случаях удобно для менеджеров, но организовав, например, канбан-доску для управления потоками работ, вы очень поможете перегруженным задачами сотрудникам.

Так что, может ITIL быть agile?

Тут я по-консультантски отвечу «зависит». Поскольку, в самом деле, ответ зависит от вас, от вашей компании.

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

Способность постоянно пересматривать и улучшать услуги, процессы и процедуры (ответы на вопрос «как») – ключевой фактор повышения гибкости. При этом компания может эффективно и постоянно совершенствоваться только если она понимает своих заказчиков. Только в этом случае она может оценивать возможности улучшения с точки зрения их влияния на ценность для заказчиков и бизнеса. Это и есть называется «agile».

Выходит, ответ на вопрос «может ли ITIL быть agile» – в том, может ли ваша компания быть agile.

ITIL® – торговая марка AXELOS Limited.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую