Как написать техническое задание для программиста 1С

Техническое задание для программиста 1С — это документ, который переводит пожелание пользователя («нам нужно, чтобы счета формировались быстрее») в конкретную задачу разработки («добавить в документ "Счет на оплату" кнопку массовой печати с выбором шаблона»). Чем точнее ТЗ, тем меньше переделок, споров о стоимости и ситуаций «мы имели в виду другое».

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

Ниже — практическая структура ТЗ, правила формулировок, типичные ошибки и способ проверить, что разработка выполнена именно так, как заказывалось.

Из каких разделов состоит ТЗ для доработки 1С

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

• Контекст и цель. Какой процесс сейчас выполняется, в чём его проблема и какой бизнес-результат нужен. Например: «Менеджеры вручную переносят данные из заказа в счёт, это занимает 10 минут на документ и приводит к ошибкам в реквизитах».
• Текущее поведение системы. Как задача решается сейчас в базе: какие документы, отчёты и обработки используются, что в них не устраивает.
• Требуемое поведение. Пошаговое описание того, что должна делать система после доработки: какие объекты создаются или меняются, какие поля заполняются, какие проверки выполняются.
• Данные и ограничения. Откуда берутся значения, какие роли имеют доступ, какие объёмы данных обрабатываются, есть ли требования к скорости.
• Окружение. Конфигурация и её версия (например, «1С:Комплексная автоматизация 2.5, релиз 2.5.x»), режим работы (файловая или клиент-серверная база), наличие других доработок.
• Критерии приёмки. Проверяемые сценарии, по которым заказчик решает, что задача выполнена.

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

Как описывать задачу языком объектов 1С

Программист 1С мыслит объектами конфигурации: справочники, документы, регистры сведений и накопления, отчёты, обработки, роли. Чем ближе формулировка ТЗ к этой терминологии, тем меньше двусмысленности.

Сравните две формулировки:

• Плохо: «Сделайте, чтобы в заказе было видно долг клиента».
• Хорошо: «В форму документа "Заказ клиента" добавить поле "Задолженность покупателя", которое при открытии формы показывает сумму долга контрагента по регистру расчётов с клиентами на текущую дату. Поле только для чтения, обновление — по кнопке "Обновить задолженность"».

Во втором варианте указаны объект (форма документа), источник данных (регистр расчётов), момент вычисления (при открытии и по кнопке) и поведение (только чтение). Программист может сразу оценить работу, не задавая пять уточняющих вопросов.

Если вы не знаете точных имён объектов в вашей конфигурации, приложите скриншоты экранных форм и опишите путь пользователя: «Открываем раздел Продажи → Заказы клиентов → создаём новый документ». Разработчик сам сопоставит это с объектами метаданных.

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

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

Формат, который хорошо работает на практике:

1. Роль и начальные условия: «Менеджер по продажам, в базе есть проведённый заказ клиента с тремя строками товаров».
2. Действие: «Нажимает кнопку "Создать счёт на оплату" в форме заказа».
3. Ожидаемый результат: «Создаётся документ "Счёт на оплату покупателю" с заполненными контрагентом, договором и табличной частью из заказа. Сумма счёта равна сумме заказа. Заказ записывается в поле "Основание"».

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

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

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

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

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

Отчёты

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

Печатные формы

Приложите образец готового документа (скан, PDF или заполненный макет) и укажите, из каких полей объекта берётся каждый реквизит. Если форма регламентированная (ТОРГ-12, счёт-фактура, УПД), сошлитесь на действующую форму и уточните, чем ваша версия отличается от типовой. Проверяйте печатную форму на документе с максимально длинными наименованиями — типичная проблема, когда текст «не влезает» в ячейку.

Обмены и интеграции

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

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

После получения ТЗ программист оценивает работу в часах. Оценка сильно зависит от полноты постановки: размытое ТЗ даёт разброс «от 4 до 40 часов», детальное — точную цифру с небольшим запасом на непредвиденное.

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

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

Способы реализации доработки

Расширение конфигурации

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

Внешняя обработка или отчёт

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

Изменение основной конфигурации

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

Как принимать работу: критерии и проверка

Приёмка выполняется по сценариям из ТЗ. Подготовьте тестовые примеры заранее: конкретный заказ, конкретный контрагент, конкретный период — и ожидаемый результат для каждого из них. Если в ТЗ написано «сумма счёта равна сумме заказа», проверьте это на трёх-четырёх реальных документах, включая документ со скидкой и с частичной оплатой.

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

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

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

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

Сценарии из ТЗ

Норма

Каждый сценарий выполняется и даёт описанный результат

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

Часть сценариев не реализована или ведёт себя иначе

Ошибочные ситуации

Норма

Система выдаёт понятное сообщение и не создаёт некорректных данных

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

Программа «падает» с технической ошибкой или молча записывает неверные данные

Права доступа

Норма

Новые функции доступны только предусмотренным ролям

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

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

Обновление конфигурации

Норма

Доработка выполнена расширением и не блокирует обновление

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

Конфигурация снята с поддержки без согласования

Типичные ошибки при составлении ТЗ

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

Отдельная ошибка — поручать написание ТЗ самому программисту «со слов пользователя» без участия заказчика. Разработчик зафиксирует то, как он понял задачу, а не то, что нужно бизнесу. Участие в составлении ТЗ со стороны исполнителя — нормальная практика, но утверждать документ должен представитель заказчика, понимающий процесс.

FAQ: частые вопросы о постановке задач программисту 1С

Достаточно ли устной постановки для небольшой доработки?

Для задачи на 1–2 часа устного описания может хватить, но итог всё равно зафиксируйте письменно хотя бы в переписке: что согласовано, сколько стоит, когда будет готово. Это защищает обе стороны, если через месяц возникнет вопрос «а мы это заказывали?».

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

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

Что делать, если в ходе работы выяснилось, что ТЗ неполное?

Оформите дополнение к ТЗ письменно: новое требование, причина его появления, влияние на сроки и стоимость. Не согласовывайте изменения устно — именно незафиксированные «добавки по ходу» превращают небольшую задачу в бесконечный проект.

Как понять, что оценка в часах завышена?

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

Нужно ли упоминать в ТЗ будущие обновления конфигурации?

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

Можно ли использовать шаблон ТЗ для всех задач?

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