Как написать техническое задание на доработку 1С

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

Хорошее ТЗ решает три задачи. Во-первых, фиксирует объём работ — по нему подрядчик считает стоимость и сроки. Во-вторых, служит критерием приёмки: готовую доработку проверяют на соответствие пунктам задания. В-третьих, защищает обе стороны при разногласиях, особенно если работа выполняется по договору с внешним подрядчиком.

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

Определите цель и границы доработки

Начните с ответа на вопрос: какую проблему решает доработка. Формулировка «нужна кнопка в заказе» ничего не говорит разработчику. Правильный вариант: «менеджеры тратят 10–15 минут на ручное заполнение счёта по данным заказа, нужно автоматическое создание счёта одной кнопкой с переносом товаров, цен и реквизитов покупателя». Из такой формулировки понятны и сценарий использования, и ожидаемый эффект.

Сразу зафиксируйте границы: что входит в работу, а что — нет. Например: «доработка касается только документа "Заказ покупателя" и счёта; изменение механизмов резервирования товара не требуется». Это защищает от «расползания» объёма: без явных границ любое пожелание смежного отдела будет объявлено «само собой разумеющимся».

Укажите, на какой конфигурации и релизе выполняется доработка: «1С:Управление торговлей 11.5», «1С:Бухгалтерия 3.0», «1С:ERP 2.5». От этого зависят и доступные механизмы, и стоимость работ. Если база сильно доработана ранее, упомяните об этом — подрядчику нужно оценивать риск конфликтов с существующими изменениями.

Опишите текущий процесс «как есть»

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

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

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

Опишите требуемую логику «как должно быть»

Это ядро ТЗ. Опишите целевой сценарий пошагово, от действия пользователя до результата в системе. Используйте нумерованный список: каждый шаг — одно действие или одно правило. Например:

1. В документе «Заказ покупателя» добавить команду «Создать счёт».
2. По команде создаётся документ «Счёт на оплату покупателю» на основании заказа: контрагент, договор, товары, количество и цены переносятся без изменений.
3. Если по заказу уже есть непроведённый счёт — выводить предупреждение и открывать существующий, а не создавать новый.
4. Сумма счёта должна совпадать с суммой заказа; при расхождении после ручного редактирования заказа выводить сообщение при проведении.

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

Для расчётной логики приведите числовой пример. Если описываете формулу расчёта скидки, наценки или комиссии — покажите её на конкретных цифрах: «товар 1000 руб., скидка по карте 5%, дополнительная скидка менеджера 3% применяется к сумме после первой скидки, итог: 1000 × 0,95 × 0,97 = 921,50 руб.». Пример устраняет двусмысленность, которую почти невозможно убрать словами.

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

Опишите интерфейс, права и печатные формы

Отдельным блоком зафиксируйте, где пользователь увидит результат: в какой форме появится кнопка или поле, в каком разделе интерфейса будет новый отчёт, кто из пользователей должен иметь доступ. Требования к правам формулируйте через роли: «доработка доступна пользователям с правами менеджера по продажам; кассирам кнопка не отображается».

Для печатных форм приложите макет — даже нарисованный от руки или собранный в Excel. Укажите, какие поля откуда берутся, как форматируются суммы и даты, есть ли логотип, подписи, колонтитулы. Печатная форма — классический источник итераций «подвиньте на 2 миллиметра», и чем точнее макет, тем меньше переделок.

Если доработка затрагивает обмен данными с другими системами (сайт, CRM, банк-клиент, складская программа), опишите формат: какие данные передаются, в каком виде (файл, API, COM-соединение), с какой периодичностью, кто отвечает за вторую сторону обмена. Интеграционные задачи без такого описания оцениваются подрядчиком с большим запасом — и это логично.

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

Сформулируйте критерии приёмки

Приёмка по принципу «посмотрел — вроде работает» приводит к тому, что ошибки находят пользователи уже в боевой базе. Включите в ТЗ раздел «Порядок приёмки»: набор проверок, которые должны пройти успешно. Каждая проверка — это конкретное действие и ожидаемый результат: «Создать заказ на 3 позиции с разными ставками НДС, нажать "Создать счёт" — счёт создаётся, суммы и НДС совпадают с заказом».

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

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

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

Большинство проблем с доработками связано не с квалификацией разработчика, а с дефектами задания. Разберите свои формулировки на предмет типовых ошибок до передачи ТЗ исполнителю.

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

Структура готового документа

Готовое ТЗ удобно собрать по единому шаблону — это упрощает и написание, и проверку полноты. Рабочая структура выглядит так:

1. Общие сведения: конфигурация, релиз, режим работы (файловый/клиент-серверный), требование к способу реализации (расширение или изменение конфигурации).
2. Цель доработки и бизнес-контекст: какую проблему решаем, кто пользователи.
3. Описание текущего процесса «как есть» со скриншотами.
4. Требуемая логика «как должно быть»: пошаговые сценарии, правила расчёта с числовыми примерами, обработка исключений.
5. Требования к интерфейсу, правам доступа, печатным формам (с макетами).
6. Требования к обменам и интеграциям, если есть.
7. Критерии и порядок приёмки, требования к тестированию на копии базы.
8. Что не входит в объём работ.

Объём документа вторичен: простая доработка умещается в 2–3 страницы, крупная — в 15–20. Полнота важнее размера: если по каждому пункту структуры есть хотя бы короткий, но конкретный ответ, ТЗ уже лучше большинства.

Частые вопросы

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

Исходное задание пишет заказчик, потому что только он знает бизнес-процесс. Разработчик или аналитик подрядчика может дополнить его техническими уточнениями и вернуть на согласование. Вариант «программист сам всё напишет по устному рассказу» почти всегда заканчивается переделками: зафиксированного документа нет, и доказать, что требовалось иначе, невозможно.

Насколько подробно нужно расписывать ТЗ для небольшой доработки?

Даже для задачи на пару часов работы напишите минимум: цель, сценарий использования, один пример с данными и критерий проверки. Это займёт 15–20 минут, но исключит ситуацию, когда кнопку добавили не в ту форму или отчёт считает не те данные. Чем меньше ТЗ, тем выше вероятность, что доработку придётся оплачивать дважды.

Что делать, если требования изменились в процессе разработки?

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

Можно ли использовать в ТЗ скриншоты вместо текста?

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

Нужно ли в ТЗ указывать сроки и стоимость?

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

Как проверить, что разработчик выполнил именно то, что в ТЗ?

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