В качестве кого принимал участие в этапах разработки?

Моя роль на различных этапах разработки проекта

В разные моменты жизненного цикла проекта я выполнял разные функции. BA — это не узкая роль, а набор компетенций, которые разворачиваются в зависимости от этапа.

Этап 1: Discovery и Планирование

Роль: Research Lead + Requirement Engineer

В этом периоде я работаю как исследователь:

Деятельность:

• Провожу интервью со всеми стейкхолдерами (бизнес, пользователи, техотдел)
• Анализирую конкурентов и market trends
• Создаю User Personas и Customer Journey Maps
• Определяю core features vs nice-to-have функции
• Пишу Business Requirements Document (BRD)
• Создаю диаграммы вариантов использования (Use Case Diagrams)

Инструменты: Figma, Miro, Confluence, Google Forms для опросов

Результат: Подробное описание того, ЧТО нужно построить и ПОЧЕМУ это нужно

Роль: Планировщик проекта

• Совместно с Product Manager определяю дорожную карту (roadmap)
• Разбиваю крупные features на спринты
• Оцениваю, какой объем работы нужен
• Обсуждаю с техлидом, что реально сделать в эту итерацию

Этап 2: Дизайн и Разработка

Роль: Bridge между заказчиком и технической командой

Здесь я становлюсь переводчиком:

Деятельность:

• Участвую в tech design sessions с разработчиками
• Объясняю requirements техническому отделу: "Вот бизнес хочет этого, а вот почему"
• Помогаю дизайнеру понять, какой user flow мы планировали
• Отвечаю на вопросы разработчиков: "А это требование критично? Это можно упростить?"
• Провожу рефайн сторис (Refinement) на планерках
• Следу за тем, чтобы разработка не отклонялась от требований

Пример: Дизайнер нарисовал интерфейс, а разработчик говорит: "Это очень дорого в реализации, займет месяц". Я перепроверяю с дизайнером: "Это требование критично для пользователей или это просто красиво?". Часто находим более простое решение.

Роль: Quality Gate между спецификацией и реализацией

• Когда разработчик считает, что задача готова, я проверяю, выполнены ли все требования
• Смотрю на Demo и спрашиваю: "Это то, что мы планировали?"
• Помогаю QA выявить gap'ы в требованиях: "А как система должна себя вести в этом случае?"

Этап 3: Тестирование и QA

Роль: Link между QA и Requirement specification

Деятельность:

• Помогаю QA командe создавать Test Cases на основе requirements
• Отвечаю на вопросы вроде: "А что произойдет, если пользователь введет отрицательное число?"
• Проверяю, что тесты покрывают все user scenarios
• Участвую в приемочном тестировании (Acceptance Testing) вместе с заказчиком
• Фиксу баги, которые переклассифицировали как feature requests

Пример: QA находит ошибку "При поиске по пустому запросу система зависает". Я проверяю requirements: в них ничего не сказано о пустом поиске. Это bug или просто неоговоренное поведение? Я уточняю с заказчиком и дизайнером.

Роль: Гарант приемки

• Создаю критерии приемки (Acceptance Criteria) для каждой user story
• Вместе с Product Owner и заказчиком проверяю, что всё работает как планировалось
• Даю sign-off на релиз

Этап 4: Релиз и Post-Launch

Роль: Support для пользователей и команды

Деятельность:

• Создаю документацию для пользователей (user guides, FAQ)
• Провожу обучение заказчика и его команды
• Собираю первые feedback'и и помогаю приоритизировать баги
• Слежу за метриками: работает ли система так, как планировали?

Роль: Product Analyst

• Анализирую, дошли ли мы к целям, которые ставили в начале проекта?
• Собираю data о поведении пользователей
• На основе реальной информации предлагаю улучшения

Пример: Мы планировали, что пользователи будут экспортировать отчеты 2 раза в день. На деле они делают это 1 раз в неделю. Это означает, что либо функция не такая нужная, либо её сложно найти, либо есть более быстрый способ. Нужно разбираться.

Этап 5: Улучшение и Оптимизация

Роль: Change Management Lead

• Координирую изменения и улучшения на основе feedback
• Помогаю приоритизировать: что важнее, что можно отложить
• Обновляю requirements документы
• Объясняю команде, почему это важно

Ключевые компетенции, которые я использую на всех этапах

Коммуникация

✓ Слушаю активно, не только слышу ✓ Говорю просто и понятно, не прячусь за жаргоном ✓ Умею адаптировать язык: с заказчиком иначе, с разработчиками иначе ✓ Письменно документирую все договоренности

Аналитика

✓ Вижу скрытые requirements (то, что заказчик не сказал, но подразумевает) ✓ Связываю бизнес-цели с техническими решениями ✓ Анализирую данные и выявляю тренды

Управление конфликтами

✓ Занимаю нейтральную позицию между всеми сторонами ✓ Помогаю найти компромисс ✓ Не защищаю ни одну сторону — ищу истину

Управление проектом

✓ Слежу за timeline ✓ Помогаю расстановке приоритетов ✓ Прозрачно информирую о рисках и проблемах

Вывод

Business Analyst — это не человек, сидящий в углу и пишущий требования. Это человек в центре всего, который:

• Говорит с пользователями и понимает их боли
• Говорит с разработчиками и объясняет логику
• Говорит с заказчиком и уточняет цели
• Говорит с QA и гарантирует качество
• На каждом этапе выполняет разные функции, но всегда с одной целью: убедиться, что мы строим правильное решение правильным способом