В отделе продаж каждый вечер переносят цифры из 1С в Excel. Сотрудники просят новый отчет, чтобы больше не собирать таблицу вручную. Программист может помочь, но ему нужно объяснить, какие данные нужны, откуда их брать и что должно получиться.
И тут появляется он — аналитик 1С. Общается, выясняет, описывает, передает, проверяет и финализирует. На словах просто. На деле важно понять, что стоит за задачей и какие детали бизнес-процесса еще предстоит уточнить.
Я руковожу проектами разработки на 1С и за 10 лет прошла путь от технического писателя до руководителя. Здесь хочу поделиться тем, что помогает аналитику увереннее работать с заказчиком и командой, браться за более сложные задачи и расти в профессии.
Этот подход и опыт моих проектов мы вместе с Инфостарт Обучением положили в основу нового курса «Системный сбор требований и работа с информацией». На нем расказываю, как организовать сбор информации, проводить интервью, разбирать противоречия и связывать требования, модели процессов и данных с будущей приемкой решения.
Новичку курс дает последовательность работы и возможность потренироваться на учебных материалах. Практикующему аналитику — инструменты для проверки своего подхода: где теряются источники требований, остаются неразрешенные вопросы или принимаются решения без достаточных оснований.
Программа будет особенно полезна, если в работе вы сталкиваетесь с такими ситуациями:
• После интервью остается много заметок, но непонятно, как превратить их в требования и какие вопросы задать на следующей встрече.
• Регламенты описывают один порядок действий, пользователи рассказывают другой, а рабочие документы показывают третий.
• У каждого подразделения свои приоритеты, и нужно подготовить аргументы для обсуждения состава первого релиза.
• Требования, схемы процессов и сценарии проверки существуют отдельно — трудно понять, все ли они описывают одно и то же решение.
Что мы разберем на курсе
-
Как спланировать сбор информации и провести интервью
Начнем с подготовки: источники информации, порядок встреч, исходные документы и обработка результатов. Покажу, как составить план сбора требований, определить цель беседы и подготовить вопросы.
Отдельный урок посвятим самому разговору: воронке вопросов, активному слушанию, уточнению общих формулировок и поиску потребностей за готовыми пожеланиями. Разберем и то, как зафиксировать результат встречи и вернуть его участникам на проверку.
-
Как превратить разрозненные сведения в требования
Будем формулировать и классифицировать требования, вести реестр, фиксировать источники и способы проверки. После перейдем к приоритизации, оценке реализуемости и согласованию с командой.
-
Как описать процессы и данные
В блоке моделирования разберем базовые элементы BPMN и построение модели AS-IS — описания того, как процесс работает сейчас.
Другой ракурс — данные. Будем выделять сущности, их атрибуты и связи, строить простую ERD, составлять глоссарий и описывать требования к данным и отчетности. Бизнес-правила разберем через таблицы решений; также познакомимся с назначением DMN.
-
Как обосновать изменения в процессе
После описания текущей работы перейдем к анализу. Например, разберем, почему сам по себе ручной ввод еще не служит достаточным основанием для автоматизации: важно учитывать объем работы и ожидаемый эффект изменения.
На этой основе перейдем к TO-BE — целевой модели процесса. Отдельно разберем обсуждение модели с участниками проекта и фиксацию согласованной версии.
-
Как проверить требования и подготовить приемку
В заключительном блоке разберем два уровня проверки: верификацию и валидацию. Сначала — качество самих материалов: полноту, однозначность, непротиворечивость и проверяемость. Затем — соответствие описанного решения реальной потребности пользователя.
Я также покажу, как подготовить пользовательское приемочное тестирование. Разберем, как классифицировать обнаруженные расхождения.
Практика с неполной и противоречивой информацией
В итоговом кейсе вам предстоит собрать навыки вместе: описать текущий процесс, подготовить компактную матрицу ответственности, требования, глоссарий, модель данных и таблицу решений. Затем — разобрать две проблемные зоны и подготовить сценарии пользовательской проверки.
По итогам практики у вас останутся собственные работы по учебному кейсу и шаблоны, которые можно адаптировать под задачи команды.
Что изменится в вашей работе после курса
Практика на курсе поможет увереннее обсуждать решения с заказчиком: показать, из каких фактов возникло требование, какие ограничения учтены и что предстоит проверить. А при передаче материалов команде — объяснить связь между задачей пользователя, процессом, данными и ожидаемым результатом.
С позиции руководителя проекта я вижу ценность такого подхода и для бизнеса:
-
реестр с источниками и приоритетами помогает обсуждать объем работ;
-
согласованная модель процесса — проверять, одинаково ли подразделения понимают будущий порядок действий;
-
сценарии приемки — заранее договариваться, по каким результатам будет оцениваться решение.
Эффект зависит от того, как команда применяет подход в проектах: отводит ли время на обследование, привлекает ли нужных участников и фиксирует ли договоренности.
Если вы хотите увереннее проводить обследования, готовить понятные требования и объяснять предложенные решения заказчику и команде, приглашаю на курс «Системный сбор требований и работа с информацией». Мы пройдем путь от исходных материалов до подготовки проверки решения и отработаем инструменты на учебных задачах.
А в следующих публикациях я планирую делиться реальными кейсами и рабочими решениями из своей практики.
Загрузка...
