Обучение и Решения · 12 мин
Почему не любят программистов 1С и что с этим делать
Разбираем, почему программистов 1С часто критикуют: реальные причины конфликтов, типичные ошибки обеих сторон и способы наладить работу с разработчиком.
Фраза «не любят программистов 1С» звучит на форумах, в бухгалтериях и на совещаниях руководителей регулярно. За ней почти всегда стоит не личная неприязнь, а накопленный опыт: сорванные сроки сдачи отчётности, доработки, которые сломались после обновления, счета за «два часа работы», выросшие в недели. При этом бизнес без 1С-разработчиков обходиться не может — конфигурации требуют настройки, обменов, печатных форм и отчётов под конкретные процессы компании.
Конфликт между заказчиком и разработчиком 1С имеет объективные причины: разные языки описания задачи, разное понимание результата и разная ответственность за последствия. Бухгалтер отвечает за сданную декларацию, а программист — за код, который «у него работал». Пока стороны не договорятся о правилах игры, раздражение будет копиться с обеих сторон.
Разберём конкретные причины негатива, отделим объективные проблемы от стереотипов и покажем, как выстроить работу с 1С-разработчиком так, чтобы не приходилось его «не любить».
Откуда вообще взялся негатив к 1С-разработчикам
1С занимает особое место в российском бизнесе: это не просто программа, а система, через которую идут деньги, налоги, зарплата и склад. Любой сбой здесь — это не «глюк приложения», а несданный отчёт, заблокированная отгрузка или штраф. Поэтому требования к разработчику 1С изначально завышены, а цена ошибки — высока.
Вторая причина — закрытость профессии. Пользователь видит только результат: кнопка появилась или нет, отчёт считается или нет. Он не видит, что за «простой кнопкой» стоит изменение трёх документов, регистра накопления и обработки проведения. Отсюда вечный спор: «почему так долго и так дорого» против «вы не понимаете, что просите».
Третья причина — рынок. Порог входа в 1С-разработку исторически ниже, чем в промышленное программирование, поэтому на рынке много специалистов с разным уровнем: от сильных архитекторов до людей, умеющих только править печатные формы. Негативный опыт работы со слабым исполнителем заказчик распространяет на всю профессию.
Была ли зафиксирована оценка письменно и включала ли она тестирование
Было ли ТЗ или работа велась «по звонку»
Использовались ли расширения вместо правки типовой конфигурации
Есть ли согласованный канал связи и регламент ответа
Объективные причины конфликтов
Размытая постановка задачи
Самая частая ситуация: «сделайте, чтобы в заказе было удобно». Разработчик делает, как понял, заказчик смотрит и говорит: «это не то». Начинается цепочка переделок, каждая из которых стоит времени и денег. Заказчик считает, что платит за одну задачу, разработчик — что выполняет новые требования.
Ответственность здесь обоюдная. Заказчик обязан описать сценарий: кто, в каком документе, какие данные вводит, что должно получиться на выходе. Разработчик обязан задать уточняющие вопросы до начала работы, а не после. Если исполнитель не задаёт вопросов по расплывчатой задаче — это тревожный признак, а не признак опыта.
Доработки, которые ломаются при обновлении
Классическая боль: программист внёс изменения прямо в типовую конфигурацию, снял объекты с поддержки, и теперь каждое обновление превращается в отдельный платный проект. Бухгалтерия не может обновиться до свежих форм отчётности, а разработчик объясняет: «так было быстрее».
Современный подход — выносить доработки в расширения конфигурации, которые не затрагивают типовой код и переживают обновления. Если исполнитель принципиально правит типовые объекты без веской причины, заказчик платит дважды: за доработку и за её перенос при каждом обновлении.
Оценка «на глаз» и скрытый объём работ
Разработчик называет срок до того, как разобрался в задаче, потому что заказчик требует цифру немедленно. Потом выясняется, что затронуты смежные механизмы, данные в базе «грязные», а типовой функционал ведёт себя не так, как ожидалось. Срок срывается, доверие падает.
Профессиональная практика — разделять этап анализа и этап реализации. Сначала оплачиваемая или бесплатная предоценка с вилкой сроков, затем фиксация объёма. Заказчику стоит насторожиться, если оценка любой задачи звучит мгновенно и без единого уточняющего вопроса.
Когда проблема не в программисте, а в заказчике
Негатив к разработчикам часто маскирует проблемы на стороне заказчика. Типичные сценарии: задачи ставятся устно и меняются по ходу; «проверить» доработку некому, потому что постановщик задачи ушёл в отпуск; требование «как у конкурентов» без понимания собственных процессов.
Отдельный источник конфликтов — ожидание бесплатных консультаций. «Вы же наша база делали, подскажите по телефону, почему не закрывается месяц» — это полноценная работа по диагностике, которая требует времени. Когда разработчик выставляет счёт за такую «консультацию», заказчик воспринимает это как жадность, хотя речь о нормальной оплате труда.
Ещё одна сторона проблемы — отсутствие владельца системы внутри компании. Когда никто не отвечает за 1С целиком, разработчик получает противоречивые требования от бухгалтерии, склада и руководства и вынужден сам решать, чьё пожелание важнее. Любое его решение кого-то не устроит.
Стереотипы, которые мешают работе
Первый стереотип: «1С — это не настоящее программирование, поэтому и отношение такое». На деле разработка на платформе 1С требует понимания учётных механизмов, запросов, СКД, интеграций и специфики регламентированного учёта. Пренебрежительное отношение со стороны «классических» разработчиков ничего не говорит о качестве конкретного специалиста.
Второй стереотип: «все франчайзи одинаковые — берут деньги и ничего не делают». Рынок партнёров 1С неоднороден: есть компании с регламентами, тестированием и гарантиями, а есть посредники, перепродающие час работы фрилансера. Обобщение мешает трезво выбрать подрядчика.
Третий стереотип: «хороший программист должен сам знать бухгалтерию». Разработчик обязан понимать механизмы конфигурации, но методологию учёта определяет главный бухгалтер. Требовать от программиста решения о том, как отражать операцию в учёте, — путь к ошибкам, за которые отвечать будет всё равно бухгалтерия.
Как выстроить работу с разработчиком 1С без конфликтов
Главный инструмент — письменное техническое задание даже на небольшие доработки. Достаточно полстраницы: текущее поведение, желаемое поведение, пример на конкретном документе, критерий приёмки. Время, потраченное на формулировку, окупается отсутствием переделок.
Второй инструмент — разделение зон ответственности. Заказчик отвечает за постановку задачи, методологию учёта и приёмку результата. Разработчик — за техническую реализацию, сохранность данных и работоспособность доработки после обновлений в рамках договорённостей. Эти зоны фиксируются в договоре или хотя бы в переписке.
- 1Опишите проблему на языке процесса: кто, где и что делает сейчас и что должно измениться
- 2Приложите конкретный пример: номер документа, скриншот, ожидаемый результат
- 3Получите от разработчика письменную оценку сроков и стоимости до начала работ
- 4Согласуйте способ реализации: расширение или правка типовой конфигурации
- 5Примите работу на тестовой копии базы по заранее заданным критериям
- 6Зафиксируйте перенос в рабочую базу и сохраните архивную копию до обновления
Третий инструмент — тестовая база. Любая доработка сначала разворачивается на копии, проверяется постановщиком задачи и только потом переносится в рабочую среду. Разработчик, который правит «сразу в боевой», подвергает риску данные всей компании — это недопустимая практика, а не «оперативность».
Как проверить результат доработки
Сценарий из ТЗ выполняется на реальных данных заказчика
Работает только на демонстрационном примере разработчика
Доработка в расширении, обновление проходит штатно
Доработка в типовом коде, обновление требует ручного переноса
Новые объекты доступны нужным ролям, лишних прав нет
Доработка видна всем или, наоборот, недоступна исполнителям
Есть краткое описание: что сделано, где лежит, как отключить
Знания о доработке существуют только в голове исполнителя
Частые ошибки при выборе и контроле исполнителя
Особо выделим риск зависимости от одного человека. Если вся информация о доработках, паролях и интеграциях находится у единственного специалиста, его уход или конфликт с ним парализует систему. Требуйте передачи исходных кодов расширений, описаний доработок и доступов к серверам — это собственность заказчика, оплаченная им.
Обратная ошибка — микроменеджмент: требовать ежечасных отчётов, лезть в код без компетенции, переспрашивать каждое решение. Это демотивирует сильных специалистов, и они уходят к заказчикам, которые контролируют результат, а не процесс.
Когда конфликт всё же возник: маршрут действий
Как выбрать действие
При смене исполнителя критично получить: исходные коды всех расширений и внешних обработок, описание нестандартных механизмов, список доработанных объектов, доступы к серверам и сервисам интеграции. Без этого новый разработчик начнёт с дорогостоящего аудита, и старый конфликт отразится ещё и на бюджете.
Что важно запомнить
Нелюбовь к программистам 1С вызвана не профессией, а сорванными сроками, размытыми задачами, хрупкими доработками и слабой коммуникацией. Письменное ТЗ, тестовая база, расширения вместо правки типового кода и зафиксированные зоны ответственности устраняют большинство поводов для конфликта.
Частые вопросы
Можно ли вообще обойтись без программиста 1С?
Для типовых процессов на свежей конфигурации с регулярными обновлениями — часто да, особенно если штатный специалист освоит настройку отчётов и печатных форм. Программист нужен при нестандартных документооборотах, интеграциях с сайтом, банками, оборудованием и при переносе данных между системами.
Как понять, что разработчик завышает цену?
Попросите разбить оценку на этапы: анализ, реализация, тестирование, перенос. Завышенная оценка обычно не выдерживает детализации. Для крупных работ получите оценку у двух-трёх независимых исполнителей по одному и тому же ТЗ — разброс покажет реальный диапазон.
Что делать, если доработка сломалась после обновления?
Сначала определите, где была доработка: в расширении или в типовом коде. Расширение чинится быстро и обычно входит в гарантийные обязательства. Правка типовой конфигурации требует переноса изменений вручную — это отдельная работа, и именно её нужно было избегать на этапе реализации.
Стоит ли брать разработчика в штат или работать с подрядчиком?
Штатный специалист оправдан при постоянном потоке задач — доработки, поддержка пользователей, интеграции. Если задачи эпизодические, дешевле платить подрядчику за конкретные работы по ТЗ. Гибридный вариант — штатный администратор для мелочей и внешний разработчик для проектов.
Кто должен писать техническое задание — заказчик или программист?
Исходную постановку на языке бизнес-процесса даёт заказчик: он знает, что должно измениться. Разработчик дополняет её техническими деталями: какие объекты затрагиваются, каким способом реализуется, какие есть ограничения. Итоговый документ согласуют обе стороны до начала работ.
Как защититься от ухода единственного разработчика?
Договоритесь заранее о передаче исходных кодов, описаний доработок и всех доступов после каждого этапа, а не «когда-нибудь потом». Храните копии у себя. Периодически привлекайте стороннего специалиста для аудита — он подтвердит, что систему можно сопровождать без автора доработок.