Продолжаем двигаться по этапу 4 "Опытная эксплуатация" проекта внедрения. В прошлой публикации проговорили о том, зачем она нужна в принципе. В рамках данной публикации поговорим о первом ключевом результате (ошибки устранены, консультации проведены, недоработки устранены).

Пользователи группы ОЭ начинают работать в новой ИС. И как раз документ "Программа проведения опытной эксплуатации", о котором я вскользь упомянул в завершающей публикации по этапу 3, описывает, в том числе, сколько и каких операций какой пользователь должен совершить. Потому что "просто поработать" в новой ИС - мало. Надо организовать ОЭ таким образом, чтобы пользователи группы ОЭ поработали со всей функциональностью внедряемой ИС.

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

▫️ ошибки ИС, причем как условно "технические" (нажал кнопку - вылетел эксепшн), так и "логические" (например, сделал операцию, операция разнеслась успешно, сформировал отчет, отчет сформировался успешно, но значения по внесенной операции отсутствуют);

▫️ отсутствие нужной функциональности (и да, если вы проводили испытания системы, как у меня было описано ранее, то вряд ли вы столкнетесь с незакрытым функциональным разрывом, но в ходе ОЭ проверяется еще и удобство использования ИС);

▫️ запросы на консультации.

Все это должно в итоге быть зарегистрированным в документе "Журнал опытной эксплуатации". При этом нет никаких противоречий в том, чтобы организовать саму регистрацию запросов пользователей и работу с ними в баг-трекере, и сделать отчет, который формирует сутевую часть документа, а уже в конце этапа оформить документ в нужном формате.

При этом если используете баг-трекер, то лучше всего организовать работу таким образом:

▫️ пользователи сами регистрируют задачу и описывают ее как могут, либо звонят, и с их слов принимающий заявку регистрирует запрос в систему;

▫️ задача фиксируется и не дополняется пользователем;

▫️ в баг-трекере делается связанная задача или задачи (а их может быть несколько), которые уже формулируются правильно с точки зрения исполнителей и уже с ними ведется работа;

▫️ когда все задачи нижнего уровня закрываются, тогда закрывается и связанная "верхняя" задача.

Само собой разумеется, что задачи на консультацию и исправление ошибки/доработку должны иметь разные пути прохождения.

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

Как я говорил ранее, лучшим вариантом будет, если сотрудники, которые в дальнейшем будут поддерживать данную ИС, выступали бы в роли первой линии ТП, а команде направляли только те запросы, с которыми не могут справиться сами (сложные вопросы, доработка системы по ошибкам или дополнительной функциональности).

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