Как оценить программиста 1С: практическое руководство

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

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

Какие компетенции проверять у программиста 1С

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

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

Третий блок — инфраструктура и смежные навыки: клиент-серверный режим, SQL на уровне чтения планов запросов, обмены через планы обмена, HTTP-сервисы, форматы XML и JSON. Для позиций уровня middle и выше это обязательный минимум.

Как провести техническое собеседование

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

Полезные вопросы, которые показывают глубину понимания:

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

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

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

Тестовое задание — самый надёжный способ оценки. Оптимальный объём — 2–4 часа работы: меньше не покажет ничего, больше отпугнёт сильных кандидатов, которые не готовы бесплатно тратить выходные.

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

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

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

Как оценить уже работающего сотрудника или подрядчика

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

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

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

Как проверить результат работы программиста

Доработки типовой конфигурации

Норма

Выполнены через расширения или с минимальным вмешательством, обновления проходят

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

Прямая правка типовых модулей, обновление превращается в ручную работу на дни

Отчёты и запросы

Норма

Отчёт на больших данных работает приемлемое время, запросы оптимальны

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

Запросы в циклах, отбор на клиенте, отчёт «думает» минутами

Передача работ

Норма

Есть описание доработок, код доступен и читаем

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

Доработки нигде не задокументированы, разобраться может только автор

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

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

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

Градация уровней: junior, middle, senior

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

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

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

Маршрут решения

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

Нанимаете junior на простые задачиДостаточно собеседования по базовым темам и короткого тестового на 1–2 часа

Ищете middle/senior на развитие системыПолноценное техническое собеседование плюс тестовое задание с разбором решения

Оцениваете текущего подрядчикаАудит кода и доработок, проверка документации и возможности обновления

Нет своего технического специалиста для проверкиПривлеките независимого эксперта для разового ревью кода и собеседования

Ограничения и риски при оценке

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

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

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

Достаточно ли сертификата «1С:Специалист» для найма?

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

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

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

Какой объём тестового задания считается разумным?

Обычно 2–4 часа работы. Задание на целый день и больше отпугивает сильных кандидатов и воспринимается как попытка получить бесплатную работу. Если задача реально крупная — разбейте её или оплатите выполнение.

На что смотреть в коде тестового задания в первую очередь?

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

Как проверить знание конкретной типовой конфигурации?

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

Что делать, если подрядчик не передаёт исходный код доработок?

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