Управление запросами на поддержку

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

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

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

Рекомендуемое содержание данного документа:

Описание того, как в настоящий момент функционирует система. Здесь следует указать, что в данной реализации работает неправильно
Суть изменений, которые следует реализовать в системе
Возможные преимущества после исправления недостатков. Этот пункт должен заполнить заказчик
Предложения по технической реализации. Если у решения несколько вариантов, здесь должны быть изложены все
Предварительная оценка трудозатрат
Детали технической реализации. Этот пункт описывает, как конкретно были реализованы изменения
Реальные трудозатраты

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

Отслеживайте состояние всех запросов на поддержку

Хороший вариант - создать документ приблизительно следующего содержания:

1	2	3	4
<SR Name>	Status	To be executed before	Finish date
	On consideration
	Resolved
	On schedule
	Rejected

<
Упомянутых статусов ("На рассмотрении", "Выполнено", "На исполнение", "Отменено") может быть вполне достаточно, чтобы контролировать ход работ. Точное время для выполнения запроса назначать не обязательно, достаточно указать дату, когда запрос должен быть выполнен. Полезным наверняка окажется учет фактической даты окончания работ над запросом

Определите порядок обработки запросов на поддержку и действующих лиц

Тут, как и при планировании итераций полезной может стать инструкция, описывающая технологию управления запросами на поддержку. Данный документ по структуре будет практически аналогичным инструкции, определяющей технологию разработки ПО на стадии планирования. Что касается содержания, то одно из отличий проявляется в том, что кроме роли разработчика и заказчика, можно выделить отдельную роль руководителя. Если в случае с требованиями, подразумевается, что руководитель уже дал согласие на начало работ по проекту, а требования утверждает заказчик в лице человека, ответственного за такие решения, то в случае с запросами на поддержку, решение о принятии запроса на исполнение может и не быть принято в силу различных причин

Направления улучшения данного процесса:

Возможно, понадобится более четко определять сроки реализации запросов на поддержку.

Содержание раздела