Привет! Я Вениамин Мустафин, директор по развитию компании fuse8. Мы строим свою экспертизу на создании цифровых продуктов для бизнеса и делимся наработками через контент. В этой и других статьях на Хабре рассказываю о процессах и практиках, которые делают разработку цифровых продуктов прозрачнее, эффективнее и понятнее для заказчиков и команды.
Мы часто говорим о проектировании. Оно важно: продумать логику, UX, фичи, приоритеты — это фундамент. Но правда в том, что на проектировании всё не заканчивается. Как только начинается разработка, в игру вступают совсем другие законы. Все, кто хоть раз запускал цифровой продукт, знают: как бы круто ты ни проектировал — на этапе разработки всегда что-то пойдет не так.
Какие-то фичи окажутся сложнее, чем предполагалось. Подрядчик сорвет интеграцию. Заказчик внезапно придет с «а давайте еще вот это» и «вот прям обязательно». И всё — план (или его часть) превращается в тыкву. Однако глобально ничьей вины в этом нет — так разрабатывается любой реальный продукт, в котором бизнес действительно нуждается.
Вот почему мы используем FFF — методологию, которая не заставляет никого делать вид, будто все будет (или уже идет) гладко. Об FFF нужно говорить не как о теории, а как об инструменте, который принесет результат, и даже сможет спасти вас на проекте, если им правильно пользоваться.
Что такое FFF
Fixed Time. Fixed Budget. Flexed Scope.
Три F, три опоры.
Время фиксировано. Мы не вываливаемся из дедлайна.
Бюджет фиксирован. Мы не требуем дополнительных денег за разработку в рамках зафиксированного срока.
Функциональность гибкая. Мы адаптируемся — и сохраняем результат в рамках времени и денег.
На практике это значит, что мы точно знаем, когда и за сколько клиент получит продукт. Но мы оставляем за собой право флексить — менять, упрощать или отказываться от части функциональности во благо продукта. Потому что по-честному понимаем, что в процессе разработки контекст может измениться.
Появляется новая задача — значит, от чего-то нужно отказаться. Что-то пошло не так — пересобираем скоп. Главное — к установленному сроку есть продукт, который работает и нужен. Он не раздут комом спорных фичей, не находится в бесконечной бете. А законченный и – главное – работающий MVP.
Пару слов об MVP
Прежде чем углубиться в прелести FFF, нам с вами важно договориться о базовом термине. MVP — это не «вырезали всё, что не влезло, и хоть что-то показали». Это не черновик продукта, не его прототип. Не «ну, оно запускается — и ладно».
MVP — это первая стабильно работающая версия продукта, которая уже решает задачу пользователя.
Представьте, что вам нужно построить мост. Что можно назвать MVP моста? Нет, не доску, которая будет перекинута через реку. MVP должен стать, как ни странно мост, просто он будет такой базовой комплектации: без декоративных элементов, без освещения или, например, удобных ограждений. При этом он не ломается от дуновения ветра и не прогибается под весом пользователя, стабильно выполняя свою функцию.
Когда мы говорим «флексить» в контексте FFF, мы не предлагаем забить на всё. Мы предлагаем трезво посмотреть на то, что реально нужно, чтобы MVP стал живым, рабочим продуктом. И всё, что выходит за рамки этой цели — может быть честно отложено.
Почему FFF лучше, чем «традиционные» подходы
Waterfall
Старый-добрый водопад живет в фантазиях, где всё можно распланировать заранее. На практике — в момент первого форс-мажора вся модель рушится. Команда в панике, сроки сдвигаются, клиент в недоумении. Все делают вид, что «ещё немного, и всё будет». Никто не понимает, что именно сейчас происходит.
Scrum
Скрам признаёт хаос, но уходит в другую крайность: «мы не можем сказать, сколько займет задача, но будем «спринтить». Это ок для стартапов или внутренних команд. Но если у клиента ограниченный бюджет и жёсткие сроки, скрам превращается в лотерею.
FFF
FFF — методология, которая предполагает, что что-то пойдет не по плану. Но не просто знает — предлагает, что делать, когда это случится. Это честный, прагматичный, и при этом прозрачный способ довести проект до результата.
Почему FFF нравится заказчикам
Заказчики – те, кто заказывают разработку продукта. Не обязательно речь может идти о заказчиках при аутсорс-модели, когда внешний бизнес покупает разработку у ИТ-подрядчика. Здесь валидны и случаи с внутренними заказчиками, когда в рамках одной организации поступает запрос на продукт – от одного департамента к другому, например. Почти все заказчики хотят одного и того же:
Получить продукт в срок.
Не выйти за рамки бюджета.
И при этом иметь возможность вносить изменения по ходу.
FFF делает это возможным — за счёт гибкости скопа. Это как шопинг с ограниченной суммой: хочешь добавить в корзину еще одну вещь — выкинь другую. Хочешь шляпу, хотя не планировал? Можешь, конечно, ее взять, но тогда придется отказаться от футболки. Или от шорт. Или от сумки.
Все это звучит разумно и логично и прельщает вот этой самой гибкостью. Когда ты честно показываешь клиенту, как работает эта система — почти все говорят: «Логично. Погнали».
Но…
Флекс – всегда боль
На этапе продаж FFF воспринимается отлично. Даже на моменте, когда мы четко проговариваем: «Чуваки, все будет круто, но стопроцентно настанет момент, когда мы придем к вам и скажем, что что-то не влезет, что для вот этой хотелки нужно вырезать что-то из ранее утвержденной функциональности». Люди понимают, что идея разумная.
И как бы вы классно все на старте ни обговорили, этот самый момент флекса всегда будет камнем преткновения. Когда надо выбирать, от чего отказываемся, всегда появляется элемент стресса.
Тогда и начинается настоящая работа. Сомнения, обиды, микроскандалы. Ключевое тут — доверие. Если заказчик команде не доверяет, любое «пофлексим» он воспримет как «вы мне ничего не сделаете, просто хотите слиться».
FFF работает только в связке с прозрачностью и зрелостью. Клиент должен понимать: мы не халтурим. Мы не уходим от задач. Мы держим срок и бюджет, как и обещали. Просто появился выбор, и его надо делать вместе.
Чтобы создать контекст прозрачности, важно помнить, что в первые недели разработки флексить неразумно. Если разработчик вначале проекта уже начинает флексить, то это плохой разработчик, красный флаг и все такое.
Сначала мы просто оформляем рабочий процесс и показываем, как все делается. Это работа на доверие. И только потом, когда оно появится с обеих сторон, — можно начинать говорить про гибкость.
Пример: FF Manager
Один из наших продуктов, где FFF себя отлично показал, — FF Manager. И нет, мы не назвали продукт в честь методологии, в FF Manager FF – это Freedom Football ?
Мы запланировали MVP. Среди фич не было драг-н-дропа тренировок в календарь — он казался слишком сложным для первой версии. Зато был, например, годовой календарь для планирования тренировок (в дополнение к недельному и месячному его видам).
Потом: приходит клиент и говорит, что драг-н-дроп нужен позарез. Окей. Сели, подумали.
Мы могли сказать нет. Но мы работаем по FFF. Поэтому:
Мы пересмотрели план.
Поняли, что драг-н-дроп не такой сложный, как казался.
Выкинули годовой календарь.
Сделали нужную фичу.
Всё честно, всё в срок. Бюджет тот же. Просто мы вместе выбрали, что важнее. А годовой календарь, который казался очень важным сначала, в итоге так и остался в бэклоге, как не самая необходимая в реальности фича.
Было тяжело? Да. Были острые переговоры? Ещё как. Но продукт получился ровно такой, какой был нужен.
Как флексить: 4 рабочих тактики
Когда нужно менять скоп, мы используем несколько подходов. Вот самые частые:
Упростить. Запланировали сложную реализацию? Делаем проще. Запланировали автоматизацию элемента? Заменяем полуручным режимом. Пример: вместо интеграции с внешней базой — временно хардкодим данные.
Отказаться. Просто убираем фичу. Без боли не обойтись, но иногда по-другому никак.
Заменить. Вместо отдельной логики на элемент — что-то примитивнее. Пример: не форма обратной связи с логикой, а кнопка на переход в Telegram с менеджером.
Минимизировать. Убираем нефункциональные «финтифлюшки» — анимации, спецэффекты, переходы. Всё, что не критично для получения пользователем результата.
FFF — это зрелость
На FFF невозможно ехать, не разбираясь в управлении проектами. Эта методология требует зрелости от команды и клиента. Она для тех, кто хочет работающий продукт.
FFF — это честный подход для проектов, которые нельзя растягивать. Он не всем подойдёт. Но сработает для тех, кто понимает, как делаются цифровые проекты.
Для заказчика: FFF требует вовлеченности. Это не пассивная история «заплатил и жду». Это история про партнерство и совместные принятия решений.
Для команды: FFF диктует общение без обманов и накруток. Нужно объяснять, доказывать, разбираться и создавать доверие через эту коммуникацию.
Гибкость в FFF – не способ закрыть дыры в опыте или ответственности. Это способ собраться, когда всё пошло не по плану.