Что такое ТЗ в 1С и как правильно его составить

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

Без ТЗ доработка 1С превращается в цепочку устных договорённостей: заказчик думает одно, разработчик делает другое, а в итоге бюджет расходуется на переделки. Корректно составленное задание снижает риск споров, позволяет заранее оценить стоимость и сроки и служит основой для проверки готовой работы.

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

Зачем нужно техническое задание при работе с 1С

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

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

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

Когда ТЗ обязательно, а когда можно обойтись без него

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

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

Маршрут решения

Как выбрать действие

Доработка меняет учётные данные или проведение документовСоставьте полноценное ТЗ с описанием процесса и критериями приёмки

Задача касается одного отчёта или печатной формыДостаточно краткого ТЗ с макетом и описанием источников данных

Нужна мелкая настройка без изменения конфигурацииОформите короткое письменное поручение с ожидаемым результатом

Структура технического задания для 1С

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

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

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

Как описывать требования, чтобы их понял разработчик

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

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

Обязательно опишите граничные случаи: что делать, если данных нет, если документ не проведён, если пользователь не заполнил обязательное поле. Разработчик реализует ровно то, что написано, и неописанные ситуации будут обработаны произвольно.

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

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

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

Вторая ошибка — отсутствие критериев приёмки. Без них работа считается завершённой «когда заказчик сказал, что хорошо», что ведёт к бесконечным правкам или, наоборот, к конфликту, когда исполнитель считает задачу закрытой.

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

Как проверить результат по ТЗ и принять работу

Приёмку выполняйте строго по критериям из ТЗ, на копии базы или тестовом контуре. Пройдите каждый описанный сценарий от начала до конца, включая отмену проведения, повторное заполнение и работу с незаполненными полями.

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

Только после успешной проверки на копии переносите доработку в рабочую базу — и обязательно сделайте резервную копию перед этим. Это стандартная мера предосторожности, которой нельзя пренебрегать независимо от размера доработки.

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

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

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

Норма

Каждый сценарий выполняется от начала до конца без ошибок

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

На каком-то шаге ошибка, или поведение отличается от описанного

Данные в отчётах

Норма

Итоги сходятся с ручной сверкой по исходным документам

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

Суммы расходятся, есть пропуски или дубли строк

Проведение документов

Норма

Проведение и отмена работают, движения по регистрам корректны

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

Документ не проводится или отмена оставляет «хвосты» в регистрах

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

Норма

Доработка в расширении, типовое обновление проходит штатно

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

Изменены типовые модули, обновление требует ручного сравнения

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

Ответы на частые вопросы

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

Исходную версию пишет заказчик, потому что только он знает бизнес-процесс. Затем разработчик уточняет формулировки, добавляет технические ограничения и возвращает документ на согласование. Финальная версия — всегда результат совместной работы.

Сколько времени занимает составление ТЗ?

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

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

Можно, но только письменно и с пересмотром сроков и стоимости. Любое изменение фиксируйте новой редакцией документа или дополнением к нему — устные корректировки «по ходу дела» ведут к спорам о конечном объёме работ.

Что делать, если я не знаю, какие объекты 1С нужны для задачи?

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

Нужно ли ТЗ, если доработку делает штатный программист?

Да, хотя бы в кратком виде. Письменная постановка дисциплинирует постановщика, позволяет проверить результат и сохраняет знание о том, зачем доработка делалась, — это важно при смене специалиста.

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

ТЗ описывает, что нужно создать, и пишется до начала работ. Инструкция описывает, как пользоваться готовым решением, и составляется после. Для сложных доработок разумно требовать от исполнителя и то, и другое.