Что делать, когда появляются изменения в требованиях?

На самом деле все не так страшно, как может показаться, когда вам с разных сторон прилетают просьбы «Надо сделать так», «А вот здесь давайте сделаем по-другому» после того, как вы согласовали ТЗ и уже приступили к разработке.

Чем сложнее проект, чем больше заинтересованных лиц, тем выше вероятность, что требования будут меняться и это нормально. Не надо бороться с изменениями, надо научиться ими управлять. Существует отдельный процесс - управление изменениями требований. И спланировать то, как вы будете управлять изменениями, надо заранее.

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

Базовый набор операций по управлению требованиями будет таким:

✔️ Управление версиями. Сначала необходимо сформировать базовую версию требований, содержащую набор требований, который уже согласован с заинтересованными лицами. Далее отслеживайте версионность, одна из самых распространенных систем ведения и версионирования требований - Confluence.

✔️ Управление изменениями. Для фиксации изменений используйте систему контроля, например, Jira.

✔️ Отслеживание состояния требований. Для начала определите, какие будут состояния (обычно используют следующие состояния - предложено, разработка, подготовлено, одобрено, реализовано, проверено, отложено, удалено, отклонено).

✔️ Отслеживание связей как между требованиями, так и с другими системами.

Есть классная статья на эту тему, кому интересно подробнее изучить эту тему, делюсь ссылкой https://analytics.infozone.pro/requirements-analysis/requirements-management-methods/