Agile vs Waterfall для бизнес-аналитика: что выбирает заказчик
Сравнение Agile и Waterfall с точки зрения бизнес-аналитика: артефакты, роль BA, типичные сценарии. Как выбрать методологию под проект и заказчика.
«Мы работаем по Agile» — фраза, которую слышали многие. Но когда начинаешь разбираться, оказывается: часть людей думает, что Agile — это «без документации», другая — что это «спринты по 2 недели», а заказчик вообще хочет фиксированное ТЗ с датой сдачи. Разберём, чем реально отличаются подходы и как бизнес-аналитик работает в каждом.
Waterfall: предсказуемость и контроль
Суть подхода
Waterfall (каскадная модель) — последовательное выполнение фаз:
Анализ → Проектирование → Разработка → Тестирование → Внедрение
Каждая фаза завершается до начала следующей. Возврат на предыдущую фазу — дорогая процедура.
Роль бизнес-аналитика в Waterfall
В Waterfall аналитик — центральная фигура первых двух фаз:
| Фаза | Что делает BA | Артефакты |
|---|---|---|
| Анализ | Сбор требований, интервью, воркшопы | BRD, описание процессов |
| Проектирование | Детализация требований, прототипы | SRS, wireframes, модель данных |
| Разработка | Уточнение требований, ответы на вопросы | Запросы на изменения (CR) |
| Тестирование | Приёмочное тестирование | Тест-кейсы, отчёт о приёмке |
| Внедрение | Обучение пользователей | Руководства, инструкции |
Объём документации: высокий. BRD (10–30 стр.) + SRS (30–100 стр.) + прототипы + модель данных.
Когда Waterfall работает
- Требования известны и стабильны — заказчик точно знает, что хочет
- Фиксированный бюджет и сроки — контракт с подрядчиком
- Регулируемая среда — банки, страхование, госсектор, медицина
- Интеграционные проекты — API-контракты нельзя менять на лету
- Офшорная разработка — команда в другом часовом поясе, нужна детальная спецификация
Когда Waterfall не работает
- Заказчик не может сформулировать требования до начала разработки
- Рынок меняется быстрее, чем длится фаза анализа
- Команда маленькая и сидит рядом с заказчиком
- Продукт новый, и нужно проверять гипотезы
Agile: адаптивность и скорость
Суть подхода
Agile — не методология, а набор принципов (Agile Manifesto). На практике чаще всего используются фреймворки:
- Scrum — спринты по 1–4 недели, роли (PO, SM, Team), церемонии
- Kanban — непрерывный поток, визуализация, лимиты
Ключевая идея: короткие циклы → обратная связь → адаптация.
Роль бизнес-аналитика в Agile
В Scrum нет формальной роли BA. Но на практике бизнес-аналитик нужен — он выполняет часть функций Product Owner или работает в паре с ним.
| Активность | Что делает BA | Артефакты |
|---|---|---|
| Подготовка бэклога | Декомпозиция эпиков в User Stories | Product Backlog |
| Refinement | Уточнение требований с командой | User Stories с AC |
| Sprint Planning | Разъяснение приоритетов и зависимостей | Sprint Backlog |
| В течение спринта | Ответы на вопросы разработчиков | Уточнения, макеты |
| Sprint Review | Демо заказчику, сбор обратной связи | Обновлённый бэклог |
| Между спринтами | Описание процессов, интеграций | BPMN, API-контракты |
Объём документации: минимальный. Бэклог с User Stories + Acceptance Criteria. Но «минимальный» не значит «нулевой».
Когда Agile работает
- Требования неопределённы — нужно экспериментировать
- Продуктовая разработка — свой продукт, а не заказной проект
- Команда рядом — доступ к PO ежедневно
- Быстро меняющийся рынок — нужно выпускать обновления часто
- Стартап / MVP — проверка гипотез важнее полноты
Когда Agile не работает
- Заказчик недоступен для регулярной обратной связи
- Контракт с фиксированной ценой и scope
- Регулятор требует полный комплект документации до начала разработки
- Команда распределена по нескольким часовым поясам без налаженной коммуникации
Сравнительная таблица
| Параметр | Waterfall | Agile (Scrum) |
|---|---|---|
| Планирование | Заранее, полное | Итеративное, по спринтам |
| Требования | Фиксированные | Эволюционирующие |
| Документация | BRD + SRS (50–130 стр.) | User Stories + AC (бэклог) |
| Обратная связь | После завершения фазы | Каждые 1–4 недели |
| Изменения | Через CR (change request) | Через приоритизацию бэклога |
| Риски | Поздно обнаруживаются | Рано обнаруживаются |
| Стоимость изменений | Растёт экспоненциально | Относительно стабильная |
| Вовлечение заказчика | На фазе анализа и приёмке | Постоянно |
| Роль BA | Центральная (автор ТЗ) | Поддерживающая (помощник PO) |
| Предсказуемость сроков | Высокая (при стабильных требованиях) | Средняя (через velocity) |
Что выбирает заказчик на самом деле
На практике заказчик редко выбирает «чистый» Waterfall или «чистый» Agile. Чаще всего получается гибрид.
Гибрид 1: «Waterfall снаружи, Agile внутри»
Ситуация: заказчик хочет фиксированный бюджет и ТЗ, но разработка ведётся спринтами.
Как работает:
- Фаза анализа (1–2 месяца) → BRD + высокоуровневые User Stories
- Оценка бюджета и сроков по бэклогу
- Фиксация контракта
- Разработка спринтами (Scrum)
- Приёмка по контрольным точкам
Роль BA: подготовить ТЗ для контракта, затем работать с командой на refinement.
Гибрид 2: «Agile с усиленной документацией»
Ситуация: продуктовая команда, но регулируемая отрасль (банк, страхование).
Как работает:
- Бэклог ведётся как User Stories
- Но параллельно BA ведёт SRS — обновляя после каждого спринта
- Регуляторная документация формируется ретроспективно
Роль BA: работать в двух режимах — лёгкие артефакты для команды, формальные — для регулятора.
Гибрид 3: «Discovery + Delivery»
Ситуация: новый продукт с неясными требованиями.
Как работает:
- Discovery (2–6 недель): исследование → CJM → прототипы → валидация с пользователями
- Delivery (спринтами): разработка по результатам discovery
- Discovery и Delivery работают параллельно: пока команда разрабатывает один блок, BA исследует следующий
Роль BA: ведёт discovery — интервью, прототипы, описание процессов. Передаёт готовые User Stories в delivery.
Как бизнес-аналитику адаптироваться
Если вы привыкли к Waterfall, а проект — Agile
- Не пишите SRS. Вместо этого — User Stories с Acceptance Criteria
- Участвуйте в церемониях. Refinement — ваша основная площадка
- Откажитесь от «полноты». В Agile требования уточняются по мере разработки
- Будьте доступны. Разработчики будут задавать вопросы каждый день, а не раз в месяц
Если вы привыкли к Agile, а проект — Waterfall
- Научитесь писать SRS. Это детальнее, чем User Stories
- Привыкайте к ревью. Документы проходят 3–5 итераций согласования
- Фиксируйте изменения. Каждое изменение — через Change Request
- Планируйте на месяцы вперёд. Спринтов нет, есть этапы и контрольные точки
Навыки, которые работают везде
Независимо от методологии, бизнес-аналитику нужны:
- Элиситация — умение извлекать требования из людей
- Моделирование — описание процессов в BPMN
- Документирование — в любом формате, чётко и однозначно
- Приоритизация — MoSCoW, Kano и другие техники
- Коммуникация — перевод между языком бизнеса и IT
Матрица выбора подхода
| Критерий | → Waterfall | → Agile | → Гибрид |
|---|---|---|---|
| Требования ясны на старте | ✅ | ||
| Требования будут меняться | ✅ | ||
| Фиксированный бюджет/контракт | ✅ | ✅ | |
| Заказчик доступен ежедневно | ✅ | ||
| Заказчик доступен раз в месяц | ✅ | ||
| Регулируемая отрасль | ✅ | ✅ | |
| Стартап / MVP | ✅ | ||
| Крупный проект (> 6 месяцев) | ✅ | ||
| Внешний подрядчик | ✅ | ✅ | |
| Продуктовая команда | ✅ |
Итог
Agile и Waterfall — не религии, а инструменты. Выбор зависит не от моды, а от контекста: стабильности требований, доступности заказчика, формальности среды и размера проекта. Бизнес-аналитик, владеющий обоими подходами, востребован на любом проекте.
Не можете определиться с подходом для вашего проекта? Обсудим — помогу выбрать методологию и адаптировать процесс анализа.