Александр Костин – Второй мозг с ИИ: как управлять знаниями, проектами и решениями (страница 6)

стандартные типы заметок;

фиксированные проектные страницы;

небольшое число рабочих тегов;

регулярная обработка.

Артефакт: минимальная структура, которую можно внедрить за один вечер

Ниже – вариант архитектуры, который можно внедрить быстро и который масштабируется.

Верхний уровень:

INBOX

PROJECTS

AREAS

KNOWLEDGE

TEMPLATES (можно как часть KNOWLEDGE, но отдельный раздел удобен)

ARCHIVE (для закрытых проектов и старого материала)

Внутри PROJECTS:

каждый проект = папка/страница проекта (центр) + подпапка/связанные заметки

в проекте хранить: протоколы, решения, материалы, ссылки, итоговые документы

на проектной странице: цель, критерии успеха, план, решения, задачи, риски, ссылки

Внутри AREAS:

по основным областям ответственности: команда, финансы, продажи, маркетинг, обучение, здоровье и т.д.

там – регулярные процессы, правила, рутинные заметки

Внутри KNOWLEDGE:

инструкции, чек-листы, принципы, глоссарий, конспекты

выделить «ядро» – раздел с evergreen-заметками (темы, к которым возвращаетесь)

Теги (пример минимального набора):

#решение

#протокол

#чеклист

#шаблон

#риск

#идея

#справка

#в_работе

#на_проверку

#важное

Этого достаточно, чтобы система была предсказуемой и управляемой. Дальше вы расширяете не «папки ради папок», а только когда появляется реальная потребность.

Итоги

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

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

Глава 4. Кодирование опыта: как превращать заметки в инструкции, шаблоны и правила, которые работают без вас

Большинство баз знаний умирает по одной причине: там много текста, но мало «исполняемых» единиц. Люди сохраняют статьи, пишут конспекты встреч, фиксируют идеи, складывают ссылки – и всё это выглядит как работа с информацией. Но в момент, когда нужно действовать, база не помогает. Она не даёт чётких шагов. Не подсказывает критерии качества. Не напоминает про риски. Не ускоряет повторение. В лучшем случае она служит архивом, в худшем – кладовкой, где всё полезное похоронено под слоями «когда-нибудь пригодится».

Чтобы второй мозг стал инструментом, который реально снимает нагрузку с головы и повышает результат, нужно уметь «кодировать опыт». Это значит превращать сырые заметки в такие формы, которые можно воспроизводить: инструкции, чек-листы, шаблоны, правила принятия решений, таблицы критериев (не в смысле оформления, а в смысле системы оценки), стандартные сценарии коммуникации. Другими словами, вы упаковываете опыт в формат, который работает даже тогда, когда вы устали, заняты, или когда задачу выполняет другой человек.

В этой главе мы разберём: как понять, что заметка достойна превращения в инструкцию; как отличать инструкции от чек-листов и шаблонов; как делать правила принятия решений и «антиошибочные» барьеры; как использовать нейросеть для ускорения упаковки, не отдавая ей власть над смыслом; и как построить цикл, в котором ваш опыт превращается в капитал, а не растворяется в потоке задач.

Почему «текст» не равен «знание»: проблема невоспроизводимости

Если вы открываете заметку и видите длинный текст, это не гарантирует, что вы сможете применить его завтра. Знание в рабочем смысле – это способность повторить результат. Если вы не можете повторить, вы не владеете знанием в операционном смысле.

Невоспроизводимость проявляется в двух ситуациях.

Первая: вы сами пытаетесь повторить удачный результат и не понимаете, какие именно шаги были критичными. Например, вы однажды сделали сильное КП, но через месяц делаете новое и снова мучаетесь, потому что «не помните, как собирали». Значит, результат был, но он не стал системой.

Вторая: вы делегируете задачу и получаете непредсказуемое качество. Исполнитель вроде бы «понял», но сделал иначе. Это не всегда его вина. Часто просто нет стандарта: нет критериев, нет примеров, нет чек-листа, нет последовательности, которую нужно соблюдать.

Кодирование опыта решает обе проблемы. Оно превращает удачные результаты в «повторяемые единицы»: вы можете повторить сами и можете передать другому.

Единицы исполнения: инструкция, чек-лист, шаблон, правило

Чтобы не путаться, важно различать четыре формата. Они похожи, но отвечают на разные задачи.

Инструкция (SOP) – это последовательность шагов «как сделать». Она нужна, когда важно соблюсти процесс, чтобы получить стабильный результат. Инструкция отвечает на вопросы: что делаем, в какой последовательности, какие входные данные нужны, какие инструменты используем, какой результат на выходе, как проверить качество.

Чек-лист – это контроль «что не забыть». Он нужен, когда процесс может быть разным, но есть критические пункты, которые нельзя пропустить. Чек-лист отвечает на вопрос: выполнены ли обязательные условия и критерии.

Шаблон – это форма «как оформить результат». Он нужен, когда вы делаете повторяемый документ: отчёт, письмо, бриф, ТЗ, коммерческое предложение, протокол. Шаблон отвечает на вопрос: какие блоки должны быть, какие вопросы нужно закрыть, какие данные собрать, какие формулировки использовать.

Правило – это короткое «если-то», которое помогает принимать решения. Например: «если задача затрагивает юридические риски, фиксируем решение и источник», «если KPI не определён, проектная страница не считается заполненной», «если работа повторяется два раза, создаём шаблон/чек-лист». Правило отвечает на вопрос: как мы выбираем и как не допускаем ошибок.

Эти форматы вместе создают операционную систему. Инструкции делают работу воспроизводимой, чек-листы защищают от пропусков, шаблоны ускоряют оформление, правила стабилизируют решения.

Когда заметку нужно «кодировать»: триггеры, которые не дают базе превратиться в архив

Если пытаться превращать в инструкции всё подряд, вы утонете. Поэтому нужен набор триггеров – критериев, по которым вы решаете: да, это надо превратить в исполняемую единицу.

Триггер 1: повторяемость. Если действие повторилось два-три раза, пора делать шаблон/чек-лист. Не нужно ждать десяти повторов. Чем раньше вы упакуете, тем больше времени сэкономите.

Триггер 2: высокая цена ошибки. Даже если действие редкое, но ошибка дорого стоит (деньги, репутация, юридические последствия, срыв срока), нужен чек-лист или инструкция. Это относится к договорам, публикациям, критическим изменениям на сайте, финансовым операциям, коммуникации с крупными клиентами.

Триггер 3: делегирование. Всё, что вы планируете отдавать другим, должно иметь минимальный стандарт: входные данные, критерии качества, формат результата, примеры. Без этого делегирование превращается в постоянные исправления.

Триггер 4: «лучший результат». Если вы сделали что-то особенно хорошо и хотите повторять, это кандидат на шаблон. В противном случае вы будете снова делать «с нуля» и получать среднее качество.

Триггер 5: конфликт мнений. Если в команде разные подходы, нужен стандарт. Иначе вы получаете хаотичную вариативность и вечные споры.

Если вы внедрите эти триггеры, база перестанет быть кладовкой и начнёт производить активы.

Как писать инструкции, которые реально выполняют: структура «вход → шаги → выход → контроль»

Плохие инструкции бывают двух типов. Одни слишком общие: «сделайте анализ», «проверьте качество», «настройте проект». Другие слишком подробные: на 15 страниц, где теряется главное, и никто не читает. Хорошая инструкция находится между: она достаточно конкретна, чтобы дать воспроизводимость, и достаточно компактна, чтобы ей реально пользовались.