Итак, что же такое 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 / Тестировщики. Эта группа стейкхолдеров может стать ценным источником сведений о процессе реализации, однако имеет свои нюансы. Технические специалисты, как правило, не погружаются в детали бизнеса. Они прекрасно понимают, как работает система, но зачастую не могут объяснить, зачем это необходимо. Это затрудняет их способность оценивать актуальность функционала. В их окружении часто утверждают, что определённая функция нужна: имеется документация, поддерживающая это мнение, существуют зависимые функции и поступают баг-репорты от пользователей как по самой функции, так и по смежным аспектам. Опираясь только на мнения этой группы, легко воспроизвести старое поведение системы с его недостатками, включая несоответствие реальным потребностям бизнеса.

  Менеджеры проектов / Бизнес-аналитики. В целом, это достаточно стабильная группа специалистов, располагающаяся на пересечении технических и бизнес-стейкхолдеров и помогающая соединить потребности с их реализацией. От них не стоит ожидать глубоких технических описаний, но они могут рассказать историю проекта, что дополнит общее понимание контекста. Обычно у них есть актуальный список проблем и хорошее понимание политической ситуации в компании.

  Надеюсь информация по Reverse Engineering бизнес требований оказались для вас полезными. Напишите в комментариях, как вы делали обратный инжиниринг бизнес требований на своих проектах  Не забудьте поставить лайк этому посту и подписаться — это вдохновляет меня на создание новых материалов! Спасибо за вашу поддержку!