Оценка проекта разработки: как считают сроки и бюджет

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

19 сентября 2026 Бизнес 15 мин чтения

---

Что такое оценка проекта разработки простыми словами

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

Сравнение из соседней отрасли: расчёт ремонта квартиры. Прораб не называет сумму, глядя на площадь. Он считает объёмы по каждому виду работ — стяжка, электрика, плитка, — умножает на расценки, добавляет материалы и закладывает запас на то, что вскроется под старой штукатуркой. Разработка устроена так же, только вместо квадратных метров — экраны, интеграции и сценарии пользователя, а вместо скрытой проводки — чужая учётная система, к которой предстоит подключиться.

Оценка отвечает на четыре вопроса заказчика. Первый — сколько денег закладывать в бюджет года. Второй — когда приложение появится в магазинах. Третий — что именно входит в названную сумму, а за что придётся платить отдельно. Четвёртый — насколько эта цифра надёжна и при каких условиях она изменится.

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

Три уровня точности: от вилки до рабочей сметы

Оценку дают в разные моменты: на первом звонке, после описания задачи и после технического задания. Это три разных расчёта с разной погрешностью, и путать их дорого. Заказчик запоминает цифру с первого звонка как обещание, подрядчик считал её как порядок величины.

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

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

Пять методов оценки трудозатрат

Методов счёта немного, и в реальном проекте их комбинируют: крупные блоки прикидывают по аналогии, спорные места разбирают по задачам, а рискованные — считают по трём точкам. Ниже — пять способов, которые встречаются в коммерческих проектах чаще всего.

Экспертная оценка

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

Оценка по аналогии

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

Декомпозиция снизу вверх

Продукт разбивают на экраны, сценарии и технические задачи, каждую задачу оценивают отдельно, затем складывают. Самый трудоёмкий метод: на среднее e-commerce-приложение уходит от 3 до 5 рабочих дней работы аналитика и ведущих разработчиков. Зато результат проверяем строка за строкой — именно такая разбивка нужна, чтобы подписывать фиксированную сумму. Важное свойство: декомпозиция вскрывает пропущенные работы. Пока задача звучит как «личный кабинет», в ней не видно ни восстановления пароля, ни удаления учётной записи, которого требуют правила магазинов приложений.

Трёхточечная оценка (PERT)

Для каждой задачи называют три числа: оптимистичное O — если всё сложится удачно, наиболее вероятное M и пессимистичное P — если сработают все негативные факторы. Итоговая величина считается как взвешенное среднее по формуле (O + 4 × M + P) / 6, а разброс оценивают как (P − O) / 6. Метод придуман ещё в 1950-х и подробно разобран в материале «Как выполнять оценку по трём точкам» на Хабре. Практическая польза для заказчика простая: подрядчик показывает не одно число, а вилку с весами — и сразу видно, какие задачи дают основной разброс.

Относительная оценка: story points и «футболки»

Команда сравнивает задачи между собой, а не с часами: эта вдвое сложнее той, эта — размера M, а эта — XL. Оценки в условных единицах переводят в календарь по фактической скорости команды за прошлые итерации. Метод хорошо работает внутри команды, которая давно работает вместе, и плохо конвертируется в коммерческое предложение: заказчику нужны рубли и даты, а не абстрактные единицы. Подробнее подход описан в статье «Оценка задач в Story Points».

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

Из чего складывается смета: роли, часы, ставки, буфер

Смета — это таблица, где каждая строка отвечает на три вопроса: какая работа, кто её делает и сколько часов на неё заложено. Сумма получается умножением часов на ставку роли. Всё, что не попало в строки, в бюджет не попадёт — и всплывёт позже как «доработка».

Типовой состав ролей на проекте мобильного приложения для интернет-магазина: аналитик, дизайнер интерфейсов, разработчик мобильного приложения, разработчик серверной части, инженер по тестированию, руководитель проекта. Разбор зон ответственности каждой роли — в статье команда разработки: роли, состав и зоны ответственности.

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

Что обычно забывают заложить

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

Запас на неизвестность

В любой смете есть строка на то, что нельзя предвидеть. Классическая рекомендация — добавлять к полученной цифре около 20%; именно такой запас советует автор материала «Оценка трудозатрат в разработке ПО для начинающих», объясняя это тем, что задачи почти всегда оказываются сложнее, чем выглядят на бумаге. Размер запаса зависит от степени неизвестности: проект на готовом техническом задании с одной интеграцией обходится меньшим буфером, чем продукт с нуля в новой для команды отрасли.

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

Почему срок в календаре не равен сумме часов

Самое частое недопонимание в переговорах: заказчик складывает часы из сметы, делит на восемь и получает срок, который не совпадает с планом подрядчика. Расхождение возникает из-за того, что часы принадлежат разным людям и часть работ идёт одновременно.

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

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

Проверку в магазинах стоит закладывать в план отдельно: это внешний срок, на который команда разработки не влияет. Требования к приложению сформулированы в правилах проверки App Store, порядок публикации в Google Play описан в разделе для разработчиков Android, а условия размещения в отечественном магазине — в документации RuStore. Отклонение на проверке добавляет к сроку не только время повторной подачи, но и дни на исправление замечаний.

Fix Price и Time & Materials: как модель меняет расчёт

Одна и та же задача считается по-разному в зависимости от того, как оформлены отношения с подрядчиком. Fixed Price — фиксированная сумма за фиксированный объём работ. Time & Materials — оплата по фактически затраченным часам и ставкам ролей. Разница не только в договоре: она меняет и метод оценки, и размер запаса, и то, кто несёт последствия ошибки в расчёте.

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

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

Ни одна из моделей не лучше другой — они решают разные задачи. Фиксированная сумма подходит там, где объём работ ясен и меняться не будет: перенос известного функционала, типовой интернет-магазин, продление существующего продукта. Оплата по фактическим часам выигрывает на исследовательских задачах и доработках работающего продукта, где список задач меняется каждый месяц. Развёрнутое сравнение с примерами расчётов — в статье Time & Materials или Fix Price, а чек-лист подготовки к обеим моделям — в материале про бюджет и сроки разработки.

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

Как считают проект, который собирают из готовых модулей

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

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

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

Модель оплаты в модульном подходе тоже состоит из частей, и в расчёт нужно закладывать все три. Первое — единоразовый платёж за интеграцию: разворачивание платформы под бренд, настройка модулей, подключение к учётной системе и эквайрингу, публикация в магазинах; срок — до 30 рабочих дней. Второе — ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды FITTIN: мониторинг, обновления модулей, обновления безопасности; своя команда разработки для сопровождения не нужна. Третье — новый функционал и доработки за пределами базового набора: они считаются отдельно по модели Time & Materials, с оценкой задачи в часах перед стартом. Актуальные суммы по направлениям — приложение, сайт, приложение и сайт на одной кодовой базе — опубликованы на странице тарифов; сравнение полной стоимости владения разобрано в материале готовое решение против модульной платформы.

Как проходит оценка: шесть шагов

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

Что должно остаться у заказчика после оценки

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

Типичная ошибка на этом шаге

Заказчик получает смету и сравнивает её с другой по итоговой сумме. Но два расчёта почти никогда не описывают один объём работ: в одном есть тестирование и публикация, в другом их нет; в одном заложены три интеграции, в другом одна. Сравнивать нужно построчно, приведя оба расчёта к одинаковому составу работ, — иначе выигрывает не более выгодное предложение, а более короткое.

Сколько стоит оценка и от чего зависит цена разработки

Первые два уровня расчёта подрядчик обычно делает бесплатно: предварительная вилка и бюджетная оценка — часть работы с обращением. Платной становится третья ступень, потому что рабочая смета невозможна без документа, который описывает продукт по шагам. Услуга разработки технического задания стоит от 80 000 ₽ и занимает 10–30 рабочих дней в зависимости от объёма продукта и числа систем, к которым он подключается. На выходе остаются описание сценариев, прототипы экранов и схема интеграций — по ним считают смету, и они же остаются у заказчика, даже если он пойдёт с ними к другому подрядчику.

Сама цена разработки определяется выбранным подходом. Продукт, написанный с нуля, на старте обходится от 5 000 000 до 10 000 000 ₽ и занимает 120–250 рабочих дней до первой версии. Готовый сервис по подписке начинается от 30 000 ₽/мес и запускается за 5–10 рабочих дней, но ограничивает изменения тем, что доступно в тарифе. Сборка из готовых модулей считается по трём частям: единоразовая интеграция до 30 рабочих дней, ежемесячная лицензия с включённой поддержкой и доработки по фактически затраченным часам; суммы по направлениям опубликованы на странице тарифов.

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

Как пользоваться калькулятором окупаемости

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

Что вводить

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

Как устроен расчёт

Логика в четыре шага. Первое — берутся введённые данные о бизнесе. Второе — закладывается прирост конверсии, который даёт мобильное приложение: +3%, +5% или +8% в зависимости от выбранного сценария. Третье — активные пользователи приложения умножаются на прирост конверсии и на средний чек, получается дополнительная выручка по месяцам. Четвёртое — выручка умножается на маржинальность, а полученная прибыль сравнивается со стоимостью интеграции и лицензии выбранного тарифа: так появляются возврат вложений и срок окупаемости.

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

Что делать с результатом

• Сравнить срок окупаемости с горизонтом планирования компании: если он длиннее, стоит пересобрать состав первой версии.
• Проверить чувствительность: изменить конверсию и средний чек на 10–20% и посмотреть, как сдвинется результат.
• Сопоставить расчёт со сметой подрядчика — окупаемость считается от полной стоимости запуска, а не от одной интеграции.
• Взять цифры на встречу: они превращают разговор о цене в разговор об эффекте.

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

Семь причин, по которым оценка расходится с фактом

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

1. Требования описаны словами, а не сценариями

«Личный кабинет» и «программа лояльности» — это не требования, а названия разделов. Пока не описан путь пользователя по шагам, каждая сторона представляет разный объём работ. Итог: смета посчитана по минимальному прочтению, приёмка идёт по максимальному.

2. Интеграции оценены до знакомства с системой

Подключение к учётной системе оценивают по названию — «обмен с 1С», — а на практике выясняется, что остатки лежат в одной базе, цены в другой, а картинок товаров нет вовсе. Разбор данных до подписания договора стоит 1–2 рабочих дня и снимает главный источник отклонений в проектах для торговли.

3. Забыт объём работ на стороне заказчика

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

4. Сроки названы без учёта ожиданий

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

5. Оценку давал не тот, кто будет делать

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

6. Изменения принимаются без пересчёта

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

7. Тестирование и публикацию считают необязательными

Эти работы сокращают первыми, когда бюджет не сходится. Результат предсказуем: правки приходят от пользователей после релиза, а исправление ошибки в вышедшей версии стоит дороже, чем её обнаружение до публикации. Что входит в проверку продукта перед выходом, разобрано в услуге тестирования и контроля качества.

Как проверить расчёт подрядчика: девять вопросов

Заказчику не нужно уметь оценивать разработку самому. Достаточно задать вопросы, по ответам на которые видно, считали проект или называли цифру.

1. Каким методом считали? Ответ «по опыту» допустим для предварительной вилки и не годится для договора с фиксированной суммой.
2. Покажите разбивку по ролям и работам. Смета из одной строки не проверяется и не сравнивается с другими предложениями.
3. Какие допущения вы заложили? Их отсутствие означает, что риски не обсуждались и всплывут в ходе работы.
4. Что не входит в сумму? Список исключений говорит о зрелости подрядчика больше, чем список включённого.
5. Сколько заложено на тестирование и публикацию? Нулевые строки здесь — признак, что цифру подгоняли под ожидание заказчика.
6. Как считаются изменения? Нужен понятный порядок: оценка задачи в часах до начала работы и согласование до старта.
7. Что нужно от нас и когда? Данные, доступы и материалы бренда с датами — иначе задержка ляжет на сроки проекта.
8. Кто именно будет делать работу? Состав команды и занятость каждой роли; оценка подтверждается теми, кто её выполняет.
9. Что происходит после релиза? Условия сопровождения: что входит в поддержку, как считаются доработки, какое время реакции.

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

Кейсы: что показала оценка на практике

Три проекта, где расчёт сроков и бюджета проверялся фактом запуска.

Finn Flare: перезапуск вместо разработки с нуля

Финский бренд одежды перезапускал существующее приложение. На старте сравнивали два сценария: продолжать развивать прежнюю версию или перенести продукт на единую кодовую базу. Выбрали перенос: по итогам проекта бюджет оказался в 2,5 раза меньше, а скорость разработки — в 1,5 раза выше в сравнении с прежним подходом. Проект стартовал 28 декабря 2025 года, релиз состоялся 3 февраля 2026 года; с учётом новогодних праздников фактическая разработка заняла менее 30 рабочих дней.

Сыроварня: срок под событие в бизнесе

Первое мобильное приложение сети ресторанов Аркадия Новикова делалось под конкретную дату, и оценка строилась от неё: что должно войти в первую версию, чтобы уложиться. Запуск состоялся за 2 месяца, а в 2026 году кейс вошёл в число лучших проектов года премии Workspace Digital Awards. Пример показывает обратный ход расчёта: когда дата задана извне, считают не срок, а объём, который в него помещается.

Сатурн: когда объём данных меняет смету

Сеть строительных магазинов работает в 20 городах, каталог — свыше 30 000 товаров, с привязкой к региональным складам и учётной системе. Такой проект нельзя оценить по числу экранов: основная трудоёмкость лежит в интеграции и правилах наличия товара. В первый месяц после запуска приложение получило 7 594 установки при конверсии 12,4%. Разбор архитектуры подобных продуктов — в статье о строении приложения интернет-магазина.

Итог: оценка проекта на одной странице

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

Материалы по теме:

• Деньги проекта: от чего зависит стоимость разработки, стоимость разработки программного обеспечения, ошибки бюджета.
• Подготовка к оценке: предпроектное исследование, жизненный цикл разработки продукта, роли в команде.
• Условия работы: Time & Materials или Fix Price, чек-лист бюджета и сроков, поддержка после запуска.

Что делать дальше:

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

Часто задаваемые вопросы

Как оценить стоимость разработки приложения до подписания договора?

Порядок суммы дают по аналогии с похожими проектами: достаточно описать тип продукта, платформы и список основных функций. Такая вилка считается за 1–2 рабочих дня и годится, чтобы решить, продолжать ли разговор. Для бюджета компании нужна следующая ступень — оценка по перечню функций с известными интеграциями, она занимает 3–5 рабочих дней. Точная сумма под договор считается только после технического задания и прототипов экранов, когда задачи разбиты и оценены по отдельности.

Почему подрядчики называют разные сроки и бюджеты по одному описанию?

Чаще всего потому, что считают разный объём работ. В одном расчёте есть тестирование, публикация в магазинах и приёмка, в другом их нет; один заложил три интеграции, второй одну; один считает по трём точкам с запасом, второй назвал оптимистичное число. Дополнительный источник разброса — скорость конкретной команды и то, сколько кода она берёт готовым. Сравнивать предложения нужно построчно, приведя их к одинаковому составу работ, а не по итоговой сумме.

Что такое трёхточечная оценка и зачем она нужна?

Это способ посчитать задачу через три числа: оптимистичное, наиболее вероятное и пессимистичное. Итог считают как взвешенное среднее по формуле (O + 4 × M + P) / 6, а разброс — как (P − O) / 6. Метод показывает не одно число, а вилку с весами, и сразу видно, какие задачи дают основной разброс: обычно это интеграции с чужими системами и сценарии, которые команда делает впервые. Для заказчика это полезно тем, что разговор переходит с «почему так дорого» на «что именно здесь неизвестно».

Сколько времени занимает оценка проекта?

На проекте среднего размера — от 4 до 9 рабочих дней. Часть шагов идёт одновременно: аналитик собирает требования, пока разработчики разбирают учётную систему и способы оплаты. Быстрее всего проходит разбор задачи и сбор требований, дольше всего — счёт трудозатрат с разбивкой по задачам. Срок растёт, если у компании нет описания функций, каталог не готов к выгрузке или в проекте несколько внешних систем, к которым нужно подключаться.

Чем отличается оценка при Fix Price и при Time & Materials?

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

Что делать, если оценка превысила бюджет?

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

Как понять, что смета не завышена?

Посмотрите на структуру, а не на итоговую сумму. В расчёте должны быть все роли и все виды работ, включая тестирование, публикацию и управление проектом; часы должны быть привязаны к конкретным задачам, а не к разделам вида «разработка». Попросите показать допущения и список того, что в сумму не входит. Сравните доли: если на дизайн заложена половина бюджета, а на серверную часть и интеграции — десятая часть, стоит спросить почему. И проверьте, кто будет выполнять работу: оценку подтверждают исполнители, а не менеджер по продажам.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации. Диапазоны сроков и долей в смете приведены как ориентиры и зависят от конкретного проекта. App Store, Google Play и RuStore — товарные знаки соответствующих правообладателей; упоминаются для описания сервисов.