Любой бизнес — от индивидуального предпринимателя до крупной международной компании — вынужден адаптироваться под запросы рынка и потребности потребителей. А поскольку сегодня бизнес практически неотделим от ИТ: потребность в изменениях бизнес-процессов = потребности в изменениях в ИТ.
Изменения могут носить эпизодический характер, быть шаблонными и регулярными, малыми и большими по объему, масштабу и бюджету. Однако, изменения — не всегда про улучшения. Иногда, если что-то работает ну уж слишком хорошо, можно это и «ухудшить» в хорошем смысле этого слова. Например, снизить уровень сервиса, или сделать круглосуточную службу некруглосуточной.
Немного теории
По классике, большинство изменений в ИТ реализуются в проектной и операционной деятельности.
Проекты — внедрение нового или изменение существующего функционала ИТ. Могут реализовываться как в рамках индивидуальных проектов, так и в рамках портфеля или программы проектов.
Операционная деятельность — запросы на изменения. Важно: это те запросы на изменения, которые могут быть инициированы через службу поддержки, и во многих организациях, с точки зрения процессной методологии, эти процессы находятся рядом с инцидентами и запросами на обслуживание. Это те изменения, которые описаны в библиотеке ITIL в разделе Change Management (Управление изменениями). Но об это в другой раз.
С точки зрения методологии
Запрос на изменение (RFC) — это формальное предложение на внесение изменений в ИТ-систему, процесс или сервис. Он является частью процесса Управления изменениями и служит для документирования, оценки и последующего утверждения изменений, выходящих за рамки стандартных операций.
Проект — это врЕменная деятельность, направленная на создание уникального результата, будь то продукт, услуга, мероприятие и т. п., в условиях временнЫх и ресурсных ограничений.
У обоих подходов есть свои достоинства и свои недостатки.
Так, запросы на изменения обычно тяготеют стать «штатными» или «шаблонными» операциями. Они выполняются по четкому алгоритму и, как правило, предварительно согласованны менеджером по изменениям и не требуют дополнительных телодвижений. Просто делай всё по шаблону и/или инструкции. Реализовать что-то нестандартное, нешаблонное, новое или отличающееся от штатного функционала и требующее «включить мозг» и пофантазировать, в таком процессе, как правило, оооочень сложно.
В целом такой подход имеет право на существование и даже свои преимущества. Процессами с таким подходом проще управлять, проще обучать людей, не нужно следить за текучкой «самых ценных кадров», да и в целом стоит помнить правило, что «лучшее – враг хорошего».
Недостатки такого подхода, естественно, сводятся к тому, что нестандартное и нетиповое в таком процессе невозможно.
В свою очередь, проекты, особенно в крупных организациях, — массивные, монструозные артефакты, частенько чрезмерно церемониальные и бюрократичные. Их просто так не откроешь и не закроешь. Как правило, решения об открытии/закрытии проектов принимаются на уровне руководства организации, иногда даже на уровне Генерального Директора. Проекты могут длиться годы. Нередки ситуации, когда проект близок к завершению, а его цель уже устарела, или уже не требуется для компании.
Конечно, есть исключения и из этого правила. Иногда проектом может называться любая нестандартная деятельность, дающая уникальный результат и длящаяся неделю. Однако в большинстве случаев реализация каких-то нестандартные функций или фич, доработка системы, или даже отрисовка дополнительной кнопки в пользовательском интерфейсе — это не история проекта. Любой руководитель проекта скажет «идите в поддержку или к разработчикам». Поддержка в свою очередь на это скажет «идите в проект» и в чем-то будет права.
Замкнутый круг…
Так что же делать, когда есть бизнес-потребность в реализации быстрых полезных изменений в ИТ? Куда идти и с кем решать вопрос, когда изменение, кажется, что небольшое, но нужно включить «голову», немного нестандартно подойти к решению вопроса без бюрократии, согласований, ритуалов и прочего?
ЗОДы
В нашей компании внедрен процесс управления Задачами Операционной Деятельности (сокращенно – ЗОД).
По определению из регламента, ЗОД — Задача на доработки функциональности существующих автоматизированных систем, инициированная Заказчиком. Если проще, в нашем понимании, ЗОД — нечто среднее между запросом на ИТ изменение и небольшим проектом.
Управление ЗОДами — отдельный процесс, у которого есть Владелец, Бизнес-заказчики почти от всех бизнес-блоков, менеджеры различных этапов процесса, свои аналитики, тестировщики, прочие ресурсы, и, самое главное, — отдельный от проектов и операционной деятельности бюджет. Обычно бюджет определяется на календарный год и ограничен некой фиксированной суммой, однако бюджет, как правило, закачивается раньше, и приходится запрашивать дополнительные средства.
В ЗОДы попадают запросы на уже существующие системы. Все новые системы внедряются в соответствующих проектах. Внедренная система передается в промышленную эксплуатацию, и дальнейшее развитие происходит уже в ЗОДах. Бывает, что система передается в ЗОДы и раньше окончательного закрытия проекта, если об этом договорились Заказчик, Руководитель Проекта и ответственный за блок Заказчика в ЗОДах.
Можно смело утверждать, что часть ЗОД — это задачи, когда-то или кем-то недоделанные в проектах. Действительно, в ряде случаев в проектах задачи доделывать нет времени и средств, а продлять проект — нет желания. И тут на помощь опять приходят ЗОДы.
Структура ЗОД
По структуре материнских и дочерних объектов в Jira все максимально просто.
ЗОД (создается в виде эпика в Jira)
Задача на проработку БТ;
Системная задача 1;
Системная задача 2;
Системная задача N;
Задача на сквозное тестирование.
Жизненный цикл
В общем случае жизненный цикл ЗОД довольно прост, стандартен и во многом схож с другими процессами:
Сбор и подготовка бизнес-требований;
Анализ и оценка;
Планирование;
Разработка/тестирование/приемка;
Передача в производственную среду.
В данной статье не будем останавливаться подробно на каждом из этих этапов, лучше распишу более подробно в следующих статьях. Остановимся на кратком описании каждого этапа.
Сбор и подготовка бизнес-требований
Данный этап больше лежит в зоне ответственности Заказчика. От каждого блока выступают по несколько представителей, которые собирают требования со своих коллег и формируют описание бизнес-требований. Здесь важно, чтобы разные подразделения не имели «завышенных» ожиданий в части реализации функционала со стороны ИТ. Поэтому ответственные от ИТ могут запрашивать планируемые сроки реализации, ожидаемые бизнесом, и, если нужно, вносить в них коррективы.
Далее БТ оформляются в виде шаблонной сущности в Jira, или в виде отдельного документа, прикрепляемого к сущности Jira.
Анализ и оценка
По завершении формирования и согласования БТ внутри бизнес-блоков, Заказчики передают их на анализ и оценку в ИТ. В большинстве случаев эти задачи будут моносистемными доработками, то есть потребуют доработки только в одной системе. У нас принята на вооружение парадигма, что лучше сделать несколько небольших моносистемных задач, чем одну большую, состоящую из доработок нескольких систем и интеграционного тестирования.
Если применим сценарий с моносистемной задачей, эпик сразу назначается на технического лидера соответствующей системы, где необходима доработка. Технический лидер либо самостоятельно оценивает необходимость, сроки, и, в ряде случаев, стоимость доработки, либо передает системным аналитикам в рамках оргструктуры своей системы. По статистике, таких задач может быть 60-70% от всего количества ЗОД.
Однако в случае, когда доработка по моносистемному сценарию невозможна, эпик передается кросс-системным аналитикам (у нас эта роль почему-то долгое время называлась «технолог»). Кросс-системный аналитик далее декомпозирует бизнес-требования, прикрепленные к эпику (ЗОД), на системные задачи, где может потребоваться доработка, а также создает задачу на оценку необходимости и состав сценариев сквозного тестирования (или интеграционного тестирования, как у нас его принято называть).
По завершении анализа, каждая система, а также команда сквозного тестирования предоставляет экспресс-оценку сроков и стоимости доработки. После этого производится согласование оценки всего ЗОДа с бизнес-заказчиком. Последний должен отдавать себе отчет в том, что затраты на доработку должны окупиться.
Планирование
После согласования оценок задачи всех бизнес-блоков переводятся в бэклог. Далее на сессиях совместного планирования раз в две недели происходит планирование спринта (мы их называем Релизами, или Релизным циклом). Чаще всего планирование и реализация интеграционных спринтов происходит, как показано на картинке ниже:
В назначенный час, когда сформирован бэклог из задач разных бизнес-блоков, происходит совместное планирование ЗОД на ближайшие спринты. Планирование разделено на две части: первичное (внутри ИТ) и совместное с бизнесом. На планировании с бизнесом заявляются задачи, которые берутся в работу в ближайших релизах, а задачи, которые не берутся в работу, — ждут следующего планирования. Бывает, задачу могут не брать в спринт в течение 10 и более сессий планирования.
Разработка, тестирование, приемка
На этом этапе все просто. Каждая системная команда берет в работу свои задачи и приступает к их разработке. Важно: разработка не может занимать все время, отведенное в спринте. Нужно также успеть провести внутреннее системное тестирование, интеграционное тестирование и приемку со стороны бизнеса (по тем задачам, где это нужно).
В случае, если по ряду причин одна или несколько систем не успевают в обозначенные в спринте сроки, весь ЗОД перепланируется и «паркуется» в один из следующих спринтов.
Передача в производственную среду
В назначенное время (как правило — в ночь со вторника на среду) происходит деплой всех выполненных доработок в промышленную среду. Это стандартная практика для цикла Release and Deployment. По понедельникам и пятницам никто никогда ничего не релизит (ну, или почти никогда). А после вторника остается еще 2 дня в запасе на исправление дефектов или применение плана отката релиза. Ночь — время наименьшей нагрузки на системы и минимального простоя для бизнеса.
Перед деплоем подбивается весь список доработок по всем системам, которые планируются к деплою на прод.
Проводится передача всех доработок в поддержку. При необходимости, проводится обучение персонала поддержки, передается документация и создается список RFD (Request for deployment).
Бывают ситуации, когда поддержка не согласовывает релиз. В этом случае релиз переносится до устранения замечаний. Но такие ситуации весьма редки, поскольку могут привести к поломке всего релизного цикла и отсрочить бизнес-критичные доработки. А бывает, конечно, и еще хуже — когда приходится откатывать уже согласованный релиз, который по каким-то причинам поломал какой-то важный бизнес-критичный сервис на проде во время деплоя. Но, к счастью, это большая редкость.
Продолжение следует…
Друзья, напишите в комментариях, о чем бы хотелось узнать подробнее. Для меня это будет очень полезно.