Разработка и Конфигурация · 9 мин
Как написать техзадание для программиста 1С
Как составить техническое задание для программиста 1С: структура ТЗ, что описать, типичные ошибки, проверка результата и готовые шаблоны формулировок.
Размытое задание «сделайте, чтобы было удобно» — главная причина перерасхода бюджета на доработки 1С. Программист реализует ровно то, что понял, а не то, что имел в виду заказчик, и после сдачи начинается цепочка переделок, каждая из которых оплачивается отдельно. Грамотное техническое задание снимает эту проблему: оно фиксирует, что должно получиться, как это проверить и что в работу не входит.
Хорошее ТЗ для 1С не требует от заказчика знания языка программирования. Требуется другое: чётко описать бизнес-процесс, показать на примерах, какие данные откуда берутся, и сформулировать критерии приёмки. Программист сам решит, какими объектами конфигурации это реализовать — регистром, документом или отчётом.
Ниже — практическая структура техзадания, правила формулировок и типичные ошибки, которые приводят к спорам и переделкам.
Определите, что именно нужно: доработка, отчёт или интеграция
До написания ТЗ важно понять тип задачи, потому что от этого зависит состав описания. Доработка типовой конфигурации требует указать, какой типовой механизм меняется и почему стандартного поведения недостаточно. Новый отчёт требует описать источники данных и макет. Интеграция с внешней системой — формат обмена, направление передачи и поведение при ошибках связи.
Отдельно зафиксируйте, на какой конфигурации и релизе ведётся работа: «1С:Управление торговлей 11.5», «1С:Бухгалтерия 3.0» и т.д. Один и тот же механизм в разных конфигурациях реализуется по-разному, и программист должен понимать среду до оценки трудозатрат.
Типы задач и что описывать
Укажите объект конфигурации, текущее поведение, желаемое поведение и пример документа, на котором видна разница.
Опишите источники данных, колонки, группировки, отборы и приложите макет, пусть даже нарисованный в Excel.
Зафиксируйте вторую систему, формат обмена (файл, API, COM), периодичность и действия при сбое.
Перечислите реквизиты, связи с существующими объектами и то, какие движения или печатные формы нужны.
Опишите текущий процесс и проблему
Раздел «как есть» нужен, чтобы программист понял контекст, а не только конечную картинку. Опишите последовательность действий пользователя сейчас: кто, в каком документе, какие данные вводит, где возникает задержка или ошибка. Например: «Менеджер оформляет заказ, затем вручную пересчитывает скидку в Excel и вносит итоговую сумму в комментарий — из-за этого скидки не попадают в отчёты».
Избегайте оценочных формулировок вроде «неудобно» и «долго» без конкретики. Вместо этого укажите измеримое: «на оформление одного заказа уходит 15 минут вместо 3» или «за месяц выявляется до 10 заказов с неверной скидкой». Это одновременно обоснование задачи и будущий критерий того, что доработка принесла эффект.
Сформулируйте требования проверяемо
Каждое требование должно проходить тест: «можно ли на конкретном примере показать, выполнено оно или нет». Формулировка «добавить контроль остатков» непроверяема. Проверяемый вариант: «При проведении документа "Реализация товаров", если остатка товара на складе недостаточно, документ не проводится, а пользователю выводится сообщение с названием товара и нехватающим количеством».
Используйте структуру «условие → действие системы → результат». Для каждого требования укажите роль пользователя, объект конфигурации и ожидаемое поведение. Если поведение различается для разных ситуаций — опишите каждую ветку отдельно, включая граничные случаи: пустые значения, отменённые документы, отрицательные остатки.
- 1Укажите роль: кто выполняет действие (менеджер, кладовщик, бухгалтер).
- 2Назовите объект: документ, справочник или отчёт, в котором происходит действие.
- 3Опишите условие: при каких данных срабатывает логика.
- 4Опишите результат: что система делает и что видит пользователь.
- 5Приведите пример на реальных данных: конкретный товар, сумма, дата.
Приложите примеры данных и макеты
Примеры — самая недооценённая часть ТЗ. Для отчёта приложите заполненный макет с реальными или правдоподобными цифрами: программист увидит формат чисел, итоги, группировки и порядок колонок. Для печатной формы — образец документа, сверенный с бухгалтерией или юристом, если форма регламентирована.
Для доработок логики приведите 2–3 сценария с числами: «Заказ на 100 000 руб., постоплата 50% — отгрузка разрешена. Заказ на 100 000 руб., оплата 30% — отгрузка блокируется, сообщение менеджеру». Такие примеры выявляют противоречия в ТЗ ещё до начала разработки.
Зафиксируйте границы работ и ограничения
Раздел «что не входит в задачу» защищает обе стороны. Укажите, например: «миграция исторических данных не требуется», «обмен работает только в одну сторону — из 1С на сайт», «доработка не должна затрагивать типовые модули обмена с банком». Без этого программист может законно оценить смежные работы отдельно, а заказчик воспримет это как срыв договорённостей.
Отдельно укажите технические ограничения: нужно ли сохранить возможность обновления конфигурации (это влияет на выбор между изменением типовых объектов и расширением), есть ли требования к производительности, должна ли доработка работать в веб-клиенте и на каких правах пользователей.
Определите критерии приёмки и проверьте результат
Критерии приёмки — это список проверок, по которым работа считается выполненной. Формулируйте их как тест-кейсы: исходные данные, действие, ожидаемый результат. Например: «Создать заказ с товаром А в количестве 10 при остатке 5 → документ не проводится, выводится сообщение о нехватке 5 шт.»
Приёмку проводите на копии рабочей базы или на тестовой базе с реальными данными, а не на пустой демонстрационной. Проверьте не только «счастливый путь», но и ошибочные сценарии: отмена проведения, повторный запуск обмена, работа под пользователем с ограниченными правами. Только после успешной проверки переносите доработку в рабочую базу.
Как проверить результат
Действие выполняется, данные корректны, результат совпадает с примером из ТЗ
Результат отличается от примера или требует ручных доработок
Система выдаёт понятное сообщение и не создаёт некорректных записей
Программа завершается с ошибкой или молча записывает неверные данные
Доработка работает под ролями, указанными в ТЗ
Проверено только под полными правами
Доработка вынесена в расширение, обновление не затронуто
Изменены типовые объекты без согласования
Типичные ошибки при составлении ТЗ
Самая частая ошибка — описание решения вместо задачи. Когда заказчик пишет «добавьте регистр сведений с измерением Номенклатура», он берет на себя проектирование, часто неверное. Правильнее описать потребность: «нужно хранить для каждого товара данные, которые меняются редко и используются в отчёте X» — а выбор механизма оставить программисту.
Вторая группа ошибок — пропущенные детали: не указан релиз конфигурации, не описано поведение при ошибках, не согласован макет печатной формы, не определено, кто и как тестирует результат. Каждый такой пробел превращается в дополнительную итерацию и дополнительные расходы.
Что важно запомнить
ТЗ для программиста 1С описывает бизнес-задачу, а не код: текущий процесс, проверяемые требования по схеме «условие → действие → результат», примеры данных и макеты, границы работ и критерии приёмки. Проверяйте результат на копии базы с реальными данными и по возможности требуйте реализацию через расширение, чтобы не сломать обновления.
Частые вопросы
Нужно ли знать язык 1С, чтобы написать техзадание?
Нет. ТЗ пишется на языке бизнес-процессов: кто, где и что делает, какие данные при этом используются и что должно получиться. Термины конфигурации (документ, справочник, отчёт) полезно знать на уровне пользователя, но проектирование объектов — задача программиста.
Какого объёма должно быть ТЗ?
Объём не регламентирован. Простая доработка печатной формы может уместиться на страницу с макетом, интеграция с внешней системой потребует нескольких страниц с описанием форматов и сценариев ошибок. Критерий достаточности: каждое требование проверяемо, а у программиста не остаётся вопросов, влияющих на результат.
Что делать, если требования изменились в процессе разработки?
Зафиксируйте изменение письменно как дополнение к ТЗ и запросите у исполнителя оценку влияния на сроки и стоимость до продолжения работ. Устные уточнения «по ходу дела» — основной источник споров при приёмке.
Кто должен писать ТЗ, если в компании нет аналитика?
ТЗ может составить руководитель процесса или ключевой пользователь, который лучше всех знает задачу. Полезно показать черновик программисту до утверждения: грамотный исполнитель задаст уточняющие вопросы, и ответы на них войдут в финальную версию документа.
Как оценить адекватность сметы по готовому ТЗ?
Попросите разбить оценку на этапы: анализ, разработка, тестирование, перенос в рабочую базу. Размытая единая сумма без детализации — повод запросить декомпозицию. Для сравнения можно запросить оценку того же ТЗ у второго исполнителя: расхождение в разы указывает на разное понимание задачи.