ТЗ для программиста 1С: что уточнить у заказчика до старта доработки

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

Что такое ТЗ для программиста 1С и почему «поправь на копии» без деталей — риск

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

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

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

Структура ТЗ для программиста 1С

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

1. Конфигурация и версия

Какая конфигурация: Управление торговлей, Бухгалтерия, ЗУП, самописная. Какая версия платформы и конфигурации. Облако или коробка. Это первое, что нужно узнать: от этого зависят все возможности доработки.

2. Бизнес-процесс

Какой процесс затрагивает доработка: как он работает сейчас и как должен работать после. Кто участвует, какие действия выполняет. Понимание процесса защищает от доработки, которая ломает смежные участки.

3. Объекты учёта

Какие документы, регистры, справочники и реквизиты участвуют. Что добавляется, что меняется. Это техническая основа: без перечня объектов доработка будет неточной.

4. Условия и алгоритм доработки

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

5. Печатные формы и отчёты

Нужно ли менять печатные формы или добавлять отчёты. Какие поля и в каком виде выводить. Приложите пример желаемого результата, если есть.

6. Миграция и тестирование

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

7. Приёмка

Как принимается работа: кто проверяет, по каким сценариям, в какой среде. Учтено ли влияние на будущие обновления конфигурации — это важно обсудить заранее.

Раздел ТЗ: что писать и частые ошибки

Мини-пример: фрагмент ТЗ на доработку 1С

Чтобы было понятнее, вот как может выглядеть реальный фрагмент ТЗ на доработку:

Конфигурация: Управление торговлей 11.5, коробка. Облако не используется.

Процесс: менеджер проводит «Заказ клиента», сейчас система не проверяет остатки, из-за чего продают отсутствующий товар.

Алгоритм: при проведении документа «Заказ клиента» контролировать остаток по складу «Основной». Если остаток меньше нуля — не проводить документ и выводить сообщение с названием товара и недостающим количеством.

Объекты: документ «Заказ клиента», регистр остатков, справочник «Склады».

Тестирование: на копии базы провести заказ с достаточным и недостаточным остатком, проверить проведение и сообщение.

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

Такое ТЗ позволяет сразу понять объём и проверить доработку на копии, не трогая рабочий учёт.

Что уточнит хороший программист 1С

Если вам прислали «надо доработать», не начинайте сразу. Задайте вопросы — это защита от сломанного учёта:

• Какая конфигурация и версия, облако или коробка?
• Используется ли типовой функционал или конфигурация сильно доработана?
• Какой процесс меняем и каков алгоритм «как есть» и «как будет»?
• Есть ли тестовая база и какие сценарии использовать для проверки?
• Кто и как будет принимать результат?
• Как доработка повлияет на будущие типовые обновления?

Зафиксируйте ответы в переписке заказа. На Workink такая переписка имеет силу ТЗ — договорённости, достигнутые в чате, защищают обе стороны.

Чек-лист до старта доработки

• Известны конфигурация и версия.
• Понятно, типовой функционал или доработанный.
• Есть тестовая база для проверки.
• Описан процесс и условия доработки.
• Согласован однозначный алгоритм.
• Определён порядок приёмки и проверяющий.
• Учтено влияние на будущие обновления.

Если хотя бы на два пункта нет ответа — сначала уточните, потом приступайте. Так вы не сломаете учёт и обновления.

Что дальше

Хорошее ТЗ защищает учёт заказчика и ваше время, вторая половина успеха — надёжный исполнитель. На Workink заказчик и программист 1С фиксируют договорённости в чате заказа — такая переписка имеет силу ТЗ, а деньги защищены безопасной сделкой до приёмки. Комиссия — 11% за заказ и 0% за вывод.

Зарегистрируйтесь на Workink — берите заказы на 1С или публикуйте свою задачу в категории «Разработка и IT». А чтобы взглянуть на задачу глазами заказчика или углубиться в смежные темы, пригодятся гайды «ТЗ для 1С: как описать доработку и автоматизацию» и «ТЗ для программиста: что дать и что уточнить».