Как подготовить ТЗ на доработку 1С, чтобы избежать ошибок и переделок

1. Кто должен готовить ТЗ, чтобы избежать ошибок и переделок

Первый и самый распространённый вопрос: кто вообще должен писать ТЗ — бизнес или ИТ?

Правильный ответ: зависит от задачи.

Чтобы не ошибиться, нужно сначала ответить на два ключевых вопроса:

• какую проблему мы решаем;
• кто отвечает на вопрос «как это должно работать».

Рассмотрим основные сценарии.

1.1. Чем вызвана доработка

Все доработки 1С условно можно разделить на три типа:

1. Программная ошибка (что-то не работает, падает, считает неправильно).
2. Новые функциональные требования бизнеса (появились новые процессы, отчёты, правила).
3. Оптимизация работы системы (медленно работает, много ручных операций, неудобный интерфейс).

От этого напрямую зависит, кто формирует ТЗ и в каком виде.

1.2. Программная ошибка: ТЗ от ИТ-специалиста

Если проблема носит технический характер:

• ошибка в коде,
• некорректная обработка данных,
• сбой после обновления,

— ТЗ должен готовить ИТ-специалист.

Почему:

• бизнес чаще всего не знает, где именно ошибка;
• попытка описать «как должно быть» без понимания архитектуры приводит к неверным требованиям;
• ИТ-специалист способен корректно зафиксировать:
  • условия возникновения ошибки,
  • ожидаемое поведение,
  • сценарии проверки.

В этом случае бизнес участвует как источник фактов, а не как автор ТЗ.

1.3. Новые функциональные требования: ТЗ от бизнес-заказчика

Если доработка связана с:

• новыми отчётами,
• изменением логики работы,
• новыми правилами учёта,
• новыми ролями и процессами,

— инициатором и автором ТЗ должен быть бизнес-заказчик.

Важно: бизнес не обязан описывать "как программировать".

Его задача — чётко сформулировать:

• что должно быть сделано;
• зачем это нужно;
• как понять, что задача выполнена правильно.

Хорошее бизнес-ТЗ всегда содержит:

• описание текущей ситуации;
• желаемый результат;
• критерии приёмки (что именно будем проверять).

1.4. Оптимизация работы: совместная работа бизнеса и ИТ

Если цель — ускорить работу, сократить ручной труд, повысить удобство, ситуация сложнее.

Здесь:

• бизнес формулирует желаемый результат (быстрее, меньше действий, меньше ошибок);
• ИТ-специалисты и системные администраторы предлагают решение (архитектура, доработки, настройки, инфраструктура).

Например:

• бизнес говорит: «Документ проводится 5 минут — это недопустимо»;
• ИТ определяет, почему это происходит и как оптимизировать.

Попытка переложить этот тип задач только на бизнес или только на ИТ почти всегда приводит к ошибкам.

2. ТЗ — не догма, а рабочий направляющий документ

Одна из самых частых ошибок — воспринимать ТЗ как «раз и навсегда утверждённый документ».

На практике ТЗ должно быть:

• настольным документом для исполнителей;
• ориентиром и напоминанием для бизнес-заказчика.

В процессе реализации почти всегда возникают:

• уточняющие вопросы;
• альтернативные решения;
• ограничения платформы;
• идеи, как сделать лучше.

Правильный подход:

• все вопросы обсуждаются при открытом ТЗ;
• договорённости фиксируются;
• изменения отражаются в новой версии ТЗ.

Это позволяет:

• избежать споров «мы так не договаривались»;
• сохранить прозрачность решений;
• обеспечить единое понимание результата.

Вывод

Грамотное ТЗ — это не бюрократия и не формальность. Это инструмент управления результатом.

Почему это важно:

• при обновлении 1С доработки могут конфликтовать с типовым функционалом;
• без ТЗ невозможно понять, зачем была сделана конкретная логика;
• при смене подрядчика или специалиста система превращается в «чёрный ящик».

Чтобы избежать ошибок и переделок:

• определяйте тип задачи до начала работ;
• разделяйте зоны ответственности бизнеса и ИТ;
• используйте ТЗ как живой рабочий документ;
• связывайте доработки с версионностью 1С.

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

✅ Чек-лист: как подготовить ТЗ на доработку 1С без ошибок и переделок

Используйте этот чек-лист перед передачей задачи в разработку или подрядчику.

1️⃣ Определите тип задачи (обязательно)

Перед началом работ ответьте на вопрос: почему нужна доработка?

• Программная ошибка
• Новые функциональные требования бизнеса
• Оптимизация работы системы (скорость, удобство, ручные операции)

От этого зависит, кто готовит ТЗ и в каком объёме.

2️⃣ Определите ответственного за ТЗ

• Если ошибка программная — ТЗ готовит ИТ-специалист
• Если нарушена логика работы с данными — бизнес-заказчик
• Если новый функционал — бизнес-заказчик
• Если оптимизация — бизнес формулирует цель, ИТ предлагает решение
• Назначен один ответственный за финальное согласование ТЗ

3️⃣ Зафиксируйте исходные данные

• Конфигурация 1С (УТ, КА, ERP и т.д.)
• Версия платформы и конфигурации
• Типовая или доработанная конфигурация
• Есть ли другие доработки, связанные с задачей
• Среда выполнения (сервер, количество пользователей, нагрузка)

4️⃣ Опишите текущую ситуацию («как сейчас»)

• Что именно не работает / работает неудобно
• В каких документах, отчётах, процессах
• Кто сталкивается с проблемой (роль пользователя)
• При каких условиях возникает проблема
• Есть ли примеры (скриншоты, данные, сценарии)

5️⃣ Опишите желаемый результат («как должно быть»)

• Что пользователь должен видеть в системе
• Какой результат должен получаться на выходе
• Что изменится в процессе работы
• Какие действия должны исчезнуть / упроститься
• Есть ли ограничения (регламенты, требования учёта)

⚠️ Важно: не описывайте «как программировать» — описывайте результат.

6️⃣ Зафиксируйте критерии приёмки (обязательно!)

• По каким признакам задача считается выполненной
• Какие сценарии нужно проверить
• Какие данные использовать для проверки
• Кто принимает результат
• Что считается ошибкой

Если критерии приёмки не описаны — задача гарантированно будет понята по-разному.

7️⃣ Учтите влияние на другие участки системы

• Влияет ли доработка на другие документы или отчёты
• Влияет ли на регламентированный учёт
• Есть ли риск при обновлении 1С
• Нужно ли тестирование в копии базы
• Нужно ли обучение пользователей

8️⃣ Зафиксируйте версионность и изменения

• У ТЗ есть версия и дата
• Все изменения в ходе обсуждений зафиксированы
• Понятно, в какой версии 1С реализуется доработка
• Старая версия ТЗ сохранена
• Есть финальная согласованная версия

9️⃣ Проверьте ТЗ перед запуском в работу

Перед стартом работ убедитесь:

• ТЗ прочитано бизнесом и ИТ
• Нет противоречий
• Понятен результат
• Понятны критерии проверки
• Назначены ответственные лица

Итоговое правило

Хорошее ТЗ отвечает на вопросы "зачем", "что" и "как проверить".
Плохое ТЗ — только на вопрос "сделайте что-нибудь".