Как принять работу 1С-программиста: чек-лист приёмки, типичные споры и что делать, если результат не устраивает

Как принять работу 1С-программиста: чек-лист приёмки, типичные споры и что делать, если результат не устраивает

Коротко: Принять работу 1С-программиста правильно — значит проверить результат по формальному чек-листу до подписания акта. Минимум: соответствие ТЗ, тест на реальных данных, проверка производительности, наличие документации и инструкции пользователя. Без этого 40% доработок возвращаются на переделку, а средняя стоимость споров с фрилансером — 30 000–120 000 ₽ потерянного времени и денег.

Почему приёмка работы 1С — отдельный навык

Большинство руководителей и бухгалтеров принимают работу 1С-программиста по принципу «включилось — значит работает». Это главная ошибка. Доработка может запускаться, но считать неправильно, тормозить при нагрузке, ломаться после обновления платформы или не иметь никакой документации. Обнаружится это через 2–3 месяца, когда исполнитель уже недоступен.

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

Что проверять при приёмке: 12-пунктный чек-лист

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

Блок 1. Соответствие техническому заданию

  • ✓ Все пункты ТЗ реализованы — пройдитесь по каждому требованию из ТЗ и проверьте наличие в системе.
  • ✓ Нет «самодеятельности» — программист не добавил функции, которые не просили, или не убрал то, что должно было остаться.
  • ✓ Интерфейс соответствует описанию — кнопки, поля, формы расположены так, как было согласовано.

Блок 2. Тестирование на реальных данных

  • ✓ Проверка на боевой базе или копии — тест только на демо-данных не считается полноценной приёмкой.
  • ✓ Граничные случаи — нулевые значения, максимальные суммы, пустые поля, нестандартные контрагенты.
  • ✓ Корректность расчётов — сверьте результаты с ручным расчётом или эталонными данными.
  • ✓ Работа при параллельных пользователях — если система многопользовательская, проверьте одновременный доступ минимум 3–5 пользователей.

Блок 3. Производительность и стабильность

  • ✓ Время выполнения операции — отчёт на 10 000 строк не должен формироваться дольше 30–60 секунд (если иное не оговорено в ТЗ).
  • ✓ Отсутствие блокировок — доработка не должна создавать технологические блокировки в базе.
  • ✓ Работа после обновления — проверьте, что доработка выполнена через расширение или механизм подписок, а не «в лоб» в типовой конфигурации.

Блок 4. Документация и передача знаний

  • ✓ Инструкция пользователя — хотя бы 1–2 страницы с описанием, как пользоваться новым функционалом.
  • ✓ Техническое описание доработки — что именно изменено, в каких объектах конфигурации, почему такое решение.

Сколько времени занимает правильная приёмка?

Время на приёмку зависит от масштаба работ. Ориентир: 10–15% от времени разработки. Если программист потратил 8 часов — заложите 1–1,5 часа на тестирование и проверку.

Тип работыВремя разработкиРекомендуемое время приёмкиКто проводит
Небольшой отчёт / печатная форма2–4 ч30–60 минБухгалтер / руководитель
Доработка справочника или документа4–8 ч1–2 чКлючевой пользователь
Интеграция с внешней системой16–40 ч4–8 чIT-специалист + бизнес-пользователь
Внедрение модуля (зарплата, склад и др.)80–200 ч16–30 чПроектная группа
Комплексное внедрение ERP500+ чОтдельный этап ОПЭ 2–4 нед.Рабочая группа + тестировщик

Типичные споры при приёмке и как их разрешить

Спор №1: «Работает не так, как я представлял»

Это самый частый конфликт — заказчик имел в виду одно, программист реализовал другое. Причина почти всегда — нечёткое ТЗ. Если в ТЗ написано «сделать отчёт по продажам», а не «отчёт с группировкой по менеджерам, с фильтром по периоду и выгрузкой в Excel» — программист формально прав, даже если результат вас не устраивает. Решение: до начала работ согласуйте макет или прототип. После — сравнивайте результат с макетом, а не с ожиданиями.

Спор №2: «После обновления 1С всё сломалось»

Если программист внёс изменения напрямую в типовую конфигурацию (поставил на «замок»), любое обновление платформы или конфигурации сломает доработку. Это нарушение стандартов 1С-разработки. Решение: при приёмке проверьте режим конфигурации — она должна оставаться на поддержке или доработка должна быть вынесена в расширение. Если программист работал «в лоб» — это повод для претензии.

Спор №3: «Считает неправильно, но программист говорит, что всё верно»

Подготовьте эталонный расчёт вручную до начала тестирования — 3–5 документов с известным результатом. Сравните с тем, что выдаёт система. Если расхождение есть — это баг, и он должен быть исправлен бесплатно в рамках гарантийного периода. Стандартный гарантийный срок на доработки 1С — 1–3 месяца (должен быть прописан в договоре).

Спор №4: «Программист недоступен после сдачи работы»

Типичная ситуация с фрилансерами: деньги получены, связь пропала. Решение: не платите 100% аванса. Оптимальная схема оплаты — 30% аванс, 70% после приёмки. При работе через маркетплейс (например, Koderion) деньги хранятся на эскроу-счёте и выплачиваются исполнителю только после подтверждения приёмки заказчиком.

Стоимость переделок: во что обходятся ошибки при приёмке

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

СитуацияСтоимость первичной работыСтоимость переделкиКоэффициент удорожания
Отчёт с неправильной логикой5 000–15 000 ₽8 000–25 000 ₽×1,5–1,7
Интеграция с ошибками в обмене30 000–80 000 ₽50 000–130 000 ₽×1,6–1,8
Модуль, сломавшийся после обновления80 000–200 000 ₽120 000–300 000 ₽×1,5–2,0
Внедрение с неверной методологией300 000–800 000 ₽200 000–500 000 ₽ (частичная переделка)+30–60% к бюджету

Акт приёмки-сдачи работ: что должно быть в документе

Акт приёмки — юридически значимый документ. Без него доказать факт выполнения работ или предъявить претензии крайне сложно. Минимальный состав акта для 1С-работ в 2026 году:

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

Если работаете с фрилансером без договора — составьте хотя бы переписку в мессенджере с явным подтверждением: «Я проверил, работа выполнена, претензий нет». Это тоже доказательство при споре.

Как выстроить приёмку при работе с аутсорсинговой компанией

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

  • Опытная эксплуатация (ОПЭ) — для крупных проектов обязателен период 2–4 недели, когда система работает параллельно со старым процессом. Все расхождения фиксируются и устраняются до финального закрытия проекта.
  • Протокол тестирования — попросите аутсорсера предоставить заполненный протокол с описанием тест-кейсов. Если его нет — это красный флаг.
  • Разграничение ответственности — уточните, кто отвечает за обновление доработок при выходе новых релизов конфигурации. Обычно это входит в абонентское обслуживание за 15 000–60 000 ₽/мес.

Что делать, если результат не устраивает: алгоритм действий

Если работа сдана, но вы обнаружили проблемы — действуйте по чёткому алгоритму:

  1. Зафиксируйте проблему письменно — скриншоты, видео экрана, описание шагов воспроизведения. Чем детальнее — тем быстрее исправят.
  2. Направьте претензию исполнителю — письменно (email, мессенджер) с описанием конкретного несоответствия ТЗ. Дайте срок ответа — 2–3 рабочих дня.
  3. Не подписывайте акт до устранения — подписанный акт означает согласие с результатом. После подписания претензии принимаются только в рамках гарантии.
  4. Если исполнитель не реагирует — при работе через маркетплейс откройте спор: платформа выступает арбитром. При прямом договоре — претензионное письмо с требованием устранить недостатки в 10-дневный срок (ст. 723 ГК РФ).
  5. Привлеките независимого эксперта — другой 1С-специалист за 3 000–8 000 ₽ напишет экспертное заключение о качестве работы. Это весомый аргумент при споре.

FAQ: частые вопросы о приёмке работы 1С-программиста

Нужно ли тестировать работу, если программист — знакомый или работает давно?

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

Кто должен проводить тестирование — заказчик или программист?

Программист проводит внутреннее тестирование до сдачи. Заказчик проводит приёмочное тестирование — проверяет, что результат соответствует бизнес-требованиям. Это разные виды проверки, и оба обязательны.

Что делать, если нет ТЗ и непонятно, с чем сравнивать результат?

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

Часто задаваемые вопросы

Что обязательно проверить при приёмке работы 1С-программиста?

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

Сколько времени занимает приёмка работы 1С?

Рекомендуемое время приёмки — 10–15% от времени разработки. Небольшой отчёт (2–4 ч разработки) проверяется за 30–60 минут. Интеграция с внешней системой (16–40 ч) требует 4–8 ч тестирования. Комплексное внедрение — отдельный этап опытно-промышленной эксплуатации (ОПЭ) длиной 2–4 недели.

Что делать, если 1С-программист сдал работу, но она работает неправильно?

Алгоритм: 1) Зафиксируйте проблему письменно — скриншоты, видео, шаги воспроизведения. 2) Направьте письменную претензию исполнителю с описанием несоответствия ТЗ, дайте срок ответа 2–3 рабочих дня. 3) Не подписывайте акт приёмки до устранения. 4) При отсутствии реакции — откройте спор через маркетплейс или направьте претензионное письмо по ст. 723 ГК РФ. 5) При необходимости привлеките независимого эксперта (3 000–8 000 ₽ за заключение).

Что такое гарантийный период на доработки 1С и сколько он длится?

Гарантийный период — время, в течение которого исполнитель обязан бесплатно устранять ошибки в сданной работе. Стандартный срок — 1–3 месяца, должен быть прописан в договоре. В гарантийный период входят баги (ошибки в логике, неверные расчёты), но не входят новые требования и изменения законодательства.

Нужен ли акт приёмки при работе с фрилансером?

Да, акт приёмки нужен всегда. Без него сложно доказать факт выполнения работ или предъявить претензии. Минимальный состав: описание работ со ссылкой на ТЗ, перечень изменённых объектов конфигурации, результаты тестирования, гарантийные обязательства, подписи и дата. Если работаете без официального договора, зафиксируйте приёмку хотя бы письменным подтверждением в мессенджере.

Во сколько обходится переделка работы 1С-программиста?

Переделка обходится в 1,5–2 раза дороже первоначальной разработки. Небольшой отчёт, стоивший 5 000–15 000 ₽, при переделке обойдётся в 8 000–25 000 ₽. Переделка интеграции с ошибками — от 50 000 до 130 000 ₽ при первоначальной стоимости 30 000–80 000 ₽. Именно поэтому правильная приёмка экономит деньги.

Как защититься от ситуации, когда программист пропадает после получения денег?

Используйте схему поэтапной оплаты: 30% аванс, 70% после подписания акта приёмки. При работе через маркетплейс (например, Koderion) деньги хранятся на эскроу-счёте и перечисляются исполнителю только после подтверждения приёмки заказчиком. Это исключает риск исчезновения исполнителя с авансом.

Что значит 'доработка выполнена в лоб' и почему это плохо?

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

Читайте также