CODEX IT 
Тендеры и лиды
Информация
Компания отправляет одно описание проекта нескольким подрядчикам и получает предложения на 1,5, 2,7 и 4 млн рублей. Сроки тоже отличаются: одна команда обещает закончить всё за три месяца, другая закладывает полгода.
Обычно причина не в том, что один подрядчик работает почти бесплатно, а другой завышает цену. Команды посчитали разные версии продукта, хотя получили одинаковый документ.
Представим сервис, в котором клиент создаёт заявку, исполнитель принимает её, стороны общаются в чате, а после завершения заказа проходит оплата. Для предварительного обсуждения этого достаточно, для оценки — нет.
Нужно понять, как пользователь регистрируется, кто назначает исполнителя, можно ли менять стоимость заказа, что происходит при неуспешной оплате, кто рассматривает спор и какие действия доступны администратору. Если ответы не зафиксированы, каждый подрядчик достраивает продукт самостоятельно.
Одна команда посчитает форму заявки, ручное назначение исполнителя и простую панель управления. Другая добавит геолокацию, автоматическое распределение, внутренний чат, рейтинг, возвраты и несколько ролей. Формально это один сервис, фактически — разные продукты.
Низкая цена может быть обоснованной, если подрядчик предлагает ограниченный MVP или использует готовые компоненты. Риск возникает, когда из расчёта исчезают работы, которые всё равно понадобятся.
Аналитика. До разработки нужно описать роли, статусы, пользовательские сценарии и исключения. Если команда разбирается с ними уже во время программирования, часть решений приходится переделывать.
Дизайн состояний. У экрана есть не только основной вид, но и загрузка, ошибки, пустые состояния и подтверждение действия. В смете могут быть посчитаны только основные макеты.
Административная панель. Бизнесу нужно управлять пользователями, заявками, ценами, контентом и статусами. Иногда это выясняется уже перед запуском.
Интеграции и релиз. Оплату, CRM, 1С, уведомления и карты нужно подключить и протестировать. Отдельно требуются сервер, домен, аналитика, публикация приложения и подготовка рабочей среды.
Тестирование. Проверка разработчиком и полноценное прохождение сценариев тестировщиком дают разный уровень качества и стоят по-разному.
Дорогая смета может включать более полную команду и реальные риски. Но иногда в неё закладывают сложную архитектуру, рассчитанную на нагрузку, которой у продукта не будет несколько лет.
Для первой версии сервиса с несколькими сотнями пользователей может быть достаточно простой серверной части. Если сразу строить распределённую систему, бизнес заплатит за масштаб, который пока не использует. Обратная крайность — слишком простая основа, которую придётся переделывать после добавления первых функций.
Оценивать нужно не размер предложения, а соответствие решения планам бизнеса.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Один подрядчик считает весь список пожеланий, другой выделяет функции, необходимые для запуска. Например, вместо рейтингов, подписок, бонусной программы и автоматического распределения в первую версию могут войти регистрация, создание заявки, кабинет, уведомления и базовое управление заказами.
В одном из проектов CODEx IT первоначальный состав мобильного сервиса оценивался примерно в 2,5 млн рублей. После обсуждения мы перенесли часть функций, упростили второстепенные сценарии и предложили CMS для стандартных административных операций. Первая версия сократилась до 1,8 млн рублей. Дешевле стал не тот же продукт — изменились границы релиза.
Для реализации MVP наиболее логичен Fixed Price: после декомпозиции фиксируются конкретный пул задач, срок и бюджет. Бизнес понимает, когда получит первую версию и сколько будет стоить проверка гипотезы.
Time and Materials означает оплату фактически потраченного времени и не гарантирует завершение всего MVP к конкретной дате и в пределах исходного бюджета. Поэтому T&M лучше подходит для развития уже запущенного продукта с меняющимися приоритетами, а не для первой версии, которую нужно выпустить целиком.
MVP, как и Fixed Price требует чётких границ: в смете должны быть указаны функциональность, допущения, результат этапов и правила оценки изменений. Тогда фиксированная цена будет защища срок и бюджет запуска.
Риск выше, если подрядчик называет точную стоимость после короткого описания, почти не задаёт вопросов и обещает реализовать весь список функций в ограниченный бюджет. В смете должны быть видны аналитика, дизайн, разработка, тестирование, интеграции и запуск либо прямо указано, что часть этих работ не входит.
Сигналом может быть как заметно более низкая, так и слишком высокая оценка без объяснения способа реализации. Низкая цена иногда скрывает исключённые работы, а высокая может означать, что подрядчик не погрузился в задачу и заложил максимальные риски, избыточную архитектуру и дополнительную маржу. Профессиональная команда должна показать, за счёт чего сформирована цена. В CODEx IT мы снижаем неопределённость через вопросы и декомпозицию, а не переносим все возможные риски в бюджет клиента.
В пресейле мы сначала погружаемся в бизнес-задачу: определяем пользователей, основной сценарий продукта, способ проверки гипотезы и ожидаемый результат запуска.
Материалы клиента приводим к нашей структуре независимо от наличия готового ТЗ. Фиксируем роли, сценарии, статусы, административные функции, интеграции, ограничения и требования к релизу.
Затем готовим декомпозированную смету: показываем функциональные блоки, состав специалистов, трудозатраты, аналитику, дизайн, разработку, тестирование, управление и подготовку к запуску.
Если исходный состав не помещается в бюджет, сначала упрощаем отдельные функции без потери бизнес-ценности MVP. Сохраняем основной путь пользователя и целевое действие, а второстепенную логику заменяем более простыми сценариями или готовыми сервисами.
Если бюджет всё ещё превышен, переносим за пределы первого релиза целые функции, которые не относятся к ядру продукта. На старте клиент получает границы MVP, которое будет приносить бизнес ценность со старта, а также смету, срок, допущения и список задач для следующих этапов.
Сначала приведите сметы к одной структуре. Запросите состав функций, исключения, используемые готовые решения, внешние платежи, команду, результат этапов и правила оценки изменений.
Если одна компания оценила проект в 1,5 млн рублей, а другая — в 4 млн, не нужно искать среднее значение. Сначала проверьте, одинаковый ли продукт они предлагают построить.
Если у вас есть идея или техническое задание, наша команда Codex IT приведет требования к единой структуре и подготовит декомпозированную оценку MVP с понятными границами, сроком и бюджетом.
