Порядок денний щотижневої командної синхронізації, що заслуговує на слот у календарі

Запитання, яке щотижневі синхронізації оминають

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

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

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

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

Тривалість: 30 хвилин для однієї команди; 45 хвилин для крос-функціональної синхронізації
Формат: синхронний; пункти порядку денного подано асинхронно перед нарадою

Вступ (2 хв)

Підтвердьте пункти порядку денного й розподіл часу
Якщо нічого змістовного в порядку денному немає, скасуйте нараду — серйозно

Розділ 1 — Пріоритети та блокери (10 хв)

Які два-три головні пріоритети команди на тиждень?
Що заблоковано на рівні команди — не індивідуальні блокери (вони належать до стендапу), а блокери, що потребують дій керівництва чи іншої команди для розв'язання
Пропускайте будь-який елемент, що рухається добре без обговорення

Розділ 2 — Міжкомандні залежності (10 хв)

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

Розділ 3 — Потрібні рішення (10 хв)

Елементи, що потребують рішення до наступної щотижневої синхронізації
Для кожного: одна людина окреслює варіанти (стисло — не презентація); група вирішує; хтось фіксує рішення й обґрунтування
Усе, що потребує понад 5 хвилин окреслення, не готове до рішення; заплануйте окреме обговорення

Розділ 4 — Оголошення (5 хв)

Зміни в командних процесах, інструментах чи графіках
Інформація від керівництва, потрібна команді до наступної синхронізації
По одному реченню на пункт; жодного обговорення, якщо тільки хтось не має блокувального запитання

Що більшість шаблонів щотижневої синхронізації роблять неправильно

Типові шаблони щотижневої синхронізації написані так, ніби мета наради очевидна. Це не так. Мета щотижневої синхронізації конкретна й вузька: вона для координації, що провалюється в проміжок між щоденним стендапом і асинхронними каналами. Шаблони, що не роблять цю межу явною, продукують наради, які поступово поглинають усе — апдейти статусу, огляди проєктів, тімбілдинг, довгі обговорення — доки вони не тривають 90 хвилин і ніхто не хоче там бути.

Найпоширеніша форма, якої це набуває, — «щотижневий стендап»: щотижнева нарада, що робить рівно те, що робить щоденний стендап, лише рідше й з більшою кількістю місць. Якщо ваш стендап працює, немає координаційної прогалини, яку заповнив би щотижневий стендап. Якщо ваш стендап не працює, виправлення — це формат стендапу, а не додаткова щотижнева нарада.

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

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

Як Pavleur обробляє запис щотижневої синхронізації

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

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

Коли скасовувати щотижневу синхронізацію

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

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