Продолжаем наше рассуждение на тему того, кто такие бизнес-аналитики, чем они занимаются и за что ответственны на проектах разного класса. В этой статье мы обсуждаем специфику работы аналитиком на проектах разработки софта с нуля. Рассказывать мы будем об этом со ссылкой на подход RUP (Rational Unified Process) к разработке программного обеспечения.
Почему именно RUP? Потому что этот подход, по сути, выстраивает четкий процесс разработки программного обеспечения в компании, а также имеет ряд методических указаний по работам, ролям на проекте и документации, многие компании используют его как некое руководство к действию. Существует также образовательный онлайн портал, на котором собраны лучшие практики, основанные на RUP, который довольно широко используется не только образовательными учреждениями, но и практиками из отрасли для анализа и улучшения своих процессов.
Итак, аналитик на проектах разработки софта — это очень очень обширная роль, этот человек участвует практически во всех этапах проекта и выполняет огромное количество задач. Если обобщить, аналитик занимается извлечением, анализом и координацией требований к системе со стороны бизнеса, а затем на их основе формирует технические требования к системе, прописывая также взаимодействия пользователей в рамках будущей системы, чтобы она работала в едином механизме. Звучит довольно страшно и не совсем понятно, а один из практиков по управлению командой на крупных проектах однажды сказал: “Аналитики — это те люди на проекте, которым хочется налить чай и пожалеть”. Действительно, задач очень много, но давайте посмотрим на них поближе.
Первым делом аналитик проводит первичные интервью основных заинтересованных лиц заказчика на предмет их потребностей и/или проблем, после чего должен сформировать документ “Видение”. На некоторых проектах это может быть документ “Инициации проекта”, документ “Предварительное обследование” и так далее, но суть у них все равно одна.
Видение (vision) — документ, который формирует бизнес-аналитик в самом начале проекта на основе общих требований к системе. В нем он/она должен описать бизнес-кейс (емко и четко сформулированную бизнес-проблему и потребность), прописать, какие будут созданы приложения (система), какие основные функции будут реализованы, почему не подходят существующие решения. Этот документ дает проекту старт и на верхнем уровне позволяет понять, чего же хочет заказчик.
После того, как видение проекта готово, пришло время сформировать перечень требований к программному продукту уже в технических терминах, которыми пользуется проектная команда. Обычно перечень требований документируется в “Спецификации” или “Техническом задании”. Аналитик сопровождает команду разработчиков на этапе программирования и консультирует по вопросам реализации требований к системе.
Следует также отметить, что зачастую перед тем, как аналитик формирует перечень требований, он/она рисует прототип интерфейса программного продукта, чтобы понять, что все бизнес-требования будут учтены, а вот уже на основе этого прототипа прописывает технические требования.
Для того, чтобы выполнять такой обширный перечень задач на проектах, аналитик должен обладать, помимо коммуникативных навыков, целым набором компетенций, технических и управленческих, о котором мы вам расскажем немного позже, когда закончим с циклом статей о профессии аналитика.
