Бесконечные правки и новые требования перед релизом
Контекст
☝️ Такое произошло с нашим менеджером по управлению проектами Екатериной. Под её руководством была команда, которая «под ключ» создавала для заказчика корпоративный портал.
На старте с клиентом согласовали техническое задание и макеты, утвердили логику работы и roadmap, а после каждого спринта проводили демонстрацию разработанного. Внезапно в компании заказчика изменился ответственный за проект специалист с другим видением портала. И вот дата релиза уже не за горами, а в работу прилетели новые фичи.

Что делать?.. 🤔
Екатерина провела с клиентом приоритизацию новых фич, а затем их оценку. Проверила, что из этого списка команда точно успеет сделать и взять в релиз, а по остальным задачам предложила несколько вариантов:
1) Выпустить MVP-версию, а после составить план по доработке портала и внести дополнительные фичи.
2) Увеличить команду, если важно взять в релиз все и успеть вовремя.
3) Сдвинуть дату релиза.

Чтобы принять решение, нужно было донести до клиента:
▪️ плюсы и минусы каждого решения;
▪️ информацию о том, что каждую новую фичу необходимо не только разработать, но и протестировать, а также заложить на это ресурсы;
▪️ свериться с бюджетом проекта и определить, какие из этих шагов можно себе позволить уже сейчас, а какие позже.

Совместно с клиентом мы решили придерживаться согласованного ранее плана, выпустить MVP-версию, утвердить новые фичи и их приоритет, а затем доработать портал.