Как проверить программиста 1С: от собеседования до приёмки работы

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

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

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

Определите, какого специалиста вы проверяете

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

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

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

Вопросы для собеседования

Теоретическая часть позволяет быстро отсеять кандидатов с поверхностными знаниями. Вопросы должны требовать объяснения, а не ответа «да/нет».

Базовый уровень

Попросите объяснить разницу между справочником и регистром сведений, между виртуальной таблицей остатков и оборотов, между методами «НайтиПоКоду» и запросом. Спросите, чем отличается обмен данными через планы обмена от правил конвертации, и когда используется «УстановитьПривилегированныйРежим».

Уровень практика

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

Тестовое задание: как составить и оценить

Тестовое задание — самый информативный этап. Оно должно занимать разумное время (обычно 1–3 часа) и проверять навыки, которые реально нужны в работе. Не давайте абстрактные олимпиадные задачи: они не показывают умение работать с конфигурацией.

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

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

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

Проверка качества готового кода

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

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

Для более строгой проверки используйте автоматизированные средства: встроенную проверку конфигурации в конфигураторе (режимы проверки орфографии, логической целостности, поиска некорректных ссылок) и инструменты статического анализа, если они применяются в компании. Ошибки, которые находит штатная проверка конфигурации, — объективный повод вернуть работу на доработку.

Приёмка выполненных доработок

Каждая доработка должна приниматься по заранее согласованному техническому заданию. Без письменного ТЗ проверка превращается в спор «я так понял» — и доказать что-либо сложно обеим сторонам.

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

Контрольные точки

Как проверить результат доработки

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

Норма

Документы проводятся без ошибок, движения соответствуют ожиданиям

Тревожный признак

Ошибки проведения, лишние или отсутствующие записи в регистрах

Скорость работы

Норма

Время выполнения операций не выросло заметно

Тревожный признак

Отчёты и проведение стали ощутимо медленнее

Обновление конфигурации

Норма

Доработки в расширении или аккуратно выделены, обновление проходит штатно

Тревожный признак

Типовые модули переписаны, обновление требует ручного слияния

Поведение при ошибочных данных

Норма

Понятные сообщения пользователю, отсутствие падений

Тревожный признак

Критические ошибки платформы, аварийное завершение

Признаки слабого и сильного специалиста

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

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

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

Частые ошибки заказчика при проверке

Первая ошибка — отсутствие критериев. Если заказчик не может сформулировать, что считать хорошим результатом, любая проверка субъективна. Зафиксируйте критерии до начала работ: функциональность, производительность, обновляемость, документация.

Вторая ошибка — проверка только «по факту оплаты». Регулярный контроль коротких итераций надёжнее разовой приёмки большого объёма: проблемы выявляются раньше и стоят дешевле.

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

Частые вопросы

Можно ли проверить программиста 1С, не будучи техническим специалистом?

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

Какое тестовое задание лучше всего показывает уровень?

Наиболее информативно задание, близкое к реальным задачам компании: например, внешний отчёт на СКД с отборами или доработка через расширение. Дополните его фрагментом кода с заложенной ошибкой и попросите её найти — это проверяет навык чтения чужого кода, который нужен в работе чаще, чем написание с нуля.

Обязательно ли требовать сертификаты 1С?

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

Как проверить, не «заложил» ли программист проблемы перед увольнением?

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

Что делать, если доработка сломала рабочую базу?

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