Порядок денний стартової наради проєкту для інженерних команд

Запитання, яке стартові наради оминають

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

Запитання, яке оминає більшість стартових порядків денних, таке: як ця команда ухвалюватиме рішення, коли щось піде не так? Не план проєкту — а рамку ухвалення рішень. Хто відповідає за скоуп, коли фічу треба вирізати? Що робить команда, коли технічне обмеження анулює продуктову вимогу? Хто зі стейкхолдерів має остаточне слово, коли два відділи хочуть різного?

На ці запитання легко відповісти на старті, бо ще нічого не поставлено на кін. Набагато важче відповісти на них посеред проєкту, коли в кожного є своя позиція. Наведений нижче шаблон резервує час на них до того, як почнеться найважча частина.

Порядок денний (скопіюйте це)

Тривалість: 60–90 хвилин залежно від складності проєкту
Формат: із ведучим; усі ключові стейкхолдери й учасники присутні або асинхронно ознайомилися перед початком

Розділ 1 — Мета й скоуп проєкту (20 хв)

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

Розділ 2 — Ролі та відповідальність (15 хв)

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

Розділ 3 — Обмеження та ризики (15 хв)

Жорсткі обмеження: дедлайн, бюджет, відповідність вимогам, залежності від інших команд
Відомі ризики: які три головні речі можуть пустити цей проєкт під укіс?
Для кожного ризику: імовірність, вплив і відповідальний за пом'якшення
Що спричинило б скасування чи суттєве урізання проєкту? Назвіть це зараз

Розділ 4 — План комунікації (10 хв)

Як часто команда синхронізуватиметься? У якому форматі?
Хто отримує апдейт статусу і як? Не припускайте, що всі стейкхолдери хочуть той самий канал
Де живе документація проєкту?
Який шлях ескалації, якщо щось блокує проєкт?

Розділ 5 — Відкриті запитання (15 хв)

Перелічіть кожне запитання, на яке команда сьогодні не може відповісти
Для кожного: призначте відповідального й дату, до якої потрібна відповідь
Запитання без дати й відповідального все ще будуть відкритими на півдорозі

Розділ 6 — Наступні кроки (10 хв)

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

Що популярні шаблони старту роблять неправильно

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

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

Третя прогалина — розділ відкритих запитань. Команди не хочуть виводити назовні те, чого не знають, на старті, бо це відчувається як визнання неготовності. Але невідомі відповіді стають блокерами посеред проєкту, а блокери посеред проєкту дорогі. Що раніше ви знаєте, що запитання існує, то раніше хтось може взяти відповідь на себе.

Про те, як ці прогалини накопичуються в накладні витрати впродовж багатомісячного проєкту: Податок на наради.

Чому нотатки старту варто робити правильно

Документ старту — найчастіше згадуваний артефакт у будь-якому проєкті. Це те, що люди перевіряють, коли скоуп оскаржують, коли приєднується новий член команди, коли стейкхолдер питає «хіба ми не вирішили X на старті?». Добре задокументований старт — це проєкт, яким легше керувати.

Pavleur захоплює весь старт автоматично: скоуп у озвученому вигляді, ролі в призначеному вигляді, ризики в названому вигляді, відкриті запитання з відповідальними, наступні кроки з відповідальними й датами. Якщо хтось показував на екрані бриф проєкту, діаграму чи документ вимог посеред наради, візуал включено у звіт поряд з обговоренням. Суто аудіоінструменти дають вам, хто що сказав; вони не захоплюють діаграму архітектури на екрані, коли техлід описував залежність. Отриманий звіт слугує документом-джерелом істини для проєкту з першого дня. Про те, як це порівнюється з традиційними інструментами захоплення нарад: Pavleur проти альтернатив.

Кілька слів про відвідування

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