# Подсистема D «Компетенции сотрудников» — Design Draft

| | |
|---|---|
| Дата | 2026-05-13 |
| Статус | **Draft — может реализовываться параллельно с MVP-2/3 или после** |
| Зависимости | MVP-1 (есть core.work_log + core.employee + core.project) |
| Срок | 1-2 недели работы (зависит от того, насколько детально нужен механизм распределения) |

> **Назначение:** зафиксировать обсуждённый подход к компетенциям. Это **набросок**.

## Ключевое решение пользователя

Цитата: «таблицу по компетенциям возможно придется собирать по проделанным зафиксированным работам в БИТ.РА, портфолио проектов возможно тоже».

**Why:** ручное ведение справочника компетенций сотрудников — нерабочая практика (устаревает, субъективно, никто не обновляет). Объективная компетенция = что человек реально делал в последний период.

См. [identity-and-scope](../../memory/feedback_identity_and_scope.md).

## Цели Подсистемы D

1. Автоматически рассчитать матрицу «сотрудник × компетенция × уровень» на основе истории работ.
2. Использовать матрицу для:
   - Подсказки распределения проектной команды Битрикс-сделок на конкретных сотрудников (улучшение MVP-1 — сейчас наивно поровну).
   - Автоматического распределения SD-задач по компетенциям (бэклог-айтем MVP-2).
   - Подсказки руководителю «кто свободен и умеет делать X».

## Что такое «компетенция» в нашем контексте

**Двухмерное определение:**
- **Конфигурация** = с каким продуктом сотрудник работал (1С:ERP, 1С:ЗУП, БИТ.ФИНАНС, и т.д.). Берём из `core.project.bitra_id` → `BIT.RA.Catalog.Проекты.Конфигурация` (`Catalog.Конфигурации`).
- **ВидРаботы** = что делал (ЛУРВ / ЛТ / ИТС / Пресейл и т.п.). Берём из `core.work_log.work_type_code` (см. [reference-bitra-work-types](../../memory/reference_bitra_work_types.md)).

То есть компетенция = пара `(Конфигурация × ВидРаботы)`.

## Расчёт уровня компетенции

```
weight(employee, config, work_type, period) =
    Σ(hours) where work_log.employee = employee
              AND work_log.project.config = config
              AND work_log.work_type = work_type
              AND work_log.period >= period - 12 months
```

Уровень владения = относительный вес:
- «Эксперт» — > 100 часов за последние 12 мес.
- «Опытный» — 30-100 часов.
- «Знаком» — 5-30 часов.
- «Нет опыта» — < 5 часов.

Пороги — конфигурируемые в `core.config`.

## Расширение core

```sql
core.employee_competence (
    employee_id bigint REFERENCES core.employee,
    config_code text,                  -- Конфигурация (1С:ERP, БИТ.ФИНАНС и т.д.)
    work_type_code text,               -- Вид работ
    hours_12m decimal(15,2),           -- часы за последние 12 месяцев
    hours_3m decimal(15,2),            -- за последние 3 месяца (для свежей картины)
    level text,                        -- эксперт | опытный | знаком | нет_опыта
    last_work_date date,               -- когда последний раз делал
    PRIMARY KEY (employee_id, config_code, work_type_code)
)
```

Заполняется materialized view'хой, обновляется раз в сутки (после ежедневной синхронизации BIT.RA).

## Применение в системе

### 1. Распределение проектной команды сделок Битрикс (улучшение MVP-1)

Сейчас (MVP-1): часы делятся поровну между членами `UF_CRM_1729244690` (проектная команда).

С компетенциями (улучшение): часы распределяются с учётом уровня компетенции каждого члена команды по `Конфигурации` сделки (`UF_CRM_1729244070`). Эксперт получает больше, новичок — меньше. Веса можно править в NocoDB вручную.

### 2. Автоматическое распределение SD-задач (бэклог-айтем)

В SD-задачах часто нужно быстро назначить исполнителя. Если задача относится к 1С:ERP (по `cf_konfiguracziya1`), система предлагает топ-3 сотрудника с подходящей компетенцией и низкой текущей загрузкой.

### 3. Дашборд «Компетенции команды»

Витрина `mart.competence_matrix`:
- Heatmap: сотрудники × Конфигурации, цвет = уровень компетенции.
- Таблица «Узкие места» — конфигурации, по которым у компании только 1 эксперт.
- Таблица «Покрытие команды» — какие компетенции есть в команде, какие нет.

## Open questions

- **Маппинг `Catalog.Конфигурации` BIT.RA ↔ Bitrix `UF_CRM_1729244070`** — это разные справочники, но семантически похожие. Нужна ручная таблица соответствий в `core.identity_map_config`. См. также [reference-bitrix24-classifications](../../memory/reference_bitrix24_classifications.md).
- **Учёт пресейла как компетенции.** Если сотрудник делал только пресейл по конфигурации (без ЛУРВ/ЛТ) — он эксперт по продаже, но не по реализации. Различать.
- **Перевод сотрудника** — если человек 5 лет делал 1С:Розница, потом переключился на 1С:ERP, окно «12 месяцев» это покажет, но текущая компетенция = ERP. Можно добавить «свежесть» (hours_3m).
- **Подсистема D vs MVP-2.** Если автоматическое распределение SD-задач нужно как часть MVP-2 — D становится зависимостью MVP-2. Если как улучшение MVP-1 — параллельно с MVP-2. Решить после MVP-1.

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

Подсистема D стартует когда:
- ✅ MVP-1 работает.
- ✅ `core.work_log` стабильно заполняется из BIT.RA.
- ✅ `core.project` маппится с конфигурациями (через `Catalog.Проекты.Конфигурация`).