На каких стадиях заходил в проекты?

На каких стадиях заходил в проекты?

Как Business Analyst я участвовал в проектах на разных этапах жизненного цикла. Каждая стадия требует разного подхода и компетенций.

1. Инициация проекта (Discovery)

Что происходит

• Компания видит проблему или возможность
• Нужно понять: стоит ли это делать и сколько будет стоить
• Финансируется обычно 1-2 недели анализа

Мой вклад как BA

• Провожу интервью со stakeholders (CEO, CFO, head of Sales)
• Документирую боли текущего процесса
• Предлагаю варианты решения с估算 (rough estimate) бюджета
• Пишу бизнес-кейс (почему это выгодно компании)

Результаты

Проблема: Процесс найма занимает 3 месяца
Стоимость проблемы: Теряем TOP кандидатов, платим recruiting агентствам 30% зарплаты

Решение: Построить внутреннюю ATS (Applicant Tracking System)
Инвестиция: $150K на разработку + $10K/месяц на обслуживание
Окупаемость: 8 месяцев (экономия на recruiting fees)
ROI: 200% за первый год

Если бизнес-кейс убедителен — проект получает зеленый свет.

2. Планирование и аналитика (Requirements)

Что происходит

• Проект одобрен, бюджет выделен
• Нужно детально описать, ЧТО разрабатывать
• Эта стадия может длиться 2-4 недели

Мой вклад

• Собираю requirements через интервью с пользователями
• Создаю user personas (типы пользователей)
• Пишу User Stories с acceptance criteria
• Рисую wireframes/mockups (низкой точности)
• Документирую business rules

Пример User Story

Как recruiter, я хочу быстро найти кандидата по навыкам
Чтобы не просматривать вручную 1000 резюме

Acceptance Criteria:
- [ ] На странице Candidates есть поле Search
- [ ] Ввод техника (Python, C++) фильтрует список
- [ ] Результаты обновляются без перезагрузки страницы
- [ ] Сохраняется история поиска за последние 7 дней

Технические замечания:
- Использовать Elasticsearch для быстрого поиска
- Full-text search по всем полям

3. Проектирование и архитектура (Design)

Что происходит

• Requirements заморозили, начинаем проектировать
• Архитектуры обсуждают frontend, backend, devops
• Длится обычно 1-2 недели

Мой вклад

• Участвую в архитектурных дискуссиях (микросервисы vs монолит?)
• Уточняю с пользователями: хорошо ли вам этот макет?
• Пишу более подробные спецификации API (какие параметры, какие ошибки)
• Согласую с дизайнером (UI/UX) как будет выглядеть
• Документирую в Confluence/Jira

Пример спецификации API

GET /api/v1/candidates/search

Параметры:
- query (string, required): поисковый запрос
- skills (array[string], optional): навыки для фильтра
- min_experience (int, optional): минимальный опыт в годах
- limit (int, default 20): количество результатов
- offset (int, default 0): пагинация

Ответ 200 OK:
{
  "items": [
    {"id": "uuid", "name": "Иван", "skills": ["Python", "Go"], "experience": 5}
  ],
  "total": 150,
  "took_ms": 42
}

Ответ 400 Bad Request:
{"error": "Query parameter is required"}

4. Разработка (Development/Sprint)

Что происходит

• Разработчики начинают писать код
• Спринты по 2 недели
• Может длиться 3-6 месяцев

Мой вклад

• Уточняю requirements по мере появления вопросов
• Участвую в Daily standups (если важный проект)
• Провожу UAT (User Acceptance Testing) — показываю features реальным пользователям
• Пишу тест-кейсы, что нужно проверить
• Документирую изменения требований в Jira

Пример test case

Тест: Поиск по навыку Python

Шаги:
1. Открыть страницу Candidates
2. В поле Search ввести "Python"
3. Нажать Enter

Ожидаемый результат:
- Список обновляется (новых 0.5 сек)
- Показаны только кандидаты с Python в навыках
- История поиска сохранена

Негативный тест:
- Если ввести " " (пробел) — должно показать сообщение "Please enter skills"

5. Тестирование (QA)

Что происходит

• Готовый code приходит в QA
• QA ищет баги
• Баги отправляют разработчикам на исправление

Мой вклад

• Помогаю QA понять requirements (что считается багом, а что нет)
• Провожу smoke-тест (быстрая проверка основных фич)
• Участвую в встречах по критичным багам
• Проверяю, что баг действительно исправлен

6. Подготовка к выпуску (Release Planning)

Что происходит

• Нужно выпустить фичу в production
• Переключаемся с разработки на операции

Мой вклад

• Пишу Release Notes (что нового, какие изменения для пользователей)
• Готовлю переговоры с Product Support (как отвечать на вопросы)
• Пишу User Guide (видео, screenshots, инструкции)
• Планирую rollout (сразу всем 1000 пользователям или постепенно?)

Пример Release Notes

## v2.1.0 — Released March 20, 2025

### New Features
- Быстрый поиск кандидатов по навыкам (closed #142)
- Сохранение истории поиска за 7 дней

### Bug Fixes
- Исправлена ошибка при пустом результате поиска (#145)
- Улучшена производительность на больших наборах данных

### Migration
- Нет breaking changes
- БД миграция (не требует downtime)

7. Post-Launch (Поддержка)

Что происходит

• Фича в production
• Пользователи начинают использовать
• Появляются баги, запросы на улучшения

Мой вклад

• Собираю feedback от пользователей
• Приоритизирую баги (критичные vs nice-to-have)
• Пишу баг-репорты в Jira
• Участвую в планировании следующей версии
• Анализирую метрики (сколько используют фичу, как часто)

Практический пример из опыта

Проект: Система управления отпусками

1. Discovery (неделя 1): Интервью с HR, узнал, что процесс ручной, теряются запросы
2. Requirements (неделя 2-3): Описал 15 user stories, нарисовал мокеты
3. Design (неделя 4): Согласовал архитектуру (PostgreSQL + React)
4. Development (месяцы 2-4): По спринтам, уточнял требования, проводил демо
5. Testing (неделя 16): Помогал QA, нашли 12 багов, исправили
6. Release (неделя 17): Написал Release Notes, записал видео-туториал
7. Post-Launch (месяц 5+): Собираю feedback, планирую v2 (интеграция с календарём)

Вывод

Как BA я заходил на ВСЕХ стадиях:

• Discovery — понимаем проблему и бюджет
• Requirements — документируем ЧТО делать
• Design — уточняем КАК делать
• Development — отвечаю на вопросы разработчиков
• Testing — помогаю QA, проверяю баги
• Release — подготавливаю документацию и коммуникацию
• Post-Launch — собираю feedback, планирую улучшения

Эта полнота участия позволила мне лучше понимать боли команды, давать лучшие требования и в итоге доставлять более полезные продукты.