Выбор подрядчика на разработку программного обеспечения — одно из решений, которое влияет на бизнес на годы вперёд. Удачный старт даёт работающий продукт, прозрачный бюджет и команду, с которой можно масштабировать функциональность. Неудачный — затягивает сроки, раздувает смету и оставляет компанию с кодом, который никто не хочет поддерживать. Рынок переполнен предложениями «сделаем быстро и дёшево», поэтому заказчику важно опираться на проверяемые критерии, а не на красивую презентацию.
Зачем системный подход к выбору подрядчика
Разработка ПО — это не покупка готового товара с фиксированными характеристиками. Это совместная работа по превращению бизнес-задачи в работающую систему при неполной информации на старте. Даже при хорошо прописанном техническом задании по ходу проекта всплывают уточнения: интеграции оказываются сложнее, пользователи ведут себя иначе, чем предполагалось, регуляторика меняется. Подрядчик с выстроенными процессами переживает такие изменения без хаоса; подрядчик без процессов — превращает каждое уточнение в конфликт и дополнительный счёт.
Для малого и среднего бизнеса ошибка в выборе особенно болезненна: нет внутреннего IT-директора, который возьмёт проект под контроль, а бюджет на переделку ограничен. Поэтому имеет смысл потратить две-три недели на оценку кандидатов до подписания договора — это дешевле, чем полгода борьбы с некачественным результатом. По нашей практике, переделка проекта после неудачного старта обходится в 1,5–3 раза дороже, чем если бы изначально был проведён этап discovery с адекватной оценкой.
Критерии оценки: что проверять до подписания договора
1. Релевантное портфолио и референсы
Список логотипов крупных клиентов мало что говорит, если нет описания задачи, масштаба и роли подрядчика. Просите кейсы, близкие к вашему проекту по домену (e-commerce, логистика, B2B-порталы, производство), по технологиям и по размеру команды заказчика. Идеально — возможность поговорить с предыдущим клиентом: как проходила сдача, как решались спорные моменты, осталась ли команда на поддержке, не было ли скрытых долгов в коде.
Обратите внимание на давность проектов. Стек, который был актуален пять лет назад, не гарантирует компетенции в текущих задачах. Смотрите на непрерывность: есть ли у подрядчика свежие релизы в похожих продуктах, публикуют ли они технические разборы, участвуют ли в профильных сообществах. Для интеграций с учётом важен опыт именно с корпоративными системами, а не только с лендингами.
2. Прозрачная оценка и декомпозиция работ
Оценка «под ключ за N миллионов» без разбивки — повод насторожиться. Нормальная смета содержит модули, этапы, допущения и риски. Для MVP и средних проектов удобна вилка: оптимистичный и пессимистичный сценарий с объяснением, от чего зависит итог. Почасовая модель с понятной ставкой (актуальные расценки ITRTS — от 3 500 ₽/час на разработку) даёт гибкость на этапе discovery, когда требования ещё уточняются.
| Модель оплаты | Когда подходит | Риски для заказчика |
|---|---|---|
| Фиксированная цена | Замороженное ТЗ, понятный scope | Жёсткие изменения = допсоглашения; заниженная смета на старте |
| Почасовая (time & material) | Discovery, R&D, эволюционирующий продукт | Нужен контроль объёма и регулярная отчётность |
| Этапами (milestone) | Крупные проекты с вехами | Нечёткие критерии приёмки этапа |
| Абонент / выделенная команда | Долгая разработка и поддержка | Неиспользованные часы, размытая ответственность |
3. Процессы: от требований до приёмки
Узнайте, как фиксируются требования: есть ли бэклог, прототипы, согласование макетов. Как устроено тестирование: кто пишет тесты, есть ли тестовый стенд, кто проводит приёмочное тестирование с вашей стороны. Как передаётся результат: репозиторий, документация по развёртыванию, инструкции для администратора, описание переменных окружения и секретов.
Коммуникация не должна ограничиваться чатом в мессенджере. Тикетная система, протоколы созвонов, еженедельные статусы — минимальная дисциплина, которая защищает обе стороны. Спросите, кто ваш единый контакт (account / project manager) и кто принимает технические решения на стороне подрядчика. При смене менеджера в середине проекта как передаётся контекст — устно или в базе знаний?
4. Договор и права на результат
В договоре должны быть явно прописаны: предмет и этапы, сроки и порядок приёмки, стоимость и порядок оплаты, ответственность сторон, конфиденциальность, права на исходный код и дизайн. Код, оплаченный заказчиком, как правило, принадлежит заказчику — это нужно закрепить, а не оставлять на устных договорённостях. Уточните лицензии на сторонние библиотеки и шрифты.
Обратите внимание на гарантийную поддержку после сдачи: сколько месяцев исправляют дефекты без доплаты, что считается дефектом, а что — новой функциональностью. Уточните условия расторжения и передачи артефактов, если сотрудничество не сложится: доступ к git, хостингу, аккаунтам облака.
Красные флаги: когда лучше отказаться
- Оценка проекта без уточняющих вопросов и без погружения в бизнес-контекст.
- Обещание «в три раза дешевле рынка» при том же объёме и сроках.
- Отказ показать процесс, репозиторий (хотя бы обезличенный) или пример документации.
- Нет тестового стенда: «проверяйте сразу на продакшене».
- Давление подписать договор «сегодня со скидкой» без времени на юридическую проверку.
- Один «универсальный» разработчик на весь стек без дизайна, аналитики и тестирования на средний и крупный проект.
- Нет упоминания о персональных данных, 152-ФЗ и хранении логов — если продукт работает с ПДн клиентов.
Чек-лист для заказчика перед стартом
- Сформулировать бизнес-цель и критерии успеха продукта (не только список функций).
- Подготовить описание текущих систем: 1С, CRM, сайт, платёжные сервисы.
- Собрать 3–5 подрядчиков, запросить короткий бриф и вилку оценки.
- Провести интервью: процессы, команда, референсы.
- Запустить платный этап discovery (20–40 часов): прототип, архитектура, уточнённая смета.
- Согласовать договор, критерии приёмки первого этапа и формат отчётности.
- Назначить ответственного с вашей стороны с полномочиями принимать решения в разумные сроки.
Начните с небольшого платного этапа discovery — прототип, архитектурная схема, уточнённая оценка. Это стоит доли бюджета всего проекта, но показывает, как подрядчик думает, общается и держит сроки. Если на discovery всё идёт плохо, на полном проекте будет хуже.
Как оценить команду на этапе пилота
На пилоте смотрите не только на артефакты, но и на поведение: задают ли уточняющие вопросы, фиксируют ли договорённости письменно, предупреждают ли о рисках заранее. Хорошая команда говорит «это займёт дольше, потому что…», а не молча срывает дедлайн. Проверьте, насколько их предложение по архитектуре соотносится с вашими планами роста: заложен ли запас на интеграции, отчётность, мобильную версию, разделение на микросервисы или монолит с модулями.
Если проект связан с учётом и обменом данными, убедитесь, что у подрядчика есть опыт работы с 1С и корпоративными системами, а не только с витринным фронтендом. Разрыв между «красивым сайтом» и «правильными остатками в учёте» — частая причина провалов в e-commerce и B2B-порталах. Спросите, кто будет сопровождать серверы после запуска — инфраструктура часто остаётся за бортом сметы разработки.
Сравнение типов подрядчиков
| Тип | Сильные стороны | Слабые стороны |
|---|---|---|
| Фрилансер | Низкая ставка, прямая коммуникация | Риск пропажи, узкое горлышко, отпуск без замены |
| Небольшая студия (5–15 чел.) | Гибкость, вовлечённость руководства | Ограниченный bench на пиках |
| Аутсорс-компания (ITRTS и аналоги) | Процессы, несколько компетенций, SLA | Чуть выше ставка, нужен чёткий контакт |
| Крупный интегратор | Масштаб, формальные процедуры | Дорого для SMB, ротация junior-ов |
Технические вопросы на собеседовании с подрядчиком
Не обязательно быть программистом — достаточно задать правильные вопросы и записать ответы. Где будет храниться код (git, ваша организация или их)? Как устроены среды dev / stage / prod? Кто имеет доступ к продакшену? Как деплоят релизы — вручную или через CI/CD? Есть ли автотесты на критичные сценарии? Как обрабатываются персональные данные и бэкапы? Ответы «потом разберёмся» на эти темы — тревожный сигнал.
Запросите пример Definition of Done для задачи: что должно быть сделано, чтобы задачу закрыли. Это показывает зрелость процесса лучше, чем заявления «мы работаем по Agile».
Роль заказчика: без этого подрядчик не спасёт
Даже сильная команда буксует, если со стороны заказчика нет владельца продукта: человека, который приоритизирует бэклог, принимает решения по спорным требованиям и организует доступ к экспертам (бухгалтерия, склад, маркетинг). Задержки согласований на стороне клиента — одна из главных причин срыва сроков; в договоре это часто отражают отдельным пунктом о продлении сроков при задержке обратной связи более N рабочих дней.
Заложите время своих сотрудников на демонстрации, приёмку и обучение. Подрядчик сдаёт систему; внедрение в ежедневные процессы — зона ответственности бизнеса. Если пользователи не прошли обучение, «плохая разработка» часто оказывается непониманием интерфейса.
Юридические и финансовые нюансы
Проверьте, с кем вы подписываете договор: ООО с историей или вчерашнее ИП без референсов. Аванс привязывайте к этапам, а не к «50% на старт всего проекта» без промежуточных результатов. НДС, закрывающие документы, электронный документооборот — заранее, чтобы не тормозить оплаты в конце месяца. Для госконтрактов и крупных B2B-партнёров могут потребоваться отдельные требования к хостингу данных — уточните до оценки.
Формулируйте приёмку сценариями: «Пользователь с ролью X выполняет шаги 1–7 и видит результат Y». Абстрактное «модуль готов» неизбежно приводит к спорам на финале.
После выбора: как не потерять качество в процессе
Выбрали подрядчика — работа не закончилась. Участвуйте в демо раз в спринт или раз в две недели. Сверяйте факт часов с планом. Эскалируйте риски рано, а не в день дедлайна. Меняйте приоритеты осознанно: каждая новая «срочная» функция вытесняет что-то из scope. Документируйте изменения требований письменно — устные «добавьте кнопку» накапливают технический и финансовый долг.
Вопросы для интервью с подрядчиком (шпаргалка)
Сохраните список и отмечайте ответы по каждому кандидату — так проще сравнивать объективно, а не по впечатлению от продажника.
- Сколько человек будет на проекте и какова их загрузка в процентах?
- Как вы поступаете, если понимаете, что оценка была занижена на 30%?
- Покажите пример еженедельного отчёта другому клиенту (обезличенно).
- Где хранятся исходники и кто владелец репозитория?
- Как устроена приёмка: кто с вашей стороны должен подписать акт?
- Есть ли опыт интеграции с нашим стеком (1С, конкретная CRM, платёжка)?
- Что входит в гарантию после сдачи и сколько длится?
- Как передаёте проект при расторжении договора?
Ответы в духе «не волнуйтесь, всё будет хорошо» без конкретики — повод снизить приоритет кандидата. Хороший подрядчик спокойно называет процедуры, риски и границы ответственности.
Ошибки заказчиков при выборе
Гонка за минимальной ценой. Дешёвая оценка часто означает отсутствие тестов, админки или нормальной обработки ошибок — вы доплатите на второй итерации. Выбор по знакомству без проверки процессов — риск испортить отношения с другом и потерять бюджет. Отсутствие внутреннего владельца — подрядчик ждёт решений неделями. Размытое ТЗ в формате «сделайте как у конкурента, только лучше» — гарантия бесконечных переделок.
Ещё одна ловушка — смешивать закупку разработки и закупку инфраструктуры в одну кучу без ответственных. Уточните, кто поднимает сервер, настраивает домен и SSL, кто отвечает за бэкапы после сдачи. Часто это отдельная компетенция, не входящая в смету «разработки сайта». Запросите у каждого финалиста письменное резюме после интервью: scope, допущения, риски, команда.
Если проект затрагивает персональные данные клиентов, спросите про опыт с 152-ФЗ, шифрование, разграничение доступа и журналирование. Если планируется оплата картами — PCI DSS на стороне платёжного провайдера не снимает с вас требований к своему приложению: не хранить CVV, использовать токены, HTTPS везде. Подрядчик, который отмахивается от compliance «это не наша зона», оставит вам юридические риски после сдачи.
Для долгосрочного партнёрства оцените стабильность компании: как давно на рынке, есть ли кейсы сопровождения 3+ лет, текучка в команде. Стартап-студия с агрессивными ценами может исчезнуть посреди проекта — тогда вы ищете нового подрядчика на полуготовом коде с документацией неизвестного качества. Сравнение таблицей «критерий / кандидат A / B / C» снижает влияние эмоций и красивых презентаций при финальном выборе.
Матрица зрелости подрядчика
Оцените кандидатов по пятибалльной шкале по каждому критерию ниже. Сумма ниже 15 из 25 — повод задуматься, даже если цена привлекательна.
| Критерий | 1 — слабо | 5 — сильно |
|---|---|---|
| Портфолио в вашем домене | Нет похожих кейсов | 3+ релевантных проекта за 2 года |
| Прозрачность оценки | Одна цифра | Модули, риски, вилка |
| Процессы | Только чат | Тикеты, демо, DoD |
| Договор и IP | Устные обещания | Права на код, гарантия, расторжение |
| Команда | Один generalist | Роли закрыты, есть замена |
Матрица не заменяет пилот, но отсекает явных аутсайдеров до траты времени на глубокое погружение. Обсуждайте результаты с финансовым директором и владельцем продукта — техническое «нравится» и бизнес «по бюджету» должны сойтись.
На этапе переговоров полезно попросить roadmap первых 6–8 недель: что будет сделано, какие артефакты вы получите, какие решения требуют вашего участия. Roadmap без дат и без имени ответственного с вашей стороны — декорация. Хороший подрядчик сразу обозначает зависимости: «без доступа к тестовой 1С не начнём интеграцию».
Наконец, доверяйте, но проверяйте: первый этап с чёткой приёмкой и умеренным авансом. Успешный discovery — лучшая рекомендация продолжать; хаотичный старт при красивом КП — сигнал остановиться, пока не сожгли весь бюджет.
Дополнительный критерий для зрелых заказчиков — зрелость инженерных практик: code review, статический анализ, ветвление в git (gitflow или trunk-based), семантические версии релизов. Это снижает стоимость сопровождения после сдачи MVP и упрощает смену подрядчика без «чёрного ящика» в репозитории.
Зафиксируйте в протоколе переговоров дату, участников и договорённости по scope — память искажает детали через неделю. Это бесплатно и снижает споры при старте работ.
Итог: прагматичный выбор без иллюзий
Идеального подрядчика «на все случаи жизни» не существует. Есть подходящий под вашу задачу, бюджет и стиль работы. Системная проверка портфолио, процессов, договора и пилотного этапа снижает риск существенно сильнее, чем выбор по цене одного коммерческого предложения. Если нужна разработка с прозрачной оценкой и опытом интеграций — посмотрите направление разработка ПО на аутсорсе ITRTS и прайс-лист; начать можно с короткой консультации и оценки discovery без обязательств по полному проекту.