Какая роль аналитика в Waterfall?

Роль аналитика в Waterfall

Waterfall (каскадная модель) имеет свои особенности работы для Business Analyst. Это совершенно другой подход, чем Agile, и требует других навыков. Расскажу детально о том, что делает аналитик на каждом этапе.

Характеристика Waterfall модели

В Waterfall проект разделяется на последовательные фазы:

1. Requirements (Требования)
2. Design (Проектирование)
3. Development (Разработка)
4. Testing (Тестирование)
5. Deployment (Развёртывание)
6. Maintenance (Поддержка)

Каждая фаза завершается полностью перед началом следующей. Изменения требований на позднем этапе требуют переделки всего предыдущего.

Фаза 1: Сбор и анализ требований

Это самая критичная фаза для аналитика. От качества здесь зависит весь проект:

• Интервью со стейкхолдерами — провожу глубокие интервью с бизнесом, чтобы понять их потребности на 100%. В Waterfall изменений после этой фазы быть не должно
• Документирование — пишу подробный документ требований (SRS — Software Requirements Specification) на 50-100+ страниц
• Формальное согласование — требования подписываются всеми стейкхолдерами. Это юридический документ
• Выявление всех деталей — нельзя забыть ничего, так как потом переделка будет дорогой
• Проверка на полноту — проводится базовая проверка требований на противоречия

Этап может занять 3-6 месяцев для крупного проекта. Спешить нельзя.

Фаза 2: Проектирование (Design)

Аналитик участвует в проектировании архитектуры:

• Валидация требований — проверяю, что архитектура соответствует требованиям
• Участие в design meetings — обсуждаю с архитекторами и разработчиками, как лучше реализовать требования
• Документирование дизайна — помогаю описывать архитектурные решения на доступном языке
• Проверка на выполнимость — убеждаюсь, что требования реалистичны технически
• Уточнение деталей — если архитектор задаёт вопросы о требованиях, я даю ответы

Это критичный момент: если архитектор неправильно понял требование, это повлечёт проблемы на позднем этапе.

Фаза 3: Разработка (Development)

Роль аналитика здесь вспомогательная, но важная:

• Ответы на вопросы разработчиков — они могут уточнять непонятные моменты в требованиях
• Контроль соответствия — убеждаюсь, что разработчики не переинтерпретируют требования
• Ведение Change Log — если появляются изменения, фиксирую их
• Подготовка к тестированию — пишу тест-кейсы на основе требований

Важно не вмешиваться в технические решения разработчиков, только следить за тем, чтобы результат соответствовал требованиям.

Фаза 4: Тестирование (Testing)

Аналитик участвует активно:

• Валидация тест-кейсов — проверяю, что все тест-кейсы покрывают требования
• Участие в UAT (User Acceptance Testing) — помогаю бизнесу проверять функциональность
• Анализ bagов — когда QA находит ошибку, я определяю, это ошибка в коде или непонимание требований
• Управление scope creep — если находятся новые требования, я помогаю принять решение о их включении
• Документирование найденных проблем — фиксирую, какие требования не выполнены

Фаза 5: Развёртывание (Deployment)

Аналитик обеспечивает гладкий переход:

• Подготовка документации — создаю пользовательские руководства на основе требований
• Обучение пользователей — объясняю, как работает система в соответствии с требованиями
• Поддержка перехода — помогаю выявить проблемы в production
• Sign-off — получаю официальное согласие от клиента, что требования выполнены

Фаза 6: Поддержка (Maintenance)

В долгосрочной перспективе:

• Баг-репорты — анализирую, являются ли ошибки отклонением от требований
• Запросы на изменения — помогаю оценивать стоимость изменений
• Обновление документации — поддерживаю SRS в актуальном состоянии

Ключевые отличия аналитика в Waterfall от Agile

Waterfall требует:

• Более детального планирования — в начале проекта нужно знать всё
• Больше документации — нет ежедневного общения, всё в бумаге
• Вперед смотрящего взгляда — предусмотреть все возможные сценарии
• Формального согласования — все решения подписываются
• Меньше гибкости — нельзя менять требования в процессе

Agile требует:

• Частого общения — ежедневные стендапы, спринты
• Меньше документации — больше прямого диалога
• Итеративного уточнения — требования уточняются по ходу работы
• Быстрого принятия решений — не всегда нужна формальная документация
• Максимальной гибкости — требования меняются постоянно

Мой опыт с Waterfall

Я использовал Waterfall в проектах:

• Государственные контракты — там требуется полная документация
• Контракты с фиксированной ценой — нужно заранее зафиксировать всё
• Проекты с чёткими требованиями — когда требования известны с самого начала
• Интеграция legacy систем — когда изменения дорогие

Сейчас Waterfall используется всё реже, но в некоторых отраслях (航空 авиация, медицина, гос. сектор) он остаётся стандартом.

Совет для аналитика в Waterfall проекте

Будь максимально внимателен на фазе требований — это твоя единственная возможность повлиять на проект. После этого стоимость изменений растёт экспоненциально. Правильно написанное требование на 80% гарантирует успех проекта.