На проектах с большими объемами и сжатыми сроками всегда актуален вопрос приоритетов.
Обычно вопрос "Что же конкретно включено в MVP?" становится всё горячее с приближением сроков релиза.
В теории (разных книгах, статьях) предполагается проведение приоритизации при планировании скоупа работ.
А что же происходит в жизни реального проекта на примере заказной разработки?
Заказчик представлен продактом. С той стороны заявляется некий набор функционала, необходимый к выпуску в рамках MVP. Обычно, на начальной стадии проекта формулировки отдельного функционала довольно поверхностные.
Декомпозиция может выглядеть, например, так:
Пользователь должен иметь возможность зарегистрироваться в системе для получения доступа к её использованию.
Зарегистрированный пользователь должен иметь доступ ко всем созданным им ранее сделкам для совершения действий по ним.
Допустим, при старте у нас есть подобная декомпозиция, примерная оценка объема разработки и сроков выпуска.
Что происходит далее? Правильно, жизнь вносит свои коррективы. Вы же видите требования выше, там разве сказано будет ли реализовано, например:
Отключение прав доступа пользователя администратором продукта — в рамках эпика по правам доступа пользователя;
Сохранение произведенной пользователем фильтрации в реестре сделок — в рамках эпика по сводному реестру сделок.
Продакт подтягивает всё новых и новых стейкхолдеров, которые в процессе аналитики воплощают источники требований по отдельным фичам. Аналитика идёт, после описания бизнес-требований и подготовки макетов интерфейса весь функционал фичи декомпозируется на задачи разработки. Перед взятием в работу очередного раздела задачи оцениваются разработкой.
И в какой-то момент становится абсолютно ясно, что все выявленные и описанные требования просто не влезают в сроки выпуска. При этом на финальных показах макетов по согласованным ранее требованиям в рамках эпиков стейкхолдеры продолжают "накидывать пожелания", обязательно приправляя свои комментарии фразой "без этого выпускать нет смысла".
Цели заказчика, конечно, сводятся к выпуску всего желаемого в первоначально оговоренные сроки. Для исполнителя же, тем временем, остро встаёт вопрос уменьшения скоупа задач и отстаивания границ функциональности MVP.
На практике я, как аналитик поняла, что подобной ситуацией необходимо уметь управлять любому члену команды на всех стадиях жизненного цикла разработки.
На чем следует держать фокус?
Ограничение сроков принятия требований по фичам: после даты х (по каждому эпику, естественно, своя дата) новые требования 100%-но пополнят бэклог и не пойдут пока даже в аналитику.
Ранняя приоритизация эпиков.
Приоритизация задач сразу после декомпозиции.
На протяжении всей разработки постоянное транслирование заказчику информации о фичах: что и по каким причинам "влезает"/"выходит за рамки" MVP.
Подобные действия открывают возможности к реальному управлению задачами на всех уровнях:
Команда на протяжении разработки включена в процесс "что и почему делаем", а что "nice-to-have" и поэтому ждёт своей очереди — весь функционал рассматривается с этого ракурса
Менеджер, Аналитик всегда могут аргументировать причины вхождение/исключения задач в MVP при снятии требований или ограничении скоупа задач
Продакт может транслировать эту же позицию среди ключевых стейкхолдеров заказчика
После декомпозиции и приоритизации фичи или даже сами эпики могут быть исключены из MVP
Ситуация будет становиться более управляемой с повышением прозрачности процесса принятия решения в согласии с выявленными приоритетами по каждой функциональности.
И есть шансы в оговоренные сроки действительно выпустить MVP.
Комментарии (6)
DrinkFromTheCup
01.06.2022 09:34И в какой-то момент становится абсолютно ясно, что все выявленные и описанные требования просто не влезают в сроки выпуска.
Стоп, дзинь!
Такое впервые?
Что было предпринято для повышения точности планирования после предыдущего пролёта-над-сроками?
Если таки впервые - почему не дали припуск по срокам х2 "на первый раз"?Ограничение сроков принятия требований по фичам: после даты х (по каждому эпику, естественно, своя дата) новые требования 100%-но пополнят бэклог и не пойдут пока даже в аналитику.
Стоп, дзинь!
Если фича настолько неважная, что её не надо прорабатывать при добавлении в бэклог, - может, её не надо добавлять в бэклог вовсе?
Чтобы не вышло ситуёвины, что оценили при добавлении одно, а в работу по той же задаче пошло совсем другое, например?Ну и моё любимое.
Обычно вопрос "Что же конкретно включено в MVP?" становится всё горячее с приближением сроков релиза.
Терминологию то дайте, пожалуйста.
Что конкретно в Вашей методологии подразумевается под MVP?
velvetovay Автор
01.06.2022 18:45Спасибо за вопросы
Такое впервые?
Что было предпринято для повышения точности планирования после предыдущего пролёта-над-сроками?
Если таки впервые - почему не дали припуск по срокам х2 "на первый раз"?Потому что клиент, например, давит по срокам. Вы же помните, что у всех свои цели?
Стоп, дзинь!
Если фича настолько неважная, что её не надо прорабатывать при добавлении в бэклог, - может, её не надо добавлять в бэклог вовсе?
Чтобы не вышло ситуёвины, что оценили при добавлении одно, а в работу по той же задаче пошло совсем другое, например?Тут вопрос не про "важность".
Это зависит от соотношения ресурсов на проекте. В конкретный момент аналитика может быть перегружена подготовкой материала для загрузки специалистов "далее по конвееру". Соответсвенно, как только часть ресурса аналитики освобождается, можно направлять внимание на проработку фичей и подготовки их к планированию.Продукт с минимально-необходимым функционалом для того, чтобы считать его отвечающим требованиям заказчика. А так как ситуация "требования заказчика меняются на ходу" всем известна, то и состав MVP порой шатает (хотя не должно в идеальном мире).
DrinkFromTheCup
02.06.2022 23:48Да, я не очень корректно выразился. Прошу пардону. По первому вопросу - "если клиент давит по срокам" снова и снова, проект за проектом.
Ситуация со слишком большим сроком не выгодна вам обоим. Ситуация с непопаданием в срок не выгодна вам обоим. Нужно нащупывать равновесную точку между реализмом и оптимизмом прогнозов. От хотелки клиента в сутках лишний час, всё-таки, не появится.Про бэклог - независимо от загрузки специалистов, есть вещи, которые делать надо. Вещи, которые помогут как ускорить разработку, так и... как это по-русски... backtracking, пройти назад на исходную в разборе задачи и где-то стратегически попланить что-то - это надо.
Если это по какой-то причине всё-таки не надо - наверное, не стоит это встраивать во флоу по принципу "хватило времени - делаем сразу, не хватило - не делаем". Наличие двух разных семейств задач (одно оформлено в спешке, второе не оформлено вовсе) укреплению планирования - не содействует.Я просто по Вашему описанию чую знакомый едва уловимый аромат попытки "и по скраму жить, и на 110% работников загрузить". Что, честно говоря, отдаёт управленческой шизофренией.
Не то чтобы это было плохо. Просто не факт, чтои у Васу Вас (как и во многих иных организациях этого рода) набрались мужества и признали себе "да, мы шизофреники, мы одновременно следуем и не следуем передовым методологиям разработки. И У НАС ПОЛУЧАЕТСЯ!" Вот не признавать это - совсем плохо...velvetovay Автор
03.06.2022 13:17Интересный разговор вырисовывается.
Да, с этим заказчиком впервые работаем.
Отловленный оттенок действительно есть ¯\_(ツ)_/¯
Согласна с вами практически во всём. Насколько вижу, в компании понимают, что мы шизофреним в некотором роде. Ситуация может быть в корне решена только в самом старте — по-другому строить отношения и опорные точки рулежки проекта, да.
wadik69
За мемчики лайк:)
velvetovay Автор
спасибо)