На каких этапах разработки принимает участие аналитик

На каких этапах разработки принимает участие аналитик

Это полный цикл разработки ПО. System Analyst вовлечён не только в начало, но и на протяжении всего пути от идеи до production и поддержки.

1. Инициация и концептуализация (5-10% времени проекта)

Роль аналитика:

• Участие в обсуждении бизнес-идеи со стейкхолдерами
• Выяснение истинных потребностей, а не проблем (лучше слушать 3 часа, чем кодить неправильное 3 месяца)
• Формулировка Vision документа: что система должна делать и почему
• Выявление основных стейкхолдеров и их интересов
• Первичная оценка масштаба и рисков

Результат: краткое описание (1-2 страницы) проблемы и решения

Пример: "Нам нужна система управления заказами, потому что сейчас используем Excel и теряем 15 часов в неделю на ручную работу. Сэкономить $300к в год."

2. Анализ требований (20-25% времени проекта)

Роль аналитика:

• Проведение интервью с разными категориями пользователей (бизнес, опер, техподдержка)
• Сбор и документирование функциональных требований
• Определение нефункциональных требований (производительность, безопасность, масштабируемость)
• Анализ существующих систем и интеграций
• Выявление ограничений и constraints (бюджет, сроки, технические стеки)
• Приоритизация требований по MoSCoW (Must have, Should have, Could have, Won't have)

Результат: Requirements Specification документ (30-50 страниц)

Пример требований:

FR1: Система должна обрабатывать 1000 заказов в час
FR2: Уведомления клиентам в течение 5 минут после смены статуса
NFR1: Время ответа < 2 секунд для 95% операций
NFR2: Доступность 99.95%

3. Дизайн и архитектура (15-20% времени проекта)

Роль аналитика:

• Участие в техническом дизайне (вместе с архитектором и техлидом)
• Формулировка функциональной архитектуры (какие модули, как они взаимодействуют)
• Определение интеграционных точек с внешними системами
• Формулировка User Stories для разработки
• Создание макетов UI (wireframes) для ключевых процессов
• Анализ и оценка рисков на этом этапе

Результат: Design документация, User Stories, макеты

Пример User Story:

As a店員 (店員 — работник)
I want to view all pending orders with filters
So that I can prioritize my work

Acceptance Criteria:
- Display shows last 100 orders
- Filter by date, customer, status
- Real-time updates every 10 seconds

4. Разработка и реализация (40-50% времени проекта)

Роль аналитика (поддерживающая):

• Ежедневные standups (30 минут) — отвечать на вопросы разработчиков
• Код-ревью с точки зрения требований (не синтаксис, а логика)
• Уточнение неясностей в требованиях
• Обновление документации при изменениях в процессе
• Контроль качества выполнения требований

Когда нужно вмешаться:

• Разработчик предлагает упрощение, которое нарушит требование
• Обнаружена невозможность реализации (архитектурный конфликт)
• Требуется приоритизация при нехватке времени

Пример вмешательства:

Разработчик: "Можно ли упростить валидацию?" Аналитик: "Нет, правило валидации — бизнес-требование. Без него потеряем данные."

5. Тестирование (15-20% времени проекта)

Роль аналитика:

• Создание Test Cases на основе требований
• UAT (User Acceptance Testing) — участие в приёмке с клиентом
• Определение критериев успеха
• Анализ багов: является ли баг нарушением требования или feature request
• Приоритизация багов

Пример Test Case:

TC-001: Create Order
Preconditions: User is logged in, inventory available
Steps:
  1. Click "New Order"
  2. Select customer
  3. Add 2 items
  4. Click "Save"
Expected: Order saved, status = "Draft"

6. Deployment и запуск (5-10% времени проекта)

Роль аналитика:

• Подготовка документации для пользователей
• Обучение пользователей (вместе с тренерами)
• Мониторинг первых дней в production
• Сбор обратной связи от пользователей
• Анализ инцидентов на предмет нарушения требований

7. Post-Launch и поддержка (постоянно)

Роль аналитика:

• Анализ метрик (KPI): используется ли система как планировалось
• Сбор feature requests и improvement ideas
• Анализ: это баг или design flaw?
• Планирование версии 2.0 на основе feedback
• Документирование known issues

Участие по интенсивности

Инициация    ████████░░  100%
Анализ       ███████░░░░  80%
Дизайн       ██████░░░░░  60%
Разработка   ████░░░░░░░  20%
Тестирование ██████░░░░░  60%
Deployment   ████░░░░░░░  30%
Поддержка    ██░░░░░░░░░  10%

Инструменты и артефакты, которые создаёт аналитик

• Требования (Requirements документация)
• Design документация
• User Stories с Acceptance Criteria
• Макеты (wireframes, mockups)
• Test Cases и сценарии
• Документация для пользователей (User Manual)
• Change Log
• Post-Launch report

Ключевой момент

Аналитик НЕ кодит, но присутствует на всех этапах. Это pont между бизнесом и技術 (техникой). На каждом этапе:

• Обеспечивает понимание требований
• Проверяет соответствие требованиям
• Управляет изменениями
• Отвечает за качество конечного продукта

Максимальное вовлечение на ранних этапах (инициация, анализ, дизайн) — это экономит 80% проблем на поздних этапах.