Всем привет! Этим постом мы начинаем разбираться в том, какие требования и как бизнес-аналитик может извлекать в ходе анализа существующих решений. В этой части немного про цели Reverse Engineering (RE), источники для него и общие подходы.
Давайте разбираться, что такое Reverse Engineering. RE – это процесс извлечения информации из уже существующего решения и представление этой информации в нужной нам форме. В нашем случае бизнес-аналитику требуется информация, которая послужит основанием для требований.
Данную технику не найдете в своде знаний от IIBA - BABOK (A Guide to the Business Analysis Body of Knowledge). Она спрятана там в технике Document Analysis
Задача RE возникает всегда в контексте какой-то другой задачи. Бизнес не заинтересован в выполнении RE самого по себе, тем более что это достаточно дорогая операция, поскольку требует вовлечения разных заинтересованных сторон и достаточной квалификации самого бизнес-аналитика. Причем здесь часто требования предъявляются именно к его hard-skill. Поэтому прежде чем бросаться выполнять RE, нужно четко понять границы этой задачи и цель ее выполнения. Ниже примеры задач которые, наиболее часто требуют выполнения RE:
1. Необходимо восстановить требования для того, чтобы осуществлять поддержку решения
2. Вы пришли на проект, связанный с добавлением или существенным изменением существующего решения
3. Затевается проект по полной переделки старой системы
4. У клиента было установлено какое-то старое решение, пришли вы со своим коробочным продуктом, и нужно осуществить замену системы
5. Необходимо написать требования на миграцию данных между уже существующими решениями
6. Необходимо написать требования на интеграцию уже существующих решений
7. Нужно провести исследование конкурентного продукта, чтобы понять какие у него полезные фичи и как они работают.
Все эти задачи бизнес-аналитика объединяет одно общее свойство: для их выполнения нужно иметь актуальные системные (в идеале) требования. Поскольку именно на достоверном и глубоком понимании As-Is системы бизнес-аналитик будет строить новый пласт требований.
Еще одно важное уточнение: редко (никогда) требуется восстановление всех требований и сразу. Очень часто эта задача локальная и первая итерация легко очерчивается.
Как и любая аналитическая задача, RE требует источников. Вот список того что можно и нужно использовать в этом качестве:
1. Интервью технических экспертов. Разработчики, QA (особенно QA!), служба поддержки.
2. Если есть возможность «потыкать кнопочки» самостоятельно, то это прекрасный источник как описаний, так и проверки гипотез «а может ли так быть»
3. Изучение данных системы (data driven decision – может стать серьезным подспорьем в работе)
4. Изучение структуры данных
5. Изучение исходного кода (если это доступно)
6. Интервью заинтересованных сторон из бизнеса, конечных пользователей, наблюдение за их работой с решением (иногда это чуть ли не единственный доступный метод)
7. Знание домена
8. Существующая документация (к сожалению, часто она отсутствует в принципе или сильно устаревшая)
9. Анализ тикетов на helpdesk
Итак мы понимаем зачем нас попросили сделать RE. Мы поговорили с людьми на проекте и более менее определились с источниками. Что дальше? Дальнейшие шаги будут зависеть от того для чего конкретно мы восстанавливаем требования и какой источник используем. Мы обсудим это в следующих статьях. Но в любом случае есть несколько принципов которых нужно придерживаться:
1. Все врут, даже код, даже база. Крайне желательно пользоваться любой возможностью и перепроверять информацию. К сожалению, любая проверка забирает время и на аналитика часто давят сроки, так приходится выбирать на что потратить время, а на что положиться
2. Никому не нужны всеобъемлющие документы, тем более сами по себе. Нам нужно решить задачу относительно новых требований к решению. Перфекционизм здесь часто не уместен.
3. Аккуратно выбирайте объем исследования и контролируйте его в процессе. Легко увлечься и застрять на какой-то незначимой мелочи или уйти в сторону. Размер «мелочи» определяется критичностью изначальной задачи (той что породила RE)
4. Аккуратно выбирайте уровень детализации. Причины те же что и в пункте выше
5. Не путайте то как система работает и то как должна. Вы можете вести рядом список изменений, который может быть добавлен в беклог, но восстанавливаемые требования должны быть записаны AsIs
6. Если предполагается дальнейшая работа с восстановленными требованиями, а не только разовое восстановление, нужно сразу озаботиться построением процесса обновления системной документации
Тренинги от "Art of Business Analysis":