В статье
Разработчика стоит выбирать по способности объяснить решение вашей задачи и показать проверяемый результат. Принимать работу нужно по заранее согласованным сценариям, а не только по демонстрации интерфейса. Код, доступы, запуск, проверки и инструкции должны составлять управляемый компанией продукт.
Невозможно заранее гарантировать качество по одному собеседованию или красивому портфолио. Но можно уменьшить неопределённость: проверить подход к требованиям, начать с ограниченного этапа и определить критерии готовности до основной разработки. Я предлагаю оценивать именно это, а не уверенность человека в разговоре о технологиях.
Как проверить компетенции без экзамена по программированию
Дайте кандидату описание одного рабочего сценария и попросите задать уточняющие вопросы. Сильное предложение должно учитывать пользователей, данные, исключения и ограничения. Если обсуждаются только язык программирования и дизайн, бизнес-задача пока не разобрана.
Попросите объяснить два возможных подхода и причины выбора. Какие готовые средства проверены? Где нужна собственная логика? Что произойдёт при недоступности внешней системы? Честное «нужен тест подключения» полезнее, чем безусловное обещание связать любые программы.
По портфолио уточняйте роль исполнителя и часть работы, которую он может обсуждать без нарушения чужих обязательств. Нельзя требовать раскрытия клиентских секретов. Для подтверждения навыков подойдут разрешённая демонстрация, открытый проект или небольшой оплачиваемый этап с понятным результатом.
Что должно быть в техническом предложении
Ищите описание сценариев, этапов, границ, рисков и способа проверки. Технические названия имеют смысл, если объясняют решение: почему нужен отдельный сервер, каким данным требуется защита, где будут храниться документы.
Проверку цены и состава работ лучше проводить отдельно по вопросам к смете разработчика. Низкая или высокая стоимость не подтверждает компетенции. Сейчас важно понять, способен ли исполнитель связать обещание с конкретным результатом и ответственностью.
Согласуйте порядок изменений: кто принимает пожелания, как оценивается влияние на срок и бюджет и где фиксируется решение. Без этого даже добросовестные стороны могут считать, что договаривались о разном.
Управление репозиторием и доступами
Репозиторий — хранилище кода и истории изменений. Компания должна иметь согласованный доступ и возможность продолжить работу при смене исполнителя. Но доступ к коду и юридические права на него — разные вопросы; условия использования и передачи закрепляются договором.
Не связывайте управление продуктом с личной почтой подрядчика. Для рабочих сервисов нужны понятный владелец со стороны компании, персональные приглашения и процедура восстановления. Права выдаются по роли, а не одной общей учётной записью на всех.
В рекомендациях GitHub для организаций отдельно выделены несколько владельцев и управление командами. Это пример устройства контроля на одной платформе, а не обязательный выбор GitHub для любого проекта.
Определите готовность до начала этапа
Для каждого сценария запишите начальные условия, действие пользователя и ожидаемый результат. Добавьте неверные данные, недостаточные права и сбой зависимости. Фраза «форма работает» должна означать не только наличие полей, но и корректное сохранение, ошибку при недопустимом вводе и отсутствие лишнего доступа.
Заранее разделите критические дефекты и допустимые замечания. Ошибка, позволяющая видеть чужие документы, не равна пожеланию переставить кнопку. Но критерии нельзя придумывать только в момент конфликта: они должны быть частью согласованной приёмки.
Зафиксируйте рабочее окружение и версию результата. Иначе на демонстрации может работать один вариант, а на переданном сервере — другой. Для решения о готовности нужно понимать, что именно проверено и как повторить проверку.
Условный пример этапной приёмки
Представим внутренний кабинет для согласования заявок. На первом этапе исполнитель показывает прототип: кто видит заявку, кто утверждает и что происходит при отказе. Здесь принимается логика, а не готовность продукта к эксплуатации.
Следующий этап — один сквозной сценарий на тестовых данных. Сотрудник создаёт заявку, руководитель получает её, принимает решение, а автор видит статус. Дополнительно проверяются повторное нажатие, пустое поле и попытка другого пользователя открыть запись.
После этого можно добавлять остальные функции и готовить эксплуатацию. Если сквозной сценарий не работает, новые экраны не компенсируют отсутствие результата. Пример условный: состав этапов зависит от задачи, но каждый должен давать проверяемое продвижение.
Какие проверки и документы запросить
Автоматические тесты полезны для повторяемых правил, интеграционных границ и исправленных ошибок. Однако число тестов само по себе ничего не говорит о покрытии важных сценариев. Попросите показать, какие бизнес-риски проверяются и где остаётся ручная приёмка.
Для безопасности можно согласовать применимые требования из OWASP ASVS. Это открытая система проверяемых требований к веб-приложениям. Не нужно механически требовать всё для любого проекта; важнее выбрать подходящий набор, версию и доказательства выполнения.
Минимальная документация должна позволять понять назначение системы, её зависимости, запуск, обновление и восстановление. Секретные значения не включают в инструкцию или архив кода. В документе фиксируют, кто управляет доступом и где уполномоченный специалист получает необходимые параметры безопасным способом.
Что должно быть передано вместе с продуктом
- Код и история в согласованном хранилище.
- Перечень зависимостей, лицензий и внешних сервисов.
- Инструкция запуска и обновления в рабочем окружении.
- Описание доступа, резервного копирования и восстановления.
- Результаты согласованных проверок и перечень известных ограничений.
- Контакты ответственных и порядок поддержки после передачи.
Если продукт основан на готовом сервисе, состав передачи будет другим: важны настройки, данные, учётные записи и условия экспорта. Требовать исходный код чужой платформы, который поставщик не передаёт по договору, бессмысленно.
Когда независимая приёмка особенно полезна
Она нужна, если риски существенны, у компании нет своего технического специалиста или предложение и фактический результат расходятся. Проверяющий должен опираться на требования и воспроизводимые факты, а не на вкусовые предпочтения к технологиям.
Для простого, хорошо знакомого процесса может быть достаточно внутренней проверки ответственным сотрудником. Полный аудит каждой небольшой доработки создаст лишние расходы. И наоборот, видимая работа интерфейса не заменяет проверку доступа и восстановления критичного приложения.
Общий ход проекта можно сверить с этапами разработки CRM, если речь о системе учёта. После запуска назначьте владельца продукта, порядок исправления ошибок и согласования развития. Приёмка завершает этап, но не отменяет дальнейших эксплуатационных обязанностей.
Выбирайте исполнителя, с которым можно договориться о проверяемом результате и передать управление продуктом компании. Если требуется второе мнение о предложении или готовности продукта: Получить независимую оценку. Сначала определим предмет и границы проверки.