Разработка отчётов 1С: 10 типовых ошибок в ТЗ, из за которых вы теряете деньги и сроки

Какие ошибки в ТЗ на отчёт 1С превращают проект в бесконечную доработку: “отчёт на все случаи”, отсутствие MVP, нет примеров, путаница управленческого и бухучёта, размытые критерии готовности. Разбираем последствия и показываем, как избежать каждой ошибки.

Почти каждый «провальный» проект по отчётам в 1С начинается не с плохого программиста, а с плохого ТЗ. В результате:

Ниже – типовые ошибки в ТЗ на отчёт 1С глазами финдиректора/главбуха и руководителей, и что сделать, чтобы их избежать. Для «как писать правильно» у вас уже есть гайд «Как составить ТЗ на отчет в 1С: практический гайд без воды» – здесь фокус именно на анти паттернах.

• Как выглядит в ТЗ:
  • «Хочу один отчёт, который будет показывать всё по продажам/закупкам/складам/марже/долгам сразу».
  • Пунктами перечислено десяток разных задач, часто противоречащих друг другу.

• Чем заканчивается:
  • Получается монстр, в котором:
    • Сложно разобраться пользователям
    • Любая правка ломает что-то другое
    • Скорость формирования падает
    • Проект превращается в бесконечный список доработок
• Как избежать:
  • Разбить задачу на несколько узких отчётов, каждый отвечает на 1–2 управленческих вопроса.
  • Сформулировать вопросы наподобие статей:
    • «Топ 5 отчётов в 1С для директора»
    • «Отчёты в 1С для отдела продаж»
  • По каждому сделать отдельный отчёт или вкладку.

• Как выглядит:
  • В ТЗ сразу заложены:
    • Сложные фильтры
    • Графики, дашборды
    • Сравнение с прошлым годом, план/факт, сценарии, версии
    • Но при этом базовый табличный вид не описан
• Последствия
  • Разработка тянется месяцы: пока не допилят все «фишки», отчёт «нельзя показывать руководству».
  • Вы тратите деньги, а пользу начинаете получать очень поздно.
• Как избежать
  • В ТЗ обязательно выделить:
    • “Срочно нужно” – минимальный набор полей и фильтров, без которых отчёт бесполезен.
    • “Желательно” и “Потом” – доработки на вторую/третью итерацию.
    • Этот подход уже разобран в гайде по ТЗ, здесь важно его зафиксировать и в управленческой постановке задачи.

• Как выглядит:
  • «Сделайте отчёт наподобие того, как мы считаем в Excel» – но Excel файл никто не приложил.
  • Описание уровня: «чтобы всё было понятно и красиво».
• Последствия
  • Разработчик додумывает за вас:
    • Порядок колонок
    • Группировки
    • Особенности расчёта
    • Дальше – длинная серия «а давайте изменим вот это», хотя всё можно было показать одним примером в начале
• Как избежать
  • К ТЗ всегда прикладывать:
    • Tекущие Excel таблицы, пусть даже «кривые»
    • Cкриншоты отчётов, к которым вы привыкли
    • Хоть набросок на листке
    • Это то, о чём прямо сказано в гайде по ТЗ на отчёт: реальные примеры важнее идеальных описаний.

• Как выглядит:
  • В одном ТЗ: «отчёт по прибыли», но:
    • Часть показателей – из бухучёта (по ПБУ/налоговому учёту)
    • Часть – из управленческого (по своим правилам группировки и периодизации)
    • Нет ни слова, какую “версию реальности” считать правильной.
  • Описание уровня: «чтобы всё было понятно и красиво».
• Последствия
  • Отчёты не совпадают с:
    • Бухгалтерской отчётностью
    • Управленческими P&L
    • Руководство теряет доверие к цифрам, проект “проваливается”
• Как избежать
  • В ТЗ отдельно указать:
    • Источники данных (какая база 1С, какие регистры/документы)
    • Принципы учёта: «отчёт управленческий, по нашим правилам», или «должен совпасть с бухгалтерским балансом/ОФР»
    • Если база смешанная – лучше сразу закладывать два разных отчёта, а не один «гибрид»

• Как выглядит:
  • «Покажите продажи в разрезе всего»:
    • По клиентам, товарам, менеджерам, регионам, категориям…
    • Не указано, что такое строка отчёта: заказ? клиент? товар? день?
• Последствия
  • Получается отчёт, который формально всё показывает, но:
    • Сложно читать
    • Тяжело сверять с другими отчётами
    • Плохо работает на больших объёмах
• Как избежать
  • В ТЗ всегда фиксировать:
    • Основной разрез (строка отчёта: клиент, договор, заказ, товар и т.п.)
    • Уровни детализации: основной (например, клиент). Детализация по кнопке «расшифровка» (например, заказы/товары этого клиента).

• Как выглядит:
  • В ТЗ нет чёткого набора требований, по которым можно принять работу:
    • Ни списка полей
    • Ни контрольных отчётов, с которыми сверяться
    • Ни тестовых кейсов
• Последствия
  • Отчёт «никогда не готов»: всегда найдётся ещё одна правка.
  • Подрядчику и внутренней ИТ службе тяжело сказать «мы сделали то, что просили».
• Как избежать
  • К ТЗ добавить:
    • Список ключевых полей и показателей
    • Список отчётов/таблиц для сверки (к чему должны сходиться цифры)
    • 3–5 тестовых сценариев: примеры документов/периодов, по которым вы будете принимать работу

• Как выглядит:
  • Отчёт заказывает директор/финдир, но:
    • С отделом продаж/закупок/склада никто не обсуждал детали
    • Пользователи видят отчёт уже «в бою» и говорят: «так работать неудобно»
• Последствия
  • Много доработок “по вкусу пользователей” уже после внедрения.
  • Сопротивление использованию отчёта.
• Как избежать
  • На этапе ТЗ собрать ожидания ключевых пользователей:
    • Какие разрезы нужны
    • Какие отчёты они уже смотрят
    • Какие вопросы им неудобно решать в текущей системе
  • Можно оформить в виде облегчающего брифа, который можно скачать на странице «Услуги по разработке отчётов 1С».

• Как выглядит:
  • В ТЗ всё выглядит «идеально»: никто не думает о:
    • Пропусках в данных
    • Дырах в истории
    • Изменении учётной политики
• Последствия
  • В процессе разработки всплывают:
    • «А по этим годам у нас был другой план счетов»
    • Тут нет закупочных цен»
    • «До 2022 года НДС считали по другому»
  • Сроки и смета растут.
• Как избежать
  • В ТЗ сразу честно прописать “костыли” и ограничения:
    • По каким периодам отчёт должен работать точно
    • Где допускаются упрощения
    • Какие дыры в данных есть и как с ними жить
  • Этот подход уже отражён в блоке про «костыли» в гайде по ТЗ – важно его не выкидывать ради “красоты”.

• Как выглядит:
  • Основная часть ТЗ – верстка: шрифты, цвета, расположение полей, «хочу как в этом Excel».
  • Структура данных и расчёты описаны вскользь.
• Последствия
  • Много времени уходит на пиксели, а не на смысл.
  • При любом изменении логики приходится переделывать и макет.
• Как избежать
  • Сначала описать:
    • Какие данные и показатели нужны
    • Как они считаются
    • Как ими будут пользоваться (фильтры, расшифровки)
  • Отдельно – пожелания по внешнему виду: «примерное расположение» + образец в Excel/Word.

• Как выглядит:
  • Сначала отчёт задумывался как инструмент для отдела продаж,
  • Через пару недель – как отчёт для директора, ещё позже – как база для KPI/мотивации. Цель эволюционирует, а ТЗ и сроки – нет.
• Последствия
  • Постоянные переделки, конфликт ожиданий и результата.
  • Отчёт либо «умирает», либо превращается в монстра из ошибки №1.
• Как избежать
  • На старте проекта жёстко зафиксировать цель:
    • Кто основной пользователь
    • Какие решения он принимает на основе отчёта
  • Если в процессе задача меняется – честно признать это:
    • Либо оформить новое ТЗ/этап проекта
    • Либо отложить новую цель на вторую итерацию

Перед отправкой ТЗ задай себе несколько вопросов:

Если на часть пунктов ответ «нет» – имеет смысл доработать ТЗ или пройтись по гайду по составлению ТЗ, прежде чем запускать разработку. Так вы с большой вероятностью избежите ситуации, когда отчёт «формально сделали», но его никто не использует – и сэкономите бюджет и время и себе, и разработчикам.