Как начинаешь работу в проекте?

Как начать работу в новом проекте: пошаговый подход

Первые недели в проекте — критичны для успеха. BA должен быстро набрать скорость и начать добавлять ценность. Вот мой проверенный подход.

Фаза 1: Подготовка и onboarding (Дни 1-3)

Шаг 1: Встреча с руководством и стейкхолдерами

Цель: Получить общее понимание проекта

Действия:

• Встреча с project manager / product owner
• Встреча с техническим лидом
• Встреча с основным заказчиком / спонсором

Вопросы, которые я задаю:

• Какие основные бизнес-цели проекта?
• Кто основные стейкхолдеры и их интересы?
• Какой бюджет и сроки?
• Есть ли уже определённые требования?
• Какие основные риски и вызовы?
• Какова текущая фаза проекта (инициация, разработка, тестирование)?

Результат: Документ "Project Overview" с ключевой информацией

Шаг 2: Изучение документации и истории

Действия:

• Прочитай все существующие документы
• Посмотри на код (хотя бы структуру)
• Изучи историю проекта и предыдущие версии
• Посмотри на текущую систему / конкурентов

Где искать информацию:

• Confluence / Wiki (внутренняя документация)
• GitHub / GitLab (код и history)
• Jira / Asana (задачи и процессы)
• Google Drive (общие документы)
• Email (предыдущие переговоры и решения)

Результат: Базовое понимание того, как всё устроено

Шаг 3: Получить доступ ко всем системам

Убедись, что у тебя есть доступ к:

• Хранилище документов (Confluence, Google Drive)
• Системе управления проектом (Jira, Asana)
• Репозиторию кода (GitHub, GitLab)
• Тестовым окружениям
• Аналитике и данным
• Общим каналам коммуникации (Slack, Teams)

Не стесняйся просить доступ! Это базовое право BA.

Шаг 4: Встреча с командой

Действия:

• Познакомься с разработчиками, QA, дизайнерами
• Понимай, кто отвечает за что
• Узнай их контакты и время доступности

Совет: Потом это облегчит коммуникацию и координацию

Фаза 2: Детальное изучение (Неделя 2-3)

Шаг 5: Встреча с пользователями / клиентами

Действия:

• Интервью с end-users (если возможно)
• Наблюдение за тем, как люди используют систему
• Понимание их болевых точек и потребностей

Вопросы:

• Как вы используете систему день за днём?
• Какие самые большие проблемы?
• Что было бы идеально иметь?
• Какие функции вы не используете?

Результат: User Personas и сценарии использования

Шаг 6: Изучение процессов

Действия:

• Отследи текущие бизнес-процессы
• Создай диаграммы BPMN текущего состояния
• Определи узкие места и неэффективности

Результат: Диаграммы As-Is (текущего состояния)

Шаг 7: Анализ требований и backlog

Действия:

• Прочитай все существующие требования
• Посмотри на backlog (список функций)
• Оцени качество документирования
• Определи пробелы и противоречия

Вопросы:

• Требования ясны и полны?
• Есть ли конфликты между ними?
• Кто авторы требований?
• Последние ли это версии?

Результат: Понимание текущего статуса требований

Шаг 8: Техническое погружение

Действия:

• Попроси техлида объяснить архитектуру
• Посмотри диаграммы системы
• Поймите технические ограничения
• Узнай о technical debt и уязвимостях

Важно: Не нужно становиться инженером, но нужно понимать возможности и ограничения

Результат: Документ "Technical Overview"

Фаза 3: Планирование и согласование (Неделя 3-4)

Шаг 9: Встреча с командой для планирования

Действия:

• Проведи встречу всей команды (PM, разработчики, QA, дизайнеры)
• Обсуди текущее состояние
• Согласуй приоритеты и цели на следующий период
• Определи мой роль и ответственность

Результат: Выравнивание всех участников

Шаг 10: Создание плана работы BA

Мой план обычно включает:

1. Уточнение и документирование текущих требований
2. Выявление пробелов в требованиях
3. Проведение деталировки backlog'а
4. Создание документации по процессам
5. Помощь в приоритизации
6. Поддержка разработки и тестирования

Результат: Roadmap работы BA на месяцы вперёд

Фаза 4: Практическое начало (Неделя 4+)

Шаг 11: Первые задачи

Я начинаю с:

• Очистка и уточнение существующих требований

  • Убедись, что все требования SMART
  • Добавь missing criteria
  • Исправь противоречия

• Деталировка backlog'а

  • Разложи крупные фичи на меньшие
  • Создай user stories
  • Добавь acceptance criteria

• Встречи с стейкхолдерами

  • Регулярные синхронизации
  • Уточнение требований
  • Управление ожиданиями

Шаг 12: Создание документации

Ключевые документы, которые я создаю:

1. Requirements Document (Документ требований)

• Функциональные и нефункциональные требования
• Acceptance criteria
• Из-за зависимости между требованиями

2. Process Documentation (Документация процессов)

• Диаграммы BPMN (As-Is и To-Be)
• Описания рабочих процессов
• Роли и ответственность

3. Data Model (Модель данных)

• Основные сущности
• Связи между ними
• Атрибуты и типы данных

4. API Specification (Спецификация API)

• Если работаем над интеграциями
• Endpoints, parameters, responses
• Error handling

5. Glossary (Глоссарий)

• Определения ключевых терминов
• Аббревиатуры
• Общее понимание язык для всей команды

Чеклист первых 4 недель

Неделя 1:

• ✓ Встреча с руководством
• ✓ Получить доступ ко всем системам
• ✓ Прочитать основную документацию
• ✓ Познакомиться с командой

Неделя 2:

• ✓ Интервью с пользователями
• ✓ Понимание текущих процессов
• ✓ Изучение backlog'а
• ✓ Техническое погружение

Неделя 3:

• ✓ Встреча по планированию
• ✓ Создание плана работы
• ✓ Первые документы (Project Overview, Technical Overview)
• ✓ Определение следующих шагов

Неделя 4:

• ✓ Уточнение и очистка требований
• ✓ Деталировка backlog'а
• ✓ Регулярные встречи со стейкхолдерами
• ✓ Начало создания документации

Ошибки, которых стоит избежать

1. Спешить с решениями

• Не предлагай решения до того, как полностью понял проблему
• Потрать время на анализ

2. Упустить stakeholder'ов

• Встреться со ВСЕМИ важными людьми
• Игнорирование кого-то создаст проблемы позже

3. Не задавать вопросов

• Спрашивай, пока не поймёшь на 100%
• "Глупые вопросы" — это нормально на первых неделях

4. Не документировать

• Пиши всё в документацию
• То, что находится в голове, теряется

5. Действовать в вакууме

• Коммуницируй с командой
• Делись находками и идеями
• Слушай обратную связь

Мой личный подход

Когда я прихожу в новый проект:

1. Слушаю больше, чем говорю

   • Первые недели — это про слушание и обучение
   • Я записываю вопросы, но не сразу их задаю

2. Ищу паттерны

   • Что повторяется?
   • Где появляются одни и те же проблемы?
   • Это подсказывает корневые причины

3. Создаю зону доверия

   • Показываю, что я здесь, чтобы помочь
   • Не критикую предыдущую работу
   • Признаю, что у каждого были хорошие причины для своих решений

4. Быстро добавляю ценность

   • Даже на ранних этапах ищу, где я могу помочь
   • Первая напечатанная документация или очищенный backlog дают доверие

5. Регулярно синхронизируюсь

   • Еженедельные встречи с PM и разработчиками
   • Регулярные обновления для стейкхолдеров
   • Это предотвращает неожиданности

Итог

Первые недели в проекте определяют весь оставшийся путь. Потратив время на правильный onboarding, ты:

• Быстрее поймёшь контекст
• Избежишь ошибок
• Заработаешь доверие команды
• Будешь более эффективен в дальнейшем

Помни: спешка на начальном этапе приводит к медленному движению позже. Лучше потратить две недели на изучение, чем три месяца на исправление ошибок из-за неправильного понимания проекта.