Порезать, чтобы выпустить реальный MVP

На проектах с большими объемами и сжатыми сроками всегда актуален вопрос приоритетов.

Обычно вопрос «Что же конкретно включено в MVP?» становится всё горячее с приближением сроков релиза.

В теории (разных книгах, статьях) предполагается проведение приоритизации при планировании скоупа работ.

А что же происходит в жизни реального проекта на примере заказной разработки?

Заказчик представлен продактом. С той стороны заявляется некий набор функционала, необходимый к выпуску в рамках MVP. Обычно, на начальной стадии проекта формулировки отдельного функционала довольно поверхностные.

Декомпозиция может выглядеть, например, так:

1. Пользователь должен иметь возможность зарегистрироваться в системе для получения доступа к её использованию.

2. Зарегистрированный пользователь должен иметь доступ ко всем созданным им ранее сделкам для совершения действий по ним.

Допустим, при старте у нас есть подобная декомпозиция, примерная оценка объема разработки и сроков выпуска.

Что происходит далее? Правильно, жизнь вносит свои коррективы. Вы же видите требования выше, там разве сказано будет ли реализовано, например:

1. Отключение прав доступа пользователя администратором продукта — в рамках эпика по правам доступа пользователя;

2. Сохранение произведенной пользователем фильтрации в реестре сделок — в рамках эпика по сводному реестру сделок.

Продакт подтягивает всё новых и новых стейкхолдеров, которые в процессе аналитики воплощают источники требований по отдельным фичам. Аналитика идёт, после описания бизнес-требований и подготовки макетов интерфейса весь функционал фичи декомпозируется на задачи разработки. Перед взятием в работу очередного раздела задачи оцениваются разработкой.

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

Цели заказчика, конечно, сводятся к выпуску всего желаемого в первоначально оговоренные сроки. Для исполнителя же, тем временем, остро встаёт вопрос уменьшения скоупа задач и отстаивания границ функциональности MVP. 

На практике я, как аналитик поняла, что подобной ситуацией необходимо уметь управлять любому члену команды на всех стадиях жизненного цикла разработки.

На чем следует держать фокус?

1. Ограничение сроков принятия требований по фичам: после даты х (по каждому эпику, естественно, своя дата) новые требования 100%-но пополнят бэклог и не пойдут пока даже в аналитику.

2. Ранняя приоритизация эпиков.

3. Приоритизация задач сразу после декомпозиции.

4. На протяжении всей разработки постоянное транслирование заказчику информации о фичах: что и по каким причинам «влезает»/»выходит за рамки» MVP.

Подобные действия открывают возможности к реальному управлению задачами на всех уровнях:

• Команда на протяжении разработки включена в процесс «что и почему делаем», а что «nice-to-have» и поэтому ждёт своей очереди — весь функционал рассматривается с этого ракурса

• Менеджер, Аналитик всегда могут аргументировать причины вхождение/исключения задач в MVP при снятии требований или ограничении скоупа задач

• Продакт может транслировать эту же позицию среди ключевых стейкхолдеров заказчика

• После декомпозиции и приоритизации фичи или даже сами эпики могут быть исключены из MVP

Ситуация будет становиться более управляемой с повышением прозрачности процесса принятия решения в согласии с выявленными приоритетами по каждой функциональности.

И есть шансы в оговоренные сроки действительно выпустить MVP.