Требования всегда будут меняться#аналитика
Люди, с которыми вы работаете, зачастую делятся на два типа: те, что хотят сделать хороший продукт и те, что хотят облегчить себе работу.
Яркий пример для выявления людей, относящихся ко второму типа - процесс изменения требований. Когда проект только стартует, и владелец продукта обсуждает с командой концепцию продукта и список того, что система будет уметь - будьте уверены, что к концу разработки это все будет выглядеть совсем по-другому.
И это нормально, потому что в процессе, оценивая промежуточные результаты, команда будет подавать идеи, как сделать лучше, пользователи, которые будут тестировать продукт, будут говорить, как им было бы удобнее - в общем, требования будут меняться. Я не имею сейчас в виду случаи бездумного изменения требований, когда заказчик приходит с
Pet Feature или пытается "впихнуть невпихуемое".
Противиться изменениям: "но ведь мы месяц/год/два года назад договаривались о другом" - неправильный путь. Этот путь ведет к тому, что рынок будет идти вперед, а ваш продукт - стоять на месте, и, когда вы его закончите - он будет никому не нужен. Он был нужен месяц/год/два года назад, но не сейчас, потому что вы застряли на требованиях из прошлого.
Первым это осознал Джефф Сазерленд, автор методологии Scrum - он стал добавлять в контракт с заказчиками пункт, гласивший, что все изменения - бесплатны. Если изменение увеличивало времени разработки - заказчик просто убирал другой функционал, чтобы суммарно время разработки осталось таким же. Компании, выпускавшие продукты, стали идти в ногу со временем.
В общем, если рядом с вами люди, которые настаивают на том, что ничего менять нельзя - объясните им, что развитие продукта важнее.