Выбор веб-разработчика часто начинается с просмотра портфолио и сравнения цен. Это полезно, но недостаточно.

Красивые работы не показывают, насколько подрядчик умеет разбираться в бизнес-задаче, управлять сроками, принимать технические решения, тестировать результат и поддерживать продукт после запуска.

Самая дорогая ошибка — выбрать исполнителя, который быстро обещает нужный результат, но не способен объяснить:

• что именно будет разработано;
• какие задачи решит первая версия;
• что не входит в стоимость;
• как будет проверяться качество;
• кому будут принадлежать код и инфраструктура;
• что произойдёт после запуска.

Правильный выбор начинается не с вопроса:

«Сколько стоит разработка?»

А с вопроса:

«Как подрядчик снижает риск того, что мы потратим деньги и получим неподходящий продукт?»

Сначала определите, кто вам нужен

Под словом «разработчик» могут скрываться совершенно разные форматы работы.

Фрилансер

Фрилансер подходит, если:

• задача относительно небольшая;
• требования уже понятны;
• не требуется большая команда;
• проектом может управлять сам заказчик;
• риск остановки работы одного специалиста приемлем.

Сильный фрилансер может быстро и качественно реализовать конкретную задачу. Но аналитика, дизайн, backend, тестирование, DevOps и управление проектом могут потребовать дополнительных специалистов.

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

Агентство

Агентство подходит, если проект требует нескольких компетенций:

• аналитики;
• UX- и UI-дизайна;
• frontend- и backend-разработки;
• тестирования;
• управления;
• запуска и поддержки.

Преимущество — ответственность распределена между командой.

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

Product studio

Product studio отличается тем, что рассматривает проект не только как набор экранов и функций, но и как продуктовую задачу.

Такой формат полезен, если необходимо:

• определить состав первой версии;
• проверить гипотезу;
• сократить лишний функционал;
• спроектировать пользовательский сценарий;
• связать технические решения с бизнес-результатом.

Но название «product studio» само по себе ничего не гарантирует. Проверять нужно реальный процесс и команду.

Внутренний разработчик или команда

Собственная команда оправдана, когда цифровой продукт является постоянной частью бизнеса и требует регулярного развития.

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

Начните не с портфолио, а с задачи

До общения с подрядчиками подготовьте короткое описание проекта.

Не нужно писать техническое задание на сто страниц. Достаточно зафиксировать:

• какую проблему должен решить продукт;
• кто будет им пользоваться;
• как выглядит основной сценарий;
• какие функции обязательны для запуска;
• какие системы нужно подключить;
• есть ли существующий сайт, дизайн или данные;
• когда нужен результат;
• какой бюджетный диапазон реалистичен.

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

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

Какие вопросы должен задавать хороший подрядчик

Сильный исполнитель не начинает разговор с технологии или точной цены.

Он уточняет:

• какую бизнес-задачу решает проект;
• почему текущий процесс не устраивает;
• кто является основным пользователем;
• какое действие должен совершить пользователь;
• что критично для первой версии;
• какие функции можно отложить;
• откуда будут поступать данные;
• какие интеграции необходимы;
• кто принимает решения со стороны клиента;
• как будет оцениваться успешность запуска.

Если подрядчик почти ничего не спрашивает, он либо оценивает типовой шаблон, либо перекладывает неопределённость на будущие доработки.

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

Портфолио показывает визуальный уровень, но не весь процесс.

По каждому релевантному проекту стоит спросить:

• какую проблему решал продукт;
• что именно делал подрядчик;
• какие ограничения были у проекта;
• какие решения пришлось изменить;
• сколько длилась работа;
• что произошло после запуска;
• поддерживает ли команда продукт сейчас.

Важно отличать:

• проект, полностью разработанный командой;
• отдельный дизайн;
• только frontend;
• доработку существующего продукта;
• концепт, который никогда не запускался.

Красивый концепт и работающая система с реальными пользователями — разные доказательства компетенции.

Ищите релевантный опыт, а не точную копию проекта

Подрядчик не обязан раньше создавать абсолютно такой же продукт.

Более важны совпадающие типы сложности:

• личные кабинеты;
• роли и права доступа;
• платежи;
• marketplace;
• CRM;
• сложные формы;
• интеграции;
• real-time функции;
• большой каталог;
• многоязычность;
• миграция данных.

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

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

Как должно выглядеть качественное предложение

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

В нём желательно увидеть:

• понимание задачи;
• рекомендуемый формат решения;
• состав первой версии;
• основные пользовательские сценарии;
• этапы работы;
• ожидаемые результаты каждого этапа;
• ориентировочные сроки;
• стоимость или принцип расчёта;
• допущения;
• исключения;
• обязанности заказчика;
• порядок работы с изменениями;
• условия запуска и поддержки.

Фраза «разработка сайта под ключ» ничего не объясняет.

Нужно понимать, входит ли в неё:

• аналитика;
• прототип;
• дизайн;
• мобильная версия;
• backend;
• административная панель;
• интеграции;
• перенос данных;
• подготовка контента;
• аналитика;
• SEO-настройки;
• тестирование;
• deployment;
• гарантия;
• поддержка.

Почему самая низкая цена опасна

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

Например, из сметы могут быть исключены:

• проектирование состояний;
• мобильная версия;
• тестирование;
• интеграции;
• инфраструктура;
• управление проектом;
• исправления после запуска;
• документация.

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

Поэтому сравнивать нужно не итоговую цену, а одинаковый объём результата.

Полезный вопрос:

«Что конкретно не входит в эту сумму и при каких условиях стоимость изменится?»

Как выбрать модель оплаты

Фиксированная стоимость

Подходит, когда:

• требования достаточно стабильны;
• результат можно описать;
• границы проекта зафиксированы;
• изменения будут редкими.

Преимущество — понятный бюджет.

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

Time and materials

Заказчик оплачивает фактически потраченное время команды.

Подходит, когда:

• продукт развивается итеративно;
• часть решений будет приниматься после исследования;
• требования могут меняться;
• невозможно заранее точно определить весь объём.

Преимущество — гибкость.

Риск — отсутствие контроля над приоритетами может привести к росту бюджета без завершённого результата.

При такой модели нужны:

• понятный backlog;
• регулярное планирование;
• прозрачная отчётность;
• лимит бюджета;
• измеримый результат каждого этапа.

Поэтапная фиксированная стоимость

Для многих проектов это наиболее практичный вариант.

Например:

1. исследование и прототип;
2. дизайн ключевых сценариев;
3. разработка первой версии;
4. интеграции;
5. запуск;
6. поддержка и развитие.

После каждого этапа объём следующего уточняется на основе новых данных.

Так заказчик не фиксирует весь проект слишком рано и одновременно сохраняет контроль над бюджетом.

Почему опасна полная предоплата

Предоплата сама по себе нормальна: подрядчику нужно резервировать команду и начинать работу.

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

Более безопасная схема:

• аванс за этап;
• оплата после принятия результата;
• следующий платёж перед следующим этапом.

Для длительного проекта платежи можно привязать к месяцам или контрольным точкам.

Сумма платежа должна соответствовать уже выполненной работе и ближайшим обязательствам, а не только обещанию завершить весь проект.

Что зафиксировать в договоре

Договор должен описывать не только цену и срок.

Предмет и объём работ

Необходимо определить:

• что будет создано;
• какие функции входят;
• какие платформы и устройства поддерживаются;
• какие интеграции включены;
• какие материалы предоставляет заказчик;
• что считается завершённым результатом.

Порядок принятия

Нужно заранее согласовать:

• как демонстрируется результат;
• сколько времени есть на проверку;
• как фиксируются замечания;
• что считается ошибкой;
• что считается новой функцией;
• сколько циклов правок предусмотрено.

Порядок изменений

Проекты почти всегда меняются.

Договор должен объяснять:

• как оформляется новая задача;
• кто оценивает её влияние;
• как изменяются срок и стоимость;
• нужно ли отдельное согласование;
• может ли подрядчик начинать дополнительную работу без письменного подтверждения.

Права на результат

Заказчик должен понимать, кому принадлежат:

• исходный код;
• дизайн;
• тексты;
• иллюстрации;
• домен;
• данные;
• документация;
• разработанные компоненты.

Также необходимо определить, какие сторонние библиотеки, сервисы и лицензии используются.

Доступы и инфраструктура

Критичные аккаунты желательно оформлять на компанию заказчика:

• домен;
• hosting;
• облачная инфраструктура;
• база данных;
• хранилище файлов;
• аналитика;
• рекламные и почтовые сервисы;
• репозиторий.

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

Конфиденциальность и данные

Если подрядчик получает доступ к клиентским данным, внутренним документам или production-системам, нужно определить:

• какие данные можно использовать;
• кто имеет доступ;
• где они хранятся;
• как передаются;
• когда доступ должен быть закрыт;
• что происходит после завершения договора.

Кто должен владеть кодом и аккаунтами

Опасная схема выглядит так:

• репозиторий находится в личном аккаунте разработчика;
• домен зарегистрирован на подрядчика;
• production развёрнут в неизвестном аккаунте;
• у заказчика нет базы данных и резервных копий;
• ключевые сервисы оплачиваются с чужой карты;
• нет инструкции по запуску.

Даже если отношения хорошие, такая зависимость создаёт бизнес-риск.

Заказчику обычно нужны:

• доступ к репозиторию;
• права на созданный код;
• доступ к production;
• доступ к данным;
• перечень внешних сервисов;
• инструкции по deployment;
• актуальные резервные копии;
• возможность передать проект другой команде.

Подрядчик может использовать собственные внутренние инструменты и универсальные компоненты. Но это не должно лишать клиента контроля над конкретным продуктом.

Как проверить техническую компетентность

Заказчику не обязательно самостоятельно оценивать код.

Можно проверить, способен ли подрядчик объяснить:

• почему выбран определённый технологический подход;
• какие альтернативы рассматривались;
• какие ограничения есть у решения;
• как будет устроена безопасность;
• как выполняется резервное копирование;
• как отслеживаются ошибки;
• как система будет обновляться;
• какие расходы появятся после запуска.

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

Хороший специалист связывает техническое решение с:

• задачей;
• риском;
• стоимостью;
• скоростью запуска;
• дальнейшей поддержкой.

Для критичного проекта полезен независимый технический review архитектуры или предложения до начала основной разработки.

Как должен выглядеть процесс работы

Прозрачный процесс обычно включает:

1. согласование цели этапа;
2. декомпозицию задач;
3. регулярные демонстрации;
4. фиксацию решений;
5. доступ к текущему результату;
6. тестирование;
7. список известных ограничений;
8. подготовку запуска;
9. передачу документации и доступов.

Заказчик не должен впервые увидеть продукт в день финальной сдачи.

Короткие регулярные демонстрации позволяют раньше обнаружить неправильное понимание задачи и дешевле изменить направление.

Какие тревожные сигналы нельзя игнорировать

Стоит насторожиться, если подрядчик:

• называет точную цену после короткого сообщения;
• не задаёт вопросов о бизнесе и пользователях;
• обещает любую функцию без анализа;
• гарантирует идеальный результат или рост продаж;
• предлагает скопировать чужой продукт без исследования;
• скрывает состав команды;
• не даёт доступ к промежуточной версии;
• требует почти полную предоплату;
• не фиксирует, что входит в стоимость;
• избегает обсуждения прав на код;
• хранит все аккаунты у себя;
• не обсуждает тестирование;
• не может объяснить поддержку после запуска;
• постоянно меняет сроки без конкретной причины;
• отвечает только после напоминаний ещё до подписания договора.

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

Нужно ли давать тестовое задание

Большое бесплатное тестовое задание — плохой инструмент.

Сильный исполнитель не обязан бесплатно проектировать часть реального продукта.

Вместо этого можно использовать:

• платную discovery-сессию;
• небольшой оплачиваемый этап;
• аудит существующего продукта;
• технический прототип;
• проектирование одного ключевого сценария.

Так вы проверите:

• качество вопросов;
• глубину анализа;
• коммуникацию;
• соблюдение сроков;
• качество результата;
• способность учитывать ограничения.

Небольшой реальный этап даёт больше информации, чем абстрактное бесплатное тестовое задание.

Как сравнить несколько подрядчиков

Используйте одинаковые критерии:

• понимание задачи;
• релевантный опыт;
• состав команды;
• качество предложения;
• прозрачность сметы;
• реалистичность сроков;
• подход к тестированию;
• права и доступы;
• модель коммуникации;
• поддержка после запуска;
• общая стоимость владения;
• доверие к процессу.

Не выбирайте только по презентации или харизме на встрече.

Полезно отдельно зафиксировать:

• блокирующие риски;
• допустимые компромиссы;
• необязательные преимущества.

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

Контрольный список перед подписанием договора

До начала работы убедитесь, что вы можете ответить на следующие вопросы:

1. Какую бизнес-задачу решает проект?
2. Что входит в первую версию?
3. Что не входит в стоимость?
4. Как выглядят этапы и результаты?
5. Кто работает над проектом?
6. Кто принимает решения с обеих сторон?
7. Как изменяются требования?
8. Как проверяется качество?
9. Как устроены платежи?
10. Кому принадлежат код и дизайн?
11. На чьих аккаунтах размещена инфраструктура?
12. Какие внешние сервисы оплачиваются отдельно?
13. Что входит в запуск?
14. Что происходит после запуска?
15. Как передать проект другой команде?

Если на несколько критичных вопросов нет понятного ответа, начинать разработку рано.

Итог

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

Сильный подрядчик:

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

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

Проверьте подрядчика или проект до начала разработки

Опишите задачу, полученное предложение или текущую ситуацию с разработкой.

Команда Prodexa поможет:

• определить реалистичный состав первой версии;
• проверить смету и этапы;
• выявить скрытые риски;
• оценить технический подход;
• подготовить проект к разработке без лишних расходов.