Reverse Engineering бизнес требований советы для Senior Business Analyst

Итак, что же такое Reverse Engineering? RE – это процесс, в ходе которого мы извлекаем информацию из уже имеющегося решения и представляем ее в нужном формате. В данном контексте бизнес-аналитику необходима информация, которая станет основой для формулировки требований.
Эта методика не представлена в своде знаний IIBA – BABOK, она находится в технике Document Analysis.
Задача Reverse Engineering возникает всегда в контексте какой-то другой задачи. Бизнес не заинтересован в самом процессе RE, так как это может быть дорогостоящей операцией, требующей участия различных заинтересованных сторон и высокой квалификации самого бизнес-аналитика. При этом часто акцент делается именно на его hard skills. Поэтому прежде чем приступать к выполнению RE, важно четко определить границы этой задачи и ее цель.
Кейсы для Reverse Engineering
-
Нужно уточнить требования для обеспечения поддержки текущего функционала.
-
Вы присоединились к проекту, который включает добавление или значительные изменения в уже существующее решение.
-
Запланирован проект по полному update-ту устаревшей системы.
-
У клиента имеется старая система, и вы пришли с вашим готовым продуктом для ее полной замены.
-
Необходимо разработать требования для миграции данных между двумя действующими системами.
-
Требуется составить требования для интеграции уже имеющихся решений.
-
Нужно провести детальный анализ конкурентного продукта, чтобы выяснить его полезные функции и принцип их работы.
Все перечисленные задачи бизнес-аналитика объединяет одно ключевое свойство: для их успешного выполнения необходимо иметь актуальные системные требования (в идеале). Именно на основе достоверного и глубокого понимания существующей системы (As-Is) бизнес-аналитик сможет сформулировать новый набор требований.
Источники информации для RE:
-
Интервью с тех-специалистами. Это могут быть разработчики, тестировщики, а также сотрудники служба customer support.
-
Если есть возможность самостоятельно поэкспериментировать нажимая на различные кнопки, это станет отличным источником как для описания, так и для проверки гипотез.
-
Анализ данных системы (data driven decision) может существенно помочь в принятии решений.
-
Детальное Изучение структуры данных.
-
Анализ исходного кода (если он доступен).
-
Интервью с заинтересованными сторонами из бизнеса, конечными пользователями и наблюдение за их взаимодействием с продуктом (парой это единственный доступный метод).
-
Понимание специфики домена.
-
Существующая документация (к сожалению ее часто нету, либо сильно устарела).
-
Анализ Тикетов в Jira, Asana, Trello или других системах
Нужно помнить следующие
-
Всеобъемлющие документы никому не нужны, особенно если они существуют сами по себе. Наша цель — решить задачу в контексте новых требований к решению. Здесь перфекционизм зачастую неуместен.
-
Все лгут, даже код и даже базы данных. Поэтому крайне важно использовать все доступные возможности для перепроверки информации. К сожалению, на проверку уходит время, а сроки для аналитиков часто сжаты, поэтому приходится выбирать, на что потратить время, а что принять на веру.
-
Внимательно выбирайте уровень детализации. Причины те же, что и в предыдущем пункте.
-
Не путайте, как система функционирует, и как она должна функционировать. Вы можете вести параллельный список изменений, который будет добавлен в backlog, но восстановленные требования должны быть зафиксированы в формате As Is.
-
Тщательно определяйте объем исследования и следите за ним в процессе работы. Легко увлечься и застрять на незначительных деталях или уйти в сторону. Что считать «мелочью», зависит от критичности исходной задачи, которая и вызвала реконструкцию требований.
-
Если планируется дальнейшая работа с восстановленными требованиями, а не только разовая реконструкция, стоит сразу позаботиться о создании процесса обновления системной документации.
Давайте напоследок рассмотрим группы пользователей из BABOK и особенности общения с ними
Reverse Engineering бизнес требований советы для Senior Business Analyst 🌟 End User. Они напрямую работают с решением и могут показать его полезность, но:
-
Им может быть неинтересно обсуждать текущее состояние системы, так как это их рутина.
-
Часто перескакивают на свои идеальные сценарии работы.
-
Плохо систематизируют знания и могут забыть как о частых, так и редких операциях.
-
Знают только свою часть процесса и могут путать факты с предположениями.
-
В отделе может быть всего один человек, ответственный за определенную функцию, что приводит к утечке информации.
Operational Support. Эта группа может предоставить полезную информацию, так как собирает данные из тикетов, но:
-
Часто не замечает свои ошибки, ассоциируя себя с системой.
-
Знания о процессе могут быть поверхностными.
-
Малоинициативны и неохотно идут на диалог.
-
Как технические специалисты могут сильно углубляться в детали.
Sponsor. Человек, отвечающий за бюджет, может прояснить странные шаги в в бизнес-процессе, но:
-
Редко погружается в детали и быстро забывает о проблемах после их решения.
-
Получает обобщенную информацию, что может приводить к устаревшим представлениям.
-
Занят, поэтому к нему сложно добраться.
Customers. клиенты бизнеса, который пользуется решением
-
Редко вовлечены и доступны для интервью.
-
Могут неверно трактовать работу системы и показывать низкую заинтересованность.
-
Имеют проблемы, схожие с конечными пользователями.
Regulator. На начальном этапе не очень полезны, но могут указать на ограничения, о которых другие не знают.
Supplier/Vendor. Используют уже готовые компоненты, предоставляемые третьими лицами. В этом случае они могут быть дополнительным источником информации по деталям реализации, но
-
Редко идут на контакт и могут саботировать работу при отключении их решения.
-
Могут отсутствовать из-за выхода их компании с рынка и других причин
К сожалению, нет волшебной кнопки, которая позволит решить все выше описанные проблемы. В целом можно рекомендовать две вещи:
— Кросс-проверка информации.
— Сверка с другими источниками.
— Использование техник «Наблюдение» и «Анализ документов»
Особенности сбора информации от Тех. Специалистов
Implementation Subject Matter Expert / Тестировщики. Эта группа стейкхолдеров может стать ценным источником сведений о процессе реализации, однако имеет свои нюансы. Технические специалисты, как правило, не погружаются в детали бизнеса. Они прекрасно понимают, как работает система, но зачастую не могут объяснить, зачем это необходимо. Это затрудняет их способность оценивать актуальность функционала. В их окружении часто утверждают, что определённая функция нужна: имеется документация, поддерживающая это мнение, существуют зависимые функции и поступают баг-репорты от пользователей как по самой функции, так и по смежным аспектам. Опираясь только на мнения этой группы, легко воспроизвести старое поведение системы с его недостатками, включая несоответствие реальным потребностям бизнеса.
Менеджеры проектов / Бизнес-аналитики. В целом, это достаточно стабильная группа специалистов, располагающаяся на пересечении технических и бизнес-стейкхолдеров и помогающая соединить потребности с их реализацией. От них не стоит ожидать глубоких технических описаний, но они могут рассказать историю проекта, что дополнит общее понимание контекста. Обычно у них есть актуальный список проблем и хорошее понимание политической ситуации в компании.
Надеюсь информация по Reverse Engineering бизнес требований оказались для вас полезными. Напишите в комментариях, как вы делали обратный инжиниринг бизнес требований на своих проектах Не забудьте поставить лайк этому посту и подписаться — это вдохновляет меня на создание новых материалов! Спасибо за вашу поддержку!
-
Автор: Pro_Project_Management