docs: add PROJECT_GOAL (north star) + MVP-1 whitelists (employees, SD projects, forecast stages)

This commit is contained in:
Roman Chesnokov
2026-05-13 20:02:27 +05:00
parent ff1db85d7c
commit 7b282af5be
7 changed files with 262 additions and 6 deletions
+95
View File
@@ -0,0 +1,95 @@
# Project Goal — Северная звезда проекта `bit-flight-deck`
> **Назначение этого документа:** возвращаться сюда каждый раз когда возникает сомнение «правильно ли мы идём», «куда мы хотим прийти», «что главное». Если фокус сбился — этот файл возвращает на курс.
## Что мы строим
Система автоматизации для руководителя проектного отдела ИТ-компании. Объединяет данные 4 учётных систем (BIT.RA, EVA Desk, Битрикс24, самописная финрезная 1С) в единое read-only хранилище и даёт **автоматические ответы** на главные операционные вопросы.
## Зачем (the Why)
Сейчас руководитель проектного отдела отвечает на эти вопросы вручную через 3-4 системы + Excel. Это:
- не масштабируется (часов в неделе не хватает на сводку);
- не даёт прогноза (только реакция постфактум);
- даёт ответы с задержкой — часто пропускает критические сигналы вовремя.
**Цель проекта — автоматизация принятия операционных решений**, освобождение руководителя от ручного сбора данных, проактивная сигнализация о проблемах.
## К чему хочу прийти (end state, через ~3-6 месяцев)
1. **Открыл утром дашборд — увидел всё:** кто загружен, кто свободен, какие проекты в риске, какая маржа, что подписывать в следующем месяце, прогноз финреза.
2. **Получил уведомление вовремя:** задача подвисла → Telegram-алёрт. Сделка ушла в реализацию без проектной команды → алёрт. Этап просрочен → алёрт.
3. **Прогноз вместо реакции:** вижу что через 3 недели у команды X простой, а в Битриксе квалифицированных сделок на Y часов — могу принять решение заранее.
4. **Финрез по подразделениям автоматически**, без месячного ручного Excel-сводения.
5. **Компетенции команды объективны** — выводятся из истории работ, не из «как сам себя оценил».
## Главные бизнес-вопросы которым отвечает система
| Вопрос | MVP / Подсистема |
|---|---|
| Кто из сотрудников сейчас загружен коммерческими работами? | MVP-1 |
| На какой период загружен и до когда? | MVP-1 |
| Сколько часов может прилететь из сделок Битрикса? | MVP-1 |
| Какие задачи подвисают и тормозят следующие работы? | MVP-2 |
| В каком состоянии проекты по срокам, с декомпозицией до задачи? | MVP-2 |
| Какая маржа проектов (план/факт)? | MVP-3 |
| Сколько НЗП (незавершёнки) на проектах? | MVP-3 |
| Сколько денег будем актировать в следующем месяце? | MVP-3 |
| Какой финрез у каждого подразделения? | MVP-4 |
| Прогноз финреза на основе загрузки? | MVP-4 |
| Кто из сотрудников реально что умеет (компетенции)? | Подсистема D |
## Принципы (используются для разрешения спорных решений)
1. **Автоматизация, не digital Excel.** Если вижу таблицу которую пользователь должен фильтровать руками — это не цель. Дашборд = ответы без фильтрации.
2. **Read-only из источников.** Не строим параллельный учёт, не вводим данные дважды. Источники остаются мастерами.
3. **Email — главный ключ identity** между всеми системами. Если в каком-то источнике email пуст — это организационная задача дозаполнить, а не повод писать сложный fuzzy-маппер.
4. **Вертикальный срез по MVP.** Каждый MVP за 2-4 недели даёт **видимый дашборд + алёрты**, не «фундамент на 3 месяца без результата». Если MVP не даёт ответа на конкретный бизнес-вопрос — нужно либо переосмыслить MVP, либо запретить запускать.
5. **Компетенции — производная.** Из реальных работ (`core.work_log`), не из ручного справочника. Ручные справочники компетенций — антипаттерн.
6. **Single-user MVP.** Multi-user, RLS, персональные дашборды — вне scope. Когда понадобится — будет отдельный проект.
7. **Используем существующую инфру.** PostgreSQL, N8N, Cloudflare Tunnel, LiteLLM, Gitea — всё это уже стоит в `~/infrastructure/`. Не дублируем.
## Возврат к этому документу — checklist «фокус не сбился»
Признаки **сбившегося фокуса** (пора открыть этот файл и пересверить):
- ✖ Обсуждаем "крутую техническую вещь" которая не отвечает ни на один из 11 бизнес-вопросов выше.
- ✖ Строим инфраструктуру "на вырост" без видимого MVP за 2-4 недели.
- ✖ Возвращаемся к ручной фильтрации таблиц вместо автоматических ответов.
- ✖ Углубляемся в один источник, теряя картину всех 4 (или общую цель).
- ✖ Проектируем фичу для воображаемых будущих пользователей вместо одного руководителя проектного отдела.
- ✖ Пытаемся синхронизировать что-то "потому что можно", а не потому что нужно для бизнес-вопроса.
- ✖ Создаём ручной справочник там где можно вывести из данных.
Если хоть один пункт совпадает — пауза, откат, чтение этого файла, переоценка.
## Roadmap высокоуровневый
| MVP/Phase | Бизнес-выход | Спек |
|---|---|---|
| MVP-1 | Дашборд загрузки сотрудников (4 слоя) | [specs/2026-05-13-mvp1-workload-design.md](specs/2026-05-13-mvp1-workload-design.md) |
| MVP-2 | Подвисшие задачи + контроль сроков + Telegram-алёрты | [specs/2026-05-13-mvp2-deadlines-design.md](specs/2026-05-13-mvp2-deadlines-design.md) |
| MVP-3 | Маржа, НЗП, прогноз актирования | [specs/2026-05-13-mvp3-finance-design.md](specs/2026-05-13-mvp3-finance-design.md) |
| MVP-4 | Финрез по подразделениям (с отдельным мозговым штурмом) | [specs/2026-05-13-mvp4-finrez-design.md](specs/2026-05-13-mvp4-finrez-design.md) |
| Subsystem D | Компетенции команды как производная из истории работ | [specs/2026-05-13-subsystem-d-competence-design.md](specs/2026-05-13-subsystem-d-competence-design.md) |
## Что вне scope (никогда, или не в этом проекте)
- ❌ Замена BIT.RA / EVA / Битрикса. Это **аналитический слой поверх**, не новая ERP.
- ❌ Multi-user интерфейс. Пользователь один — Руководитель проектного отдела.
- ❌ Расширение функционала источников. Если что-то нужно добавить в BIT.RA / EVA — это отдельные задачи, не часть этого проекта.
- ❌ Mobile app, web frontend для сотрудников. Метабейс + NocoDB через браузер — достаточно.
- ❌ Алгоритмы предсказания на ML/AI до тех пор, пока не разберёмся со статистикой простыми SQL.
## Связанные документы
- **Спеки MVP** — в [specs/](specs/).
- **План реализации MVP-1** — в [plans/2026-05-13-mvp1-workload.md](plans/2026-05-13-mvp1-workload.md).
- **Конфигурация MVP-1** (whitelist'ы сотрудников, SD-проектов, стадий) — в [specs/mvp1-config.md](specs/mvp1-config.md).
- **Декомпозиция и архитектурные решения** — в memory-системе агента (`project_workload_control`, `architecture_*`, `feedback_*`).
@@ -454,15 +454,17 @@ Materialized views, обновляемые после каждой пачки sy
- **Дисциплина EVA**: внедрить в команде заполнение `plan_start_date` / `plan_end_date` / `deadline` / `responsible_id` для всех новых задач. Через 2-3 месяца — пересмотр MVP-1 с честной «плановой» через plan_start_date.
- **Email во всех системах**: дозаполнить email сотрудников в BIT.RA `Catalog.Пользователи` где пусто. Аналогично в Битриксе для новых юзеров.
## 13. Open questions / TODO
## 13. Open questions / TODO — закрыто (2026-05-13)
-**Имя проекта**`bit-flight-deck`. Gitea-репозиторий `bit-flight-deck`. Локальная папка `~/projects/bit-flight-deck/`.
-**Поддомен для Bitrix-webhooks**`n8n.bigmadnekenny.ru`. Добавить ingress-роут в cloudflared `host-systemd`.
- **Список ~20 сотрудников MVP-1.** Какие конкретно email/department-id попадают в фокус? До начала разработки — выписать явный whitelist.
- **3 SD-проекта.** Извлечь точные ID/коды из `https://gitea.bigmadnekenny.ru/admin/eva-bot/docs/`.
- **Стадии Битрикса для прогноза.** Подтвердить точный список стадий CAT=16, в которых сделка должна учитываться в прогнозе. Кандидаты: `FINAL_INVOICE` («Защита сделки»), `UC_A02TUT` («Отложено»), `UC_U68WK1` («Подготовка рамочного договора»). Стадии `UC_XPZ8Z5/UC_QYTFP3` (Реализация) — туда уже EVA, в прогноз НЕ включаем.
- **Заполняемость email в BIT.RA.** Через MCP проверить какой % пользователей имеет email в `КонтактнойИнформации`. Если ниже 80% — параллельная организационная задача.
- **Распределение часов сделки по проектной команде.** Базовая логика — поровну между членами команды. Веса можно править в NocoDB. Возможно нужна более умная логика (по компетенциям) — это backlog для подсистемы D.
- **Список сотрудников MVP-1** — 15 email подтверждены пользователем + 1 TBA. Полный список в [mvp1-config.md](mvp1-config.md). Применяется через `sql/seed/mvp1_target_employees.sql`.
- **3 SD-проекта EVA**`pbsd`, `sd-perm`, `sd-czentralnyj`. Применяется через `sql/seed/sd_projects_whitelist.sql`.
- **Стадии Битрикса CAT=16 для прогноза**`C16:UC_A2446J` (Оценка и подготовка КП), `C16:FINAL_INVOICE` (Защита сделки), `C16:UC_U68WK1` (Подготовка рамочного договора). Применяется через `sql/seed/bitrix_forecast_stages.sql`. `UC_A02TUT` (Отложено) и стадии Реализации **НЕ включены** (двойной счёт с EVA).
- **Заполняемость email в BIT.RA** — пользователь подтверждает «все заполнены или будут заполнены к запуску MVP-1». Через MCP не проверяемо, но это организационная гарантия. ETL пишем в предположении что email есть.
Остающиеся внутренние:
- **Распределение часов сделки по проектной команде.** Базовая логика — поровну между членами команды. Веса можно править в NocoDB. Более умная логика (по компетенциям) — backlog для Подсистемы D.
## 14. Backlog после MVP-1
+68
View File
@@ -0,0 +1,68 @@
# MVP-1 Configuration — Whitelists и точные коды
> **Назначение:** конкретные значения для конфигурации MVP-1. Меняются по мере добавления/удаления сотрудников, проектов, стадий. Не зашиваем в спеку (она про дизайн), а живут здесь — отдельным конфигом. SQL-файлы в `sql/seed/` импортируют эти значения.
## Сотрудники MVP-1 — whitelist по email
Команда РП-2 и связанные. Перечень от пользователя на 2026-05-13.
| # | Email |
|---|---|
| 1 | `AleUZhukov@1cbit.ru` |
| 2 | `AKPetyanina@1cbit.ru` |
| 3 | `AAGevorgyan@1cbit.ru` |
| 4 | `AAPrilukov@1cbit.ru` |
| 5 | `VVGaspirovich@1cbit.ru` |
| 6 | `VDKhaldin@1cbit.ru` |
| 7 | `VUKozlov@1cbit.ru` |
| 8 | `GATokareva@1cbit.ru` |
| 9 | `DSBulychev@1cbit.ru` |
| 10 | `dmvmikhaylov@1cbit.ru` |
| 11 | `EASenik@1cbit.ru` |
| 12 | `ZGalihanova@1cbit.ru` |
| 13 | `IAGadzhiev@1cbit.ru` |
| 14 | `LAYagudina@1cbit.ru` |
| 15 | `SYaMamedbakova@1cbit.ru` |
| 16 | (TBA — будет добавлен) |
Применение: см. `sql/seed/mvp1_target_employees.sql`.
## SD-проекты EVA — явный список
Известны через URL в EVA (предоставлены пользователем):
| EVA Project code | URL | Описание |
|---|---|---|
| `pbsd` | https://firstbit.evateam.ru/project/Project/pbsd | Центр поддержки офиса Екатеринбург Проектный центр |
| `sd-perm` | https://firstbit.evateam.ru/project/Project/sd-perm | SD Пермь |
| `sd-czentralnyj` | https://firstbit.evateam.ru/project/Project/sd-czentralnyj | SD Центральный |
Эти 3 проекта — единственные SD-проекты. Все остальные `CmfProject` — обычные PM-проекты, даже если `enable_sdesk` пустое.
Применение: см. `sql/seed/sd_projects_whitelist.sql`.
## Стадии Битрикса CAT=16 для прогнозной загрузки
| STAGE_ID (полный) | NAME | Используется в прогнозе |
|---|---|---|
| `C16:UC_A2446J` | Оценка и подготовка КП | ✅ |
| `C16:FINAL_INVOICE` | Защита сделки | ✅ |
| `C16:UC_U68WK1` | Подготовка рамочного договора | ✅ |
Не включаем в прогноз:
- Более ранние стадии (NEW «Wish-List», PREPARATION «Проработка», PREPAYMENT_INVOIC «Квалификация», EXECUTING «Уточнение требований») — слишком ранняя стадия, ещё не подтверждено что будет проект.
- `UC_A02TUT` «Отложено» — пауза, неопределённость, не считаем загрузку.
- `UC_XPZ8Z5` «Реализация первого этапа проекта», `UC_QYTFP3` «Реализация проекта» — это уже **фактическая загрузка через EVA**, не прогноз (двойной счёт нельзя).
- `WON`, `LOSE`, `APOLOGY` — закрытые, не считаем.
Применение: см. `sql/seed/bitrix_forecast_stages.sql`.
## Email в BIT.RA — статус
**От пользователя:** через MCP проверить невозможно, но email сотрудников **все заполнены или будут заполнены к моменту запуска MVP-1**. Это организационная гарантия — на ETL пишем код в предположении что email есть для всех целевых сотрудников.
Fallback (если кто-то всё-таки без email): запись в `core.identity_map` с `confidence='manual'`, ждёт ручного разрешения через NocoDB.
## История изменений
- **2026-05-13:** первая версия. 15 email + 1 TBA. 3 SD-проекта. 3 стадии Битрикса.