Comments 6
был, например, годовой календарь для планирования тренировок
...Выкинули годовой календарь. Сделали нужную фичу.
чего не хватило методологии FFF чтобы ненужный "годовой календарь" не появился даже на стадии MVP ? 🤔🙂
FFF здесь ни при чем — он не отвечает на вопрос что взять в MVP, а что не взять. Он говорит нам что мы можем сделать, когда такое происходит. А такое происходит на каждом проекте.
В нашем кейсе классическая история разработки продуктов: когда мы на проектировании отталкиваемся от гипотез и расставляем приоритеты, многие фичи считаются важными и нужными.
Когда на разработке мы сталкиваемся с реальностью и приобретаем новый опыт — приоритеты задач могут меняться. В данном случае «годовой календарь» это не ненужная фича. Она нужна и классная, просто появилась новая задача, у которой приоритет больше. Поэтому пришлось перестраивать объем задач.
И здесь мы говорим не о недостатке FFF, а об его преимуществе. Если бы не он, то мы бы не могли контролировать такие ситуации: появляются новые важные задачи, старые остаются — скоуп работ растет, сроки плывут, бюджет пухнет.
Для каких-то проектов и команд это окей, для нас — нет.
FFF здесь ни при чем — он не отвечает на вопрос что взять в MVP, а что не взять
ну тогда где логика?
Что можно назвать MVP моста? ...MVP должен стать, как ни странно мост, просто он будет такой базовой комплектации
если MVP - это уже продукт, то к нему нужно относится как к продукту и применить FFF! да, пока нет конкретной реализации, нет данных, нет реального контекста, будем использовать похожий принцип - 0xFFF!
✨ 0xFFF - "0x- итерация FFF" или "First Features Freeze"
Первичная заморозка фич.
Мы замораживаем scope ещё до разработки , чтобы избежать завышенных ожиданий и ненужных календарей.
🎨 Альтернативы:
1. 0xFFF = "For Future Flexing"
Для гибкости в будущем
Если ты правильно заморозил scope на ранних стадиях, потом тебе будет проще им управлять по классическому FFF.
2. 0xFFF = "Fake Final Forecast"
Ложный прогноз финального вида
MVP всегда немного ложь. Он выглядит как конец, а на самом деле - только начало.
Зато с помощью 0xFFF ты хотя бы не обманываешь себя слишком сильно.
..😅
FFF с заморозкой фич перед стартом — это обычный водопад с фиксированием всего.
Давайте на примере моста.
Вот строим мы мост по проекту с фиксированным бюджетом, сроками. Типовой мост, тысячу таких построено. Шанс ошибиться с оценками — минимальный, поэтому и фичи зафризим и получим MVP1.
В процессе вы узнаёте, что геологи накосячили с расчетами грунта. Тех свай, которые у вас в проекте уже закуплены, не достаточно чтобы мост просто стоял.
В этот момент объем фич резко изменился и появился MVP2. Вместо установки 10 свай надо 15.
Что делать? Терпеть, стараться уложиться в сроки и бюджет, идти пересогласовывать, двигать сроки, игнорировать это, забить 10 свай и молиться что не упадёт?
При реализации проекта постоянно будут возникать MVPn+1. Фризинг фич подразумевает то, что мы просто игнорируем этот факт? Или что мы должны сделать в такой ситуации?
А если строительство моста пройдет без проблем, так и получим мы то, что изначально планировали, без всяких изначальных фризов.
Поэтому смысл фиксации фич я так и не понял, извините :)
Пример, кстати, реальный, только вместо моста был жилой многоэтажный дом.
Спасибо, что познакомили с подходом и за наглядные примеры.
Поправьте если считаете, что не прав. Но в моей практике отказаться от чего то, это боль для заказчика и он от этого грустит. Лучше продлить ДК за рамки согласованных сроков и показать, что фича из следующего месяца, переезжает на год, но это уже новый контракт или следующий цикл.
И не могу не отметить комментарий про SCRUM. Всё же это цикл мероприятий, а не планирование разработки. (душанул слегка).
Представьте, что у нас проект, в котором результат привязан к какому-то понятному и не сдвигаемому дедлайну. И фиксированному бюджету.
Например, запускаете сервис для футбольной лиги — нужно успеть до начала предсезонной подготовки. Если не успеем, то следующий шанс на внедрение этого продукта появится через год, в следующее предсезонное окно.
И вот с этим ограничением мы должны запустить продукт. Работоспособный, завершенный, после запуска которого выделят еще бюджет на развитие и никого из команды не уволят :)
То есть у нас нет варианта перенести срок запуска и нет варианта увеличить бюджет. Мы не можем себе позволить сказать: «ага, вот эту фичу мы берем и сдвигаем срок запуска на 1 месяц».
Мы должны здесь и сейчас решить, что мы делаем, а что не делаем.
Да, вы правы, отказываться от фич больно, грустят не только заказчики, но и команда разработки.
Но в то же время отказаться от фичи в FFF это не значит убить ее безвозвратно. Это значит, что в данной итерации продукта ее не будет. Ну вот вообще никак.
Зато эту фичу мы заботливо положим в беклог и договоримся вернуться к ней в следующих итерациях.
Важный момент: в реальности на проектах редко бывает, что команда отказывается от фич. Обычно мы либо упрощаем реализацию или заменяем фичу на более простую, но с той же функцией.
В том же примере из проекта мы не отказались от фичи Календаря. Мы упростили ее — не стали делать годовое отображение. А недельный и месячный сделали.
А про SCRUM: да, возможно немного некорректное прямое сравнение его с FFF. Для меня в SCRUMе среди всех его артефактов и мероприятий не хватает как раз указаний, что делать, когда команда понимает, что не успевает к намеченному сроку. Как будто бы в нем мы можем только за этим наблюдать, а что делать — непонятно :)
FFF: методология, которая принимает реальность и помогает делать цифровой продукт