Внедрение или доработка системы 1С:Предприятие часто превращается в долгострой не из-за сложности кода, а из-за нечеткой постановки задачи. Заказчик говорит «сделайте удобно», а программист реализует это по-своему. Результат — десятки итераций правок, потеря времени и бюджета.
Навык написания качественного технического задания (ТЗ) — это не привилегия IT-специалистов, а обязательная компетенция для любого руководителя или аналитика, работающего с 1С. Грамотное ТЗ экономит деньги и нервы.
В этой статье мы разберем структуру идеального документа, научимся переводить бизнес-желания на язык алгоритмов и избежим типичных ошибок, которые приводят к провалу проектов.
Фундамент: Бизнес-процесс против Функционала
Самая распространенная ошибка новичка — начать описывать кнопки и поля. Программисту не нужно знать, какого цвета должна быть кнопка «Сохранить». Ему необходимо понять бизнес-процесс, который эта кнопка обслуживает.
Прежде чем открыть текстовый редактор, опишите текущую ситуацию (As Is) и желаемую (To Be). Используйте нотацию BPMN или простые блок-схемы. Это поможет визуализировать потоки данных.
⚠️ Внимание! Никогда не начинайте писать ТЗ без предварительного интервью с конечными пользователями. То, что кажется очевидным директору, может быть непреодолимым барьером для бухгалтера или кладовщика.
Разделите требования на функциональные (что система должна делать) и нефункциональные (как быстро, сколько пользователей, безопасность). Например, требование «отчет должен формироваться не дольше 5 секунд при базе в 100 ГБ» относится ко второму типу.
Используйте скриншоты текущих отчетов из Excel или старых систем. Визуальный ряд сокращает время на понимание задачи программистом в 2 раза.
Структура идеального ТЗ для 1С
Хаотичное описание требований в мессенджере — путь к катастрофе. Документ должен иметь жесткую структуру. Стандарт де-факто включает введение, описание предметной области, сценарии использования и требования к интерфейсу.
В разделе «Описание предметной области» четко определите терминологию. Если вы используете слово «Клиент», уточните: это юридическое лицо, контрагент в базе или конкретный человек? В 1С термины Контрагент, Партнер и Физическое лицо имеют разную техническую реализацию.
Обязательно включите раздел с ограничениями. Укажите, какие конфигурации используются (например, 1С:Бухгалтерия 3.0 или 1С:Управление торговлей 11), и можно ли менять типовые механизмы. Это критически важно для возможности будущих обновлений.
Язык требований: от «хочу» к «должен»
Избегайте эмоциональных окрасок и слов-паразитов. Фраза «сделайте так, чтобы было красивее» не поддается алгоритмизации. Вместо этого пишите: «Расположить поле "Номенклатура" вторым в списке, шрифт жирный, цвет черный».
Используйте императивный стиль или конструкцию «Система должна...». Это убирает двусмысленность. Каждое требование должно быть атомарным — содержать одну законченную мысль.
Для описания логики расчетов используйте псевдокод или формулы. Не пишите «рассчитайте премию по правилам отдела». Распишите формулу: Премия = (Оклад * KPI) - НДФЛ. Программист 1С мыслит категориями регистров и проводок, дайте ему точные вводные.
Вот пример правильной декомпозиции задачи на создание нового вида документа:
- 📄 Определить состав реквизитов шапки документа (Дата, Номер, Склад, Ответственный).
- 📦 Описать структуру табличной части (Товар, Количество, Цена, Сумма, Ставка НДС).
- ⚙️ Установить правила проведения документа (движения по регистрам накопления и бухгалтерии).
- 🖨️ Сформировать печатную форму на основе макета «Накладная ТОРГ-12».
Таблица соответствия полей и логики
Один из лучших способов передать требования — таблица маппинга (соответствия). Она связывает бизнес-сущности с конкретными объектами метаданных 1С. Это снижает риск того, что программист создаст новые справочники там, где можно использовать типовые.
В таблице ниже приведен пример описания нового отчета «Продажи по менеджерам»:
| Поле в отчете | Источник данных (1С) | Тип данных | Алгоритм расчета |
|---|---|---|---|
| Менеджер | Справочник.Пользователи | Ссылка | Выбор из списка активных пользователей |
| Сумма продажи | РегистрНакопления.Продажи.Сумма | Число (15,2) | Сумма по документу «Реализация» за период |
| Валовая прибыль | Вычисляемое поле | Число (15,2) | Сумма продажи минус Себестоимость (из регистра) |
| % выполнения плана | РегистрСведений.ПланыПродаж | Число (5,2) | (Факт / План) * 100 |
Чем детальнее описаны источники данных в ТЗ, тем меньше вопросов возникнет у разработчика в процессе написания кода.
Сценарии использования и тестирование
ТЗ не заканчивается на описании полей. Необходимо описать сценарии использования (Use Cases). Как пользователь попадает в этот раздел? Что происходит при нажатии кнопки? Какие сообщения выводятся при ошибках?
Опишите «счастливый путь» (когда все идет по плану) и обработку исключений. Например: «При попытке провести документ с нулевым количеством система должна выдать сообщение "Ошибка: количество не может быть нулевым" и запретить проведение».
⚠️ Внимание! Обязательно предусмотрите сценарий отката изменений. Если новый механизм сбоит, как быстро можно вернуться к старой версии без потери данных? Это требование должно быть в любом серьезном ТЗ.
Включите в документ раздел «Критерии приемки». Это чек-лист, по которому вы будете принимать работу. Если все пункты чек-листа выполнены — задача считается закрытой. Это защищает от бесконечных правок «по мелочам».
☑️ Критерии приемки задачи
Распространенные ошибки и антипаттерны
Даже опытные постановщики задач часто наступают на одни и те же грабли. Избегайте требования «сделать как в 1С 7.7». Архитектура платформ кардинально отличается, и попытка перенести логику один в один убьет производительность современной 1С:Предприятие 8.3.
Еще одна ошибка — отсутствие приоритетов. Если вы сваливаете в одну кучу 50 требований, программист не поймет, что делать в первую очередь при нехватке времени. Используйте маркировку Must have (обязательно), Should have (желательно) и Nice to have (по возможности).
Не забывайте про права доступа. Кто будет видеть новый отчет? Только директор или все менеджеры? Опишите матрицу прав доступа в самом начале, чтобы не переделывать систему безопасности в конце.
Почему нельзя требовать "быстро и дешево"?
В разработке ПО существует "железный треугольник": быстро, дешево, качественно. Можно выбрать только два параметра. Требование всех трех ведет к созданию нестабильного кода, который придется переписывать через полгода.
Инструменты и шаблоны для написания
Для ведения ТЗ не обязательно использовать сложные системы вроде Jira или Confluence, хотя они удобны для больших команд. Для малых задач достаточно Google Docs или Word с включенным режимом рецензирования.
Главное — версионность. Файл должен называться не «ТЗ_финал.doc», а «ТЗ_ОтчетПродажи_v1.2_2023-10-25.doc». Всегда фиксируйте дату и версию изменений. Это позволит отследить, когда и почему появилось новое требование.
Используйте стандарты ГОСТ 34 или адаптированные под них шаблоны, если работаете с крупными энтерпрайз-заказчиками. Для внутренних задач подойдет упрощенная форма, главное — наличие разделов «Зачем», «Что» и «Как проверить».
⚠️ Внимание! Интерфейсы и возможности платформы 1С регулярно обновляются фирмой «1С». Перед утверждением ТЗ сверьте предполагаемые механизмы реализации с актуальной версией платформы в личном кабинете партнера или официальной документации, чтобы не требовать функционал, который уже устарел или изменился.
Сохраняйте все согласованные ТЗ в отдельной папке с доступом только на чтение для исполнителей. Это предотвратит случайное изменение требований в процессе работы.
Часто задаваемые вопросы (FAQ)
Можно ли изменить ТЗ в процессе разработки?
Да, но это должно оформляться как отдельное дополнение к договору или изменение задачи в трекере. Любое изменение «на лету» без фиксации сдвигает сроки и увеличивает бюджет. Программист должен пересчитать оценку трудозатрат.
Нужно ли описывать дизайн интерфейса в ТЗ для 1С?
Детальный дизайн (цвета, шрифты) описывать не нужно, если это не корпоративный стиль. Достаточно схематичного расположения элементов (wireframe). 1С имеет свои стандарты интерфейса «Такси», которые нарушать не рекомендуется без веских причин.
Кто должен писать ТЗ: заказчик или программист?
Идеальный вариант — совместная работа. Заказчик описывает бизнес-потребность, а системный аналитик или ведущий программист помогает перевести это на технический язык и предлагает оптимальные средства платформы.
Что делать, если программист говорит, что ТЗ невозможно реализовать?
Попросите аргументировать ответ. Часто «невозможно» означает «слишком дорого» или «требует изменения ядра системы». В таком случае нужно искать компромиссное решение, которое закроет бизнес-потребность другим путем.
Сколько страниц должно быть в хорошем ТЗ?
Объем не имеет значения. Простая доработка может уместиться на одной странице, а внедрение нового подсистемы — на пятидесяти. Главное критерий — отсутствие двусмысленностей. Если программист прочитал и понял задачу однозначно — ТЗ хорошее.