Из чего состоит оценка проекта для заказной разработки

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

Получили оценки от нескольких подрядчиков? Сравнение КП сведёт часы, ставки, сроки и итоговые суммы в одну таблицу.

Смотрите также: как мы проводим оценку разработки.

О том, как формируется стоимость проектов в YuSMP Group, рассказали в статье.

Предварительная оценка 

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

Такой подход помогает отфильтровать нерелевантные заявки и работать уже только с подходящими проектами - так мы экономим время команды и заказчика.

В YuSMP Group занимаются заказной разработкой, и мы никогда не предлагаем написать заново то, что уже есть на рынке. То есть, если проект заказчика может уложиться в какое-то коробочное решение - мы всегда об этом скажем и дадим соответствующую наводку.

Если проект все-таки подошел, по желанию клиента можем сделать первую грубую оценку. Исходя из ставки и примерных трудозатрат дадим вилку, так как погрешность на этом этапе может составлять до 30%.

Подробная оценка

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

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

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

Как происходит оценка

• Оценка аналитики и дизайна

Аналитик и менеджер проектов делают список функциональностей (фичелист), затем аналитик и дизайнер оценивают каждый пункт.

• Оценка разработки и тестирования

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

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

После завершения фичелиста  менеджер проектов составляет календарный план и представляет клиенту сроки и бюджеты проекта.

От чего зависит итоговая стоимость

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

• Сложность продукта. Простое MVP с базовым CRUD-функционалом стоит в разы дешевле сервиса с ролями, интеграциями и сложной бизнес-логикой.
• Выбор платформы и стека. Два нативных приложения (iOS + Android) обычно дороже одного кроссплатформенного решения на Flutter или React Native — дублируется часть работы.
• Состав и модель найма команды. Выделенная команда в штате студии, аутстаффинг или разовый проектный найм по-разному влияют на ставку и накладные расходы.
• Риски и незапланированные доработки. Интеграции со сторонними API, миграции данных и правки на позднем этапе закладываются в оценку заранее — иначе смета «поплывёт» в процессе.
• Сроки. Ускоренный запуск требует расширения команды и параллельной работы нескольких специалистов над одной фичей — это дороже последовательной разработки.

Примерное распределение бюджета по этапам, которое мы закладываем в подробную оценку:

Модели сотрудничества: Fixed Price и Time & Material

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

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

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

Как снизить стоимость без потери качества

Если бюджет ограничен, а сроки поджимают, есть несколько рабочих способов не раздувать смету:

• Начать с MVP. Выделить ядро продукта — 3–5 ключевых функций, без которых сервис не работает — и запустить его первым, а остальное добавлять по фидбеку пользователей.
• Выбрать кроссплатформенную разработку. Одна кодовая база на Flutter вместо двух нативных приложений сокращает разработку и последующую поддержку.
• Запускать функциональность поэтапно. Разбить фичелист на релизы и выводить в продакшн частями — это распределяет затраты во времени и позволяет корректировать план по метрикам первых релизов.
• Использовать готовые модули там, где это оправдано. Авторизация, платежи, аналитика — там, где нет смысла писать с нуля, если задача не уникальна для бизнеса.