Єдиний контекст команди: спільні правила роботи з ШІ

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

Зміниться при цьому спосіб роботи, а не набір інструментів. Кожен може лишитися на своєму асистенті.

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

Короткий словник

• Спільний контекст — відібрані матеріали про бізнес і роботу команди, доступні кожному співробітнику та його ШІ-асистенту.
• Правило — письмова вимога до роботи, розкладена на кроки, які можна виконати й перевірити.
• Процедура — опис повторюваної задачі: що на вході, які кроки, що на виході, як перевіряють результат.
• Git-репозиторій — сховище файлів з історією всіх змін: видно, хто й коли правив і до чого можна повернутися.
• teamai-cli — відкритий проєкт Tencent, який тримає спільний контекст, правила та процедури в такому сховищі й синхронізує їх з асистентом кожного учасника.

Чому особиста швидкість від ШІ не стає швидкістю команди

Окремий помічник під кожну задачу вже не виглядає розумним вкладенням. Копірайтер, фільтр резюме, генератор документів: раніше під кожен сценарій робили свій інструмент і окремий вхід, а зараз співробітник відкриває універсального ШІ-асистента й отримує те саме без переходів між сервісами.

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

Контекст доводиться вводити заново в кожному новому діалозі

Відкрили нове вікно діалогу: передісторію проєкту, стан справ, визначення термінів і раніше ухвалені рішення треба вставляти знову. Долучився новий співробітник, і все повторюється по колу.

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

Двоє співробітників на одній посаді здають несумісні результати

Доручіть одну задачу двом співробітникам на однакових посадах. Вони сформулюють запит по-різному, дадуть асистенту різні вхідні матеріали й здадуть роботи, які відрізняються за повнотою та стилем настільько, що зводити їх докупи дорожче, ніж зробити заново.

Типова картина після робочої наради: хтось дав асистенту протокол, хтось повний запис розмови, хтось додав сторонню методику з інтернету.

Вдалі прийоми застрягають в особистих чатах

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

Що таке єдиний контекст команди і чим він відрізняється від папки з документами

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

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

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

Спільний контекст не замінює постановку задачі. Він знімає повторюваний переказ передісторії, але що саме зробити цього разу, людина однаково формулює сама.

Чому архів усіх документів компанії не працює як контекст

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

Відбирати доводиться руками. Критерій простий: матеріал потрапляє в сховище, якщо хтось у команді справді буде спиратися на нього в роботі.

Довгий документ має ще один побічний ефект: частина вимог губиться, коли діалог розростається, і правила перестають діяти в довгому чаті. Коротке сховище виграє навіть технічно.

Три типи вмісту спільного сховища: фактаж, правила й процедури

Головне рішення під час збирання сховища: куди покласти конкретний матеріал. Помилка тут дорожча за решту, бо фактаж, записаний як постійне правило, живе в сховищі місяцями після того, як перестав відповідати дійсності.

Змінний фактаж: стан справ, асортимент, ухвалені рішення

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

Постійні правила: термінологія, тон і вимоги до результату

Те, що діє для всіх і щоразу. Як називаємо речі (одне поняття, одне слово), яким тоном говоримо з клієнтом, що обов'язково має бути в готовій роботі.

Правила читають постійно, тому їх тримають короткими. Довгий трактат ніхто не виконує, причому це стосується і людей.

Оформлені процедури під повторювані задачі

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

Одноразову задачу оформлювати не треба. Якщо вона не повториться, опис стане мертвим файлом, який плутає.

Тип вмісту	Що туди належить	Як часто оновлюють	Хто відповідає
Фактаж	Стан справ, асортимент, домовленості, ухвалені рішення	За подією: щось змінилося, запис поправили	Той, хто ближче до даних: керівник напряму або власник процесу
Правила	Термінологія, тон, вимоги до готової роботи	Рідко, після розбору помилок	Той, хто формулює доручення для асистентів
Процедури	Повторювані задачі з кроками та перевіркою	Коли змінився сам порядок роботи	Виконавець задачі разом із тим, хто приймає результат

Як переписати гасло на правило, яке ШІ справді виконує

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

Робоче правило відповідає на п'ять питань.

Чеклист готовності правила: що прочитати, що перепитати, що здати

• Що прочитати спершу. Які матеріали зі сховища потрібні, щоб узятися за задачу.
• Чого перепитати. Яких даних без людини не дістати й що робити, якщо їх немає.
• Що здати. Склад готової роботи: формат, обов'язкові частини, обсяг.
• Як перевірити. За якими ознаками видно, що роботу можна передавати далі.
• Хто підтверджує. Людина, без якої результат не йде наступному виконавцю.

Якщо хоч один пункт лишився порожнім, правило працюватиме через раз.

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

Приклади формулювань до і після

Гасло	Правило, яке можна виконати
Пиши зрозуміло	Прочитай профіль читача зі сховища. Терміни пояснюй при першій згадці. Перевір, чи є відповідь на питання читача в перших рядках
Цифри мають бути точні	Бери показники лише зі звіту за минулий місяць. Потрібного показника немає — перепитай фінансиста. У готовій роботі познач, звідки взято кожен показник
Враховуй наші стандарти	Прочитай вимоги до готової роботи та опис процедури для цієї задачі. Перед здачею пройди перевірку за чеклистом і зафіксуй її результат

Готові шаблони для відділів і спільні стандарти якості

Писати правила з нуля боляче й довго. Готові шаблони для відділів (продукт, маркетинг, фінанси, кадри) знімають найтяжчу частину: у них уже є опис процесу, місце під командний контекст, вимоги за посадами, процедури й шаблони готової роботи.

Команді залишається додати власні дані та підкрутити посади, спосіб обліку показників і вимоги до погодження. Це робота на кілька днів.

Чому стандарти мають діяти для всіх, хто взявся за задачу

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

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

Перевірка результату тут важить більше за вибір моделі. Про це варто почитати окремо: рівні контролю для надійних AI-агентів описані на конкретних процесах.

Що таке teamai-cli і яку частину роботи він знімає

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

Інструмент знімає механіку роздачі. Вирішувати, що саме покласти в сховище і як сформулювати правило, однаково доводиться команді.

Де тримати спільний контекст: спільний диск, база знань чи git-репозиторій

Технічна частина тут другорядна. Спільний диск годиться, коли правил мало й змінюють їх рідко; база знань зручна, коли матеріалів багато й потрібні пошук і посилання між ними; git-репозиторій виграє там, де правила правлять часто та важливо бачити історію змін.

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

Що робити зі суперечностями й застарілим у спільному контексті

Сховище живе, тому суперечності з'являються неминуче: старий регламент проти свіжого рішення, дві версії одного порядку в різних файлах.

Яке рішення головніше і як позначити скасоване

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

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

Хто відповідає за спільний контекст і що буде, якщо власника немає

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

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

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

З чого почати в команді з кількох співробітників

Один відділ, одна повторювана задача, перевірка на реальних дорученнях

Маркетинговий відділ зручний як перший кандидат: там багато повторюваних задач і швидко видно результат.

Ознаки, що пора розширювати на інші задачі та відділи

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

Як зрозуміти, що підхід працює: за якими ознаками міряти результат

• Час на пояснення задачі. Скільки триває постановка, коли передісторію не треба переказувати.
• Кола правок до приймання. Скільки разів роботу повертають виконавцю.
• Повторні питання про дані. Як часто питають, де взяти показник або документ.
• Введення нового співробітника. За скільки часу він починає здавати роботу, яку приймають без переробки.

Орієнтири в кожної команди свої, тому міряти варто до і після, на тих самих задачах.

Типові помилки впровадження

• Правила написані як декларації. Гасла, які неможливо виконати й перевірити.
• Контекст завели й забули. Немає відповідального, записи застаріли, довіра до сховища зникла.
• Кожен відділ зробив своє сховище. Термінологія знову розійшлася, а передача роботи між відділами не стала простішою.
• Стандарти існують лише на папері. Ніхто не перевіряє роботу за ними, тому їх і не читають.
• Почали з усієї компанії відразу. Описали правила для всіх відділів і отримали документ, яким ніхто не користується.

Що залишається за людиною навіть із налаштованим контекстом

Приймання результату. Рішення про виняток, коли задача не вкладається в правило. Оновлення фактажу після змін у бізнесі.

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