Доработка 1С: кто занимается и как выбрать исполнителя

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

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

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

Кто физически выполняет доработку 1С

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

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

Штатный программист 1С: когда это оправдано

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

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

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

Франчайзи 1С и интеграторы

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

Интеграторы берутся за крупные проекты: внедрение с нуля, переход между конфигурациями, сложные интеграции с несколькими системами, отраслевые решения. У них есть методология проектов, выделенная команда и формальные этапы приёмки. Минус — стоимость и порог входа: мелкие задачи вроде «поправить печатную форму» интегратору неинтересны или будут оценены с большим коэффициентом.

Сравнение исполнителей

Штатный разработчик

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

Франчайзи 1С

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

Фрилансер

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

Интегратор

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

Фрилансеры: когда можно и когда рискованно

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

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

Как оформить задачу, чтобы её сделали правильно

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

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

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

Как принять и проверить результат

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

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

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

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

Основной сценарий на копии базы

Норма

Результат совпадает с примером из постановки

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

Поведение отличается или требует ручных действий, не оговорённых в задаче

Работа под правами пользователя

Норма

Доработка доступна и работает без прав администратора

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

Ошибки доступа или пустые данные у обычных пользователей

Способ реализации

Норма

Расширение или внешняя обработка, поддержка типовой конфигурации не нарушена

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

Прямые изменения типовых объектов без обоснования

Передача материалов

Норма

Получены исходники, описание, инструкция по установке

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

Есть только результат в базе, исходники исполнитель не передаёт

Типичные ошибки заказчика

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

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

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

Задача разовая и небольшая, бюджет ограниченФрилансер с отзывами, поэтапная оплата, обязательная передача исходников

Задачи возникают регулярно, нужна предсказуемость и договорФранчайзи 1С на абонентском обслуживании или почасовой оплате

Поток задач ежедневный, требуется реакция в течение часовШтатный разработчик или выделенный специалист франчайзи

Внедрение с нуля, переход между конфигурациями, сложные интеграцииИнтегратор с проектной методологией и командой

Задача решается настройкой без изменения кодаКонсультант по внедрению — платить за разработку не нужно

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

Можно ли дорабатывать 1С самостоятельно без программиста?

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

Кто должен ставить задачи разработчику со стороны заказчика?

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

Что делать, если прежний исполнитель пропал, а доработки никто не знает?

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

Лучше расширение или изменение конфигурации?

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

Как оценить адекватность оценки трудоёмкости от исполнителя?

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

Нужно ли заключать договор на небольшую доработку?

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