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 и особенности общения с ними
End User. Они напрямую работают с решением и могут показать его полезность, но:
- Им может быть неинтересно обсуждать текущее состояние системы, так как это их рутина.
- Часто перескакивают на свои идеальные сценарии работы.
- Плохо систематизируют знания и могут забыть как о частых, так и редких операциях.
- Знают только свою часть процесса и могут путать факты с предположениями.
- В отделе может быть всего один человек, ответственный за определенную функцию, что приводит к утечке информации.
Operational Support. Эта группа может предоставить полезную информацию, так как собирает данные из тикетов, но:
- Часто не замечает свои ошибки, ассоциируя себя с системой.
- Знания о процессе могут быть поверхностными.
- Малоинициативны и неохотно идут на диалог.
- Как технические специалисты могут сильно углубляться в детали.
Sponsor. Человек, отвечающий за бюджет, может прояснить странные шаги в в бизнес-процессе, но:
- Редко погружается в детали и быстро забывает о проблемах после их решения.
- Получает обобщенную информацию, что может приводить к устаревшим представлениям.
- Занят, поэтому к нему сложно добраться.
Customers. клиенты бизнеса, который пользуется решением
- Редко вовлечены и доступны для интервью.
- Могут неверно трактовать работу системы и показывать низкую заинтересованность.
- Имеют проблемы, схожие с конечными пользователями.
Regulator. На начальном этапе не очень полезны, но могут указать на ограничения, о которых другие не знают.
Supplier/Vendor. Используют уже готовые компоненты, предоставляемые третьими лицами. В этом случае они могут быть дополнительным источником информации по деталям реализации, но
- Редко идут на контакт и могут саботировать работу при отключении их решения.
- Могут отсутствовать из-за выхода их компании с рынка и других причин
К сожалению, нет волшебной кнопки, которая позволит решить все выше описанные проблемы. В целом можно рекомендовать две вещи:
- Кросс-проверка информации.
- Сверка с другими источниками.
- Использование техник "Наблюдение" и "Анализ документов"
Особенности сбора информации от Тех. Специалистов
Implementation Subject Matter Expert / Тестировщики. Эта группа стейкхолдеров может стать ценным источником сведений о процессе реализации, однако имеет свои нюансы. Технические специалисты, как правило, не погружаются в детали бизнеса. Они прекрасно понимают, как работает система, но зачастую не могут объяснить, зачем это необходимо. Это затрудняет их способность оценивать актуальность функционала. В их окружении часто утверждают, что определённая функция нужна: имеется документация, поддерживающая это мнение, существуют зависимые функции и поступают баг-репорты от пользователей как по самой функции, так и по смежным аспектам. Опираясь только на мнения этой группы, легко воспроизвести старое поведение системы с его недостатками, включая несоответствие реальным потребностям бизнеса.
Менеджеры проектов / Бизнес-аналитики. В целом, это достаточно стабильная группа специалистов, располагающаяся на пересечении технических и бизнес-стейкхолдеров и помогающая соединить потребности с их реализацией. От них не стоит ожидать глубоких технических описаний, но они могут рассказать историю проекта, что дополнит общее понимание контекста. Обычно у них есть актуальный список проблем и хорошее понимание политической ситуации в компании. Однако следует избегать чрезмерной зависимости от их поддержки и вовлечения в корпоративные интриги.
Понравилась статья, скопировал себе на будущее. Все написано четко, внятно и без воды.
Спасибо! Рад стараться 🤝