Перейти к основному содержимому

План MVP: месяц, полгода и год

Даты здесь являются ориентирами. Важен порядок: сначала проверяем инженерную платформу, затем строим один сквозной сценарий, после этого расширяем продукт.

Рабочая гипотеза MVP​

Первый сценарий: пользователь пишет или говорит «создай встречу», видит независимую от канала карточку, явно подтверждает данные, после чего система создаёт событие календаря и показывает результат.

Правила первого сценария подтверждены. Начинаем с fake-calendar; обязательны название, начало, конец и часовой пояс; создание всегда требует явного подтверждения. Описание и участники необязательны. Выбор AI-модели, speech-to-text и настоящего календаря остаётся отдельным решением после сквозного теста.

Переводы денег не входят в MVP. До отдельного threat model они доступны только как будущие read-only или simulation сценарии.

Первый месяц — инженерный полигон​

Цель: любой участник поднимает систему, запускает тесты и видит её состояние до появления бизнес-кода.

Неделя 1 — правила и воспроизводимость​

  • завершить rulesets, CODEOWNERS и обязательные CI checks;
  • зафиксировать маленькие TDD-коммиты и шаблон pull request;
  • создать ADR для каждого нового инструмента;
  • подготовить одну команду для проверки каждого репозитория;
  • добавить публичный roadmap, RFC-шаблон и tech radar.

Результат: чистый checkout можно проверить по README без устных инструкций.

Неделя 2 — локальные окружения​

  • спроектировать отдельные репозитории deploy, infra и test-lab;
  • быстрый профиль Docker Compose для ежедневной разработки;
  • полный профиль k3d для проверки Kubernetes;
  • Helm charts и одинаковые настройки local, dev, stage;
  • PostgreSQL, Keycloak, Temporal, Kafka и OPA с тестовыми данными;
  • секреты только через локальные примеры и External Secrets, без значений в Git.

Результат: быстрый профиль запускается одной командой; полный профиль воспроизводим на чистой машине.

Неделя 3 — наблюдаемость и тесты системы​

  • OpenTelemetry SDK и Collector как единая точка telemetry;
  • Prometheus, Grafana, Tempo и Loki;
  • correlation id проходит через HTTP, событие и workflow;
  • smoke и end-to-end тесты на fake-коннекторах;
  • k6: smoke, baseline, stress и короткий soak;
  • дашборд latency, throughput, errors и saturation.

Результат: один тестовый запрос виден в логах, метриках и trace от входа до fake-коннектора.

Неделя 4 — масштабирование и отказы​

  • ephemeral namespace для pull request через Argo CD ApplicationSet;
  • Horizontal Pod Autoscaler на измеряемой метрике;
  • тесты повторной доставки, idempotency и потери внешнего сервиса;
  • Chaos Mesh только в отдельном разрешённом namespace;
  • SBOM, Trivy, Cosign, provenance и OpenSSF Scorecard;
  • отчёт с найденными пределами, а не «красивое» число RPS.

Результат: каркас переживает перезапуск pod и временную недоступность зависимости без тихой потери данных.

Два–три месяца — работающий MVP​

  1. Согласовать RFC первого календарного сценария.
  2. Сначала написать сквозной acceptance-тест на fake AI и fake Calendar MCP.
  3. Реализовать Channel Gateway без зависимости от Telegram.
  4. Сделать Telegram адаптер примером канала, а не центром архитектуры.
  5. Добавить совместимый контракт ответа диалога и карточки подтверждения.
  6. Реализовать Conversation Service минимального размера и переключить на него Channel Gateway.
  7. Создать Widget SDK, который проверяет и отображает общий контракт.
  8. Реализовать Approval Service только когда появятся правила подтверждения сложнее текущего Action API.
  9. Подключить один реальный календарь за тем же контрактом, что и fake.
  10. Добавить audit trail, policy decision и durable workflow.
  11. Провести load, soak, chaos и restore проверки.
  12. Выпустить публичную MVP-версию с demo и инструкцией запуска.

Definition of Done MVP:

  • текстовая команда проходит весь путь до календаря;
  • голос является адаптером того же сценария;
  • пользователь видит точные данные до подтверждения;
  • повтор запроса не создаёт дубль;
  • все шаги видны в trace и audit trail;
  • система работает с fake-интеграциями без внешних аккаунтов;
  • документация позволяет стороннему разработчику повторить demo.

Шесть месяцев — публичная alpha​

  • multi-tenancy и отдельные подключения пользователей;
  • Web/PWA и Telegram используют один Widget SDK;
  • календарь, задачи и Jira как три независимых MCP-коннектора;
  • quotas, rate limits и контроль стоимости AI;
  • versioned contracts и автоматическая проверка совместимости;
  • preview environments для pull request и постоянный stage;
  • SLO, alerts, backup/restore и регулярные game days;
  • SDK и шаблон для внешнего MCP-коннектора;
  • публичные RFC, changelog, release notes и community meetings;
  • первые внешние contributors проходят путь от issue до release.

Критерий alpha: продукт полезен небольшой группе тестировщиков, а сбой одного коннектора не ломает остальные сценарии.

Один год — beta или 1.0​

  • стабильный публичный API и политика совместимости;
  • каталог проверенных коннекторов и процесс их security review;
  • горизонтальное масштабирование stateless-сервисов и worker pools;
  • multi-region план, проверенный restore и documented disaster recovery;
  • canary/blue-green release и автоматический rollback по SLO;
  • управление стоимостью, capacity model и регулярные нагрузочные отчёты;
  • зрелая governance-модель с maintainers и review ownership;
  • security baseline OpenSSF и воспроизводимый release supply chain;
  • высокорисковые сценарии только после threat model, step-up auth и независимого аудита;
  • wallet остаётся read-only/simulation, пока отдельный пилот не докажет безопасность.

Критерий 1.0: стабильность контрактов, понятная эксплуатация и безопасное расширение важнее количества интеграций.

Правило изменения плана​

Каждый этап заканчивается измеримым результатом и коротким отчётом. Если измерение не прошло, следующий этап не начинается. Новая технология сначала получает статус assess или trial в tech radar и ADR; статус adopt появляется только после успешного теста на полигоне.