Как проверить компетенции разработчика 1С-Битрикс?

При оценке разработчика проверьте:

• умеет ли он разбирать задачу до начала работы, а не сразу называть стоимость и срок;

• понимает ли основные пользовательские сценарии;

• способен ли объяснить решение простым языком;

• учитывает ли существующий код, интеграции и ограничения проекта;

• предлагает ли проверку результата, а не только внесение изменений;

• фиксирует ли сделанные доработки так, чтобы проект не зависел от одного человека.

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

Частая ситуация: задача звучит просто — «добавить поле в заказ». Но это поле может участвовать в обмене с 1С, отображаться в личном кабинете, передаваться в CRM и влиять на документы. Опытный специалист сначала проследит весь путь данных, а затем оценит доработку.

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

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

Перед началом работ команда обычно задаёт вопросы:

• Какую задачу компании должна решить доработка?

• Какие действия пользователя изменятся после её выпуска?

• Откуда поступают данные и куда они передаются дальше?

• Какие связанные разделы и сценарии нужно проверить?

• Что может пойти не так, если изменить функцию без дополнительной проработки?

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

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

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

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

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

Как проверить опыт работы с интеграциями

Компетенция в 1С-Битрикс особенно заметна там, где сайт связан с другими системами. Интеграция считается работающей не тогда, когда запрос ушёл, а когда бизнес получил нужный результат: цены обновились, заказ передан, статус изменён, дубль не появился.

Попросите разработчика объяснить, как он будет проверять:

• полноту товаров, цен и остатков после обмена;

• передачу заказа и оплаты в учётную систему;

• обновление статусов для покупателя;

• обработку ошибки внешнего сервиса;

• безопасный повтор операции после сбоя;

• соответствие данных на сайте и в системе-источнике.

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

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

Тестовая задача должна проверять подход, а не скорость написания кода

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

Подходящая задача может выглядеть так:

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

В ответе важно увидеть последовательность:

1. Специалист уточняет масштаб проблемы и время её появления.

2. Проверяет, какие данные пришли на сайт и где они могли измениться.

3. Сопоставляет данные сайта с системой-источником.

4. Определяет, какие страницы и сценарии затронуты.

5. Предлагает исправление и способ проверить результат.

6. Фиксирует причину, чтобы похожая ошибка не повторилась.

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

Что проверить в подходе к коду и изменениям

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

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

Хорошая доработка не только решает текущую задачу. Она сохраняет понятность проекта для следующих изменений.

Сертификат и портфолио полезны, но не заменяют проверку

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

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

• Какая задача была сложной в похожем проекте?

• Что нужно было проверить до внесения изменений?

• Какие варианты решения рассматривались?

• Как команда убедилась, что функция работает корректно?

• Как проект развивался после запуска?

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

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

Один разработчик и команда разработки решают разные задачи

Один сильный разработчик может эффективно вести понятный и ограниченный по объёму проект. Но если сайт регулярно развивается, связан с несколькими системами или важен для продаж, компетенции одного человека не всегда покрывают весь объём задач. Подробнее – в статье Нужен ли штатный разработчик 1С-Битрикс?

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

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

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

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

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

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