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