9.6.Ведем список запросов на изменение

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

• описание источника проблемы (что не так, чем недовольны);
• описание влияние проблемы (почему не так, почему недовольны);
• предложение по решению (что должно быть сделано).

Жизненные циклы запроса на изменение и сообщения о дефекте/несоответствии функциональности достаточно похожи, но есть различия в следующем:

• запрос на изменение – почти всегда повод для пересмотра бюджета и сроков проекта. Несоответствия, как правило, устраняются «бесплатно»;
• обычно устранение несоответствий/дефектов имеет более высокий приоритет, чем реализация запросов на изменение.

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

• Возникнут ли при реализации данного запроса на изменение противоречия с теми функциями и характеристиками системы, которые уже реализованы или утверждены к реализации?
• Потребуются ли изменения архитектуры системы, и если да, то насколько масштабные?
• Так ли уж важна реализация данного изменения?
• Какие могут быть альтернативы предложенному изменению (в том числе организационно-административного характера)?

На основе результатов анализа, предпринятого на предыдущих шагах, даются оценки запрашиваемого изменения:

• трудоемкость;
• срок реализации;
• стоимость.

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

Например, запрос на изменения уровня «давайте это не делать, мы подумали, оно не нужно», когда что-то уже сделано, будет иметь стоимость и сроки (нужно будет удалять сделанное, менять инструкции) и экономией не станет.

На основе полученных оценок по ресурсам и срокам делаем вывод о влиянии на бюджет, сроки и требуемые ресурсы по проекту:

• все (или некоторые) параметры проекта изменятся;
• изменений параметров проекта не последует.

Как правило, если реализация запроса на изменение не приведет к изменению бюджета и срока проекта, то решение о реализации запроса на изменение принимается практически автоматически – делаем!

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

Запрос на изменение должен быть:

• сформулирован в терминах, понятных проектной команде, в четких, однозначно трактуемых формулировках (аналогично исходным требованиям для проекта);
• запрашиваемые изменения должны пройти итерацию проектирования и проверку системным архитектором на отсутствие противоречий текущей архитектуре системы (это не всегда возможно в процессе регистрации запроса на изменение, тогда эти работы входят в оценку сроков и бюджета реализации изменения).

После реализации запроса на изменение необходимо провести тестирование, которое должно быть направлено на установление факта достижения целей:

• изменение внесено в соответствии с требованиями инициатора запроса на изменение;
• уже существующая в системе функциональность и другие характеристики не ухудшились в результате реализации изменения.

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

Прямой отказ от всех запросов на изменения, позиция: «У нас все зафиксировано по договору, и ничего дополнительно мы не делаем», – вызовет отрицательные эмоции у инициаторов запросов на изменения, а это часто ключевые сотрудники заказчика – конечные пользователи, которым работать с системой. Рассмотрение же запросов на изменения и их реализация (или откладывание, или отказ) их по согласованию снимает любой негатив, а также убирает проектные риски недостатков проектирования и сбора требований на предыдущих фазах: всегда можно внести корректировки по ходу проекта, выявляя лучшие решения или оптимизируя бизнес-процессы. Система автоматизации и согласованный ранее проект автоматизации не должны стать якорем для бизнеса. Нужно быть открытым к изменениям, когда они оправданны.

Отправить