Каждый из тех, кто в своей жизни хоть раз занимался спортом, знает это ощущение. Это чувство трепета и волнения перед игрой, боем или показательным выступлением, охватывающее тело и разум.
Каждый из тех, кто продолжил свои занятия, также знает, что победить может только тот, кто уверен в своей победе. Победителем будет тот, для кого исход поединка предопределен, и для волнения попросту нет места.
Каждый раз, когда мне приходится заниматься внедрением продукта или процесса, запуском в работу функционального модуля, наступает момент, когда в продуктивную среду вносятся значительные изменения, и весь организационно-технический комплекс, включающий в себя софт, оборудование и людей должен начать работать по новым правилам.
Эту работу (а в особенности сам релиз и запуск) не удастся успешно организовать и выполнить, если в голове и руках команды не будет той самой уверенности победителя. Да и вообще, зря волноваться вредно, особенно там, где волноваться бы и не нужно.
Для того, чтобы быть уверенным в том, что все пройдет в соответствии с нашими ожиданиями, я использую древнюю как клинопись, но от этого не менее результативную практику чек-листов.
Мой подход к подготовке этих чек-листов достаточно прост:
- Разбиваем нашу зону ответственности на несколько областей. Определить их нам помогает структура ресурсов услуги (4 "P"):
- People (Люди)
- Partners (Партнеры, заинтересованные стороны)
- Products (продукты и технологии)
- Processes (Процессы)
- Заполняем эти области контентом, задавая себе вопросы "Что должно быть сделано?", так, чтобы эта составляющая не становилась стоп-фактором для предстоящего изменения.
Приведу несколько примеров:
Люди
- Все ли пользователи обучены?
- Готовы ли супер-пользователи оказывать первичную поддержку?
- Присутствуют ли в достаточном количестве расходные, демонстрационные, обучающие материалы?
- Какова готовность команды администраторов и группы первичной поддержки?
- Проведена ли информационно-разъяснительная работа среди пользователей?
- Готовы ли пользовательские материалы, инструкции, портал самообслуживания, личный кабинет?
Партнеры
- Готовы ли подрядчики и поставщики к работе в новых условиях/по новым правилам?
- Готовы ли коллеги, с которыми мы осуществляем информационный обмен к изменению?
- Проведена ли заранее разъяснительная кампания и готовы ли мы к поддержке партнеров (для случая, когда изменение затрагивает их процессы и чувствительные для них данные существенным образом)?
- Готова ли разрешительная и нормативная документация?
- Получено ли разрешение от колег из информационной безопасности, с учетом требований к технологиям и данным.
Продукты
- Вся ли функциональность разработана и протестирована?
- Готовы ли интеграции, обмен с шиной данных?
- Готовы ли API и публичные информационные сервисы к публикации?
- Настроена ли система мониторинга?
- Проведен ли нагрузочный стресс-тест?
Процессы
- Определены ли ответственные?
- Все ли участники процессов знают свои роли и обязанности?
- Разработаны ли методика и инструментария для измерения процесса?
- Новая редакция процессов заранее опубликована и готовится вступить в силу?
- Систематизируем собранные знания в виде некоторого плана, карты со стикерами, доски в Trello или наскального рисунка. Это даст нам очевидную возможеность быстро и наглядным образом ответить на вопросы о нашей готовности и добавить в эту живописную картину забытые нами факторы риска или артефакты, являющиеся обязательными результатами изменения.
Мой подход достаточно прост и не требует особенных затрат или инструментов. Есть понимание, что в силу определенных обстоятельств, он лучше работает, если мы говорим о дискретных преобразованиях при водопадном способе выполнения изменений/релизов.
Если мы будем опираться на Scrum, то хоть наш набор вопросов и изменится, все равно на значительную часть из них нам придется отвечать на каждом последующем спринте. Например, может измениться подход развертывания технического решения и функциональности с пары Push-Push, на пару Push-Pull, если у нас не будет возможности подготовить всех пользователей к вносимым изменениям в рамках одного спринта, и это очевидно повлияет на нашу подготовку к релизу.
То как вы готовитесь к релизу, зависит от наших практик и подходов, личных предпочтений, масштаба изменений и зрелости команды.
Я своим способом поделился, поделитесь и вы. 🙂
