Как выбрать разработчика: вопросы до аванса

Проверьте, как исполнитель понимает бизнес

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

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

Смотрите в портфолио нужное действие

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

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

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

Смета должна позволять сравнение. Запишите страницы и шаблоны, сценарии, содержание, мобильную версию, внешние системы и проверку. Отдельно уточните, кто готовит тексты, фотографии и документы. Два предложения с одинаковым словом «сайт» могут описывать совершенно разные результаты. Самая низкая сумма не будет экономией, если важный сценарий остался за её пределами и появится отдельной доплатой.

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

Уточните проверку и передачу результата

Спросите, как принимается форма: достаточно ли сообщения на экране или проверяется появление обращения в системе. Как тестируется телефон? Что происходит при ошибке? Кто проверяет тексты и доступность страниц? Руководство W3C по формам даёт практические ориентиры для подписей и сообщений, но подрядчик должен перевести их в конкретную проверку вашего продукта. Название технологии не заменяет эту работу.

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

Согласуйте участие команды и поддержку

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

После запуска различайте исправление ошибки согласованного результата и новую функцию. Уточните, что входит в поддержку, когда исполнитель отвечает и как оценивает доработки. Не считайте словосочетание «поддержка после запуска» достаточным условием. Нужен понятный перечень работ и границ. Для обновляемой CMS отдельно обсудите обновления и восстановление: документация WordPress по защите показывает, почему сопровождение нельзя сводить только к редактированию текста.

Принимайте решение по наблюдаемым признакам

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

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

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

Что проверить в своей задаче

1. Подрядчик объяснил основной сценарий и открытые вопросы.
2. В портфолио показана релевантная работа с ясной ролью.
3. Сметы сравниваются по одинаковому составу и исключениям.
4. Приёмка включает реальную доставку данных и ошибки.
5. Доступы, передача и условия поддержки согласованы заранее.