Как написать техническое задание для разработчика 1С
Содержание
Грамотное ТЗ для программиста 1С — это документ, где вы описали не «что хочется», а что должно происходить в базе: какой документ, по какой кнопке, с какими данными и каким результатом. Чем точнее формулировки, тем меньше правок и споров на приёмке.
Минимальный рабочий состав: цель доработки, как процесс устроен сейчас, что нужно получить, где в интерфейсе это появится, по каким данным считать и как вы проверите готовую работу. Если эти шесть блоков закрыты — исполнителю есть от чего оттолкнуться, а вам есть что принять.
Ниже — как собрать такое техническое задание по шагам, из каких разделов его сложить и на чём чаще всего спотыкаются постановщики.
С чего начать: опишите процесс «как есть»
Перед тем как формулировать доработку, зафиксируйте текущий порядок работы. Разработчик не сидит в вашей бухгалтерии и не знает, кто какой документ заводит и в какой последовательности.
Опишите цепочку по шагам: кто инициирует операцию, какой документ создаёт, что заполняет вручную, что подтягивается автоматически. Укажите конфигурацию и примерную версию релиза — поведение 1С:Бухгалтерии и 1С:УТ в одной и той же ситуации различается.
Отдельно отметьте, что именно не устраивает. Три частые формулировки боли:
- 🔁 действие делается руками, хотя могло бы считаться автоматически;
- ❌ система позволяет провести документ с ошибкой, которую ловят уже в отчётности;
- 📄 нужной печатной формы или колонки в отчёте просто нет.
Соберите реальные примеры: номера документов, скриншоты форм, выгрузку в Excel «как есть» и «как надо». Один конкретный пример экономит исполнителю час догадок.
Если доработка затрагивает учёт, проговорите её с бухгалтером до написания ТЗ. Техническое решение, которое ломает методологию, формально «работает», но пользоваться им нельзя.
Полезно сразу обозначить, на каком объекте всё строится: документ, справочник, регистр сведений
или накопления. Разработчик по названию объекта понимает, где искать и что менять. «Нужно хранить лимит по контрагенту» и «добавить реквизит
в справочник Контрагенты» — формулировки разной полезности, и вторая экономит время обеих сторон.
Из каких разделов состоит техническое задание
Единого ГОСТ-шаблона под доработку 1С нет, да он и не нужен для большинства задач. Рабочая структура документа укладывается в семь разделов.
| Раздел | Что в нём |
|---|---|
| Цель и контекст | зачем доработка, какую проблему закрывает |
| Текущий процесс | как всё устроено сейчас, «как есть» |
| Требования | что должно происходить после доработки |
| Данные | какие справочники, реквизиты, регистры затрагиваются |
| Интерфейс | где появятся кнопки, поля, печатные формы |
| Ограничения | права доступа, нагрузка, сроки |
| Приёмка | как вы проверите, что работа сделана |
Для мелкой правки (добавить колонку в отчёт) хватит пары абзацев по этой схеме. Для интеграции с внешней системой каждый раздел развернётся на страницу.
Не смешивайте в одном ТЗ несвязанные задачи. Три разные доработки — три документа или хотя бы три чётко разделённых блока с отдельной приёмкой по каждому.
Пронумеруйте требования. Ссылаться на «пункт 3.2» на приёмке и в переписке в разы удобнее, чем на «ну там, где про печатную форму».
Как описать функциональные требования и логику
Это ядро задания. Здесь вы отвечаете на вопрос «что система должна делать», максимально конкретно.
Пишите требования через сценарий: условие → действие → результат. Не «сделать проверку контрагента», а так:
- При проведении документа
Реализациясистема проверяет, заполнен ли у контрагента ИНН . - Если ИНН пустой — проведение блокируется, выводится сообщение с текстом ошибки.
- Если заполнен — документ проводится как обычно.
Обязательно опишите граничные случаи и что делать при них:
- 🔸 данных нет или они пустые — что показать пользователю;
- 🔸 значение выходит за ожидаемый диапазон (отрицательная сумма, дата из будущего);
- 🔸 одновременно выполняются оба условия, под которые есть разные правила.
Для расчётных задач приведите формулу и числовой пример с ответом. Фраза «посчитать скидку по правилам компании» бесполезна. «Скидка = 5% при сумме заказа от 50 000 ₽, 10% — от 100 000 ₽; на заказ 120 000 ₽ скидка 12 000 ₽» — исполнимо и проверяемо.
Если доработка меняет проведение документа или движения по регистрам, это нужно указать прямо. Молчаливое изменение проводок всплывёт при закрытии месяца, и виноватым окажется тот, кто писал ТЗ.
Укажите, откуда берутся данные для расчёта и куда записывается результат. Для каждого значения назовите источник: реквизит шапки, колонку табличной части, ресурс регистра, константу. Если число должно где-то сохраниться после проведения — скажите, в какой реквизит или регистр. Иначе исполнитель посчитает верно, но результат «повиснет» и в отчёт не попадёт.
Отдельно договоритесь, где живёт доработка: во внешней обработке, в расширении конфигурации или в основной конфигурации. Расширение не слетает при типовом обновлении — для поддерживаемых баз это почти всегда предпочтительнее правок в основной конфигурации.
Что писать про формы, кнопки и печать
Исполнитель должен понять, где пользователь столкнётся с доработкой. Опишите интерфейсную часть отдельным блоком.
По каждому новому элементу укажите:
- 📍 Место. На какой форме и в каком её разделе появится кнопка, поле или команда. Назовите форму документа или справочника, а не абстрактный «нужный раздел».
- 🏷️ Подпись. Точный текст на кнопке и заголовок поля — так, как он должен выглядеть на экране.
- ⚙️ Поведение. Что происходит по нажатию: открывается форма, печатается документ, заполняется таблица.
Для печатных форм приложите макет — хотя бы собранный в Word или Excel. Укажите, какие поля откуда берутся: «Покупатель» → наименование контрагента из шапки, «Сумма прописью» → итог по табличной части.
Про эргономику стоит сказать прямо, если это важно: что заполняется по умолчанию, какой реквизит становится обязательным, в каком порядке пользователь переходит по полям. Мелочь вроде автозаполнения даты экономит оператору секунды на каждом документе, а за смену это заметная цифра.
Если доработка добавляет отчёт, опишите его макет через набор колонок и группировок: что в строках, что в колонках, по каким полям итоги. «Отчёт по продажам в разрезе менеджеров с итогами по месяцам» исполним сразу; «удобный отчёт по продажам» — нет.
Не требуйте «сделать красиво и удобно». Это не проверяемо и на приёмке превратится в спор. Либо опишите конкретное поведение, либо оставьте внешний вид на усмотрение исполнителя — но тогда не предъявляйте претензий к оформлению.
Нагрузка, права доступа и безопасность
Эти требования называют нефункциональными: они не про конкретную кнопку, а про условия, в которых доработка живёт.
Права доступа . Укажите, кому доступна новая функция. Если кнопку должен видеть только бухгалтер, а рядовой менеджер — нет, это требование, а не само собой разумеющееся. Назовите роли или профили групп доступа, под которые настраивать видимость.
Объём данных. Напишите, на каких объёмах работает доработка. Отчёт по 100 документам и по 2 млн строк регистра — это разный код. Если обработка перебирает всю базу при каждом проведении, на большой базе она встанет.
Фоновое выполнение. Для тяжёлых операций (массовый пересчёт, выгрузка за год) оговорите, что они идут фоновым заданием и не блокируют пользователя.
Безопасность и обмен данными. Для интеграций с внешними системами опишите, что и куда передаётся, как хранятся пароли и токены, что делать при недоступности сервиса.
Персональные данные (ФИО, паспорта, зарплаты) нельзя просто так выгружать в тестовую базу или на сторонний сервер. Если доработка касается таких данных, пропишите, как они обезличиваются или защищаются.
Логирование. Для критичных операций полезно требование вести журнал: кто, когда и что изменил. На разборе спорной ситуации такой журнал закрывает вопрос за минуту.
Поведение при сбое. Опишите, что система делает, если операция прервалась на середине: откатывает изменения целиком или оставляет частичный результат. Для обменов и массовых обработок это принципиально — половина выгруженных данных часто хуже, чем ничего.
Как принять работу: тестирование и приёмка
Раздел, который чаще всего забывают, — а именно он защищает обе стороны. Пока не описано, как проверяется результат, «готово» остаётся вопросом вкуса.
Сформулируйте критерии приёмки как проверяемые факты. Не «отчёт работает корректно», а конкретика:
- ✅ при сумме заказа 120 000 ₽ в колонке «Скидка» выводится 12 000 ₽;
- ✅ документ с пустым ИНН контрагента не проводится и показывает сообщение;
- ✅ выгрузка за месяц формируется не дольше 30 секунд на тестовой базе.
Договоритесь о порядке проверки:
- Исполнитель тестирует доработку на копии вашей базы, а не на «сферической» демо-базе.
- Готовое решение вы проверяете на тестовой копии, а не сразу в рабочей.
- В рабочую базу доработка попадает только после вашего подтверждения.
Обязательно прогоните негативные сценарии: пустые поля, нули, отрицательные суммы, закрытый период. Доработки чаще ломаются на нестандартных данных, чем на обычных.
Полезно вести короткий протокол тестирования: список критериев приёмки и напротив каждого отметку «проверено / замечание». По такому списку видно, что осталось, и приёмка не превращается в бесконечное «вроде работает, но давайте ещё посмотрим».
Отдельно пропишите, что считается гарантийным исправлением (ошибка относительно ТЗ — правит исполнитель бесплатно), а что — новой задачей (вы захотели иначе, чем было в ТЗ, — это доработка за отдельную оплату). Эта граница снимает большинство конфликтов на финальном этапе.
Ошибки, из-за которых ТЗ переделывают
Разберём, что превращает задание в источник правок и переплат. Это не повтор шагов выше, а типовые промахи постановщиков.
- 🚫 Решение вместо задачи. «Добавьте реквизит X в документ Y» — а по-настоящему нужно было автоматически подставлять склад. Описывайте проблему и цель, способ пусть предложит исполнитель.
- 🚫 «И так понятно». Очевидное для вас не очевидно для того, кто не работает в вашей базе. Что не написано — то не сделано.
- 🚫 Нет граничных случаев. Логика описана только для идеального сценария. Дальше начинается импровизация исполнителя, и почти всегда не в вашу пользу.
- 🚫 Размытая приёмка. Без измеримых критериев «готово» определяется настроением сторон.
- 🚫 Растущие требования. В процессе добавляются новые «мелочи» без фиксации. Либо оформляйте их письменно с пересмотром срока, либо выносите в следующий этап.
- 🚫 Правки в основной конфигурации без причины. Для поддерживаемой базы это боль при каждом обновлении. Если задача решается расширением — требуйте расширение.
Хорошее ТЗ не обязано быть длинным. Оно обязано быть однозначным: прочитав его, и вы, и исполнитель одинаково представляете результат. Если по документу расходятся два толкования — переписывайте спорный пункт, пока толкование не останется одно.