Даже если вы провели прекрасную работу по сбору и утверждению требований, вам следует постоянно быть готовым к изменениям. Бизнес меняется, и его требования меняются тоже. И когда вас как менеджера проекта просят внести изменения, не нужно отказываться, ссылаясь на подписанные ранее документы. Если бизнесу что-то потребовалось, то у него на это есть свои причины. И если новые требования отвечают целям бизнеса, то нужно их принимать и согласовывать вместе со всеми изменениями в содержании работ, бюджете и расписании.
Не бывает проектов, в которых не было бы изменений. Даже если речь о небольшом двухнедельном спринте, то, скорее всего, даже на этом отрезке появятся какие-то корректировки. Изменения — это хорошо, мы им рады и умеем ими управлять, но об этом будет отдельная глава.
Работая по модели с MVP (минимально жизнеспособный продукт) и прототипом, мы много раз сталкивались с одним интересным заблуждением. MVP или прототип — это быстро созданные решения, которые слабо масштабируются. Несколько таких решений могут накладываться друг на друга, что со временем затрудняет очередное расширение функционала. Это ведет к необходимости переделывать часть программы. При этом заказчик уверен, что у него уже есть полный функционал, который работает замечательно. Менеджер должен предупреждать заказчика о подобных рисках.