Обследование без путаницы в требованиях: как собрать понятную картину процесса
Обследование в 1С-проектах часто начинается достаточно просто. Есть встреча с пользователями, есть описание процесса, есть первые заметки и ощущение, что задача понятна.
Но после первой встречи обычно появляются уточнения. Один участник вспоминает исключения. Другой говорит, что в его подразделении процесс работает немного иначе. Руководитель описывает процесс крупными шагами, а пользователи рассказывают много деталей. В итоге становится сложнее понять, что именно нужно автоматизировать.
Если не держать структуру, требования быстро начинают расходиться по разным местам: часть остается в заметках, часть в почте, часть в мессенджере, часть в голове у аналитика. Разработчик при этом может получить задачу, в которой не хватает важных деталей.
Поэтому обследование лучше проводить не как свободный разговор, а как последовательный сбор информации. Нужно отдельно зафиксировать процесс, участников, данные, исключения, сроки и открытые вопросы.
В статье разберем, что стоит собирать на обследовании, как не потерять важные детали и как получить результат, с которым дальше удобно работать аналитикам, разработчикам и заказчику.
Почему требования начинают путаться
Проблемы с требованиями редко появляются случайно. Обычно у них есть понятные причины.
1. Разные участники по-разному описывают один процесс
Один и тот же процесс может выглядеть по-разному для разных сотрудников.
Например, руководитель говорит: “Нужно согласование документа”. Пользователь называет это “отправить на подпись”. Юрист говорит про проверку рисков. Делопроизводитель — про регистрацию. ИТ-команда — про маршрут, роли и задачи в 1С.
Все говорят об одном процессе, но каждый описывает свою часть. Если это не собрать в общую схему, требования будут неполными.
2. Сразу обсуждают решение, а не процесс
На обследовании часто быстро переходят к интерфейсу: какие кнопки добавить, какие поля вывести, какой отчет сделать, куда поставить флажок.
Это не всегда плохо, но есть риск начать проектировать решение до того, как понятен сам процесс.
Сначала нужно понять:
- какая задача решается;
- кто участвует в процессе;
- что является началом и концом процесса;
- какие данные нужны;
- какие есть исключения.
Только после этого стоит обсуждать, как именно это будет выглядеть в 1С.
3. Исключения вспоминают поздно
На первой встрече процесс часто выглядит простым. Но позже появляются дополнительные условия:
- срочные случаи;
- нестандартные контрагенты;
- особый порядок согласования;
- документы без типового маршрута;
- возвраты на доработку;
- замещение отсутствующих сотрудников;
- ручные действия, которые пока не описаны.
Если такие случаи не собрать на этапе обследования, они появятся уже во время постановки, разработки или тестирования. Тогда придется менять согласованные требования.
4. Информация хранится в разных местах
Еще одна частая проблема — отсутствие единого места, где хранится рабочая версия требований.
Например:
- схема процесса лежит в одном файле;
- комментарии заказчика — в почте;
- уточнения — в мессенджере;
- открытые вопросы — в личных заметках аналитика;
- разработчику передали только часть информации.
В такой ситуации легко потерять важную деталь или начать работать по устаревшей версии.
Требования становятся понятнее, когда у процесса есть единое описание, единый список вопросов и единое место хранения материалов.
Что нужно собрать на обследовании
Хорошее обследование должно давать не просто набор заметок, а понятную структуру. Для 1С-проектов обычно важно собрать несколько блоков.
1. Граница процесса
Сначала нужно определить, где процесс начинается и где заканчивается.
Не стоит ограничиваться общей фразой “согласование документов”. Лучше зафиксировать конкретнее:
- что запускает процесс;
- кто его запускает;
- какой документ или событие является началом;
- какой результат считается завершением.
Примеры начала процесса:
- входящий документ поступил в организацию;
- договор подготовлен и отправлен на согласование;
- создана заявка на оплату;
- служебная записка передана на рассмотрение;
- кадровый документ запущен в работу.
Если границы не определить, обсуждение легко уйдет в смежные процессы, отчеты, интеграции и будущие доработки.
2. Участники и роли
На обследовании важно понять, кто участвует в процессе и какую роль выполняет каждый участник.
Лучше фиксировать не только фамилии, но и роли:
- инициатор;
- согласующий;
- проверяющий;
- подписант;
- исполнитель;
- контролер;
- замещающий;
- администратор процесса.
Это помогает не привязывать требования только к конкретным сотрудникам. Сотрудники могут меняться, а роли в процессе остаются.
3. Документы и данные
В 1С-проектах данные часто оказываются не менее важными, чем сам процесс.
На обследовании нужно понять:
- какие документы участвуют в процессе;
- какие реквизиты обязательны;
- откуда берутся данные;
- какие справочники используются;
- кто отвечает за заполнение данных;
- есть ли дубли или неактуальные элементы НСИ;
- какие данные нужны для отчетов и контроля.
Иногда требование кажется сложным, хотя настоящая проблема находится в данных. Например, нет единого правила заполнения контрагента, подразделения, статьи затрат, вида документа или ответственного.
4. Исключения и особые случаи
Исключения лучше собирать отдельно. Если обсуждать только основной сценарий, требования будут выглядеть аккуратно, но в реальной работе быстро появятся вопросы.
На обследовании полезно спросить:
- что происходит, если документ срочный;
- что делать, если участник процесса отсутствует;
- как обрабатывается возврат на доработку;
- кто принимает решение в нестандартном случае;
- какие документы идут не по типовому маршруту;
- что делается вручную;
- какие правила работают не всегда.
Исключения не обязательно сразу полностью прорабатывать. Но их нужно увидеть и записать, чтобы они не появились внезапно на этапе разработки.
5. Сроки и контроль
Если процесс нужно контролировать, важно сразу определить сроки.
Нужно понять:
- есть ли срок выполнения всего процесса;
- есть ли сроки по отдельным задачам;
- кто контролирует просрочки;
- какие уведомления нужны;
- что происходит при нарушении срока;
- нужен ли отчет по просроченным задачам.
Без этого можно получить схему процесса, но не получить управляемый процесс.
Как проводить обследование последовательно
Чтобы требования не расползались, удобно использовать один и тот же порядок вопросов по каждому процессу.
Шаг 1. Назвать процесс одной фразой
Сначала нужно коротко назвать процесс. Это помогает всем участникам говорить об одном и том же.
Примеры:
- регистрация входящего документа;
- согласование договора;
- создание и контроль поручения;
- заявка на оплату;
- внутреннее согласование служебной записки;
- подготовка и подписание кадрового документа.
Если процесс нельзя назвать одной фразой, скорее всего, в обсуждении смешались несколько разных процессов.
Шаг 2. Разобрать процесс по шагам
После этого процесс нужно пройти последовательно.
- Что запускает процесс?
- Кто его запускает?
- Какие данные нужны на старте?
- Кто получает первую задачу?
- Что происходит дальше?
- Где возможны возвраты?
- Какие есть исключения?
- Как процесс завершается?
Такой порядок обычно дает больше пользы, чем общий вопрос “как у вас это работает”.
Шаг 3. Отдельно записывать спорные места
Если на встрече звучат фразы “зависит от ситуации”, “иногда бывает иначе”, “это надо уточнить”, их нужно записывать отдельно.
Это не ошибка и не проблема. Это нормальная часть обследования. Главное — не потерять такие места.
Для спорных вопросов удобно фиксировать:
- что именно непонятно;
- кто должен уточнить;
- до какой даты нужно дать ответ;
- на что влияет этот вопрос.
Шаг 4. Не смешивать разные процессы
Во время обследования часто появляются смежные темы: отчеты, интеграции, права доступа, уведомления, печатные формы, будущие улучшения.
Эти темы не нужно игнорировать. Но их лучше записывать отдельно и не смешивать с текущим процессом.
Иначе одна задача постепенно превращается в большой набор разных требований, по которому сложно оценить сроки и объем работ.
На обследовании важно держать границы: сначала один процесс, потом следующий. Смежные темы лучше фиксировать отдельно.
Что фиксировать сразу
Чтобы после встречи не собирать информацию заново, лучше сразу записывать основные элементы процесса.
| Что фиксировать | Зачем это нужно |
| Название процесса | Чтобы все участники одинаково понимали тему обсуждения |
| Начало процесса | Чтобы было понятно, что запускает работу |
| Завершение процесса | Чтобы определить ожидаемый результат |
| Роли участников | Чтобы понимать ответственность и порядок действий |
| Документы и данные | Чтобы не потерять реквизиты, справочники и источники данных |
| Исключения | Чтобы особые случаи не появились слишком поздно |
| Сроки | Чтобы процесс можно было контролировать |
| Ручные действия | Чтобы понять, какие обходные действия есть сейчас |
| Открытые вопросы | Чтобы видеть, что еще нужно уточнить |
Пример: когда обследование идет без структуры
Рассмотрим типовую ситуацию.
На первой встрече заказчик говорит: “Нужно настроить согласование договоров”. Команда начинает обсуждать маршрут. Потом выясняется, что согласование зависит от суммы договора. После этого вспоминают, что для отдельных контрагентов есть особый порядок. Затем появляется требование по уведомлениям, отчету для руководителя, истории изменений и контролю сроков.
В итоге из одной задачи получается несколько разных направлений:
- маршрут согласования;
- правила по суммам;
- исключения по контрагентам;
- уведомления;
- отчеты;
- права доступа;
- история изменений.
Все эти темы могут быть важными. Проблема возникает тогда, когда они не разделены. Команде становится сложно понять, что входит в первую очередь работ, а что нужно оформить отдельными требованиями.
Чтобы этого избежать, на обследовании нужно сразу разделять основной процесс, исключения, дополнительные требования и открытые вопросы.
Как выглядит нормальный результат обследования
После обследования должен остаться не просто набор заметок, а рабочие материалы, с которыми можно двигаться дальше.
Обычно полезно подготовить:
- краткое описание процесса;
- черновую схему процесса;
- список ролей участников;
- список документов и данных;
- перечень исключений;
- список открытых вопросов;
- первые требования к настройке или доработке;
- риски и ограничения;
- список тем, которые не входят в текущий объем работ.
Для 1С-проектов это особенно важно. В 1С:Документообороте нужны понятные маршруты, роли, сроки и правила возврата. В ERP важны данные, НСИ и связи между подсистемами. В ЗУП нужно внимательно учитывать кадровую логику, регламенты и юридически значимые сценарии.
Если обследование не дает структуры, эту структуру все равно придется собирать позже — уже на этапе постановки, разработки или тестирования.
Как удержать требования после встречи
Часть проблем появляется уже после обследования. На встрече договорились об одном, потом в чате добавили уточнение, в письме появился новый комментарий, а через несколько дней кто-то прислал еще один вариант процесса.
Чтобы требования оставались управляемыми, лучше придерживаться простых правил:
- для каждого процесса вести отдельный набор материалов;
- все уточнения добавлять в единый список;
- новые темы не смешивать с уже согласованными;
- спорные места отмечать отдельно;
- после встречи отправлять короткое резюме;
- каждое изменение требований фиксировать с причиной;
- устаревшие версии материалов не использовать в работе.
Это не сложные правила, но они помогают избежать расхождений между аналитиком, разработчиком и заказчиком.
Таблица: как переводить общие фразы в нормальные требования
| Как часто говорят на встрече | Как лучше зафиксировать |
| “Надо, чтобы было удобно” | Указать, что именно сейчас неудобно и какой результат нужен |
| “Тут все зависит” | Описать условия, при которых сценарий меняется |
| “Иногда бывает по-другому” | Выделить отдельный сценарий или исключение |
| “Потом уточним” | Записать открытый вопрос и ответственного за уточнение |
| “Это и так понятно” | Проверить, одинаково ли это понимают все участники |
| “Нам нужен простой процесс” | Описать конкретные шаги процесса и то, что не входит в него |
| “Пусть система сама решает” | Определить правила, по которым система должна принимать решение |
Чек-лист обследования
Ниже короткий чек-лист, который помогает проверить, достаточно ли собрана информация.
- Процесс назван одной фразой.
- Определено начало процесса.
- Определено завершение процесса.
- Понятно, кто участвует в процессе.
- Описаны роли участников.
- Собраны основные документы и данные.
- Отдельно записаны исключения.
- Зафиксированы сроки и контроль.
- Отмечены ручные действия и обходные сценарии.
- Создан список открытых вопросов.
- Есть единое место хранения материалов.
- После встречи подготовлено короткое резюме.
Что лучше не делать на обследовании
Есть несколько действий, которые часто усложняют работу с требованиями.
- Не стоит обсуждать несколько процессов одновременно, если у них разные участники и результат.
- Не стоит хранить требования только в личных заметках.
- Не стоит оставлять спорные вопросы без ответственного.
- Не стоит начинать с обсуждения интерфейса, если процесс еще не понятен.
- Не стоит проектировать решение до описания задачи.
- Не стоит считать, что одной встречи всегда достаточно.
- Не стоит смешивать текущую задачу и будущие пожелания.
Если эти моменты контролировать, обследование становится понятнее для всех участников.
Пример короткого плана обследования
Если нужно быстро провести обследование по одному процессу, можно использовать простой пятидневный план.
День 1
Определить границу процесса, его начало, завершение и ключевых участников.
День 2
Разобрать процесс по шагам. Собрать документы, данные и основные действия участников.
День 3
Отдельно разобрать исключения, спорные места, ручные действия и обходные сценарии.
День 4
Подготовить короткое резюме обследования, список открытых вопросов и предварительную схему процесса.
День 5
Проверить материалы с участниками, уточнить спорные вопросы и зафиксировать рабочую версию требований.
Такой план не заменяет полноценную методику обследования, но помогает быстро собрать основу и не потерять важные детали.
Итог
Обследование в 1С-проекте должно помогать команде получить понятную картину процесса. Для этого важно не просто поговорить с пользователями, а последовательно собрать основные элементы: границы процесса, роли, документы, данные, исключения, сроки и открытые вопросы.
Если структура есть, требования проще обсуждать, согласовывать и передавать в разработку. Если структуры нет, команда быстро начинает работать с разными версиями понимания задачи.
Особенно это важно для 1С-проектов, где один процесс часто связан с документами, справочниками, ролями, правами доступа, маршрутами, отчетами и интеграциями.
Хороший результат обследования — это не идеальный документ без вопросов. Хороший результат — это понятное описание процесса, список того, что уже согласовано, и список того, что еще нужно уточнить.
Обследование не должно сразу отвечать на все вопросы. Но оно должно показать, какие вопросы есть, где они зафиксированы и кто отвечает за их уточнение.
Такой подход экономит время на постановке, разработке, тестировании и дальнейшей поддержке решения.