Заказная разработка

Заказная разработка программного обеспечения: когда нужна и как устроена

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

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

Готовое решение или заказная разработка

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

• Процесс нестандартный. Готовый продукт заточен под усреднённый процесс усреднённой компании. Если ваш процесс объективно отличается — не потому что «мы особенные», а потому что бизнес-модель, регуляторика или масштаб другие — под него придётся либо ломать процесс, либо ломать продукт напильником, либо писать своё.
• Нужна глубокая интеграция. Готовые продукты интегрируются друг с другом через то, что разрешил вендор. Если логика должна связывать три-четыре системы нестандартным образом — это уже не настройка, а разработка.
• Продукт — часть бизнеса, а не инструмент. Если то, что вы строите, — это то, чем зарабатываете (маркетплейс, SaaS, мобильное приложение для клиентов), то это не внутренний инструмент, который можно взять готовым, а актив, который создаёт конкурентное преимущество только если сделан под вас.

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

Из чего складывается стоимость

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

1. Число ролей и сценариев. Система с одной ролью пользователя и линейным сценарием стоит принципиально дешевле системы с пятью ролями и матрицей прав доступа.
2. Количество интеграций. Каждая внешняя система, с которой нужно связать разработку — 1С, банк, CRM, платёжный шлюз — это отдельный кусок работы с собственными рисками (у внешнего API может не быть документации, или она может быть неактуальной).
3. Требования к нагрузке и отказоустойчивости. Внутренний инструмент для 20 сотрудников и публичный сервис на 50 000 пользователей в час пик — разные архитектуры, разная цена.
4. Требования регуляторов. Если система работает с персональными данными, платежами или медицинской информацией, к разработке добавляется слой требований (152-ФЗ, PCI DSS и подобные), который стоит времени и денег, но экономить на нём нельзя.
5. Готовность данных и процессов заказчика. Перенос данных из архива тридцати Excel-файлов с разной структурой почти всегда занимает больше времени, чем ожидает заказчик — и об этом стоит говорить на старте, а не в середине проекта.

Именно поэтому мы не называем вилку цен без разбора задачи: два проекта с одинаковым названием «CRM» могут отличаться по стоимости в разы из-за этих пяти переменных.

Как устроен процесс по этапам

Прежде чем что-то писать, важно проверить гипотезу на практике, а не в презентации. Процесс, через который проходит каждый проект:

Разговор — 40 минут

Смотрим процесс и находим, где именно теряются деньги и время. Через день присылаем, что предлагаем сделать, в какой срок и за сколько — конкретную фикс-цену на первый этап, а не диапазон «от».

Кабинет и доступы — 2 дня

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

Пилот — 2 недели

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

Внедрение — 2–3 месяца

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

Переход и развитие

Обучаем команду, дежурим первые недели после запуска. Дальше — по подписке на доработки, отдельными задачами или силами вашей команды: система ваша, зависимости от нас нет.

Как выбрать подрядчика

Разработчика для такой задачи стоит выбирать по конкретным признакам, а не по общему впечатлению от презентации:

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