§3.03 Структура пака: 7 разделов
Время: 45 мин чтение + 30 мин
В одном предложении: Человек думает, что Pack — это просто папка с полезными заметками, а на самом деле Pack представляет собой архитектуру с семью несущими стенами, и если одна из стен прорехана, вся конструкция дрейфует, даже когда кажется, что «всё работает».
Мем, который снимается. «У меня в Pack всё нужное: онтология, методы, формы, примеры. Структура не важна, важно только содержание. Я и так найду, что нужно.» На самом деле структура не обёртка, а несущий каркас. Когда структура неясна, новые понятия появляются хаотично: метод попадает в онтологию, пример оказывается в формах, а онтологическая связь уходит в методы. Через год Pack превращается в свалку, которую вы называете «базой знаний». Семь разделов Pack не придуманы для красоты. Каждый отвечает на свой вопрос, и ответы на эти вопросы вместе создают целостную картину.
Понятия. Pack состоит из семи разделов. 00-manifest: назначение и границы Pack. Зачем он существует, что входит, что не входит, кто владелец. 01-contract: контракты использования. Соглашения о том, как Pack обновляется, кто может изменять, как разрешаются споры. 02-entities: онтология домена. Сущности, их атрибуты, отношения. Это карта мира, в котором работает пилот. 03-methods: методы и протоколы. Как действовать в типовых ситуациях. 04-work-products: рабочие продукты. Шаблоны, критерии приёмки, примеры. 05-failure-modes: режимы отказа. Что может пойти не так, как распознать, как действовать. 06-sota: состояние искусства. Что известно миру по теме Pack, какие источники используются. 07-map: навигация. Оглавление, индексы, граф связей, поисковые механизмы. Каждый раздел имеет чёткое назначение, и пересечение разделов запрещено: метод не должен дублироваться в онтологии, пример не должен заменять протокол.
Объяснение. Разделы Pack работают как слои обороны. 00-manifest защищает от размывания границ: когда Pack начинает хранить всё подряд, манифест напоминает, зачем он создан. 01-contract защищает от конфликтов изменений: кто обновляет, кто проверяет, как часто. 02-entities защищает от хаоса понятий: каждая сущность имеет место, атрибуты, связи. 03-methods защищает от импровизации: типовые ситуации имеют протоколы, не нужно изобретать каждый раз. 04-work-products защищает от разнобоя форматов: шаблоны обеспечивают единообразие. 05-failure-modes защищает от повторения ошибок: прошлые отказы зафиксированы и известны. 06-sota защищает от provincialism: Pack знает, что происходит за его пределами. 07-map защищает от потери: даже в большом Pack можно найти нужное. Слабость одного раздела компенсируется другими, но не бесконечно. Если 02-entities пустой, 03-methods работают в вакууме: протоколы не знают, к каким сущностям применяться. Если 05-failure-modes пустой, ошибки повторяются, потому что никто не зафиксировал урок. Если 07-map пустой, Pack превращается в лабиринт, и даже владелец теряется.
На практике. Практика «Аудит семи разделов» (30 мин):
- Откройте ваш Pack. Найдите каждый из семи разделов или их аналоги. (5 мин)
- Для каждого раздела оцените полноту по шкале 0–3: 0 = отсутствует, 1 = есть, но скудно, 2 = достаточно, 3 = исчерпывающе. (15 мин)
- Найдите слабейший раздел (оценка 0 или 1). Составьте план: три действия, которые повысят его до 2. (10 мин)
Типичный кейс. Программист тридцати лет создал Pack для своего проекта: онтология, методы, шаблоны кода. Через год Pack вырос до пятидесяти файлов, но новые разработчики тратили по неделе на погружение. Аудит показал: 00-manifest был одной строкой («Pack для проекта X»), 01-contract отсутствовал, 05-failure-modes был пуст, 07-map: просто список файлов. Программист написал манифест: зачем Pack, что входит, что не входит, кто владелец. Добавил контракт: как обновлять, кто ревьюит, как часто. Заполнил failure-modes: три типичные ошибки и способы их избежать. Создал карту: граф связей между понятиями. Новые разработчики стали погружаться за два дня вместо недели, а количество повторных ошибок сократилось наполовину.
Типичная ошибка. «Мне не нужен манифест, я и так знаю, зачем мой Pack.» Знаете сейчас. Через полгода забудете. А если Pack увидит другой человек, он вообще не поймёт. Манифест нужен не для красоты, а для выживания. Другая ошибка: «Failure-modes негативны: я не хочу фокусироваться на ошибках.» Failure-modes не негатив, а вакцинация. Зафиксированная ошибка не повторяется. Незафиксированная повторяется бесконечно.
Степени мастерства:
- Объяснение. Могу назвать семь разделов Pack и объяснить назначение каждого. Критерий перехода: провёл аудит своего Pack.
- Умение. При создании нового артефакта определяю, в какой раздел Pack он попадает, и помещаю туда. Критерий перехода: десять артефактов размещены в правильных разделах.
- Навык. Системно поддерживаю баланс разделов: слабые усиливаю, перегруженные разделяю. Критерий перехода: коллега заметила, что мой Pack «легко читается, хотя он большой».
- Мастерство. Проектирую Pack для предметной области: создаю структуру, которая масштабируется под рост знаний. Критерий перехода: другой человект использовал вашу структуру Pack для своей предметной области.
Проверка себя.
- Могу назвать семь разделов Pack и для каждого привести один пример из своего Pack
- Провёл аудит полноты разделов за последние три месяца
- Есть раздел, который я усилил на основе аудита
- Новый артефакт я помещаю в правильный раздел, а не «куда получится"
- Могу объяснить новому человеку, как устроен мой Pack, за пять минут
На практике. Откройте ваш Pack. Найдите раздел с наибольшим количеством файлов. Задайте вопрос: «Все ли эти файлы принадлежат этому разделу?» Переместите один файл, который попал сюда случайно, в правильное место. Это и есть поддержание структуры.
См. также: Pack и DS: PD.GUIDE.3.S2.SS2, Иерархия знаний: PD.GUIDE.3.S3.SS2.
Что дальше. Следующий подраздел посвящён фундаментальным принципам и онтологической целостности: как убедиться, что Pack не противоречит сам себе.