Разработка и Конфигурация · 10 мин
Как составить техническое задание для 1С
Практическое руководство по составлению ТЗ на доработку 1С: структура документа, описание требований, критерии приёмки, типичные ошибки и советы.
Техническое задание (ТЗ) на доработку 1С — это документ, который связывает заказчика и разработчика: он фиксирует, что именно должна делать система после изменений, и служит основой для приёмки работы. Некорректное или расплывчатое ТЗ — главная причина срыва сроков, перерасхода бюджета и конфликтов «мы имели в виду другое». Качественное ТЗ позволяет оценить трудоёмкость до начала работ и избежать бесконечных правок на этапе сдачи.
Хорошая новость: для большинства задач по 1С не требуется громоздкий документ по ГОСТ. Достаточно структурированного описания на 3–10 страниц, если оно отвечает на ключевые вопросы: что меняем, зачем, как должно работать, как проверим результат. Ниже — практическая структура, правила формулировок и контрольные точки, которые помогут составить ТЗ, понятное и бухгалтеру, и программисту.
Определите цель и границы доработки
Начните с формулировки бизнес-цели: какую проблему решает доработка. «Менеджеры тратят 2 часа в день на ручное формирование счетов» — это цель. «Добавить кнопку в документ» — это решение, и оно может оказаться неоптимальным. Если в ТЗ зафиксирована цель, разработчик вправе предложить более простой способ её достичь, и это часто экономит бюджет.
Отдельно обозначьте границы работ: какие конфигурации, подсистемы и объекты затрагиваются, а что точно не входит в задачу. Например: «Доработка выполняется в 1С:Управление торговлей 11, затрагивает документы "Реализация товаров и услуг" и "Счёт на оплату". Интеграция с сайтом и изменение мобильного приложения в данную задачу не входят». Такая фраза предотвращает споры о «недоделанном» функционале.
Укажите актуальные версии: релиз конфигурации и платформы, наличие доработок, снята ли конфигурация с поддержки. От этого зависит способ реализации — через расширение или изменение основной конфигурации.
Опишите текущий процесс «как есть»
Разработчик не знает вашу учётную практику, поэтому раздел «текущее состояние» обязателен. Опишите пошагово, кто и как выполняет операцию сейчас: какие документы создаёт, в каком порядке, какие данные переносит вручную, где возникают ошибки и задержки. Лучше всего работает формат: роль → действие → результат → проблема.
Приложите скриншоты существующих форм и примеры реальных документов (с обезличенными данными). Один скриншот заполненного документа часто заменяет страницу текстового описания. Если доработка касается отчёта, приложите текущий вариант отчёта в Excel с пояснениями, откуда берётся каждая колонка.
Упомяните смежные особенности: обмены с другими системами, регламентные задания, права доступа, работу в РИБ. Доработка, которая конфликтует с обменом данными или обрывает регламентное задание, создаст проблемы, которых в ТЗ «не было».
Сформулируйте требования проверяемо
Каждое требование должно быть конкретным, измеримым и проверяемым. Плохая формулировка: «Сделать удобный подбор товаров». Хорошая: «В документе "Заказ клиента" добавить кнопку "Подбор по остаткам". По нажатию открывается форма со списком товаров, у которых свободный остаток на выбранном складе больше нуля. При двойном щелчке товар добавляется в табличную часть с количеством 1 и ценой из действующего прайса».
Используйте нумерованный список требований — по номерам удобно вести переписку, писать замечания при приёмке и вести журнал изменений. Каждое требование — одна законченная мысль. Не объединяйте несколько независимых требований в один пункт: при частичном выполнении будет неясно, принимать работу или нет.
Для логики расчётов приводите точные формулы и примеры на конкретных числах. «Скидка 5% при сумме свыше 100 000 руб.» недостаточно: уточните, от чего считается база (с НДС или без), применяется ли скидка к каждой строке или к документу целиком, что происходит при возврате. Пример: «Сумма документа 120 000 руб. с НДС → скидка 6 000 руб., итого 114 000 руб.» закрывает большинство вопросов разработчика.
- 1Опишите бизнес-цель и границы работ
- 2Зафиксируйте текущий процесс со скриншотами
- 3Сформулируйте требования нумерованным списком
- 4Приложите макеты форм, печатных форм и отчётов
- 5Опишите примеры расчётов на конкретных числах
- 6Согласуйте критерии приёмки и порядок тестирования
Приложите макеты форм и печатных документов
Если доработка затрагивает интерфейс, нарисуйте макет: подойдёт схема в Excel, Paint или на бумаге. На макете подпишите каждый элемент: название поля, источник данных, обязательность заполнения, поведение при изменении. Для печатных форм приложите пример итогового документа и таблицу соответствия: «Поле "Грузополучатель" ← реквизит "Грузополучатель" документа; если не заполнен — контрагент из договора».
Для отчётов укажите: состав колонок и их источники, группировки и итоги, отборы, которые должен задавать пользователь, периодичность и требования к скорости формирования. Если отчёт строится по большому объёму данных, отдельно оговорите допустимое время формирования на реальной базе — это влияет на выбор архитектуры решения.
Зафиксируйте критерии приёмки и нефункциональные требования
Критерии приёмки — это чек-лист, по которому работа считается выполненной. Формулируйте их как сценарии: «При создании счёта на основании заказа с тремя строками в печатной форме выводятся все три позиции, итоговая сумма совпадает с суммой документа». Такой сценарий тестирует и заказчик, и разработчик одинаково.
Добавьте нефункциональные требования, если они существенны: производительность (время открытия формы, формирования отчёта), права доступа (какие роли видят новый функционал), работа в тонком и веб-клиенте, поведение при обмене данными, необходимость переноса исторических данных. Эти пункты чаще всего «всплывают» после сдачи, если их не зафиксировать заранее.
Как проверить качество ТЗ
Можно составить тест с ответом да/нет
Содержит слова «удобно», «быстро», «корректно» без критериев
Есть формула и числовой пример
Описание только словами
Перечислено, что не входит в задачу
Границы не определены
Есть сценарии проверки
Критерий — «заказчик посмотрит»
Согласуйте формат и порядок изменений
Для небольших доработок достаточно документа на 3–5 страниц в Word или Google Docs. Для крупных проектов ТЗ разбивают на этапы с отдельными разделами приёмки по каждому. В шапке документа укажите: наименование задачи, версию документа, дату, ответственных с обеих сторон, согласование (кто утверждает ТЗ и кто принимает работу).
Сразу договоритесь, как обрабатываются изменения ТЗ в процессе. Рабочая практика: любые дополнения фиксируются новой версией документа или протоколом изменений с оценкой влияния на сроки и стоимость. Устные пожелания в мессенджере — источник большинства конфликтов на приёмке.
Если внутренних компетенций не хватает, поручите составление ТЗ аналитику со стороны исполнителя, но обязательно с этапом вашего согласования: подписывая ТЗ, вы подтверждаете, что описанное — именно то, что нужно бизнесу.
Минимальный шаблон ТЗ для 1С
Рабочий каркас документа выглядит так: 1) Цель и решаемая проблема; 2) Среда внедрения (конфигурация, релиз, платформа, способ реализации — расширение или изменение конфигурации); 3) Текущий процесс «как есть»; 4) Нумерованный список функциональных требований; 5) Макеты форм, печатных форм и отчётов; 6) Нефункциональные требования (права, производительность, клиенты); 7) Критерии приёмки и тестовые сценарии; 8) Что не входит в работу; 9) Порядок изменения ТЗ.
Такой шаблон покрывает типовые задачи: новая печатная форма, доработка документа, отчёт, обработка загрузки данных, простая интеграция. Для обменов между системами добавьте разделы с форматом данных, расписанием обмена и поведением при ошибках связи.
Что важно запомнить
Хорошее ТЗ для 1С — это не объёмный документ, а проверяемый: цель, границы, нумерованные требования, макеты, числовые примеры расчётов и сценарии приёмки. Если по каждому пункту можно составить тест с однозначным результатом — ТЗ готово к передаче разработчику.
Частые вопросы
Сколько страниц должно быть в ТЗ на доработку 1С?
Объём зависит от задачи, а не от формальных норм. Простая печатная форма — 1–2 страницы с макетом и источниками полей. Доработка документа с новой логикой — 3–7 страниц. Комплексный проект с интеграциями может занимать десятки страниц и разбиваться на этапы. Критерий достаточности: по документу можно оценить трудоёмкость и принять работу без устных пояснений.
Кто должен писать ТЗ — заказчик или исполнитель?
Оба варианта рабочие. Заказчик лучше знает процесс, исполнитель — возможности платформы. Оптимальная схема: заказчик описывает цель, текущий процесс и желаемый результат, аналитик исполнителя формализует это в требования и возвращает на согласование. Подписывать ТЗ должен представитель заказчика, понимающий описанный процесс.
Нужно ли в ТЗ указывать, как именно программировать решение?
Нет, если вы не уверены в техническом решении. ТЗ описывает, что должна делать система, а не код. Исключение — осознанные ограничения: реализация только через расширение, запрет на изменение типовых модулей, требования к совместимости с обменами. Их фиксировать нужно обязательно.
Что делать, если требования изменились в процессе разработки?
Зафиксируйте изменение письменно: новой версией ТЗ или протоколом изменений с указанием влияния на сроки и стоимость. Устные доработки «по ходу дела» — основная причина споров при оплате. Небольшие уточнения, не меняющие сути, можно оформлять комментариями к согласованной версии документа.
Чем ТЗ отличается от постановки задачи в баг-трекере?
По сути — ничем, если соблюдены те же требования к содержанию. Задача в Jira, YouTrack или системе учёта заявок вполне заменяет отдельный документ, если содержит цель, требования, макеты и критерии приёмки. Для разовых доработок такой формат даже удобнее: история изменений и обсуждений сохраняется автоматически.
Как проверить, что разработчик выполнил ТЗ полностью?
Пройдите по сценариям приёмки из ТЗ на тестовой копии базы с реальными данными. Каждый нумерованный пункт требований должен иметь статус «проверено». Замечания отправляйте списком со ссылками на пункты ТЗ, а не общими фразами. После исправлений повторите проверку только по затронутым сценариям и смежным процессам.