Опишите не способ программирования, а проверяемый результат
Для первого обращения достаточно объяснить, что происходит сейчас, что должно измениться и как ответственный сотрудник проверит результат. Программисту также нужны название программы, редакция и релиз, примеры данных, правила работы и известные исключения.
Не обязательно самостоятельно выбирать расширение, объекты конфигурации или технический способ реализации. Это определяют после изучения задачи и состояния базы.
Шаблон описания задачи
- Программа и версия. Название конфигурации, редакция, релиз и версия платформы, если они известны.
- Текущая ситуация. Какие действия выполняет пользователь и какой результат получает сейчас.
- Желаемый результат. Что должно появиться или измениться после выполнения задачи.
- Пользователи и сценарии. Кто будет работать с изменением, когда и в какой последовательности.
- Правила и исключения. Условия расчёта, отбора, доступа или выполнения действия, включая нестандартные случаи.
- Примеры. Скриншоты с пометками, образцы Excel или PDF, документы, отчёты, обезличенные данные либо последовательность действий для воспроизведения.
- Критерии проверки. Конкретные примеры, по которым ответственный сотрудник примет результат.
- Связанные изменения. Известные расширения, внешние обработки, интеграции и нетиповой код.
Короткий пример
Сейчас: менеджер вручную собирает просроченные заказы из нескольких штатных отчётов.
Нужно: получить один отчёт со списком заказов, сроком оплаты, ответственным и суммой долга.
Правила: показывать только неоплаченные заказы с истёкшим сроком; отменённые заказы не включать.
Проверка: результат должен совпасть с перечнем из пяти приложенных контрольных заказов.
Такое описание не заменяет техническую оценку, но помогает быстрее определить границы задачи и список уточняющих вопросов.
Что происходит при неточном описании
- Перед оценкой требуется больше уточнений, потому что одинаковая формулировка может означать разные результаты.
- Часть исключений обнаруживается только при проверке, если их не показали на исходных примерах.
- Оценка становится менее определённой, когда неизвестны границы задачи и состояние базы.
- Если критерии приёмки меняются после начала разработки, появляется новый объём, который нужно согласовывать отдельно.
Хорошее описание не гарантирует отсутствие технических вопросов, но отделяет исходную задачу от новых пожеланий и позволяет проверять результат по заранее понятным примерам.
Что делать, если требования ещё не согласованы
Если сотрудники по-разному понимают результат, неизвестны правила или нельзя определить критерии приёмки, сначала согласуйте их внутри организации. При необходимости АБИС может помочь с подготовкой технического задания на доработку 1С. Это не обязательный этап для каждой небольшой задачи.
Готовое описание можно передать программисту 1С для технической оценки. Не отправляйте рабочие пароли и конфиденциальные данные в обычной переписке; порядок доступа к базе согласовывается отдельно.