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

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

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

Разберитесь в терминологии платформы 1С

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

Практический способ освоения — открыть типовую конфигурацию (например, «Управление торговлей» или «Бухгалтерию предприятия») в режиме «Конфигуратор» или хотя бы изучить её структуру через пользовательский интерфейс. Сопоставляйте каждое действие пользователя с объектом: оформление продажи — это документ «Реализация товаров и услуг», остатки на складе — данные регистра накопления. Через несколько недель такого сопоставления термины закрепятся естественно.

Освойте стандартную структуру ТЗ

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

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

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

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

Научитесь описывать алгоритмы без кода

Писать ТЗ — не значит писать код, но алгоритм нужно передать однозначно. Используйте конструкции «если — то — иначе», таблицы соответствия и пошаговые сценарии. Например, вместо «рассчитывать скидку по особым правилам» напишите: «если сумма документа меньше 50 000 — скидка 3%; от 50 000 до 200 000 — 5%; свыше 200 000 — скидка согласуется с руководителем отдела продаж, документ блокируется до подтверждения».

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

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

Тренируйтесь на простых типовых задачах

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

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

С чего начать практику

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

Идеальна для первого ТЗ: чёткий результат (готовый документ), легко проверить. Ограничение — не учит работе с регистрами и проведением.

Отчёт

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

Проверка при проведении

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

Обмен данными

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

Избегайте типичных ошибок начинающих

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

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

Проверяйте качество ТЗ до передачи в работу

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

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

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

Как проверить готовое ТЗ

Каждое требование

Норма

Можно сформулировать тест: действие → ожидаемый результат

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

Требование нельзя проверить действием, только «на глаз»

Объекты доработки

Норма

Указаны точные названия документов, справочников, отчётов

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

Общие формулировки: «в продажах», «в отчёте»

Граничные случаи

Норма

Описано поведение при пустых полях, нулях, отмене документа

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

Описан только «счастливый путь»

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

Норма

Определено, какие роли видят и используют новую функцию

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

Про права ничего не сказано

Развивайте навык дальше

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

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

Часто задаваемые вопросы

Нужно ли уметь программировать, чтобы писать ТЗ по 1С?

Нет, но полезно понимать логику платформы: что такое объекты конфигурации, проведение документов, регистры. Многие авторы ТЗ — аналитики и ведущие пользователи без опыта кодирования. Базовое чтение кода помогает оценивать реалистичность требований, но не обязательно.

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

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

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

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

Что делать, если заказчик не может сформулировать требования?

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

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

Оценку сроков и трудозатрат обычно даёт разработчик после ознакомления с ТЗ — это отдельный этап. В самом документе достаточно указать желаемый срок внедрения и приоритет, если они критичны для бизнеса.

Как описывать доработки, затрагивающие обмен данными между базами?

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