Nimbus Docs

Appearance

Карта 5D Vision: проект Nimbus ​

Назначение документа: связать продуктовую и техническую стратегию Nimbus с пятью измерениями цикла развития продукта (Discover → Design → Develop → Deploy → Deliver). Документ — «живая карта»: обновляется по мере проверки гипотез и смены приоритетов.

Методология: измерения не строго линейны — команда итерирует между ними. Идея близка к подходу 5D Vision / Product Management across 5 dimensions (Discover, Design, Develop, Deploy, Deliver).

Связанные материалы: product_vision.md, executive_summary.md, roadmap_3m.md, modules.md.

Сводная карта (обзор) ​

ИзмерениеВопрос для NimbusКлючевой результат
DiscoverКакие боли УК и жильцов закрываем в первую очередь?Приоритизированный бэклог, ICP, метрики проблемы
DesignКак выглядит ценность в UX, API и договорах с рынком?Сценарии, прототипы, модульность, compliance-контуры
DevelopЧто строим в коде и как разделяем сервисы?MVP ядра биллинга, core, auth, интеграции
DeployКак выводим в эксплуатацию и масштабируем?DevOps, безопасность, мультитенантность, ГИС/банки
DeliverКак измеряем успех и удержание?KPI, поддержка, дорожная карта расширений

1. Discover (Исследование и фокус) ​

Суть измерения ​

Понимание клиента, рынка и незакрытых возможностей: кто платит, за что, какие альтернативы (1С, Excel, конкуренты).

Nimbus: что уже зафиксировано ​

  • ICP (первичный сегмент): средние УК (ориентир 100–300 домов); далее ТСЖ/ЖСК, крупные УК — см. executive_summary.md.
  • Боли: устаревшие учётные системы, ошибки начислений, долгая отчётность, слабая коммуникация с жильцами — см. раздел «Проблема» в executive summary.
  • Рынок: ориентиры TAM/SAM в executive summary; регуляторика РФ (ПП 354, ГИС ЖКХ) как обязательный контекст — см. product_vision.md.

Потребности (Needs) ​

  • Регулярные интервью с УК (директор, главбух, диспетчер).
  • Сравнение сценариев с действующими продуктами ЖКХ-ПО.
  • Ясная формулировка MVP vs «позже» (AI, AR, marketplace — как гипотезы, не блокеры ядра).

Вызовы (Challenges) ​

  • Разрыв между «хочу всё сразу» и сроками ядра биллинга.
  • Разные зрелости клиентов (Excel vs 1С vs другая УК-система).

Инструменты / артефакты ​

  • Jobs To Be Done по ролям (бухгалтер, диспетчер, жилец).
  • Обновление roadmap_3m.md по результатам Discover.

2. Design (Проектирование ценности) ​

Суть измерения ​

Прототипы, информационная архитектура, контракты API, коммерческая упаковка (тарифы, модули).

Nimbus: что проектируется ​

  • Продуктовая ценность: облачный биллинг ЖКХ, ЛК жильца, диспетчерская, отчёты, интеграции — product_vision.md.
  • Архитектура: разделение auth / core / billing / bank integrator / GIS gateway — modules.md.
  • Модульность и монетизация: продаваемые блоки vs базовый контур — см. постановки в docs/tasks/task-organization-feature-modules.md (при наличии).
  • Договоры и счета SaaS: использование доменной модели Contract для организации — docs/tasks/task-platform-subscription-contracts-invoices.md.

Потребности (Needs) ​

  • Единые UX-паттерны админки (MUI, роли, супер-админ vs УК).
  • Спецификации интеграций (ГИС ЖКХ, 1С клиент-банк, платёжные шлюзы) до разработки.

Вызовы (Challenges) ​

  • Сложность ПП 354 и пеней — дизайн «без дыр» в Ledger и аудите.
  • Баланс простоты UI и полноты справочников УК.

Инструменты / артефакты ​

  • Диаграммы последовательностей (уже есть в modules.md).
  • Макеты ключевых потоков: начисление → оплата → отчёт.

3. Develop (Разработка) ​

Суть измерения ​

Итеративная реализация: код, тесты, ревью, технический долг под контролем.

Nimbus: текущий фокус (по roadmap) ​

  • Этап 1: ядро биллинга — начисления, перерасчёты, закрытие периода (roadmap_3m.md).
  • Этап 2: платежи, долги, пени, принципы Ledger без «ручного UPDATE баланса».
  • Этап 3: интеграции банков/1С, ГИС ЖКХ.
  • Этап 4–5: отчётность, дашборды, стабилизация.

Потребности (Needs) ​

  • Жёсткие правила для junior/контрибьюторов: не ломать ядро ПП 354 в core без ревью — см. onboarding.md, junior_tasks.md.
  • CI, линтеры, миграции БД по сервисам.

Вызовы (Challenges) ​

  • Согласованность данных между core-service и billing-service.
  • Безопасность (JWT, CSRF, RBAC) — auth-service.

Инструменты / артефакты ​

  • Репозиторий: services/auth-service, core-service, billing-service, frontend.
  • Документация архитектуры: docs/architecture/, docs/business_logic/.

4. Deploy (Развёртывание и эксплуатация) ​

Суть измерения ​

Доставка в прод, наблюдаемость, резервное копирование, соответствие требованиям безопасности и масштабирования.

Nimbus: направления ​

  • Контейнеризация, окружения (dev/stage/prod) — см. dev-quick-start.md, Docker-гайды.
  • Секреты, HTTPS, изоляция данных по организациям (мультитенантность).
  • Мониторинг обмена с ГИС и банками (ретраи, журналы) — заложено в описании модулей modules.md.

Потребности (Needs) ​

  • Runbook для инцидентов и миграций.
  • Политика резервного копирования БД по сервисам.

Вызовы (Challenges) ​

  • Внешние API (ГИС, банки) — нестабильность и изменение форматов.
  • Рост данных по ЛС и проводкам — планирование индексов и архивации.

Инструменты / артефакты ​

  • Docker Compose / прод-стек (как принято в команде).
  • Логирование (структурированные логи в сервисах Go).

5. Deliver (Результат для клиента и бизнеса) ​

Суть измерения ​

Измерение ценности, поддержка, обучение, NPS/удержание, обратная связь в Discover.

Nimbus: что измерять ​

Метрика / артефактЗачем
Время цикла «начисление → закрытие периода»Эффективность ядра MVP
Доля ошибок/перерасчётов vs ручной учётКачество расчётов
Подключённые интеграции (ГИС, банк)Compliance и операционная ценность
ARPU, churn, срок внедренияБизнес-модель из executive_summary.md
Обращения в поддержку по модулямПриоритизация Design/Develop

Потребности (Needs) ​

  • Онбординг клиента (данные, обучение ключевых пользователей).
  • Внутренний дашборд супер-админа: договоры, счета, модули организаций — см. постановки в docs/tasks/.

Вызовы (Challenges) ​

  • Долгий цикл продаж B2B в ЖКХ; пилоты на реальных домах.
  • Ожидания «уникальных» отчётов под каждую УК.

Инструменты / артефакты ​

  • Договорное и биллинговое сопровождение (Contract + счета).
  • Обратная связь из пилотов → обновление roadmap и 5D-карты.

Как пользоваться этой картой ​

  1. Планирование квартала: пройти по 5 измерениям и отметить «красные зоны» (где нет артефакта или владельца).
  2. Синхронизация с roadmap: этапы roadmap_3m.md в основном лежат в Develop и Deploy, но должны опираться на Discover и Design.
  3. Инвестиции и питчи: Discover + Deliver усиливают историю рынка и трекции; Design + Develop — техническую правдоподобность.

История изменений ​

ДатаИзменение
2026-03-19Первая версия карты 5D Vision для Nimbus