Как описать требования клиента для автоматизации 1С

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

Главная проблема при сборе требований — разрыв между языком бизнеса и языком разработки. Клиент говорит «менеджер должен видеть задолженность», а разработчику нужно знать: какую именно задолженность (по договорам, по заказам, по актам), на какую дату, с какой детализацией, в какой конфигурации и в каком разделе интерфейса это должно отображаться. Задача того, кто описывает требования, — перевести пожелания в конкретные, проверяемые формулировки.

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

Подготовка: что узнать до написания требований

До первой встречи с клиентом соберите исходные данные о текущем состоянии учёта. Уточните, какая конфигурация 1С используется (или планируется к внедрению), типовая она или доработанная, какой релиз, сколько пользователей работает одновременно и ведётся ли учёт в нескольких базах. Эти сведения определяют технические рамки: например, доработка типовой конфигурации с сохранением поддержки и правка сильно изменённой базы — принципиально разные объёмы работ.

Определите круг участников со стороны клиента. Понадобятся: владелец процесса (принимает решения и подписывает результат), ключевые пользователи (рассказывают, как работают на самом деле) и представитель руководства, который оплачивает проект. Частая ошибка — собирать требования только у руководителя: он описывает процесс «как должно быть», а реальная работа отличается, и внедрение упирается в сопротивление пользователей.

Зафиксируйте цель автоматизации в измеримом виде. «Ускорить оформление заказов» — не цель, а пожелание. «Сократить время оформления заказа с 15 до 5 минут» — цель, по которой можно проверить результат. Если клиент не может сформулировать измеримую цель, это сигнал, что задача пока не готова к автоматизации и требует предварительного обследования.

Как проводить интервью с клиентом

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

Используйте уточняющие вопросы-рамки: что происходит до этого шага, что после, кто отвечает, что делать при ошибке, как часто возникает исключительная ситуация. Отдельно фиксируйте частные случаи: возвраты, частичные оплаты, работу с несколькими организациями, отрицательные остатки. Именно исключения, забытые при описании, порождают большинство доработок после запуска.

Записывайте интервью (с согласия участников) или ведите подробный протокол. После встречи в течение одного-двух дней оформляйте заметки в структурированный документ, пока контекст не потерян. Спорные формулировки выносите в список открытых вопросов и согласовывайте отдельно — не додумывайте за клиента.

Просите клиента показать реальные документы и отчёты, которыми он пользуется сейчас: Excel-файлы, распечатки, выгрузки из старой системы. Один реальный образец отчёта заменяет страницу словесного описания и снимает большинство споров на приёмке.

Структура документа с требованиями

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

Четвёртый блок — функциональные требования: конкретные сценарии работы в формате «пользователь делает X → система выполняет Y». Пятый — отчёты и печатные формы с образцами. Шестой — нефункциональные требования: количество одновременных пользователей, допустимое время формирования отчёта, требования к резервному копированию и разграничению доступа.

Каждое требование нумеруйте и формулируйте так, чтобы его можно было проверить. Плохо: «система должна быстро формировать отчёт». Хорошо: «отчёт "Продажи по менеджерам" за произвольный месяц формируется не дольше 30 секунд при объёме базы до 500 тысяч документов». Вторую формулировку можно протестировать и принять, первую — нет.

1. 1
   Опишите текущий процесс «как есть» со слов ключевых пользователей
2. 2
   Зафиксируйте целевой процесс «как должно быть» и согласуйте с владельцем процесса
3. 3
   Перечислите роли, права и данные, необходимые для каждого шага
4. 4
   Сформулируйте проверяемые функциональные требования с номерами
5. 5
   Приложите образцы отчётов и печатных форм
6. 6
   Определите критерии приёмки и порядок тестирования

Как формулировать сценарии и критерии приёмки

Для каждого сценария описывайте три части: начальные условия, действия пользователя и ожидаемый результат системы. Например: «Условие: у контрагента есть неоплаченный счёт с просроченным сроком оплаты. Действие: менеджер открывает форму создания нового заказа для этого контрагента. Результат: система выводит предупреждение о задолженности с суммой и датой просрочки, создание заказа не блокируется, но в журнале фиксируется отметка».

Критерии приёмки оформляйте отдельным разделом: по каким сценариям будет проводиться тестирование, кто со стороны клиента участвует, на каких данных (тестовая копия базы или реальные документы), какой срок отводится на проверку и как фиксируются замечания. Согласованные критерии приёмки защищают обе стороны: разработчика — от бесконечных «а сделайте ещё», клиента — от сдачи неработающего решения.

Отдельно опишите, что не входит в объём работ. Раздел «вне рамок проекта» снимает большинство конфликтов: например, «перенос исторических данных за периоды ранее двух лет не выполняется» или «интеграция со складским терминалом реализуется отдельным этапом».

Типовые ошибки при описании требований

Самая распространённая ошибка — описание решения вместо задачи. Клиент пишет «добавьте кнопку в форму заказа», хотя реальная задача — ускорить проверку остатков, и её можно решить иначе, без лишних доработок. Формулируйте проблему и желаемый результат, а выбор технического решения оставляйте специалисту по внедрению.

Вторая ошибка — игнорирование исключений. Описан «счастливый путь»: заказ создан, оплачен, отгружен. Но не описаны возвраты, частичные отгрузки, отмены и корректировки, которые в реальной работе составляют заметную долю операций. Третья ошибка — отсутствие приоритетов. Когда все требования помечены как «критичные», подрядчик не может предложить поэтапный план, и проект растягивается.

Проверка полноты и согласование документа

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

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

Контрольные точки

Как проверить документ с требованиями

Проверяемость формулировок

Норма

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

Тревожный признак

Слова «удобно», «быстро», «интуитивно» без измеримых критериев

Полнота сценариев

Норма

Описаны основной путь и исключения: возвраты, отмены, ошибки

Тревожный признак

Описан только идеальный ход процесса

Образцы отчётов

Норма

К каждому отчёту приложен макет или реальный пример

Тревожный признак

Отчёт описан одной фразой «как в Excel»

Согласование

Норма

Документ подтверждён пользователями и владельцем процесса письменно

Тревожный признак

Требования согласованы только устно с руководителем

Частые вопросы

Кто должен писать требования — клиент или внедренец?

Оптимальный вариант — совместная работа: клиент описывает процессы и цели, специалист по внедрению структурирует их в проверяемые требования. Если клиент пишет документ сам, внедренец должен провести ревизию и задать уточняющие вопросы до оценки работ.

Насколько подробным должен быть документ?

Достаточно подробным, чтобы по нему можно было оценить трудоёмкость и принять результат. Для небольшой доработки хватает 3–5 страниц со сценариями и образцами; для проекта внедрения документ будет больше, но детализация всё равно должна оставаться на уровне «что должна делать система», а не «как писать код».

Что делать, если требования меняются в ходе проекта?

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

Можно ли использовать готовые шаблоны технического задания?

Да, шаблон полезен как чек-лист разделов: процесс, роли, данные, сценарии, отчёты, интеграции, критерии приёмки. Но содержание всегда индивидуально — копирование чужого ТЗ без адаптации под реальные процессы клиента приводит к тем же проблемам, что и отсутствие документа.

Нужно ли описывать требования для небольшой доработки?

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