Кто будет взаимодействовать с заказчиком на новом проекте?

Коммуникация с заказчиком: ролевая матрица

Взаимодействие с заказчиком — это не просто одна роль, а целая система коммуникации. Давайте разберёмся, кто и за что отвечает.

Основные роли

1. Business Analyst (я) — основной контакт по требованиям

• Сбор и уточнение требований
• Документирование функциональности
• Детализация сценариев использования
• Перевод бизнес-проблем в технические решения
• Постоянная коммуникация по спецификациям

2. Project Manager / Scrum Master — управление ожиданиями и сроками

• График проекта и дедлайны
• Статус-репорты
• Управление scope и изменениями
• Интеграция интересов разных сторон
• Риск-менеджмент

3. Техлид / Architect — технические вопросы

• Возможность реализации требований
• Технические ограничения
• Интеграция с существующей инфраструктурой
• Производительность и масштабируемость

4. Product Manager (если есть) — стратегия и приоритизация

• Видение продукта
• Приоритизация фич
• Post-launch анализ
• Долгосрочная дорожная карта

5. UX/UI дизайнер — пользовательский опыт

• Визуальные требования
• Юзабилити
• Демонстрация макетов
• Validation с заказчиком

Модель коммуникации

Заказчик
    |
    +-- Основной контакт: PM (недельные синки)
    |       |
    |       +-- Детальные требования: BA (2-3 раза в неделю)
    |       +-- Технические вопросы: Техлид (по необходимости)
    |       +-- Дизайн и UX: Designer (еженедельно)
    |
    +-- Руководитель проекта у заказчика
            |
            +-- User personas (подразделения, конкретные люди)

Примеры взаимодействия по типам

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

• BA проводит интервью с end-users
• Документирует user stories и acceptance criteria
• Проводит review сценариев с заказчиком

По дизайну:

• Designer показывает прототипы
• Собирает feedback от stakeholders
• Итерирует и согласовывает

По интеграции:

• Техлид согласовывает API contracts
• Обсуждает данные, форматы, частоту обновлений

По статусу:

• PM еженедельно отчитывается
• BA демонстрирует ready компоненты
• Обсуждаются риски и изменения

Правило единственного контакта

Важно определить primary contact — одного человека, который собирает все вопросы. Иначе:

• Разные сообщения от разных ролей
• Conflicting requirements
• Потеря контекста

Оптимально: PM — primary contact, BA — для уточнений, техлид — по запросу

Критические моменты, когда участие расширяется

1. Первый спринт (setup)

• Все роли: BA, PM, Архитектор, Designer
• Синк с key stakeholders заказчика

2. Change requests

• BA уточняет объём
• PM согласовывает график
• Техлид оценивает effort

3. Critical issues

• BA и техлид диагностируют
• PM уведомляет заказчика
• Вместе ищут решение

Мой подход

На новом проекте я:

1. Первую неделю — провожу интенсивный interview cycle с заказчиком
2. Уточняю структуру коммуникации — кто принимает решения, кто даёт требования
3. Определяю frequency — синки 2 раза в неделю + асинк через tickets
4. Документирую процесс — как и когда согласуются требования
5. Ведучу shared backlog — видимость для всех сторон

Вывод

Успешный проект — это не один контакт, а хорошо организованная система коммуникации между разными ролями. BA здесь действует как переводчик между бизнесом и технологией, но не как единственный коммуникатор.