Наш старый знакомый Роб Ингланд (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 полностью, заключает Роб.