Продолжаем разговор про опытную эксплуатацию. Отдельно стоит поговорить о доработках ИС по дополнительным требованиям.

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

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

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

При этом, если смотреть на проект со стороны, то обе стороны можно понять:

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

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

Готового рецепта нет, но есть подходы, которые снимут, определенно, приличный объем споров:

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

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

▫️ в отдельных сложных случаях проект стоит разбивать на 2 отдельных проекта. В рамках первого содержанием является этап 1 "Обследование и анализ", в рамках второго этапы 2-5.

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

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