Как извлечь пользу для проекта из того, что Заказчик часто меняет требования?

Как извлечь пользу для проекта из того, что Заказчик часто меняет требования?

Спасибо за редкий вопрос! Обычно спрашивают «Как заставить Заказчика не изменять требования?» или «Как бороться с изменчивостью требований?». Хотя на самом деле, нужно думать именно в ключе заданного вопроса – это и конструктивнее, и результативнее.

Прежде чем начать получать пользу от изменчивости требований, нужно поработать над связанными с этим рисками, иначе будет «как всегда». Лучше всего этот вопрос проработан в гибких методологиях, которые, собственно, и создавались для эффективного «обслуживания» таких ситуаций. Подробно познакомиться с данными методологиями и научиться по ним работать можно на специальном тренинге. Короткие итерации (1-2 недели), разумный минимум проектной документации (для снижения затрат на ее обновление), в том числе – менеджерской, связанной с планированием и контролем исполнения проекта, максимальная автоматизация проектных процессов (прежде всего – сборки; обязательно используем непрерывную интеграцию), разумный максимум автоматизации регрессионного тестирования (модульные тесты, функциональные тесты), активная вовлеченность Заказчика в уточнение и детализацию требований (доступность для ответов на вопросы команды, просмотр промежуточных результатов), показ Заказчику результатов каждой итерации и восприятие его обратной связи. Ну и конечно – модель оплаты за реально выполненные работы и потраченные материалы (time & materials). Не все из этого легко «продать» Заказчику, но объяснение важности этих подходов для успеха их (ну, нашего с ними) проекта в условиях повышенной изменчивости требований очень часто помогает. Вместе со ссылками на предыдущие успешные проекты, мнение признанных экспертов software engineering и т.п.

 Поработав с рисками и подготовившись к относительно малоболезненному процессу учета изменений в требованиях, мы готовы извлекать из этого пользу. А она в основном заключается в том, что любое изменение – это дополнительная работа для команды как на фазе активной разработки, так и после перехода к поддержке. И чем лучше и оперативнее мы будем реагировать на эти изменения, тем более адекватную потребностям Заказчика систему мы создадим. Тем самым повысив его удовлетворенность, готовность придти к нам с новыми проектами, а также порекомендовать нас своим знакомым в бизнес-тусовке. А это уже очень правильная «цепная реакция», столь необходимая для успешного бизнеса по разработке ПО!