Кто ты без своего костюма? Гений, миллиардер, аналитик 1С

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

И тут появляется он — аналитик 1С. Общается, выясняет, описывает, передает, проверяет и финализирует. На словах просто. На деле важно понять, что стоит за задачей и какие детали бизнес-процесса еще предстоит уточнить.

Я руковожу проектами разработки на 1С и за 10 лет прошла путь от технического писателя до руководителя. Здесь хочу поделиться тем, что помогает аналитику увереннее работать с заказчиком и командой, браться за более сложные задачи и расти в профессии.

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

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

Программа будет особенно полезна, если в работе вы сталкиваетесь с такими ситуациями:

• После интервью остается много заметок, но непонятно, как превратить их в требования и какие вопросы задать на следующей встрече.

• Регламенты описывают один порядок действий, пользователи рассказывают другой, а рабочие документы показывают третий.

• У каждого подразделения свои приоритеты, и нужно подготовить аргументы для обсуждения состава первого релиза.

• Требования, схемы процессов и сценарии проверки существуют отдельно — трудно понять, все ли они описывают одно и то же решение.

Что мы разберем на курсе

1. Как спланировать сбор информации и провести интервью

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

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

2. Как превратить разрозненные сведения в требования

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

3. Как описать процессы и данные

   В блоке моделирования разберем базовые элементы BPMN и построение модели AS-IS — описания того, как процесс работает сейчас.

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

4. Как обосновать изменения в процессе

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

   На этой основе перейдем к TO-BE — целевой модели процесса. Отдельно разберем обсуждение модели с участниками проекта и фиксацию согласованной версии.

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

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

   Я также покажу, как подготовить пользовательское приемочное тестирование. Разберем, как классифицировать обнаруженные расхождения.

Практика с неполной и противоречивой информацией

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

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

Что изменится в вашей работе после курса

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

С позиции руководителя проекта я вижу ценность такого подхода и для бизнеса:

• реестр с источниками и приоритетами помогает обсуждать объем работ;

• согласованная модель процесса — проверять, одинаково ли подразделения понимают будущий порядок действий;

• сценарии приемки — заранее договариваться, по каким результатам будет оцениваться решение.

Эффект зависит от того, как команда применяет подход в проектах: отводит ли время на обследование, привлекает ли нужных участников и фиксирует ли договоренности.

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

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