Разработчику проще оценить задачу, когда понятно, что сотрудник делает сейчас и что должно измениться. Для небольшой обработки или отчёта достаточно короткого описания, примера данных и ожидаемого результата. Ниже — шаблон и заполненный пример, по которому можно проверить готовую работу.

Это рабочий шаблон DeltaC для небольших доработок. Его можно заполнить в обычном документе; форму договора он не заменяет. Пример описывает новый отчёт для УНФ 3.0 на платформе 8.3, в управляемом приложении и тонком клиенте. Указанные элементы отчёта — пожелания к разработке.

Сначала опишите результат обычными словами

Начните с фразы: «Сотрудник должен получить…». Например: «Менеджер должен видеть свои незавершённые заказы с датой готовности, чтобы утром уточнять задержки». Затем объясните, как он решает эту задачу сейчас и что мешает: открывает заказы по одному, переносит данные вручную или не видит единый список.

Не выбирайте заранее расширение, обработку или изменение основной конфигурации, если это не отдельное ограничение. Сначала согласуйте поведение. Разработчик предложит технический способ с учётом обновлений и поддержки; различия механизмов описаны в отдельной статье.

Разделите обязательное и то, что можно добавить позже. Утренний отчёт для менеджера — одна задача. Автоматическая рассылка клиентам добавляет адреса, расписание, права и обработку ошибок. Лучше обсудить её отдельно, чем оставить в конце фразу «и ещё отправлять».

Шаблон задания

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

  • Конфигурация и версия. Полное название, редакция, релиз конфигурации и платформы, режим клиента, тип размещения, известные доработки.
  • Текущий процесс. Кто выполняет действие, как часто, в какой последовательности и с какими документами.
  • Проблема и результат. Что неудобно или ошибочно сейчас и что должно измениться для пользователя.
  • Входные данные. Источники, обязательные поля, объём, период и искусственный пример.
  • Правила обработки. Отборы, расчёты, сопоставление, порядок действий и приоритет условий.
  • Результат и формат. Колонки, единицы, сортировка, вывод на экран или в файл, допустимые пустые значения.
  • Права пользователей. Кто запускает, что видит, что может изменять; ограничения по организациям и ответственным.
  • Исключения. Нет данных, неизвестное значение, повторный запуск, недоступный объект, ошибка посередине операции.
  • Критерии приёмки. Конкретные входы, ожидаемые строки и суммы, действия проверяющего и условия завершения.

Разделение требований, проектирования и проверки соответствует подходу к сопровождению задач, представленному в системе проектирования прикладных решений 1С. Сам шаблон не требует покупать этот инструмент: его можно заполнить в обычном документе.

Заполненный пример: контроль сроков заказов

Среда. УНФ 3.0, тонкий клиент Windows, локальная тестовая база. Полные номера платформы и конфигурации заказчик берёт из окна сведений о программе. Какие расширения установлены и менялась ли конфигурация, уточняют при обследовании.

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

Входные данные. Заказы, их состояния и сроки готовности. Разработчик проверяет конфигурацию и определяет технические поля. Если дата записана только в свободном комментарии, нужно отдельно решить, как её получать: считать такой источник готовым правилом нельзя.

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

Результат. Требуемые колонки: номер заказа, дата готовности, ответственный и число календарных дней задержки. Сортировка — от наибольшей задержки, затем по номеру. Из строки открывается исходный документ в пределах прав пользователя. Основной результат выводится на экран; отдельный экспорт не требуется.

Контрольный набор

Для проверки возьмём вымышленные заказы на 12 сентября 2026 года. Менеджер А видит только свои записи. Какие состояния в рабочей базе означают завершённый заказ, предстоит согласовать отдельно.

З-101

  • Ответственный: А
  • Готовность: 10.09.2026
  • Завершён: Нет
  • Ожидаемый результат: В списке, задержка 2 дня

З-102

  • Ответственный: А
  • Готовность: 12.09.2026
  • Завершён: Нет
  • Ожидаемый результат: Не задержан, исключён

З-103

  • Ответственный: А
  • Готовность: 09.09.2026
  • Завершён: Да
  • Ожидаемый результат: Исключён как завершённый

З-104

  • Ответственный: Б
  • Готовность: 08.09.2026
  • Завершён: Нет
  • Ожидаемый результат: Не виден менеджеру А

З-105

  • Ответственный: А
  • Готовность: Не задана
  • Завершён: Нет
  • Ожидаемый результат: Отдельная группа без срока

Эти пять заказов помогут проверить границу даты, завершённость и доступ к чужим записям. На одном полностью заполненном документе под администратором такие ошибки легко пропустить.

Права, исключения и приёмка

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

Если подходящих заказов нет, отчёт должен прямо об этом сообщить. Повторное формирование при тех же данных даёт тот же результат и не меняет документы. Неизвестное состояние заказа нужно показать как ошибку настройки и разобрать, а не молча считать заказ незавершённым.

При приёмке сверяем строки с примером: у З-101 задержка два дня, З-104 не виден менеджеру А, З-105 находится в отдельной группе, а документы не изменились. Затем проверяем скорость на рабочем объёме. Допустимое время и условия замера нужно согласовать заранее.

Что влияет на оценку

На оценку влияют состояние данных, объём, права пользователей и доработки, которые уже есть в базе. Запись документов, сложные исключения и поддержка обновлений тоже добавляют работу. Поэтому один ясно описанный отчёт оценить проще, чем общую задачу «автоматизировать продажи».

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

Заполненный шаблон и искусственный пример можно передать через заказ доработки DeltaC. Пароли, полная рабочая база и персональные данные для первого обсуждения не нужны.