Руководство по выбору подрядчика для отрасли «Стартапы и продукты»

Для кого: Руководителям, которые выбирают команду разработки или интегратора и хотят снизить риски. · Формат: PDF, 18 страниц, опросник для встреч и чек-лист договора

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

Третий — готовность обсуждать ограничения. Подрядчик, который на первой встрече называет риски и допущения, обычно надёжнее того, кто обещает всё сразу.

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

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

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

Если оценка делается «от и до», уточните, что именно считается завершением проекта: работающий функционал, принятый вами, или количество затраченных часов. Разница между этими формулировками обычно становится видна в середине проекта.

Материал адаптирован под отрасль «Стартапы и продукты»: ниже — задачи, которые мы учитываем и на которые опираемся при разборе.

• Разработка тянется месяцами — Команда пытается сделать сразу финальный продукт: чем больше функций в первой версии, тем позже старт и тем дольше обратная связь от рынка.
• Нет данных о поведении пользователей — Решение о следующей функции принимается на ощущениях: воронка не измеряется, причины отвала и точки выхода пользователей неизвестны.
• Монетизация сделана в последний момент — Тарифы, подписки и платежи прикручиваются поверх готового продукта, из-за чего приходится переделывать личный кабинет и доступы.
• Первая нагрузка ломает продукт — Публикация в СМИ или маркетинговая акция приводят к отказам: запросы падают по таймауту, интеграции не выдерживают очередь.
• Знания живут в одном человеке — Продукт держится на подрядчике или одном разработчике: нет документации, тестов и понятной схемы данных, менять что-то рискованно.