MVP-2 «Подвисшие задачи и контроль сроков» — Design Draft


Дата	2026-05-13
Статус	Draft — фиксация обсуждённого, требует доработки после MVP-1
Зависимости	MVP-1 завершён (есть core.employee, core.task, core.project, core.work_log)
Срок	2-3 недели после MVP-1

Назначение этого документа: зафиксировать то, что уже обсудили по MVP-2, чтобы не вспоминать заново. Это набросок, не финальная спека. Финальная спека пишется отдельно перед стартом MVP-2 после результатов MVP-1.

Цели MVP-2

Автоматический контроль за сроками проектов и поиск подвисающих задач, которые тормозят следующие работы. Расширение дашборда MVP-1 + добавление алёртов.

Главные бизнес-вопросы (из исходной постановки пользователя)

В каком состоянии сейчас проекты?
Где отстаём по срокам?
Какие задачи подвисают и тормозят следующие работы?
На какой задаче может зависнуть проект (декомпозиция до уровня задачи)?

Что добавляем к MVP-1

Расширение core

-- (MVP-1 уже имеет core.task)
core.task_status_history (
    id bigserial PRIMARY KEY,
    task_id bigint REFERENCES core.task,
    from_status_type text,        -- OPEN | IN_PROGRESS | IN_REVIEW | CLOSED
    to_status_type text,
    from_status_id text,
    to_status_id text,
    cmf_author_id text,           -- кто сделал переход (EVA)
    employee_id bigint REFERENCES core.employee,
    cmf_created_at timestamptz,
    transition_id text,
    resolution_id text
)

core.stage (
    id bigserial PRIMARY KEY,
    name text,
    bitra_id text,
    project_id bigint REFERENCES core.project,
    plan_start_date date,
    plan_end_date date,
    is_completed boolean,         -- BIT.RA.Catalog.ЭтапыПроектов.Выполнен
    is_acted boolean              -- BIT.RA.Catalog.ЭтапыПроектов.АктПодписан
)

Новые витрины

mart.stalled_tasks            — задачи IN_PROGRESS без смены статуса > N дней (N конфигурируется)
mart.project_health           — по каждому открытому проекту: список задач, кто работает, факт-часы, текущий статус, риск-флаги
mart.deadline_risks           — задачи и этапы у которых дедлайн в ближайшие N дней, но статус не закрыт
mart.task_lead_time           — среднее время задачи в каждом статусе (для бенчмарка «нормальное» vs «подвисло»)

Источники данных (помимо MVP-1)

EVA — добавить полную синхронизацию CmfStatusHistory (есть 114k записей, фильтр по cmf_created_at работает — инкрементально).
BIT.RA — добавить эндпоинт /api/stages для Catalog.ЭтапыПроектов (с реквизитами Выполнен, АктПодписан).
BIT.RA — добавить эндпоинт /api/project_status для Document.СтатусПроекта (протоколы статус-совещаний). Опционально — может пригодиться для понимания «когда последний раз обсуждали проект».

Алёрты Telegram

Базовый набор:

«Задача подвисла» — в IN_PROGRESS более N дней без смены статуса (N = 5 / 7 / 10 — конфигурируется).
«Этап проекта просрочен» — Catalog.ЭтапыПроектов.ДатаОкончания < today AND Выполнен=false.
«Проект без активности» — нет работ по проекту за последние N дней.

Триггер — N8N workflow раз в сутки → SELECT из витрин → POST в Telegram бот.

Дашборд (расширение MVP-1)

Новые секции на главном дашборде Metabase:

Плитка «N подвисших задач» с цветом (красная если > X).
Таблица «Топ-N подвисших задач» — задача, исполнитель, проект, статус, дней без активности.
Таблица «Проекты с риском срыва» — проект, плановая дата, % выполнения, последняя активность.
Heatmap «Среднее время в статусе» по сотрудникам — кто узкое горло.

Бэклог в рамках MVP-2

Автоматическое распределение SD-задач по компетенциям сотрудников (из исходного бэклога). Это связано с Subsystem D: компетенции = производная от core.work_log. Распределение = выбор сотрудника с подходящей компетенцией и низкой текущей загрузкой.

Open questions (для финализации перед стартом MVP-2)

Пороги «подвисло» — конфигурируемые в core.config (per-status, per-priority?) или единый N дней?
Включаем ли в MVP-2 контроль сроков по подписанию документов (актов)? Это пересекается с MVP-3 (НЗП). Возможно стоит часть из MVP-3 (контроль актов) перенести в MVP-2.
Алёрты — только в Telegram, или ещё в дашборд (плитка «требует внимания»)?
Что делать с задачами без responsible_id (43% покрытие — см. reference-eva-empirical)? Они невидимы в контроле сроков — нужна отдельная стратегия (например, алёрт «N задач без исполнителя» — намёк команде заполнять).

Зависимости от MVP-1

MVP-2 стартует когда:

✅ MVP-1 работает в проде (3 слоя загрузки + дашборд).
✅ core.task и core.work_log заполняются стабильно.
✅ Identity-map по сотрудникам стабильно работает (>95% сматчены).
Дисциплина EVA в команде начала улучшаться (растёт % задач с responsible_id).

7.2 KiB Raw Blame History Unescape Escape