ФИЛОСОФИЯ: Принципы построения систем

Любая система имеет уровни абстракции:

    АБСТРАКТНОЕ (идеи, принципы)
         │
         ▼
    КОНКРЕТНОЕ (реализация, код)

Полное описание системы отвечает на 8 вопросов:

    0. ЗАЧЕМ?    ← Цель, мотивация
    1. ЧТО?      ← Границы, состав
    2. КАК?      ← Метод, процесс
    3. КТО?      ← Роли, ответственность
    4. ЧЕМ?      ← Инструменты, технологии
    5. ГДЕ?      ← Среда, инфраструктура
    6. КОГДА?    ← Время, последовательность
    7. СКОЛЬКО?  ← Метрики, измерение

Система может описывать сама себя:

    Платформа управления проектами
         │
         └── сама является проектом
              │
              └── управляется той же платформой

Уровень 0: Концепция (неизменно)
    │
    ▼
Уровень 1: Стандарты (редко меняется)
    │
    ▼
Уровень 2: Паттерны (растёт)
    │
    ▼
Уровень 3: Шаблоны (активно используется)
    │
    ▼
Уровень 4: Реализация (постоянно меняется)

┌─────────────────┐     ┌─────────────────┐
│   ОПИСАНИЕ      │     │   РЕАЛИЗАЦИЯ    │
│   (что хотим)   │ ──► │   (что сделали) │
│                 │     │                 │
│   • Документы   │     │   • Код         │
│   • Схемы       │     │   • Конфиги     │
│   • Требования  │     │   • Данные      │
└─────────────────┘     └─────────────────┘

Каждый уровень — слот, куда можно вставить:

    ┌─────────────────────────────────┐
    │  [  СТАНДАРТ  ]                 │
    │                                 │
    │  • Открытый (ISO, PMBOK)        │
    │  • Отраслевой (TOGAF, ITIL)     │
    │  • Свой (если нет подходящего)  │
    └─────────────────────────────────┘

Одна истина — одно место.
Если что-то повторяется → вынести в шаблон/паттерн.

Сложность — враг.
Минимум необходимого для решения задачи.

Не делай то, что не нужно сейчас.
Будущие требования — будущие решения.

Ошибка должна быть видна сразу.
Валидация на входе, не на выходе.

Любой участник может увидеть:
• Текущее состояние
• Историю изменений
• Причины решений

От требования до кода — прослеживаемый путь:

    Цель → Требование → Задача → Код → Тест

Всё имеет версию:
• Документы
• Код
• Конфигурации
• Решения

Плохо: Спроектировать всё заранее
Хорошо: Итеративное уточнение

Плохо: Писать своё, когда есть готовое
Хорошо: Использовать стандарты, расширять при необходимости

Плохо: Один инструмент для всего
Хорошо: Правильный инструмент для задачи

Плохо: Оптимизировать до измерения
Хорошо: Сначала работает, потом быстро