Вайрфреймы в разработке ПО: как планирование экономит время и деньги

Почему Фора Софт написала этот плейбук

Фора Софт разрабатывает программное обеспечение на заказ с 2005 года. За 20+ лет мы провели планирование и вайрфрейминг для самых разных задач: телемедицинских платформ, live-commerce, видеостриминга, LMS, AI-инструментов для продаж, IoT-дашбордов и on-premise-систем связи. Такие проекты, как BrainCert, Meetric и TapeReal, начинались одинаково — с дискавери и кликабельного вайрфрейма, согласованного до того, как мы написали первую строку продакшен-кода.

К нам же приходят, когда более дешёвый подрядчик этот этап пропустил. Сценарий всегда один и тот же: наполовину готовый продукт, запутанный бэклог, дорожная карта, которая не совпадает с кодовой базой, и счёт больше первоначальной оценки. Эта статья — внутренний чек-лист, которым мы пользуемся, чтобы такого не происходило, опубликованный целиком, потому что каждый основатель имеет право прочитать его до того, как подпишет контракт на разработку.

Если вы — тот человек в команде, кому приходится защищать строку «планирование» перед советом директоров или ко-фаундером, вот одностраничная версия аргумента: с цифрами, процессом, типичными ошибками и альтернативами.

Ответ в одном абзаце

Вайрфрейминг — это самый дешёвый этап в жизненном цикле ПО, на котором можно передумать. Небольшое UX-изменение в кликабельном вайрфрейме занимает пять минут. То же изменение после разработки обходится примерно в 100 раз дороже, а после релиза — до 1 000 раз дороже, если учитывать реагирование на инциденты, откаты и нагрузку на поддержку. Это не мнение, а вывод из четырёх десятилетий эмпирических исследований (Боэм, IBM, NIST, Standish). Заплатить за 2–6 недель полноценного дискавери и вайрфрейминга до начала разработки — самый дешёвый вид страховки, который может позволить себе бюджет на ПО.

Кривая стоимости изменений — с реальными цифрами

Три независимых тела исследований — эмпирическая работа Барри Боэма в TRW/IBM, IBM Systems Sciences Institute и американский NIST — сходятся на одинаковой форме кривой: дефект или изменение, пойманное на этапе требований, стоит примерно 1 условную единицу; найденное в разработке — в 10 раз больше; после релиза — в 100 раз и более.

Отчёт NIST 2002 года оценил стоимость низкого качества ПО только в США в 4,4 трлн ₽ в год (примерно 0,6% ВВП на тот момент); продолжение исследования от Consortium for IT Software Quality в 2022 году поднимает эту цифру до 180 трлн ₽. На любом масштабе вывод один: переработка, которой можно было избежать на этапе планирования, всё равно нагонит вас позже.

Большинство провалов происходит до кода, а не в нём

Двадцать лет отраслевых исследований до неловкого однозначно показывают, где на самом деле ломаются проекты:

35–56% дефектов в продакшене берут начало в требованиях. Анализы Accenture и Кейперса Джонса относят примерно половину всех багов в выпущенном ПО к нечётким, отсутствующим или двусмысленным требованиям, а вовсе не к инженерной команде.

Только 31% проектов полностью успешны. Отчёты Standish CHAOS из года в год показывают: около трети проектов сдают в срок, в бюджет и в скоупе; половина «проблемные» (просрочка, перерасход или урезанный скоуп); примерно пятая часть вовсе отменяется. Маленькие проекты успешны более чем в 90% случаев; крупные — менее чем в 10%.

Крупные ИТ-проекты выходят за бюджет на 45%, отстают по срокам на 7% и приносят на 56% меньше ценности, чем планировалось. Исследование McKinsey совместно с Оксфордом по более чем 5 400 проектам показало, что средняя крупная ИТ-программа выходит за бюджет на 66% и за сроки — на 33%.

Чёткая формулировка требований входит в топ-3 предикторов успеха проекта по Standish — наряду с вовлечённостью пользователей и поддержкой руководства. Ни один из этих трёх факторов не достигается тем, что вы быстрее печатаете в IDE. Все три — это про лучшее планирование.

Вайрфрейм vs макет vs прототип vs спецификация

Большинство разногласий на проектах, которые мы приходим спасать, начинается с того, что заказчик и подрядчик понимают под «дизайном» разное. Вот таксономия, которой мы пользуемся.

Правило, которое мы соблюдаем: никогда не пропускайте слой. Если у вас есть только высокодетальный макет — вы зафиксировали бренд до того, как зафиксировали поток. Если только прототип — у вас, скорее всего, нет критериев приёмки. Каждый пропущенный слой — это будущий спор.

Инструменты вайрфрейминга в 2026 году — что и когда использовать

Наш стандарт — Figma. Сверху добавляем Miro для ранних брейнштормов и переключаемся на Axure только тогда, когда спецификация клиента требует тяжёлой условной логики (финансовые дашборды, сложные формы). Если ваш подрядчик до сих пор работает в Adobe XD — считайте это красным флагом: инструмент больше не развивается.

Процесс планирования и вайрфрейминга Фора Софт

Каждый наш проект идёт по одному и тому же скелету. Содержание этапов меняется от продукта к продукту, порядок — нет.

Этап 1 — Дискавери и бенчмаркинг (1–2 неделя)

Мы начинаем с интервью каждого стейкхолдера, который будет принимать решения по продукту. Бизнес-аналитик фиксирует постановку задачи, нерушимые условия, допущения и открытые вопросы в одном документе. Затем мы бенчмаркаем три-пять ближайших конкурентов или сопоставимых продуктов, собираем скриншоты того, что работает, и помечаем паттерны, которые стоит перенести к себе. Свой подход к аналитике мы открыто расписали в материале про процесс аналитики.

Этап 2 — Пользовательские истории и информационная архитектура

Для каждой роли в продукте мы пишем пользовательские истории в формате «Как <роль>, я хочу <действие>, чтобы <результат>». Затем раскладываем их в карту сайта и первичную навигационную схему. Именно на этом этапе скоуп становится честным — или становится опасным.

Этап 3 — Низкодетальные вайрфреймы

Аналитик скетчит каждый экран в сером цвете. Тимлиды разработки и архитекторы смотрят на них рано — не после передачи, — чтобы сразу пометить то, что окажется дорогим в разработке. QA тоже в комнате: чем раньше пишутся тест-кейсы, тем меньше дыр в спецификации, с которой вы пойдёте в продакшен.

Этап 4 — Кликабельный прототип и обратная связь от клиента

Вайрфреймы связываются в интерактивный прототип. Клиент кликает по продукту так, будто он уже живой. Большинство наших проектов сходятся за 1–3 итерации обратной связи. На этом же этапе мы проводим неформальные юзабилити-тесты: исследования показывают, что пять пользователей выявляют около 85% юзабилити-проблем, так что большая выборка не нужна.

Этап 5 — Подробное коммерческое предложение по разработке

После согласования прототипа мы режем бэклог на фичи с независимыми оценками. Клиент видит стоимость и сроки по каждой фиче и сам решает, что войдёт в MVP, а что — в v2. Это механическая часть нашей практики оценки: никаких чёрных ящиков, никаких единых «цен на проект», за которыми ничего не стоит.

Этап 6 — Передача в продакшен-команду

Финальные артефакты (кликабельный прототип, подписанная дизайн-спецификация, бэклог, критерии приёмки) переходят к команде разработки. Звонок-кикофф закрывает дискавери и открывает разработку. С этого момента запросы на изменение идут через формальный процесс относительно подписанной спецификации, а не через ад-хок-сообщения в мессенджерах.

Как Agent Engineering ускоряет этот процесс на 15–20%

Мы пользуемся внутренней AI-инфраструктурой — мы называем её Agent Engineering, — чтобы сжать механическую часть дискавери. Бенчмаркинг фичсетов конкурентов, расшифровка дискавери-созвонов в черновики пользовательских историй, генерация инвентаря компонентов по вайрфреймам, автодрафт критериев приёмки по экранам прототипа, предварительный расчёт диапазонов оценок. За каждым выходом по-прежнему стоит senior-аналитик, но стоимость черновой работы существенно ниже.

На практике это значит, что фаза планирования, которая в традиционных агентствах занимала 4–6 недель, у нас обычно идёт 3–5 недель. Мы не оставляем себе сэкономленные часы — если у аналитика часов меньше, в счёте их тоже меньше.

Типичные сроки и бюджеты планирования

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

Мини-кейс: как вайрфрейминг спас дейтинг-приложение от раздувания скоупа

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

На этапе вайрфрейминга мы провели простой разбор: по предыдущим проектам мы знали, что именно много фильтров без сильного процента совпадений добивает ранние дейтинг-приложения. Мы предложили срезать MVP до минимального ядра — мэтчинг, чат, безопасность — а фильтры, группы и ленту отложить на v2.

Кликабельный вайрфрейм сделал это наглядным. Клиент увидел, что именно встретит пользователь в первый день, согласился на обрезание и запустился примерно вдвое быстрее изначального плана. Когда клиент вернулся за v2, у нас уже был полностью проработанный бэклог. Такая экономия — скоуп срезается на вайрфреймах, а не в продакшене — это и есть точка, в которой кривая стоимости начинает окупаться.

Мини-кейс: чего на самом деле стоит пропуск вайрфрейминга

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

Через полгода клиент вернулся с просьбой «поправить». Подрядчик-заменитель проигнорировал наши вайрфреймы, захардкодил Adobe After Effects как заглушку на бэкенде (никакого реального бэкенда не было), выкатил красивый фронт, который ломался под реальной нагрузкой, и выставил счёт почти на ту же сумму, что и наша первоначальная оценка. 5-секундное видео рендерилось 20 минут. Клиент в итоге заплатил нам ещё раз — переписать платформу по тем самым вайрфреймам, которые он отложил на полку, чтобы сэкономить.

Какая-то версия этой истории повторяется у нас каждый квартал. Вывод не «нанимайте команду дороже». Вывод — «никогда не нанимайте команду, которая хочет пропустить план».

Фреймворк решения — сколько планирования вам нужно, в пяти вопросах

1. Сколько разных ролей обслуживает ваш продукт? Одна роль (личный инструмент) переживёт неделю планирования. Три и больше (пациент / врач / администратор; покупатель / продавец / платформа; студент / преподаватель / организация) требуют полного набора вайрфреймов и кликабельного прототипа.

2. Вы регулируемый бизнес? HIPAA, GDPR, SOC 2, MiCA, EU AI Act, COPPA. Регулятор, который может вас закрыть, — это причина зафиксировать критерии приёмки до кода, а не после.

3. Сколько реальных денег на кону в каждом релизе? Продукты, которые проводят платежи, переводят деньги или ведут пациентов, имеют асимметричные потери при сбоях. Планирование — это страховка от длинного хвоста.

4. Команда распределённая? Распределённая продакшен-команда не может встать за плечом дизайнера. Письменные спецификации и критерии приёмки — это то, как они остаются согласованными. Без них переработка тихо удваивается.

5. Будут ли инвесторы или совет директоров смотреть на эту дорожную карту? Если да — вас попросят показать майлстоуны, burn rate и скоуп. Вайрфреймы и оценка на уровне фич — это и есть способ ответить без размахивания руками.

Пять ошибок, которые мы видим почти в каждом спасении

1. Lorem ipsum повсюду. Заглушки скрывают реальную проблему плотности информации. Используйте реальный по длине контент из конкретной предметной области — имена врачей, номера полисов, названия курсов — с самого первого скетча. Строки реальной длины ломают макеты, которые на lorem ipsum выглядели нормально.

2. Высокая детализация слишком рано. Команды неделями спорят про цвета и типографику, пока поток в основе ещё не верный. Оставайтесь в низкой детализации, пока не подписаны информационная архитектура и базовый поток. Бренд приходит после поведения.

3. Мобильная версия — позже. Дизайнить десктоп первым, а потом «адаптивить» — это способ выкатить сломанный мобильный опыт 70% пользователей. Скетчите мобильные вайрфреймы параллельно с десктопом с первой недели.

4. Критериев приёмки нет. Каждому экрану нужны измеримые правила: состояния загрузки, пустоты, ошибки, крайние случаи, варианты доступа. Прототип без критериев — это обещание без контракта.

5. Нет формального согласования. Если спецификацию никто явно не утвердил — все её утвердили молча, а потом будут спорить. Закройте фазу планирования подписанным артефактом (e-mail, DocuSign, утверждение в трекере задач) и ссылайтесь на него по каждому будущему запросу на изменение.

Критерии приёмки — контракт, который нужен вашему вайрфрейму

Вайрфрейм без критериев приёмки — это картинка продукта, а не контракт на его сборку. Как только визуал подписан, у каждого экрана должен быть набор правил: пустые состояния, состояния ошибок, загрузка, права доступа, валидация, точки адаптива, аналитические события. Это пункты, которые превращают «круто выглядит» в «мы договорились, что значит ‘готово’».

Мы фиксируем критерии в формулировках в стиле Gherkin к каждой пользовательской истории: «Дано: незалогиненный посетитель. Когда: он отправляет форму контакта с пустым email. Тогда: поле email подсвечивается красным с сообщением X, а кнопка отправки остаётся неактивной». Это скучно. И это ровно тот способ, которым закрывается зазор неопределённости, порождающий половину дефектов в продакшене.

KPI, по которым видно, что планирование окупилось

KPI качества. Доля дефектов, утёкших из требований, ниже 5%. Доля запросов на изменение после кикоффа — ниже 10% от состава фич. Прохождение юзабилити-теста выше 85% с первого круга. Если хоть что-то из этого мимо — проблема в спецификации, а не в инженерах.

Бизнес-KPI. Время до подписанной спецификации — меньше 4 недель для стандартного MVP. Прирост скорости разработки на 10–15% в первых двух спринтах (чёткая спецификация даёт измеримый рост стори-поинтов). Отклонение burn rate от плана — менее 15% к концу третьего спринта. Если показатель сползает — значит, бэклог был недопроработан.

KPI надёжности. Ноль блокирующих запросов на переработку, связанных с пропущенными требованиями, в первые 8 недель разработки. Если запросы «по спецификации» продолжают приходить — поставьте спринт на паузу и вернитесь к плану. Это дешевле, чем кодить сквозь это.

Когда планирование избыточно

Когда продукт — одноразовый внутренний инструмент. Одна экранная админская форма, которой пользуются три человека, не нуждается в кликабельном прототипе. Напишите пользовательские истории на салфетке и выкатывайтесь.

Когда вы уже прошли product-market fit и итерируетесь. Команды на зрелом продукте обычно ведут планирование на уровне фич, а не на уровне продукта. Цикл вайрфрейминга сжимается до дней, а не недель.

Когда у вас нет ни одного подтверждения, что продукт нужен рынку. Если вы пока не знаете, нужен ли продукт хоть кому-нибудь, потратьте бюджет вайрфрейминга на интервью с клиентами. Вайрфреймить продукт, о котором никто не просил, — это способ построить красивый провал точно в срок.

Как оценить процесс планирования у подрядчика

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

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

Спросите, как они оценивают. Пофичные оценки с поимёнными рисками лучше, чем «проект стоит X». Форма, которую используем мы, описана в нашем процессе.

Спросите, как выглядят первые две недели сотрудничества. Если ответ «начинаем кодить» — бегите. Если «интервьюируем ваших пользователей и анализируем конкурентов» — оставайтесь.

Спросите, как обрабатываются запросы на изменения. Должна быть письменная политика, привязанная к подписанной спецификации. «Разберёмся по ходу» — это строка в будущем счёте.

Частые вопросы

Сколько должна занимать нормальная фаза вайрфрейминга для MVP?

Для однопользовательского SaaS-MVP — 2–4 недели от и до: дискавери, пользовательские истории, низкодетальные вайрфреймы, кликабельный прототип, 1–3 раунда обратной связи и подписанная спецификация. Для мультиролевой платформы или регулируемого продукта закладывайте 4–6 недель. Меньше реально, если скоуп действительно маленький; больше — обычно знак того, что скоуп всё ещё не определён.

Можно ли пропустить вайрфреймы и сразу делать макеты в Figma?

Можно — и заплатите за это позже. Пропуск низкодетальных вайрфреймов — это способ начать спорить про цвета до того, как договорились о потоке. Начинайте с низкой детализации, фиксируйте поток, а потом переходите к макетам. Figma тянет и то и другое — фокус в том, чтобы не торопиться раскрашивать.

Сколько обычно стоит планирование и вайрфрейминг?

Мы называем цену по проекту после 30-минутного скоупинг-звонка. Диапазоны идут от сотен тысяч рублей за микро-MVP до десятков миллионов за регулируемую мультиролевую платформу. Благодаря Agent Engineering мы делаем работу на 15–20% быстрее традиционных агентств — и счёт это отражает: мы не накручиваем часы, которых больше не нужно.

Что если у нас уже есть дизайны от другой команды?

Мы их аудируем. Если информационная архитектура крепкая и есть критерии приёмки — подхватываем с передачи и экономим вам ранние этапы. Если дизайны красивые, но структурно сломанные — нет адаптива, нет крайних случаев, нет согласованности с бэкендом — мы это скажем и предложим минимальный объём переработки до начала разработки.

Действительно ли нужен кликабельный прототип, или хватит статичных экранов?

Кликабельный прототип — это самый высокорычажный артефакт всей фазы. По статичным экранам каждый стейкхолдер представляет продукт по-своему. Клик по потоку вынуждает прийти к консенсусу. Для всего, что больше лендинга, мы настаиваем на прототипе.

Как вайрфрейминг сочетается со спринтами Agile/Scrum?

Хорошо — если относиться к планированию как к нулевому спринту, а не как к бесконечному преквелу. Дискавери и вайрфреймы заполняют sprint zero и, иногда, sprint one; дальше дискавери идёт параллельной дорожкой внутри каждого спринта, на один спринт впереди разработки. Бэклог никогда не «готов» — он всегда на один спринт лучше проработан, чем тот, что сейчас в работе.

Какую ошибку чаще всего совершают основатели на этой фазе?

Воспринимают её как творческое упражнение, а не как контрактное. Задача вайрфрейма — закрыть неопределённость до кода. Когда стейкхолдеры начинают говорить «круто выглядит, давайте уже строить», не добавив «и вот критерии приёмки», следующие полгода переработки уже тихо закладываются в график.

Делаете ли вы вайрфрейминг как отдельный сервис?

Да. Наша услуга по планированию и аналитике идёт как проект с фиксированным скоупом, который заканчивается подписанной спецификацией, кликабельным прототипом и пофичной оценкой. С этими артефактами вы можете идти к любой команде разработки — к нам, к вашей внутренней или к кому-то ещё. Часто мы и сами это рекомендуем.

Что почитать дальше

Готовы зафиксировать скоуп до того, как зафиксируете код?

Исследования, цифры и наш собственный бэклог спасательных проектов сходятся на одном выводе: самое дешёвое время решить, что вы строите, — на этапе вайрфрейма; самое дорогое — после запуска. Несколько недель медленной работы в календаре фазы планирования обычно экономят месяцы быстрой переработки в продакшене.

Если вы начинаете что-то новое — принесите идею и ограничения. Если вы уже в середине разработки и нервничаете — принесите то, что есть. В любом случае следующий шаг — короткий и прямой разговор о том, что реально входит в скоуп, и затем план с реальными цифрами.