ФФФ: фиксированный срок и бюджет, гибкий объём
ФФФ — сокращение от Fix time, Fix budget, Flex scope: фиксировать срок и бюджет проекта, а состав функций корректировать по мере работы. Модель исходит из того, что проект движется от исходного состояния к цели в условиях неопределённости. План помогает выбрать направление, но не гарантирует, что все заранее задуманные функции удастся выпустить в первоначальном виде.
На ход проекта влияют обнаруженные требования, технические ограничения, решения заказчика и другие события. Поэтому фактический путь может отклоняться от первоначального плана. ФФФ предлагает не скрывать отклонения и не компенсировать их автоматически переносом даты, ростом бюджета или снижением качества: команда и заказчик заранее решают, какой частью объёма можно пожертвовать.
Что фиксируют и что меняют
Заголовок раздела «Что фиксируют и что меняют»| Параметр | Правило ФФФ | Что согласовать заранее |
|---|---|---|
| Срок | Дата запуска остаётся ориентиром, на который команда планирует работу | Дату, внешние зависимости, условия переноса и последствия задержек по вине сторон |
| Бюджет | Объём работ адаптируют в пределах согласованной суммы | Состав цены, допущения, порядок оценки изменений и то, что считается дополнительной работой |
| Объём | Набор функций можно сократить, упростить или перенести | Приоритеты, обязательные сценарии, критерии приёмки и кто утверждает изменения |
| Качество | Нельзя компенсировать нехватку времени выпуском неприемлемого результата | Минимальные требования к безопасности, доступности, надёжности, тестированию и готовности к запуску |
«Гибкий объём» не означает произвольное удаление функций. При изменении прогноза команда показывает последствия и предлагает варианты: упростить второстепенный сценарий, отложить функцию или выпустить меньшую версию. Заказчик выбирает вариант до того, как сокращение станет неприятным сюрпризом.
Как вести проект по ФФФ
Заголовок раздела «Как вести проект по ФФФ»- Определить цель запуска. Сформулировать, какую задачу должен решать первый выпуск и какие пользовательские сценарии для этого обязательны.
- Зафиксировать ограничения и допущения. Записать дату, бюджет, зависимости, обязательный объём, критерии приёмки и границы качества. Отдельно перечислить функции, которые можно упростить или перенести.
- Разбить работу на короткие циклы. Каждый цикл заканчивать проверяемым результатом; по возможности — готовой к использованию частью продукта. Не ждать финальной даты, чтобы впервые увидеть работающую систему.
- Проверять прогноз регулярно. На плановых встречах сопоставлять остаток работы и доступное время. Если дата под угрозой, сразу оценить варианты по приоритету и стоимости.
- Согласовать изменение объёма. Ответственный за решения со стороны заказчика выбирает, что убрать или упростить. Команда фиксирует договорённость и обновляет план; не оставляет решение до последнего дня.
- Запустить, измерить и решить, что дальше. После выпуска проверить продукт на реальных сценариях. Перенесённые функции становятся предметом отдельного решения и оценки, а не автоматическим обещанием следующего этапа.
Сроковые рамки и бюджет сами по себе не делают план предсказуемым. Планирование требует небольшого резерва, прозрачного учёта рисков и регулярной проверки фактического прогресса. Резерв снижает риск, но не превращает оценку в гарантию.
Запуски частями
Заголовок раздела «Запуски частями»Если запускать только весь объём целиком, большая часть ценности появится в конце проекта. Поэтапная поставка позволяет раньше проверить ключевые сценарии и получить обратную связь. Для этого части продукта должны иметь самостоятельную пользу и быть готовы к использованию, а не просто соответствовать отдельным строкам технического плана.
Ранний выпуск помогает проверить предположения и понять, какие функции действительно нужны. Но это преимущество появляется только при корректной работе продукта: быстрый запуск не оправдывает ошибки, небезопасную обработку данных или критические дефекты.
Роли и принятие решений
Заголовок раздела «Роли и принятие решений»Для быстрых решений полезно заранее назначить одного ответственного заказчика, который определяет приоритеты и утверждает изменения объёма. Это не означает, что остальные заинтересованные стороны исключаются: их требования собирают заранее, а юристы, специалисты по безопасности и владельцы операций сохраняют необходимые полномочия согласования.
Дизайнерские решения продолжаются во время разработки. Если все вопросы проходят через заказчика как посредника, детали могут теряться, а обратная связь замедляется. Заказчик должен принимать продуктовые и коммерческие решения; дизайнер и разработчики — напрямую согласовывать реализацию интерфейса в рамках утверждённых целей и ограничений.
Ограничения и критическая оценка
Заголовок раздела «Ограничения и критическая оценка»ФФФ помогает обсуждать компромисс между объёмом, датой и бюджетом, но не отменяет проектные риски и договорённости. Его стоит применять там, где стороны действительно могут менять объём и заранее определили, что нельзя исключать.
- Нельзя флексить обязательные требования. Законодательные требования, безопасность, целостность данных и критичные пользовательские сценарии должны быть выделены в обязательную часть. Если она не помещается в рамки, нужно менять дату, бюджет или саму цель проекта, а не выдавать неполное соответствие за приемлемый выпуск.
- «Качество» нужно определить. Это не одна шкала: функциональная полнота, визуальная полировка, производительность и надёжность имеют разные пороги. Зафиксируйте минимальные критерии приёмки для каждого важного качества, иначе одна сторона будет считать упрощение допустимым, а другая — браком.
- Фиксированный бюджет распределяет риск. Договор должен описывать исходные допущения, порядок изменения требований, зависимость сроков от решений заказчика и способ оценить дополнительную работу. Иначе гибкий объём может превратиться в спор о том, что входило в первоначальную цену.
- Один ответственный не заменяет экспертизу. Назначьте владельца приоритетов, но заранее организуйте сбор требований от пользователей, бизнеса и специалистов. Оставьте обязательные проверки для правовых, технических и операционных рисков.
- Не все системы можно выпускать частями. Некоторые архитектурные изменения и миграции требуют последовательных подготовительных этапов. Делите работу по безопасным границам, а перед запуском проверяйте совместимость, откат и эксплуатационную готовность.
- Сокращение объёма должно опираться на ценность. Если выбирать функции только по оценке трудоёмкости, можно убрать важный сценарий и сохранить удобные, но второстепенные детали. Сравнивайте ожидаемую пользу, обязательность, риски и стоимость реализации.
ФФФ — это модель управления ограничениями проекта, а не универсальная методика разработки или способ заранее угадать точный объём работы. Она полезна, когда заказчик и команда готовы регулярно принимать решения и открыто пересогласовывать объём в пределах заранее заданных правил.