Избавьтесь от CAB!

Наш старый знакомый Роб Ингланд (Rob England, The IT Skeptic) находится в очень боевом настроении духа и категорично предлагает ни много ни мало — пристрелить Комитет по изменениям (Change Advisory Board, CAB). Ну или поставить его в такие условия, чтобы он поборолся за свою жизнь, заслужив  право на существование. По всей видимости, посещение DOES17 (DevOps Enterprise Summit), не прошло для Роба без последствий.

Какой смысл ждать разрешения от CAB на проведение изменения, рассуждает Роб, когда изменение уже произошло? Система должна быть неработоспособной, чтобы CAB собрался, выработал решение, дал "зелёный" свет изменению. А нужно просто исправить ошибки в коде системы и уничтожить CAB. Всё.

На Facebook'е к Робу подтянулись единомышленники. Кто-то говорил про большие серии согласований внутри компании, где каждый из согласующих может сказать "нет", и изменение не пройдёт, но при этом никто не отвечает за конкретное изменение. Кто-то приводил примеры с подсчётом количества задействованных высокопоставленных участников мероприятия — директоров направлений и ИТ-руководителей — и потраченное количество трудочасов. Неэффективно и затратно.

CAB по мнению Роба — это компенсационный механизм, применяемый в организации для защиты продуктивной среды от изменений невысокого качества.А что же нужно делать и сделать, чтобы действительно быть готовым к изменениям? Роб перечисляет несколько пунктов:

  1. Назначьте ответственных за конкретную разработку. Единственными ответственными за неудачное изменение должны быть люди, кто её выполнял.
  2. Перестаньте выпускать дефектный код. Одна из функций CAB — с неохотой принимать список выявленных дефектов. Сместите фокус левее, прикладывая больше усилий в части улучшения качества и безопасности. Выдавайте качественный код, и смысл существования CAB окажется под вопросом.
  3. Выпускайте весь разработанный код полностью и определёнными циклами. Помечайте зависимости при планировании циклов, уточняйте на стадии интеграции разработки и идентифицируйте при завершении сборки.
  4. Ручная проверка полноты изменений неэффективна и подвержена ошибкам. Автоматизируйте рабочие процессы и согласования.
  5. Управляйте воздействием. Развертывайтесь поэтапно. Нужно иметь возможность выпускать код «втихую». Пусть постоянно идут небольшие релизы на небольшие группы пользователей, прежде чем начнётся более широкое распространение.
  6. В тех редких случаях, когда релиз оказывается неудачным, сделайте так, что его можно было исправить в течение рабочего дня...
  7. ...И исправьте. В некоторых организациях обычное изменение — самый быстрый путь в продуктивныую среду. И нет необходимости в экстренных изменениях. Подобные организации могут выпустить патч быстрее, чем вы соберёте ECAB (Emergency CAB) 🙂

А теперь заставим CAB выживать по его же принципам:

  • Каждый квартал (или любой другой период) заставьте членов CAB отчитываться о проделанной работе. С отчётами об эффективности, об обнаруженных ошибках, стоимости, рисках, влиянии на поток создания ценности, выгодах
  • Поскольку каждый член Комитета имеет право вето, то если кто-либо скажет "нет", сразу же завершайте заседание
  • Наблюдайте за результатом. Измените используемую политику проведения изменений и механизм реализации. Направьте на согласование всем членам Комитета. Дождитесь, пока каждый одобрит изменение
  • Проведите через месяц Post-Implementation Review
  • Если что-то пошло не так, соберите ECAB, чтобы решить, нужно ли возвращать практику проведения CAB
  • Каждый квартал каждый из участников Комитета анализирует данные по эффективности CAB
  • Повторите ещё раз

Роб предлагает, чтобы вместо монстрообразной тяжёлой бюрократической и во многом бесполезной махины, CAB уменьшился в размерах, сосредоточившись на определённых изменениях, которые представляют собой высокий риск из-за сложных зависимостей между командами и системами. Наступит день, когда мы "прибьём" CAB полностью, заключает Роб.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей Труфанов

    Вот правда! Эти набросы на вентилятор уже начинают порядком раздражать! Даже складывается ощущение, что дорогой IT скептик ни дня не работал с действительно крупным, распределенным ИТ. И уж тем более ничеда не отвечал за это головой. Важнейшая функция комитета по изменениям — это информирование, и governance в части проведения масштабных, сложных и многосвязных изменений в гетерогенной, территориально распределенной инфраструктуре. Управление и надзор над выполнением изменений и проектов там, где в регулярных работах массово участвуют с десяток подрядчиков и развит аутсорсинг, там, где для предоставления ИТ-услуг используются человеческие и технические ресурсы различных юридических лиц, например в рамках холдингов. Преобразования в государственных органах. Мне конечно сложно судить, но если ты (зачеркнуто) пивной ларек (\зачеркнуто) или Twitter, штат которого можно безболезненно сократить до 2-3 десятков человек практически без ущерба для бизнеса по размещению рекламы читателям и писателям сообщений в длиной в 140 букавок, то CAB тебе не нужен. Поддержим же Роба, славься наш светоч знания! Утомил.

    0
    0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ОКТ
19
ОКТ
23