«Тупой карандаш лучше острой памяти».
— поговорка
Программа трансформации живёт дольше, чем память любого её участника. Через полгода люди сменились, чатов с ИИ у команды — десятки, а заказчик спрашивает, почему в марте решили именно так. Чат с моделью — удобный интерфейс, но не база знаний: в нём нет версий, оснований решений и порядка, понятного всей команде. Показываю, как собрать память проекта из четырёх простых файлов и где в ней место NotebookLM и GitHub.
Фразу из эпиграфа приписывают разным людям, первоисточник я не нашёл. А вот история про силу записанного вполне документальная. Социолог Никлас Луман с 1950-х годов вёл картотеку и к концу жизни собрал около девяноста тысяч карточек, связанных ссылками друг с другом. В статье 1981 года он называл картотеку партнёром по общению: она помнила связи, которые сам он уже забыл, и иногда удивляла его. Ящик с бумажками стал собеседником, потому что в нём была структура, а не просто стопка заметок.
Сегодня у каждой команды есть собеседник посильнее — языковая модель. Но без структуры она помнит ровно один разговор.
Почему чат — не память
Чат хорош как окно, через которое задают вопросы. Хранилищем он быть не может:
- контекст живёт у одного человека, а не у команды;
- нет версий: непонятно, какая выгрузка и какой вывод последние;
- решения есть, а оснований и отвергнутых вариантов нет;
- новый чат начинается с нуля, а новый участник — с пересказа;
- проверить, откуда взялось утверждение, нельзя.
В записи «Чему консультанты могут научиться у вайб-программистов» я сформулировал это так: хороший проект как хороший репозиторий — гипотезы, принятые решения, причины отказа от альтернатив и договорённости с клиентом должны быть письменными.
Сквозной пример — условная программа операционной трансформации: полгода, три потока (производство, логистика, закупки), офис программы, внутренние эксперты и внешние консультанты. К четвёртому месяцу руководитель одного из потоков сменился. Пример собирательный, а не про конкретного клиента.
Четыре файла
Память проекта не обязана быть сложной системой. Достаточно четырёх текстовых файлов в формате Markdown — простой текст с заголовками, который читают и люди, и любая модель, и который не привязан ни к одному сервису.
PROJECT.md — что это за проект
Цель, границы, заказчик и участники, потоки и их владельцы, текущий статус, глоссарий: как называются показатели и что именно под ними понимается. Это первое, что читает новый участник, и первое, что получает модель перед любой задачей. В примере здесь записано, что «простой» в производстве и «простой» в логистике считают по-разному, — иначе через месяц потоки сравнивают несравнимое.
DECISIONS.md — что и почему решили
Журнал решений: дата, решение, кто принял, на каких фактах, какие варианты отвергли и почему, что из этого следует. Самый ценный и самый заброшенный файл. Через полгода никто не помнит, почему отказались от централизованного склада, а короткая запись отвечает на это сразу. В примере она выглядит так:
- что решили: централизованный склад не строим, склады остаются на площадках;
- кто: управляющий комитет программы;
- на чём: расчёт плеча доставки и запасов по трём площадкам — ссылка на файл в SOURCES.md;
- что отвергли и почему: централизацию — выигрыш в запасах не перекрывает рост сроков поставки на площадки;
- что следует: поток логистики пересматривает нормативы запасов на каждой площадке.
TASKS.md — что открыто
Задачи, открытые вопросы и гипотезы с владельцем, сроком и статусом. В программе удобно делить по потокам. Гипотезам можно отвести отдельный файл, если их много: гипотеза, доказательства, статус проверки.
SOURCES.md — откуда что взялось
Реестр источников: файл или документ, откуда получен, дата, насколько достоверен, можно ли отдавать во внешние сервисы. Без него любая цифра на слайде рано или поздно становится цифрой «откуда-то».
Где здесь NotebookLM
NotebookLM и похожие сервисы — слой вопросов поверх отобранных документов: регламентов, протоколов, интервью, отчётов. В обзоре ИИ-инструментов для руководителя проектов я называл его единой базой знаний команды, которая работает строго по загруженным документам. Если ресурсов разворачивать что-то своё нет, с него проще всего начать. Уточню то, что тогда не договорил: базой для вопросов — да, хранилищем — нет. Исходники, решения и версии должны жить в контролируемом месте, а в NotebookLM — копия для вопросов.
Где здесь GitHub
Четыре файла можно держать и в общей папке с историей версий. GitHub даёт больше: видно, кто и когда изменил решение, можно обсудить правку до того, как она попала в память, а задачи живут рядом с файлами. Для команды трансформации это не про код, а про историю изменений. Репозиторий закрытый, а где он живёт — согласуется с ИБ клиента. Порог входа есть: людям без опыта разработки GitHub поначалу непривычен. И одно правило: задачи живут в одном месте — либо в TASKS.md, либо в задачах GitHub, но не в обоих.
Командная работа
Память ломается не на технологии, а на привычках. Работают простые правила:
- кто и когда пишет. В течение дня каждый добавляет факты, вечером — короткий разбор, что поменялось в решениях и вопросах;
- одно имя — одно понятие. Новый показатель сначала появляется в глоссарии;
- факт, гипотеза и вывод не смешиваются. У каждого утверждения есть пометка и источник;
- у каждого файла есть хозяин. Он отвечает, чтобы файл не устарел;
- персональные и чувствительные данные клиента обезличиваются до того, как попадут в память, а что можно отдавать модели — решено заранее.
Без этих правил, как я писал в разборе диагностики без аналитиков, общая память быстро превращается в общую свалку.
Например, на одном из проектов сам ИИ себе придумал правило, что клиент находится под санкциями и ему нельзя предлагать никакие международные решения и продукты. Мы обнаружили это только через день, когда уже напрямую спросили у нейросети «Почему ты не предлагаешь клиенту воспользоваться ХХХ?» Это стоило команде лишних часов 5 работы, чтобы переделать анализы и слайды
Что это даёт в нашем примере. Новый руководитель потока в первый день читает PROJECT.md и DECISIONS.md, а потом спрашивает модель, которой дан доступ к памяти: «почему в марте отказались от централизованного склада?» Если решение записано, ответ придёт со ссылкой на запись в журнале и на расчёт, на котором оно держалось, — и запись стоит открыть, а не верить пересказу модели. Погружение начинается не с пересказа от коллег, а с документа, где видно, что известно, что решено и что открыто.
Риски и ограничения
- Свалка. Память без правил и хозяина растёт и перестаёт читаться. Лучше четыре живых файла, чем сорок мёртвых.
- Конфиденциальность. Память — концентрат знаний о клиенте. Где она лежит, кто к ней имеет доступ и что из неё уходит во внешние сервисы, решается до первой записи.
- Иллюзия полноты. Модель отвечает по тому, что записано. Чего нет в памяти, того для неё нет, и уверенный ответ по неполной памяти опаснее, чем «не знаю».
- Память не заменяет площадку. Записанное наблюдение — это след гембы, а не гемба.
С вопроса, почему чат с ИИ ещё не система работы, начнётся бесплатный практикум 31 октября. Дальше — реальный обезличенный проект: больше сотни рабочих файлов и интервью с восемью функциями, из которых за три дня получился проект отчёта. Покажу, как это было устроено и что в этой работе осталось за людьми. Полтора часа разбора и полчаса на вопросы.
Записаться на бесплатный практикум — или в Telegram: @AI_native_reg_bot