Как выбрать подрядчика по разработке ПО

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

Рынок IT-аутсорсинга огромен. На hh.ru, Habr Career и профильных площадках вроде Clutch или Upwork можно найти тысячи команд — от фрилансеров-одиночек до студий с сотнями разработчиков. Каждый обещает «качество, сроки и гибкость». Как не потеряться?

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

Чтобы принять взвешенное решение, нужна система критериев — и понимание, какие из них действительно важны, а какие — лишь маркетинговый шум.

С чего начать: требования до поиска

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

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

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

Как читать портфолио правильно

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

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

Ещё лучше — попросить контакты двух-трёх заказчиков из портфолио и поговорить с ними напрямую. Спросите: уложились ли в бюджет? Были ли срывы сроков? Как команда реагировала на правки? Порекомендуете ли снова? Эти четыре вопроса дадут больше информации, чем любая презентация.

Выбор формата во многом определяет и модель оплаты. Студии чаще работают по Fixed Price (фиксированный бюджет и объём) или Time & Material (оплата по факту затраченного времени). Небольшие команды и фрилансеры гибче в этом вопросе.

Fixed Price удобен, когда требования чётко зафиксированы и вряд ли изменятся. Time & Material — когда продукт развивается итеративно и требования будут уточняться в процессе. Гибридная модель (фиксированный первый этап + T&M на последующие) часто оказывается оптимальной для стартапов и новых продуктов.

Техническое интервью: что спросить, если вы не разработчик

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

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

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

Договор: что нельзя упускать

Договор с IT-подрядчиком — не формальность. Именно он защищает вас в спорных ситуациях, а они возникают даже в хороших проектах.

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

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

Отдельно зафиксируйте порядок внесения изменений в объём работ. «Небольшие правки» — самая частая причина разногласий. Хорошая практика — любые изменения объёма оформляются дополнительным соглашением с указанием стоимости и влияния на сроки.

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

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