Итак, программное обеспечение разработано и протестировано внутри компании. Даже, возможно, неплохо протестировано. Появляется и заказчик, который заинтересован в продукте. И тут наступает великий и ужасный Процесс Внедрения. Расскажу о том, что он собой представляет и какие сложности таит.
Внедрение — это встраивание ПО в существующие технические и бизнес-процессы заказчика. Сами заказчики бывают двух видов:
Мы знаем, что хотим, вот вам ТЗ. Это хороший, годный заказчик, потому что он даёт нам конкретный набор требований, под который можно подогнать наше решение. Но есть риск, что ТЗ содержит много того, чего в ПО нет, потребуются доработки. Тогда придётся договариваться с заказчиком о сроках, искать вариант, который устроит обе стороны.
Мы не знаем, чего хотим, сделайте хорошо. Хорошая новость в том, что в этом случае к внедрению можно приступать сразу. Здесь хорошие новости заканчиваются, и начинается классика жанра: «а теперь доделайте это, нам не нравится вот это». И если мы решим работать с этим заказчиком, остаётся только составлять ТЗ самостоятельно и согласовывать всю функциональность, доступную на данный момент. А доработки делать отдельно, по новому договору.
Поясню на примере. Возьмём некий банк. В нём работают в Jira и Confluence. Есть выстроенный процесс создания и описания задач, есть правила, как в рамках задачи одной команды запросить доработку в сервисе другой команды. И вот наступает момент, когда нужно перейти на дружественную альтернативу, например, Сфера.Задачи. Как сделать это максимально плавно? Как не нарушить существующие привычные процессы? Приходится дополнительно модифицировать и конфигурировать внедряемое ПО.
Или вот другой пример. В банке есть контур тестирования, и в нём есть БД, где генерируются тестовые данные для проверки мобильного приложения перед релизом. Но за генерирование отвечает скрипт, который кто‑то когда‑то написал. В результате тестовая БД очень далека от структуры метаданных и данных прода, что чревато дефектами. Тогда в процесс вместо скрипта внедряют платформу Сфера.Обезличивание, которая прогоняет через себя продовские данные и создаёт полную копию БД, но без персонализированной информации. В этом случае внедряемое ПО не модифицируется, видоизменяется сам этап, а вместо запуска скрипта получаем удобный интерфейс и прозрачный процесс.
Если свести всё сказанное к одной фразе, то внедрение бывает двух видов: коробочного продукта («ванильное» внедрение) и с доработками.
О чём важно помнить?
При планировании внедрения тщательно (лучше несколько раз) посчитайте, сколько нужно мощностей под ваше решение и сколько вам выделяют. Потянет ли ПО и железо прогнозируемое количество пользователей? Учитывается ли рост и возможное масштабирование?
Обсудите и зафиксируйте в документах сроки реализации и возможные простои. Внедрение может застопориться по самым разным причинам, Например, новые санкции введут. Ключевой сотрудник уволится. Возникнут непредусмотренные технические проблемы. Так что советую договориться «на берегу» и указать в договоре внедрения возможные причины и продление сроков, если эти причины «стрельнут». Что‑то вроде страховки.
Этапы
Вне зависимости от того, предполагается ли внедрение с доработками или без, есть этапы, одинаковые для всех:
Анализ. Выделение критических, с точки зрения общего результата, процедур в деятельности организации. В анализе участвуют аналитики и методологи.
Артефакты. Составление документации по каждому из этапов: техническое задание на настройку, архитектура внедрения, протокол тестирования.
Доработка. Внесение изменений в продукты в соответствии с ТЗ: добавление индивидуальных функций, интеграция для конкретного заказчика.
Тестирование. Обеспечение качества QA‑специалистами на всех этапах.
Разворачивание ПО на стороне заказчика.
Настройка (сюда же включаем и кастомизацию) под бизнес‑процессы согласно ТЗ. Например, какие элементы можно создавать в Сфера.Задачи, какая у них статусная модель, какие есть взаимосвязи «родительская‑дочерняя», и т. д.
Повторное тестирование на стенде заказчика для отлова конфигурационных и инфраструктурных дефектов.
Апробирование. Период пробной ограниченной эксплуатации представителями заказчика.
Эксплуатация. Заказчик начинает пользоваться стендом в полном объёме.
Сбор обратной связи от заказчика: дефекты, пожелания доработок.
Обучение. Проведение обучающих демонстраций, семинаров.
А теперь проиллюстрирую всё то же самое, но на примере внедрения Сфера.Задачи:
Анализ. Смотрим, какие сейчас элементы в Jira, какая у них статусная модель, модель приоритетов, набор обязательных и необязательных полей.
Артефакты. Составляем ТЗ, в котором описываем, как именно всё будет реализовано конкретно в Сфера.Задачи.
Настройка. Никаких дополнительных интеграций не планируется, поэтому этап доработки пропускаем. Но, например, надо доделать новые элементы и статусную модель. Для этого на стенде разработки разворачиваем экземпляр инструмента, и наши внедренческие аналитики переделывают ванильную версию.
Тестирование. Изучив ТЗ и написав тестовую модель, тестировщики проверяют, что всё работает, как задумано.
Разворачивание. DevOps»ы берут со стенда разработки доработанную версию Сфера.Задачи и переносят в контур заказчика.
Повторное тестирование. Тестировщики дополнительно проверяют стенд после разворачивания на случай инфраструктурных и прочих проблем. Вдруг DevOps»ы что‑то не довезли? Если обнаруживаем дефекты, то заводим по ним задачи и исправляем.
Апробирование. Рабочая группа заказчика под лупой рассматривает собранный стенд, имитирует на нём работу, пробует различные сценарии.
Сбор обратной связи. Общаемся, слушаем и прислушиваемся к замечаниям и пожеланиям.
Обучение. Собираем на встрече конечных пользователей системы — всех, кого посчитаем нужным обучить, от руководящего состава до джунов. Всё досконально показываем и рассказываем, отвечаем на вопросы.
Эксплуатация. Порциями запускаем пользователей.
Сбор обратной связи. После массового запуска со всеми лично не поговоришь, поэтому делаем специальный почтовый ящик си возможностью писать вопросы в окне поддержки.
Команда
Как выстроить процессы внутри команды внедрения? Ведь она — связующее звено между разработкой и заказчиком. У нас эта команда работает сразу над несколькими проектами, под каждый из них мы собираем «виртуальную команду» из руководителя проекта, разработчиков, тестировщиков и аналитиков. Если этого требуют обстоятельства, они занимаются только каким-то одним проектом, но обычно переключаются с одного на другой, потому что проекты движутся с разной скоростью, задействуют разные наборы продуктов.
Этап тестирования
Особенность тестирования во внедрении заключается в том, что мы тестируем разные наборы по‑разному настроенных продуктов. Нельзя просто так взять и использовать уже готовые сценарии. Они являются, по сути, функциональными. Нам же необходимо проверять набор интеграций в зачастую уникальных комбинациях. На выходе получается синтез сценариев от тестировщиков и других команд.
Мы работаем в инструменте Сфера.Функциональное тестирование:
Выделяем для конкретного проекта тестировщиков из общего пула. Коллеги погружаются в задачу, изучают аналитические документы, получают вводные от руководителя проекта. Под каждый проект создаём оперативный чат для коммуникации с коллегами. В пространстве проекта создаём задачу на тестирование стенда, туда добавляем ссылку на тест‑план и описание стенда. Затем команда DevOps разворачивает сборку на стенде, и мы приступаем к тестированию.
Дефекты заводим в отдельном пространстве в инструменте Сфера.Задачи:
Тестовые планы и методика тестирования описывают:
виды тестирования, применимые к системе (функциональное, интеграционное, инсталляционное и т. д.);
описание среды или стенда, на котором проводится тестирование;
приложенные тестовые сценарии.
При тестировании мы находим дефекты трёх типов:
Продуктовые — классические дефекты продукта.
Конфигурационные — различные ошибки при разворачивании. Например, если некорректно указать в манифестах связи между определёнными микросервисами, то будет возникать ошибка при обработке информации, требующей использования этих микросервисов.
Инфраструктурные — дефекты стенда. Если вдруг что‑то тормозит или отваливается.
Обнаруженные дефекты мы передаём на исправление. Команда поддержки собирает их и дополнительно анализирует, а затем пачкой отправляет командам разработчиков. Если это продуктовые дефекты, то их исправляют разработчики команд внедрения.
А после завершения тестирования мы пишем протоколы. Это может быть, например, программа и методика испытаний (ПМИ), по сценариям которого вместе с заказчиком затем проводятся приёмо‑сдаточные испытания.
Владимир Амелькин
главный менеджер по качеству НОТА (ИТ-холдинг Т1)