Pivot-Pivot-Pivot! Как управлять стремительно меняющимися требованиями

Никто из нас не любит изменения. Но меньше всех любит их команда разработчиков, когда речь заходит о новых требованиях к задачам, уже взятым в спринт, а тем более, выполненным. В моем последнем проекте таких было достаточно, и эту статью я писала по результатам его ретроспективы. Поэтому в какой-то степени ее можно назвать работой над ошибками и даже мануалом для тех, кто будет менеджить требования в условиях “rapidly changing environment”.


Попав в проект, я обрадовалась: чистый аджайл, T&M-контракт, фиксированы только сроки и состав команды, а скоупом проекта можно играть. Да скоупа как такового и нет: есть идея, вайрфреймы, примерное видение и дедлайн. Именно здесь скрывался подвох: MVP (в нашем случае MLP — Minimal Lovable Product) нужно было сделать за три месяца, начиная с сегодняшнего дня. Отсутствие концепта того, что именно мы предлагаем юзеру как MLP, сразу поставило дедлайн под вопрос для всей команды.


Итак, проект начался 1 июня: UX-трек и трек разработки стартанули одновременно. На этапе отрисовки User Flow оказалось, что одно из основных флоу не несет для пользователя никакого value — и мы сделали первый Pivot. Процессы регистрации