Skip to content
 
 

Latest commit

 

History

35 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SRT Template

Шаблон хранилища знаний по методу SRT (Systems-Roles-Table) — организация проекта через таблицу 3×3 систем и ролей с интеграцией First Principles Framework (FPF).

Для кого этот шаблон

  • Проектные команды — организация знаний о продукте
  • Стартапы — структурирование описания проекта
  • Разработчики — документация архитектуры и процессов
  • Исследователи — управление базой знаний

Что такое SRT-метод

SRT (Systems-Roles-Table) — это способ организации знаний через таблицу 3×3, которая определяет 9 семейств документов + 1 метасемейство (управление хранилищем).

Таблица 3×3: 9 семейств документов

                     Предприниматель  Инженер           Менеджер
                     (Зачем?)         (Как устроено?)   (Как работает?)
┌────────────────────────────────────────────────────────────────────┐
│ Suprasystem        F1               F2                F3           │
│ (Надсистема)       Контекст         Окружение         Взаимодействие
│                    и рынок          и интерфейсы      и партнёрства│
├────────────────────────────────────────────────────────────────────┤
│ System-of-Interest F4               F5                F6           │
│ (Целевая система)  Требования       Архитектура       Реализация   │
│                    и ценность       продукта          и процессы   │
├────────────────────────────────────────────────────────────────────┤
│ Constructor        F7               F8                F9           │
│ (Система создания) Принципы         Платформа         Команда      │
│                    и экономика      и инструменты     и методология│
└────────────────────────────────────────────────────────────────────┘

Терминология систем (из FPF):

Русский термин Английский термин (FPF) Синонимы
Надсистема Suprasystem Supersystem
Целевая система System-of-Interest (SoI) Target System
Система создания Constructor Constructor System

F0: Метасемейство — Управление хранилищем

F0 — это 10-е семейство, которое управляет остальными девятью. В отличие от F1-F9, метасемейство не делится по ролям Предприниматель/Инженер/Менеджер, а организовано по функциональным областям:

Подраздел Назначение
0.1. Логика хранилища и знаний Модель семейств, принципы, терминология
0.2. Процессы работы с хранилищем Стандарты, workflows, создание документов
0.3. Планы и совещания Координация, roadmap
0.4. Автоматические отчёты ИИ Отчёты AI о состоянии хранилища
0.9. Входящие Inbox для идей и черновиков
0.99. Архив Устаревшие документы

Все 10 семейств документов

Семейство Разработчик Целевые читатели НЕ для (примеры ошибок)
F0 Администраторы хранилища AI-агенты, редакторы Пользователи, инвесторы
F1 Маркетологи, аналитики Потенциальные клиенты, широкая аудитория Инвесторы (→F7), разработчики (→F8)
F2 Системные аналитики, Product Owner Интеграторы, партнёры Инвесторы (→F7), внутренняя команда (→F9)
F3 PR-менеджеры, BD-специалисты Партнёры, регуляторы, медиа Пользователи (→F4/F6), разработчики (→F8)
F4 Визионер, Product Owner Пользователи, заказчики Инвесторы (→F7), технические специалисты (→F8)
F5 Архитекторы, методологи Разработчики, техлиды Пользователи напрямую (→F4/F6), инвесторы (→F7)
F6 Разработчики, техническая поддержка Пользователи, операторы Инвесторы (→F7), внешние партнёры (→F3)
F7 Фаундеры, бизнес-стратеги Инвесторы, стратегические партнёры Пользователи (→F4), операционная команда (→F9)
F8 DevOps, Platform Engineers Разработчики, техлиды Пользователи (→F4), инвесторы (→F7)
F9 HR, Engineering Managers Операционная команда, новые сотрудники Пользователи (→F4), инвесторы (→F7)

Быстрый старт: Разворачивание хранилища для вашего проекта

Шаг 1: Копирование шаблона

Вариант A: Fork на GitHub

  1. Нажмите Fork на странице репозитория
  2. Укажите имя для вашего репозитория
  3. Склонируйте форк локально:
git clone https://github.com/YOUR_USERNAME/YOUR_REPO_NAME.git
cd YOUR_REPO_NAME

Вариант B: Локальное копирование

git clone https://github.com/TserenTserenov/srd-template.git my-project
cd my-project
rm -rf .git
git init

Шаг 2: Проверка FPF

Убедитесь, что FPF загружен:

# Проверить наличие FPF-Spec.md
ls -la .fpf/

# Должны быть файлы:
# - INDEX.md (~250 строк)
# - FPF-Spec.md (~43000 строк)
# - FPF-Readme.md

Обновление FPF (если нужно)

curl -sL "https://raw.githubusercontent.com/ailev/FPF/main/FPF-Spec.md" \
  -o .fpf/FPF-Spec.md

Шаг 3: Создание описания проекта

Создайте файл PROJECT_DESCRIPTION.md в корне репозитория. Используйте шаблон из файла templates/PROJECT_DESCRIPTION_TEMPLATE.md.

Что нужно для начала работы

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

  • System-of-Interest (SoI) — целевую систему, что создаём
  • Suprasystem — надсистему, в какой системе будет работать целевая система
  • Constructor — систему создания, кто и как создаёт

Мантра системного мышления: Если вы выявили целевую систему, то для неё обязательно должно быть: (1) надсистема и функция в ней, (2) подсистемы, (3) создатель (часто граф создателей).

Подробные принципы определения систем см. в system-identification.md.

Если сразу не получается сформулировать системы чётко — сделайте описание по следующему шаблону:

Структура описания:

  1. Общее описание — название, краткое описание, команда
  2. System-of-Interest (SoI) — целевая система: что создаём, для кого, какую проблему решает
  3. Suprasystem — надсистема: система пользователя/клиента, в которую целевая система входит как часть. Описание того, как целевая система встраивается в надсистему и какую роль в ней играет
  4. Constructor — система создания: команда, инструменты, методология
  5. Первичные названия систем — предложения по именованию

Шаг 4: Экспертиза описания (с AI)

После заполнения PROJECT_DESCRIPTION.md запустите экспертизу с Claude Code:

Прочитай PROJECT_DESCRIPTION.md и проведи экспертизу на основе FPF и SRT:

1. Проверь чёткость определения целевой системы (паттерны A.1, A.7)
2. Проверь полноту описания надсистемы (паттерн A.1.1)
3. Проверь реалистичность системы создания
4. Оцени предложенные названия систем
5. Дай рекомендации по улучшению

Используй паттерны FPF для обоснования критики.

Важно: На следующем шаге 5 вам потребуется определиться с тремя системами (System-of-Interest, Suprasystem, Constructor), поскольку структура хранилища строится исходя из этого. При необходимости более глубокой проработки можно отдельно поработать с FPF (.fpf/FPF-Spec.md).

Критерии качества описания

Критерий Хорошо ✅ Плохо ❌
System-of-Interest «Мобильное приложение для учёта личных финансов» — физический объект, можно измерить «Крутой продукт для людей» — абстракция
Suprasystem «Система управления личными финансами пользователя, где приложение — центральный компонент» «Рынок финтеха» — это контекст, не надсистема
Constructor «Команда 3 человека + React Native + Agile» — люди + инструменты + методы «Мы справимся» — не описывает систему

Важно по FPF (A.1): Надсистема — это система, частью которой становится целевая система, а НЕ рынок или окружение. Рынок, конкуренты, регуляторы — это контекст надсистемы (документы F1-F3), но не сама надсистема.

Типичная ошибка: сервис vs результат

Многие слова означают и процесс, и результат. Целевая система — это результат, не процесс:

Слово Процесс (❌ не SoI) Результат (✅ SoI)
Покупка «Покупка заняла 10 минут» «Покупка весит 3 кг» (товар в руках)
Доставка «Доставка занимает 2 дня» Посылка в руках получателя
Обучение «Обучение длится полгода» Мастерство (навык в голове)

Формула: Провайдер [сервис] создаёт [результат = целевая система]

Подробнее: Принципы определения систем


Шаг 5: Принятие решения о названиях систем

После экспертизы вы сами принимаете решение о названиях:

## Финальные названия систем

| Система | Название | Обоснование |
|---------|----------|-------------|
| System-of-Interest | FinTracker | Приложение для финансов |
| Suprasystem | FinMarket | Рынок личных финансов |
| Constructor | DevTeam | Команда разработки |

⚠️ Важно: Названия должны быть осмысленными и отражать суть вашего проекта.


Шаг 6: Минимальное разворачивание хранилища

После определения названий запустите команду:

Разверни минимальную структуру хранилища для проекта:

System-of-Interest: [Ваше название]
Suprasystem: [Ваше название]
Constructor: [Ваше название]

Создай:
1. Обновлённые README для каждого раздела с новыми названиями
2. По одному документу в каждой ячейке Meaning (F1, F4, F7)
3. Глоссарий проекта в 0.Management/0.1. Логика хранилища и знаний/

Результат минимального разворачивания

content/
├── 0.Management/                          # F0 — Управление (без изменений)
│   └── 0.1. Логика хранилища и знаний/
│       └── project-glossary.md            # Глоссарий ВАШЕГО проекта
├── 1.[Suprasystem]/                       # F1-F3 (переименовано)
│   └── 1.1.Meaning/
│       └── context.md                     # F1: Описание контекста
├── 2.[System-of-Interest]/                # F4-F6 (переименовано)
│   └── 2.1.Meaning/
│       └── requirements.md                # F4: Основные требования
└── 3.[Constructor]/                       # F7-F9 (переименовано)
    └── 3.1.Meaning/
        └── principles.md                  # F7: Принципы разработки

Шаг 7: Настройка автопроверок

После разворачивания настройте автоматические проверки:

Настрой автопроверки хранилища:
1. Проверь все документы по стандартам из 0.2. Процессы работы с хранилищем/
2. Сгенерируй первый отчёт в 0.4. Автоматические отчёты ИИ/
3. Покажи текущее покрытие таблицы SRT (9 семейств)

Дальнейшее развитие

Еженедельный цикл

День Активность
Понедельник Review входящих (0.9.Incoming)
Среда Создание новых документов
Пятница Проверка связей и качества

Метрики роста по семействам

Неделя F0 F1-F3 F4-F6 F7-F9 Всего
1 5 3 6 3 17
2 7 5 10 5 27
4 10 8 15 8 41
8 15 12 25 12 64

Структура репозитория

srd-template/
├── README.md                    # Этот файл
├── CLAUDE.md                    # Инструкции для AI
├── CONTRIBUTING.md              # Правила участия
├── PROJECT_DESCRIPTION.md       # Ваше описание проекта (создаёте вы)
│
├── templates/                   # Шаблоны
│   └── PROJECT_DESCRIPTION_TEMPLATE.md
│
├── .fpf/                        # First Principles Framework
│   ├── INDEX.md                 # Локальные принципы
│   ├── FPF-Spec.md              # Полная спецификация
│   └── FPF-Readme.md            # Обзор FPF
│
└── content/                     # Контент по SRT (10 семейств)
    ├── 0.Management/            # F0: Метасемейство (не делится по ролям)
    │   ├── 0.1. Логика хранилища и знаний/    # Онтология
    │   ├── 0.2. Процессы работы с хранилищем/ # Операции
    │   ├── 0.3. Планы и совещания/            # Координация
    │   ├── 0.4. Автоматические отчёты ИИ/     # Автоотчёты AI
    │   ├── 0.9. Входящие/                     # Входящие идеи
    │   └── 0.99. Архив/                       # Архив
    ├── 1.Suprasystem/           # F1-F3: Надсистема → [Ваше название]
    ├── 2.System-of-Interest/    # F4-F6: Целевая система → [Ваше название]
    └── 3.Constructor/           # F7-F9: Система создания → [Ваше название]

Ссылки


Лицензия

MIT License — используйте свободно для своих проектов.

About

The SRD (Systems Role Description) knowledge repository template – organizing a project through systems and roles

Resources

Contributing

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors