Повестка стартовой встречи проекта для инженерных команд

Вопрос, который пропускают стартовые встречи

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

Вопрос, который пропускают большинство стартовых повесток: как эта команда будет принимать решения, когда что-то пойдёт не так? Не план проекта — а рамка принятия решений. Кто отвечает за рамки, когда фичу нужно урезать? Что делает команда, когда техническое ограничение обесценивает продуктовое требование? У какого стейкхолдера последнее слово, когда два отдела хотят разного?

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

Повестка (копируйте и вставляйте)

Длительность: 60–90 минут в зависимости от сложности проекта
Формат: с ведущим; все ключевые стейкхолдеры и участники присутствуют или ознакомились асинхронно до начала

Раздел 1 — Цель и рамки проекта (20 мин)

Сформулируйте цель одним предложением: как выглядит успех, по возможности измеримо
В рамках: что проект поставит, названное конкретно
Вне рамок: что этот проект явно делать не будет — перечислите минимум три вещи
Критерии успеха: как команда поймёт, что проект завершён?
За этот раздел отвечает EM или PM; инженеры возражают, если заявленные рамки не соответствуют реализуемости

Раздел 2 — Роли и ответственность (15 мин)

Для каждого потока работ назовите одного ответственного — не команду, а человека
Кто принимает финальное решение по: продуктовым рамкам, технической архитектуре, внешним коммуникациям?
Кого информируют, с кем консультируются и кто принимает решение по каждому крупному типу решений?
Назовите руководителя проекта, который отвечает, если ничего другого не ясно

Раздел 3 — Ограничения и риски (15 мин)

Жёсткие ограничения: срок, бюджет, комплаенс, зависимости от других команд
Известные риски: какие три вещи вероятнее всего могут сорвать этот проект?
По каждому риску: вероятность, влияние и ответственный за митигацию
Что вызвало бы отмену или существенное сужение рамок проекта? Назовите это сейчас

Раздел 4 — План коммуникаций (10 мин)

Как часто команда будет синхронизироваться? В каком формате?
Кто получает статус-апдейт и как? Не считайте, что стейкхолдеры хотят один и тот же канал
Где живёт документация проекта?
Каков путь эскалации, если что-то блокирует проект?

Раздел 5 — Открытые вопросы (15 мин)

Перечислите каждый вопрос, на который команда сегодня не может ответить
По каждому: назначьте ответственного и дату, к которой нужен ответ
Вопросы без даты и ответственного всё ещё будут открыты на полпути

Раздел 6 — Следующие шаги (10 мин)

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

Что делают не так популярные шаблоны старта

Большинство шаблонов старта основательны по части плана проекта и худосочны по части того, что происходит, когда план не держится. Они порождают чистый документ о рамках и матрицу RACI, что полезно. Но они не порождают общий ответ на «что мы делаем, когда вендор БД посреди проекта утраивает цены?» или «что урезается, если мы упрёмся в жёсткий дедлайн при 80% готовности фич?»

Отсутствие «вне рамок» — другой устойчивый пробел. Заявить, что в рамках, несложно. Заявить, что явно вне рамок — перечислить три-четыре конкретные вещи, которые проект делать не будет, — заставляет провести тот же разговор об ожиданиях стейкхолдеров, но с другой стороны. Стейкхолдеры, которые собирались считать, что мобильный клиент входит, узнают об этом на старте, а не на шестой неделе.

Третий пробел — раздел открытых вопросов. Командам не хочется выносить на старте то, чего они не знают, потому что это ощущается как признание неготовности. Но неизвестные ответы становятся блокерами посреди проекта, а блокеры посреди проекта дороги. Чем раньше вы знаете, что вопрос существует, тем раньше кто-то может взять на себя ответ.

О том, как эти пробелы накапливаются в накладные расходы за многомесячный проект: Налог на встречи.

Почему стоит хорошо оформить заметки старта

Документ старта — самый часто упоминаемый артефакт в любом проекте. Это то, что люди проверяют, когда рамки оспариваются, когда приходит новый член команды, когда стейкхолдер спрашивает «разве мы не решили X на старте?» Хорошо задокументированный старт — это проект, которым легче управлять.

Pavleur фиксирует весь старт автоматически: рамки в заявленном виде, роли в назначенном виде, риски в названном виде, открытые вопросы с ответственными, следующие шаги с ответственными и датами. Если кто-то показывал экран с брифом проекта, диаграммой или документом требований посреди встречи, визуал включён в отчёт рядом с обсуждением. Чисто аудиоинструменты дают вам, кто что сказал; они не фиксируют диаграмму архитектуры на экране в момент, когда техлид описывал зависимость. Итоговый отчёт служит документом-источником истины проекта с первого дня. О том, как это сравнивается с традиционными инструментами фиксации встреч: Pavleur и альтернативы.

Замечание о присутствии

Каждый, от кого ожидается решение по этому проекту, должен присутствовать на старте или просмотреть полную запись и письменную сводку до начала работы. Стейкхолдер, который пропускает старт и узнаёт рамки неформально две недели спустя, — это готовый спор о рамках посреди проекта. Задача старта — построить общий контекст, а общий контекст существует только тогда, когда нужные люди в комнате.