Портал №1 по управлению цифровыми
и информационными технологиями

Ключ на старт

keep-calm-and-master-the-releaseКаждый из тех, кто в своей жизни хоть раз занимался спортом, знает это ощущение. Это чувство трепета и волнения перед игрой, боем или показательным выступлением, охватывающее тело и разум.

Каждый из тех, кто продолжил свои занятия, также знает, что победить может только тот, кто уверен в своей победе. Победителем будет тот, для кого исход поединка предопределен, и для волнения попросту нет места.

Каждый раз, когда мне приходится заниматься внедрением продукта или процесса, запуском в работу функционального модуля, наступает момент, когда в продуктивную среду вносятся значительные изменения, и весь организационно-технический комплекс, включающий в себя софт, оборудование и людей должен начать работать по новым правилам.

Эту работу (а в особенности сам релиз и запуск) не удастся успешно организовать и выполнить, если в голове и руках команды не будет той самой уверенности победителя. Да и вообще, зря волноваться вредно, особенно там, где волноваться бы и не нужно.

Для того, чтобы быть уверенным в том, что все пройдет в соответствии с нашими ожиданиями, я использую древнюю как клинопись, но от этого не менее результативную практику чек-листов.

Мой подход к подготовке этих чек-листов достаточно прост:

  1. Разбиваем нашу зону ответственности на несколько областей. Определить их нам помогает структура ресурсов услуги (4 "P"):
  • People (Люди)
  • Partners (Партнеры, заинтересованные стороны)
  • Products (продукты и технологии)
  • Processes (Процессы)
  1. Заполняем эти области контентом, задавая себе вопросы "Что должно быть сделано?", так, чтобы эта составляющая не становилась стоп-фактором для предстоящего изменения.

Приведу несколько примеров:

Люди

  1. Все ли пользователи обучены?
  2. Готовы ли супер-пользователи оказывать первичную поддержку?
  3. Присутствуют ли в достаточном количестве расходные, демонстрационные, обучающие материалы?
  4. Какова готовность команды администраторов и группы первичной поддержки?
  5. Проведена ли информационно-разъяснительная работа среди пользователей?
  6. Готовы ли пользовательские материалы, инструкции, портал самообслуживания, личный кабинет?

Партнеры

  1. Готовы ли подрядчики и поставщики к работе в новых условиях/по новым правилам?
  2. Готовы ли коллеги, с которыми мы осуществляем информационный обмен к изменению?
  3. Проведена ли заранее разъяснительная кампания и готовы ли мы к поддержке партнеров (для случая, когда изменение затрагивает их процессы и чувствительные для них данные существенным образом)?
  4. Готова ли разрешительная и нормативная документация?
  5. Получено ли разрешение от колег из информационной безопасности, с учетом требований к технологиям и данным.

Продукты

  1. Вся ли функциональность разработана и протестирована?
  2. Готовы ли интеграции, обмен с шиной данных?
  3. Готовы ли API и публичные информационные сервисы к публикации?
  4. Настроена ли система мониторинга?
  5. Проведен ли нагрузочный стресс-тест? 

Процессы​

  1. Определены ли ответственные?
  2. Все ли участники процессов знают свои роли и обязанности?
  3. Разработаны ли методика и инструментария для измерения процесса?
  4. Новая редакция процессов заранее опубликована и готовится вступить в силу?

 

  1. Систематизируем собранные знания в виде некоторого плана, карты со стикерами, доски в Trello или наскального рисунка. Это даст нам очевидную возможеность быстро и наглядным образом ответить на вопросы о нашей готовности и добавить в эту живописную картину забытые нами факторы риска или артефакты, являющиеся обязательными результатами изменения. 

 

Мой подход достаточно прост и не требует особенных затрат или инструментов. Есть понимание, что в силу определенных обстоятельств, он лучше работает, если мы говорим о дискретных преобразованиях при водопадном способе выполнения изменений/релизов.

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

То как вы готовитесь к релизу, зависит от наших практик и подходов, личных предпочтений, масштаба изменений и зрелости команды.

Я своим способом поделился, поделитесь и вы. 🙂

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM