Анализ смешивания измерений в структуре планирования

Версия: 1.0.0
Дата: 2026-02-03
Проблема: Стадии 08-11 смешивают разные измерения в линейной последовательности

СУТЬ ПРОБЛЕМЫ

Текущая структура 01-11 пытается упорядочить линейно то, что должно быть организовано по разным измерениям:

01-04: БИЗНЕС (ПОЧЕМУ, ЗАЧЕМ, ЧТО) — маркетинг
05-06: РЕШЕНИЕ абстрактное (ЧТО, КАК) — IT без платформы
07:    ПЛАТФОРМА (ЧЕМ) — выбор инструмента
08-09: ТЕХНИЧЕСКОЕ (КАК детали, ГДЕ) — как реализовать, где разместить
10-11: УПРАВЛЕНИЕ (КОГДА, СКОЛЬКО) — когда делать, сколько ресурсов
       ↑ ПРОБЛЕМА: возврат к другому измерению!

ТОЧКА ЗРЕНИЯ 1: Теория 9 вопросов

Последовательные vs Параллельные

По теории вопросов (architect/theory/QUESTIONS.md):

ПОСЛЕДОВАТЕЛЬНЫЕ (обязательный порядок):
    ПОЧЕМУ → ЗАЧЕМ → ЧТО → КТО → КАК

ПАРАЛЛЕЛЬНЫЕ (независимы, после КАК):
    ЧЕМ, ГДЕ, КОГДА, СКОЛЬКО

Что мы делаем неправильно

Проблема: В стадиях 08-11 мы пытаемся последовательно пройти то, что должно быть параллельно:

07. КАК (архитектура на платформе)
    ↓
08. КАК детализировано (техническое) ← параллельный вопрос!
    ↓
09. ГДЕ (инфраструктура)             ← параллельный вопрос!
    ↓
10. КОГДА (план-график)               ← параллельный вопрос!
    ↓
11. СКОЛЬКО (бюджет)                  ← параллельный вопрос!

Правильно: После ответа на КАК (стадия 07), вопросы ЧЕМ, ГДЕ, КОГДА, СКОЛЬКО решаются одновременно, а не друг за другом.

ТОЧКА ЗРЕНИЯ 2: Измерение ОТВЕТСТВЕННОСТИ (КТО)

Кто отвечает за каждую стадию

Проблема

08-09 = техническое проектирование (как написать код, где развернуть)
10-11 = управление проектом (когда делать, сколько стоит)

Это разные профессии:
- Инженер не планирует график и бюджет
- Менеджер не проектирует архитектуру

Мы смешали проектирование решения и управление его реализацией.

ТОЧКА ЗРЕНИЯ 3: Измерение ПРИРОДЫ РАБОТЫ

Что мы делаем на каждой стадии

Проблема

Стадии 01-09 — это ЧТО и КАК (проектирование).
Стадии 10-11 — это КОГДА и СКОЛЬКО (управление).

Это разные процессы:
- Проектирование = определяем ЧТО делать и КАК это сделать
- Управление = определяем КОГДА сделаем и СКОЛЬКО потратим

Первое делает архитектор/инженер, второе — менеджер проекта.

ТОЧКА ЗРЕНИЯ 4: Измерение АБСТРАКЦИИ

Уровень детализации

01-04:  БИЗНЕС          (высокая абстракция)
        ↓
05-06:  РЕШЕНИЕ         (средняя абстракция)
        ↓
07:     ПЛАТФОРМА       (низкая абстракция)
        ↓
08-09:  РЕАЛИЗАЦИЯ      (конкретика)
        ↓
10-11:  УПРАВЛЕНИЕ      ← ⚠️ ВОЗВРАТ к высокой абстракции!

Проблема

После детализации (08-09) мы возвращаемся к высокоуровневому планированию (10-11).

Это нарушает монотонность процесса проектирования.

Правильно: сначала полностью спроектировать (от абстракции к конкретике), потом планировать выполнение.

ТОЧКА ЗРЕНИЯ 5: Измерение ДОКУМЕНТОВ

Какие документы на каких стадиях

Проблема

Документы 01-09 — это техническая документация (что и как делать).
Документы 10-11 — это управленческая документация (когда и сколько).

Разные аудитории, разные цели.

Мы смешали:
- planning/ (техническое проектирование)
- management/ (управление проектом)

КОРНЕВАЯ ПРИЧИНА

Неправильное применение линейной нумерации

Мы пытаемся применить линейную последовательность (01, 02, 03...) к многомерному пространству.

Измерения, которые смешали:
1. Ответственность (WHO): маркетинг → IT → PM
2. Тип вопроса (последовательный → параллельный)
3. Природа работы (проектирование → управление)
4. Абстракция (высокая → низкая → снова высокая)
5. Тип документа (технический → управленческий)

Прежние наработки, которые применили неверно:

1. ✅ Последовательность вопросов (ПОЧЕМУ → ЗАЧЕМ → ЧТО → КТО → КАК) — работает для 01-07
2. ❌ Линейная нумерация (01, 02, 03...) — не работает для 08-11, потому что:
   - ЧЕМ, ГДЕ, КОГДА, СКОЛЬКО — параллельны, а не последовательны
   - КОГДА, СКОЛЬКО — другое измерение (управление, не проектирование)

ПРАВИЛЬНАЯ СТРУКТУРА

По теории 9 вопросов

ПРОЕКТИРОВАНИЕ (последовательно):
├── 01. ПОЧЕМУ - проблема (маркетинг)
├── 02. ЗАЧЕМ - цель (маркетинг)
├── 03. ЧТО - сущность решения (маркетинг → IT)
├── 04. КТО - участники (маркетинг → IT)
├── 05. КАК абстрактно - решение без платформы (IT)
├── 06. ЧЕМ - выбор платформы (IT)
└── 07. КАК конкретно - архитектура на платформе (IT)

ДЕТАЛИЗАЦИЯ (параллельно):
├── 08. ГДЕ - инфраструктура (IT/DevOps)
├── 09. ЧЕМ детально - технологии, библиотеки (IT)
└── 10. КАК детально - спецификации (IT → Coder)

УПРАВЛЕНИЕ (параллельно, но отдельно):
├── КОГДА - план-график (PM)
└── СКОЛЬКО - бюджет (PM/финансы)

Структура папок

Вариант 1: По измерениям

projects/org/lideravto/
├── planning/                    ← ПРОЕКТИРОВАНИЕ (IT)
│   ├── 01-why.md                ← ПОЧЕМУ (бизнес)
│   ├── 02-goals.md              ← ЗАЧЕМ (бизнес)
│   ├── 03-what.md               ← ЧТО (бизнес → IT)
│   ├── 04-who.md                ← КТО (роли)
│   ├── 05-solution.md           ← КАК абстрактное
│   ├── 06-platform.md           ← ЧЕМ (выбор платформы)
│   ├── 07-architecture.md       ← КАК конкретное
│   │
│   └── details/                 ← ДЕТАЛИЗАЦИЯ (параллельно)
│       ├── infrastructure.md    ← ГДЕ (08)
│       ├── technologies.md      ← ЧЕМ детально (09)
│       └── specifications/      ← КАК детально (10)
│           └── CODE-PROMPT-*.md
│
├── management/                  ← УПРАВЛЕНИЕ ПРОЕКТОМ (PM)
│   ├── schedule.md              ← КОГДА
│   ├── budget.md                ← СКОЛЬКО
│   └── risks.md
│
└── it/                          ← РЕАЛИЗАЦИЯ (код)
    └── implementation/

Вариант 2: По ролям

projects/org/lideravto/
├── business/                    ← Маркетинг/Бизнес
│   ├── 01-why.md                ← ПОЧЕМУ
│   ├── 02-goals.md              ← ЗАЧЕМ
│   ├── 03-what.md               ← ЧТО
│   └── 04-who.md                ← КТО
│
├── solution/                    ← IT (проектирование)
│   ├── 05-abstract.md           ← КАК абстрактное
│   ├── 06-platform.md           ← ЧЕМ (платформа)
│   ├── 07-architecture.md       ← КАК конкретное
│   │
│   └── specs/                   ← Детализация
│       ├── infrastructure.md    ← ГДЕ
│       ├── technologies.md      ← ЧЕМ детально
│       └── CODE-PROMPT-*.md     ← КАК детально
│
├── project/                     ← PM (управление)
│   ├── schedule.md              ← КОГДА
│   ├── budget.md                ← СКОЛЬКО
│   └── risks.md
│
└── implementation/              ← Реализация (код)

ВЫВОДЫ

Что мы поняли

1. Линейная нумерация 01-11 — неправильная модель для многомерного пространства вопросов
2. Параллельные вопросы (ЧЕМ, ГДЕ, КОГДА, СКОЛЬКО) нельзя упорядочивать последовательно
3. Проектирование (ЧТО, КАК) и управление (КОГДА, СКОЛЬКО) — разные измерения
4. Роли (маркетинг, IT, PM) должны быть явно разделены в структуре

Рекомендация

Отказаться от линейной нумерации 01-11.

Использовать структуру:
- planning/ — проектирование (01-07 последовательно + детализация параллельно)
- management/ — управление проектом (КОГДА, СКОЛЬКО)
- implementation/ — реализация (код)

Или по ролям:
- business/ — маркетинг (ПОЧЕМУ, ЗАЧЕМ, ЧТО, КТО)
- solution/ — IT (КАК, ЧЕМ, ГДЕ + спецификации)
- project/ — PM (КОГДА, СКОЛЬКО)
- implementation/ — код

СВЯЗЬ С ФАЙЛОВОЙ СИСТЕМОЙ УПРАВЛЕНИЯ ПРОЕКТАМИ

Вопрос: Можно ли вообще планирование и управление проектами построить на файлах?

Ограничения файловой системы

Что файлы НЕ умеют:
1. Многомерные связи — файл живёт в одной папке, но может относиться к нескольким измерениям
2. Динамические представления — нельзя показать один список файлов по разным критериям (по ролям, по стадиям, по приоритетам)
3. Вычисляемые поля — нельзя автоматически обновить статус "выполнено" при появлении кода
4. Уведомления — нельзя уведомить PM при изменении технической спецификации

Что файлы УМЕЮТ

1. Текстовый контент — удобно писать и читать
2. Версионирование (git) — история изменений
3. Разделение доступа — разные папки, разные права
4. Простота — не нужна база данных

Гибридный подход

Файлы: для контента (требования, архитектура, спецификации)
Мета-информация: для связей, статусов, зависимостей

Пример:

# projects/org/lideravto/planning/07-architecture.md

---
status: done
owner: architect
depends_on:
  - 06-platform.md
blocks:
  - specs/infrastructure.md
  - specs/CODE-PROMPT-catalog.md
tags:
  - it
  - web
  - cscart
---

# Архитектура сайта lideravto.ru
...

Индексация: скрипт читает YAML frontmatter и строит граф зависимостей.

СЛЕДУЮЩИЕ ШАГИ

1. Определить окончательную структуру папок (planning/ + management/ vs business/ + solution/ + project/)
2. Создать стандарт для YAML frontmatter (статус, владелец, зависимости)
3. Реструктурировать документацию lideravto по новой модели
4. Создать индексатор для построения графа зависимостей

ССЫЛКИ

• architect/theory/QUESTIONS.md — Теория 9 вопросов
• architect/theory/MERKABA.md — Геометрическая модель
• architect/standards/structure/PLANNING_CODING_SEPARATION.md — Разделение планирования и кода

Версия: 1.0.0
Дата: 2026-02-03