Кого возьмешь на встречу по презентации артефактов

Команда для встречи по презентации артефактов: стратегический подход

На встречу по презентации артефактов я возьму минимальную, но максимально эффективную команду, которая может полноценно ответить на вопросы по содержанию, технической реализации и бизнес-контексту. Моя цель — избежать «парада всех звёзд», который рассеивает внимание и увеличивает время встречи, но обеспечить присутствие ключевых представителей, ответственных за создание и принятие артефактов.

Ключевые участники (Core Team)

1. Я как Project Manager — ведущий встречи. Моя роль: обеспечить структуру, управлять временем, контролировать повестку, формулировать выводы и отслеживать принятые решения.

   # Пример структуры встречи, которую я подготовлю
   agenda = {
       "00:00-05:00": "Цели встречи и контекст",
       "05:00-15:00": "Презентация основного артефакта (Tech Lead)",
       "15:00-30:00": "Демонстрация и вопросы по реализации (Tech Lead + ключевой разработчик)",
       "30:00-40:00": "Бизнес-перспектива и критерии приемки (Product Owner)",
       "40:00-50:00": "Открытая дискуссия и решение спорных моментов",
       "50:00-60:00": "Консенсус, выводы и план следующих шагов"
   }
   

2. Tech Lead или архитектор — технический спикер. Он отвечает за:

    *   Детальное объяснение архитектурных решений в артефакте (например, диаграммы компонентов или модели данных).
    *   Ответы на глубокие технические вопросы о масштабируемости, безопасности, интеграции.
    *   Представление альтернатив и обоснование выбранного пути.

1. Product Owner (или Business Analyst) — владелец бизнес-контекста. Его присутствие критически важно для:

    *   Связи артефакта с бизнес-целями и пользовательскими потребностями.
    *   Объяснения критериев приемки (Acceptance Criteria) и ожидаемых результатов.
    *   Участия в дискуссии по возможным изменениям требований на основе представленного артефакта.

1. Ключевой разработчик (1 человек) — если артефакт технически сложный (например, детальный дизайн API или схема базы данных). Он может дать конкретные примеры реализации и ответить на вопросы уровня «как именно это будет работать в коде».

   // Пример: он может пояснить фрагмент архитектуры, представленной в артефакте
   public class OrderService {
       // Артефакт предписывает использование шаблона "Strategy" для расчетов
       private PricingStrategy strategy;
   
       public double calculateTotal(Order order) {
           return strategy.calculate(order); // Это решение было утверждено на прошлом review
       }
   }
   

Участники по приглашению или ситуационно (Ad-hoc Participants)

• QA Lead — если артефакт напрямую влияет на тестовую стратегию (например, миграция схемы данных или спецификация API). Он может сразу обозначить риски для тестирования и потребности в тестовых данных.
• DevOps/Инженер инфраструктуры — если артефакт касается конфигурации среды, требований к развертыванию или мониторингу.
• Представитель смежной команды — если артефакт затрагивает их область (например, интерфейсы интеграции). Их лучше пригласить на конкретный сегмент встречи.

Кого НЕ стоит брать на встречу по умолчанию

• Полная команда разработчиков — это приводит к хаотичным дискуссиям и потере фокуса. Информацию они получат из записанной встречи и итогового email.
• Все стейкхолдеры одновременно — встречи с артефактами часто требуют технических деталей. Высокоуровневых стейкхолдеров (например, директора продукта) лучше информировать отдельно, подготовив для них сводную презентацию с выжимкой бизнес-выгод и ключевых решений.
• Неподготовленных участников — каждый приглашенный должен заранее ознакомиться с артефактом и быть готов ответить на вопросы в своей области.

Мой принцип управления встречей

Я использую подход «ответственный + эксперт». Я управляю процессом, а Tech Lead и PO — содержанием. Это позволяет:

• Сократить время встречи за счет четкого тайм-боксинга.
• Принимать более качественные решения, потому что каждый вопрос адресуется непосредственно специалисту.
• Избегать конфликтов и отклонений от темы, так как я могу мягко, но твердо вернуть дискуссию в рамки повестки.

Итог: На встречу я возьму себя (PM), Tech Lead и Product Owner как обязательный набор. Ключевого разработчика, QA или DevOps — только если артефакт требует их экспертизы. Все остальные получат результат встречи в виде официального решения (decision log) и обновленного артефакта. Это баланс между эффективностью коммуникации и полнотой покрытия всех аспектов артефакта.