Шаблон shared-context: крос-функціональне вирівнювання з AI

Найбільша помилка, яку я бачу в SMB-власників щодо крос-функціонального вирівнювання — це просити тракер робити роботу, для якої він ніколи не створювався. Тракер ловить статус — задачі, власників, дедлайни. Він не ловить контекст — рішення, trade-offs, чому ми обрали саме це. А статус без контексту — причина, чому ваш Slack у пʼятницю о 17:00 палає від "стоп, ми змінили скоуп?".

Чому тракера недостатньо?

Бо тікети відповідають на "що" — що в роботі, що готово, що блокує. Вони не відповідають на "чому цей підхід, що ми відкинули, кого зачепить, якщо змінимо курс". Цей контекст живе у Slack-тредах, записах зустрічей, side-DM і голові лідера проекту — і випаровується в момент, коли хтось із них у відпустці.

Definition: Shared-context документ — єдиний живий артефакт, що належить named-людині, що тримає "чому" за роботою як комплемент до тракерного "що".

Більшість SMB вирішує це статус-зустріччю. Це працює на малому масштабі і ламається після ~40 людей, бо той самий контекст треба пере-пояснювати чотирьом аудиторіям у чотирьох зустрічах.

Як виглядає 5-секційний shared-context?

Пʼять секцій, фіксована форма. AI-агент читає тракер, comms-потік і попередню версію; видає delta-чорнетку щопонеділка зранку; власник підписує за <10 хв.

Definition: Живий документ — єдиний канонічний артефакт, чия поточна версія завжди представляє найкращий відомий стан команди, оновлений на регулярному каденсі з чітким власником.

1. Для чого цей проект — результат, до якого йдемо, бізнес-мовою. Оновлюється рідко.
2. Що зараз правда — поточний стан з тракера, з іменами. Оновлюється щотижня.
3. Що ми вирішили цього тижня — рішення зі Slack / зустрічей / DM, які не очевидні з тракера. Щотижня.
4. Що розглянули і відкинули — альтернативи, що обговорювалися і не пройшли, з причиною. Запобігає циклу "стоп, ми ж уже думали про X?".
5. Що зміниться наступного тижня — заплановані зміни скоупу, власника, мілстоунів. Forward-looking.

Секція 4 — те, що команди скіпають. І саме вона одна запобігає найбільш leverage-помилці в крос-функціональних проектах: re-litigation рішень через тижні.

Шаблон shared-context (copy/paste)

Сидить у будь-якому doc-інструменті — Notion, Confluence, Google Doc, Markdown у репо. Формат важливіший за інструмент.

SHARED CONTEXT — [PROJECT NAME]
Власник: [NAME]
Остання AI-чернетка: [DATE/TIME] by [AGENT]
Остання верифікація власника: [DATE/TIME] by [NAME]

1. ДЛЯ ЧОГО ЦЕЙ ПРОЕКТ
   [2-4 речення. Бізнес-мова. Результат, не фіча.]

2. ЩО ЗАРАЗ ПРАВДА
   - [булет з іменем і числом, де можливо]
   - [булет]
   - [булет]
   Джерело: [TRACKER снепшот DATE]

3. ЩО МИ ВИРІШИЛИ ЦЬОГО ТИЖНЯ
   - [Рішення] — від [NAME] на [DATE]. Чому: [1 рядок].
   - [Рішення] — від [NAME] на [DATE]. Чому: [1 рядок].

4. ЩО РОЗГЛЯНУЛИ І ВІДКИНУЛИ
   - [Опція] — відкинуто [DATE] тому що [1 рядок].
   - [Опція] — відкинуто [DATE] тому що [1 рядок].

5. ЩО ЗМІНИТЬСЯ НАСТУПНОГО ТИЖНЯ
   - [Зміна scope/власника/мілстоуна з датою]
   - [Зміна з датою]

AI-asist: чернетка понеділок [TIME]. Верифікація: понеділок [TIME].
Правки: [count]. Спірно: [imена, якщо є].

Рядок "Спірно" — це механізм trust-and-safety. Якщо член команди не згоден з тим, як AI охарактеризував рішення, він названий, а суперечка йде у секцію 3 наступної версії. Без тихої незгоди.

Tool tip (AIAdvisoryBoard.me): Shared-context док — операційний шар, на який спирається щоденний Plan → Fact → Gap. Plan читає з секції 5 (що змінюється). Fact — з секції 2 (що правда). Gap виносить, коли є drift. Без shared-context доку щоденному digest немає з чим порівнювати. Після 7 днів обох разом — вартість вирівнювання на крос-функціональних проектах падає у видимий на рівні керівництва спосіб. https://aiadvisoryboard.me/?lang=en.

Як часто AI запускається?

Щотижня — правильний каденс для AI-чорнетки. Щодня — занадто шумно; нічого змістовного не змінюється день-у-день на рівні контексту. Щомісяця — занадто повільно; до того часу рішення пере-обговорилися двічі. Понеділок зранку, до першої крос-функціональної зустрічі тижня — канонічний слот.

Підпис власника має відбутися у 4 години після AI-чорнетки. Довше — команда починає користуватися доком без верифікації, і AI-помилки розходяться як правда. 4-годинний SLA — те, що тримає док чесним.

Manager scan (2-хвилинний digest, приклад)

• Plan: 8 активних крос-функціональних проектів → 8 shared-context доків мають оновлюватися щотижня
• Fact: 7 чернеток у понеділок, 6 підписані в 4 години, 5 повністю верифіковані
• Gap: 2 проекти зі стейл-доками (з іменами); 1 проект, де AI-чорнетка спірна, але неспірний текст відправився
• Власники з найбільшою кількістю врегульованих суперечок: з іменами
• Секція 4 використана у 6 з 8 доків — попереджає re-litigation
• Середній час від чорнетки до підпису власника: 35 хв
• Секція 1 оновлюється щоквартально, інакше стабільна
• Нові співробітники онбордяться на крос-функціональні проекти через док, не через 1:1
• Історія версій тракується; старі рішення findable у секції 4
• Вартість AI-чорнетки на док: <$0.10 — не питання бюджету

Micro-case (що змінюється за 7-14 днів)

Компанія на 240 людей з 11 крос-функціональними проектами (запуски, операційні міграції, зміни sales-процесів) розкотила shared-context доки з понеділковою AI-чорнеткою і 4-год SLA на підпис. До: ~6 статус-синків на тиждень на проект, втома учасників відчутна, re-litigation скоупу — хронічна. За два тижні: статус-синки впали приблизно вдвічі, бо док ніс навантаження; секція 4 впіймала 9 спроб пере-відкрити вирішене за перший місяць. Глибша зміна: нові співробітники, що онбордилися, витрачали ~45 хв на читання відповідного shared-context доку замість 4 годин catch-up зустрічей. Док став джерелом правди; тракер лишився джерелом стану.

Note on this case: Це ілюстрація — на основі типових патернів у компаніях 30-500 людей, не один клієнт. Числа — заокруглені діапазони, не гарантії.

Tool tip (AIAdvisoryBoard.me): Shared-context док живий рівно настільки, наскільки є дисципліна підпису. Док, що дрейфує тиждень, стає доком, що дрейфує місяць, стає доком, якому ніхто не довіряє. Plan → Fact → Gap виносить SLA-підпису в щоденний digest: які доки чернетили, хто підписав за 4 години, хто прослизнув. Власники не мусять памʼятати SLA — система нагадує, поіменно, наступного ранку. https://aiadvisoryboard.me/?lang=en.

FAQ

Хіба це не просто project charter? Charter статичний — пишеться на kickoff, рідко оновлюється. Shared-context док живий — оновлюється щотижня, з delta-логом. Форма (5 секцій) перетинається; каденс (і AI-чорнетка) — це те, що робить його реально несучим.

Що, якщо власник не підпише за 4 години? Док показує "stale: not verified" банер, а щоденний Gap іменує проект. Після двох послідовних провалів — 5-хвилинна розмова з owner-of-owners (CEO, COO, голова proj ops). Механізм соціальний, не технічний.

Чи може AI писати секцію 4? Частково — зі Slack-тредів і транскриптів зустрічей, де альтернативи обговорювалися і відкидалися. Власник зазвичай додає рядок "чому", бо інференція мотиву — найслабша частина AI.

Чи потрібен project lead, якщо док володіє контекстом? Так — док це артефакт, не decision-maker. Project lead — це named-власник, що підписує. Док лише означає, що lead не мусить бути єдиним носієм контексту.

Чи працює це для постійних операцій, не лише проектів? Так — постійні операції (support, sales motion) виграють з тої ж форми, оновлюваної щомісяця замість щотижня. Каденс зсувається; структура тримається.

Висновок

Тракер каже, що відбувається. Shared-context док каже чому, що відкинули, що змінюється. AI достатньо швидкий, щоб писати друге щопонеділка; підпис власника тримає чесно. Пʼять секцій, один власник, один 4-год SLA.

Візьми найбільш крос-функціональний проект. Напиши shared-context док у цьому шаблоні вручну цього тижня. Додай AI-щотижневе оновлення наступного. Подивись, де зникають re-litigation розмови.

Якщо хочеш систему, що сама виносить Plan → Fact → Gap — щодня, по всій компанії — подивись, як працює 7-денна діагностика: https://aiadvisoryboard.me/?lang=en.