Промпт: декомпозиция и оценка задачи перед спринтом

1. Вопросы к продакт-менеджеру

• Какие бизнес-правила действуют при оплате через СБП? Есть ли отличия от текущих платежей?
• Как часто планируется запускать автоматическое продление? Возможны ли отложенные платежи или отмена автоподписок пользователем?
• Нужно ли интегрироваться напрямую с банками-партнёрами или достаточно использовать существующий шлюз?
• Необходимо ли уведомлять пользователей об успешности/неуспешности платежа после завершения операции?
• Насколько критична поддержка сразу обеих платформ — мобильного приложения и веб-версии?
• Есть ли конкретные требования к UI/UX мобильных приложений и веб-интерфейса?
• Планируется ли дополнительная аналитика или метрики конкретно по платежам через СБП?
• Необходима ли интеграция с внутренними системами мониторинга и обработки ошибок для нового типа оплаты?
• Требуется ли интеграция с внешней системой отчетности (например, бухгалтерия)?
• В случае отказа оплаты нужно ли отправлять уведомления пользователям и команде поддержки?
• Нужна ли возможность отмены автоматической подписки внутри интерфейсов приложения или кабинета пользователя?

---

2. Декомпозиция задачи

Подзадача №1: Исследовательская задача (Spike)

Цель: уточнить технические детали интеграции с существующим шлюзом, выявить возможные сложности и подготовить прототип.
Критерий готовности:

• Получены точные данные по работе с новым типом платежей.
• Прототип реализации успешно проходит базовое тестирование.

Оценка: оптимистично — 0,5 дня, реалистично — 1 день, пессимистично — 2 дня.

Подзадача №2: Добавление функционала в Backend (Java/SpringBoot)

Цель: реализовать обработку запросов на создание, обновление и удаление подписок через СБП.
Критерий готовности:

• Код написан, покрыт тестами, проверяет корректность входящих данных и обрабатывает ошибки.
• Поддерживается автообновление подписок согласно правилам продукта.
• Логирование операций и уведомление внутренних сервисов (мониторинг).

Оценка: оптимистично — 6 дней, реалистично — 8 дней, пессимистично — 12 дней.

Подзадача №3: Изменение инфраструктуры (если потребуется)

Цель: обновить инфраструктуру (Dockerfile, Kubernetes manifests, CI/CD пайплайны), если необходимы изменения для новой функциональности.
Критерий готовности:

• Инфраструктура обновлена и протестирована локально и в среде разработки.
• Система деплоя готова к выкатке изменений.

Оценка: оптимистично — 1 день, реалистично — 2 дня, пессимистично — 3 дня.

Подзадача №4: Интеграция с фронтендом (веб-кабинетом)

Цель: разработать интерфейс выбора способа оплаты и отображения статуса текущей подписки.
Критерий готовности:

• Интерфейс готов, подключён к бэкенду, работает проверка валидности формы и отправка запроса на сервер.
• Статус подписки корректно отображается пользователю.

Оценка: оптимистично — 4 дня, реалистично — 5 дней, пессимистично — 8 дней.

Подзадача №5: Мобильное приложение (Flutter)

Цель: добавить возможность оплаты через СБП и показывать статус подписки в мобильном приложении.
Критерий готовности:

• Реализован экран оформления подписки и проверки текущего состояния подписки.
• Пользователи могут выбрать способ оплаты и оформить подписку через СБП.

Оценка: оптимистично — 5 дней, реалистично — 7 дней, пессимистично — 9 дней.

Подзадача №6: Тестирование

Цель: провести полное ручное и автоматизированное тестирование всех аспектов работы подписки через СБП.
Критерий готовности:

• Написаны и пройдены автотесты для каждого компонента системы.
• Проведено ручное регресс-тестирование ключевых сценариев использования.

Оценка: оптимистично — 3 дня, реалистично — 4 дня, пессимистично — 6 дней.

---

3. Оценки по методу PERT

Формула расчёта PERT:
$PERT = \frac{(O + 4R + P)}{6}$
где O — оптимистичная оценка, R — реалистичная оценка, P — пессимистичная оценка.

Итого общая оценка примерно равна 28 идеальным дням, учитывая двухнедельный спринт (10 рабочих дней) и наличие параллельных потоков работ (бэкэнд, фронт, мобайл):

Принимая во внимание необходимые буферы, разумнее выделить три спринта (~6 недель) для гарантированного выполнения задачи.

---

4. Риски и зависимости

• Неопределенность технического решения и необходимость уточнений требований (SPIKE решает этот риск частично).
• Задержки в коммуникациях между командой разработчиков и продуктовым менеджером.
• Потенциальная сложность интеграций с внешними сервисами и задержка ответов от технической службы шлюза.
• Дополнительные риски связаны с миграциями и изменениями инфраструктуры, особенно если нужны будут доработки Docker/Kubernetes конфигураций.
• Возможность обнаружения скрытых технических долгов, связанных с архитектурой монолита, замедляющих разработку.
• Если реализация займёт больше времени, чем ожидалось, придётся отложить другие запланированные задачи на ближайший спринт.

---

5. Минимальная версия MVP

Минимальной версией будет первая рабочая реализация подписки через СБП только в веб-интерфейсе, чтобы быстрее получить обратную связь от пользователей и минимизировать затраты ресурсов на поддержку мобильной платформы одновременно.

Выпуск первой версии должен включать следующие шаги:

• Разработка основной части бэкенда.
• Полностью реализованный и работающий функционал в веб-приложении.
• Частичное покрытие автотестами основных кейсов.
• Ограниченный релиз для бета-группы пользователей.

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

Ниже — предварительная оценка. Я бы не коммитился в полный объём без короткого spike по API платёжного шлюза для СБП-подписок: автопродление через СБП часто имеет нюансы по мандатам, статусам, вебхукам, отменам и повторным списаниям.

---

1. Вопросы к продакт-менеджеру

Продуктовое поведение

1. Какие тарифы поддерживаем в первой версии: все текущие или только один/несколько?
2. СБП — это новый способ оплаты для существующих подписок или отдельный тип подписки?
3. Можно ли пользователю с активной карточной подпиской перейти на СБП?
4. Можно ли пользователю с активной СБП-подпиской перейти обратно на карту?
5. Что делать, если у пользователя уже есть активная подписка и он пытается купить новую через СБП?
6. Нужно ли поддерживать промокоды/скидки/триалы для СБП?
7. Как показываем дату следующего списания?
8. Как пользователь отменяет автопродление?
9. Должна ли отмена прекращать доступ сразу или в конце оплаченного периода?
10. Нужны ли напоминания перед списанием?
11. Что показываем пользователю, если автосписание не прошло?
12. Сколько попыток повторного списания делаем и с каким интервалом?
13. Есть ли grace period после неуспешного списания?
14. Нужно ли отправлять email/push/in-app уведомления по событиям СБП-подписки?
15. Какие тексты и UX должны быть при подключении автопродления через СБП?

Юридические и платёжные вопросы

1. Нужно ли отдельное согласие пользователя на автопродление?
2. Где и как храним факт согласия?
3. Нужны ли изменения в оферте/условиях подписки?
4. Кто отвечает за фискализацию чеков: наш сервис или платёжный шлюз?
5. Требуется ли отправка чеков при каждом рекуррентном списании?
6. Какие банки/клиенты СБП поддерживают привязку для автоплатежей?
7. Есть ли ограничения по суммам, периодичности, валюте?
8. Что считается успешной привязкой: редирект пользователя, webhook, отдельный статус в API?
9. Что происходит, если пользователь не подтвердил привязку в банке?
10. Как выглядит сценарий отмены мандата/согласия на стороне банка?

Технические вопросы по шлюзу

1. Есть ли sandbox для СБП-подписок?
2. Насколько sandbox соответствует production?
3. Какие webhook-события приходят по созданию подписки, оплате, автосписанию, отмене, ошибке?
4. Есть ли идемпотентность в API шлюза?
5. Какой SLA у webhook-доставки?
6. Нужно ли самим опрашивать шлюз при отсутствии webhook?
7. Есть ли API для отмены СБП-подписки?
8. Есть ли API для изменения суммы/тарифа?
9. Как шлюз сообщает о неуспешном рекуррентном списании?
10. Какие финальные и промежуточные статусы у СБП-подписки?
11. Какие требования к callback/deeplink URL для web и mobile?

---

2. Декомпозиция с критериями готовности

0. Spike / техническое исследование

---

Backend

---

Frontend — веб-кабинет

---

Мобильное приложение Flutter

---

Тесты

---

Инфраструктура / релиз

---

3. Оценка в идеальных днях

Оценка дана в идеальных человеко-днях, без учёта митингов, переключений, ожидания ответов от шлюза/продукта и очереди QA.

Формула PERT для каждой задачи:

PERT = (O + 4M + P) / 6

где:

• O — optimistic,
• M — most likely / realistic,
• P — pessimistic.

Таблица оценок

Общая оценка

Сумма optimistic:

O_total = 26

Сумма realistic:

M_total = 49

Сумма pessimistic:

P_total = 83

Общий PERT:

PERT_total = (26 + 4 * 49 + 83) / 6 = 50.8 идеальных человеко-дней

Итого: примерно 51 идеальный человеко-день.

Что это значит для спринта

Команда за 2 недели условно имеет:

• backend: 2 разработчика × 10 рабочих дней = 20 человеко-дней,
• frontend: 1 × 10 = 10 человеко-дней,
• mobile: 1 × 10 = 10 человеко-дней,
• QA общий на 3 команды — фактическая доступность, вероятно, 2–4 дня.

Даже если frontend и mobile успевают, backend + интеграция + QA являются узким местом. Полный объём в один двухнедельный спринт выглядит рискованно. Более реалистично — 2 спринта, либо 1 спринт на spike + backend foundation + MVP без части функций.

---

4. Риски и зависимости

Высокие риски

1. Неясности API шлюза по СБП-автопродлению

Возможны неожиданные статусы, ограничения, нестабильный sandbox.

1. Webhook-сценарии

Повторные webhooks, задержки, out-of-order события, отсутствие события после возврата пользователя.

1. Deeplink/возврат в мобильное приложение

Может отличаться на iOS/Android, зависеть от банка или сценария через браузер.

1. Юридическое согласие на автопродление

Если нужно менять оферту, тексты, подтверждения и хранение согласий — срок увеличится.

1. Фискализация и чеки

Если текущий карточный flow завязан на карту и не покрывает СБП-рекурренты, появится дополнительная работа.

1. Ограниченная доступность QA

Платёжные сценарии требуют ручной проверки на web/mobile и регрессии существующих платежей.

1. Регрессия текущих карточных подписок

Если текущая модель подписки жёстко завязана на карточный payment method, изменения могут быть глубже.

1. Production-настройки у платёжного шлюза

Доступы, callback URL, активация СБП-подписок на стороне шлюза могут занять время вне команды.

1. App Store / Google Play нюансы

Если подписка относится к цифровому контенту, нужно проверить правила стора. В некоторых случаях внешние платежи в мобильных приложениях ограничены.

1. Поддержка отмены/изменения тарифа

Если в MVP потребуется смена тарифа для СБП-подписки, объём увеличится.

---

5. Что выпустить первым как минимальную версию

Я бы предложил MVP так:

MVP scope

1. Только новое подключение подписки через СБП.
2. Только один или ограниченный набор тарифов, без смены тарифа.
3. Без миграции существующих карточных подписок на СБП.
4. Без промокодов, скидок и trial, если они требуют дополнительной логики.
5. Поддержать:
6. создание СБП-подписки,
7. подтверждение пользователем,
8. получение webhook об успешной оплате,
9. активацию доступа,
10. отображение статуса,
11. отмену автопродления.
12. Включить через feature flag сначала для internal/test users.
13. Сначала можно выпустить на web, если мобильный deeplink окажется сложным. Но если продукту критичен mobile, тогда mobile делать с fallback через внешний браузер.

Что отложить

• Смена тарифа для СБП-подписки.
• Миграция с карты на СБП.
• Миграция с СБП на карту.
• Повторные списания с кастомной retry-логикой, если шлюз уже делает retry.
• Сложные уведомления.
• Расширенная аналитика, кроме базовых событий.
• Массовое включение для всех пользователей.

Рекомендуемый план на ближайший спринт

В первый спринт я бы взял:

1. Spike по шлюзу.
2. Backend-модель и миграции.
3. Backend happy path:
4. создать СБП-подписку,
5. принять webhook успешной оплаты,
6. активировать подписку.
7. Feature flag.
8. Минимальный web или mobile flow.
9. Базовые тесты и sandbox-проверка.

Цель спринта: доказать end-to-end happy path на sandbox и понять реальные сложности, а не пытаться сразу закрыть полный production-ready объём.

Оценка задачи: Оплата подписки через СБП с автопродлением

1. Вопросы к продакт-менеджеру

Бизнес-логика и продукт:

1. СБП для подписок через привязку (есть разные модели у разных банков/агрегаторов) — шлюз уже поддерживает именно автосписания, или только разовые платежи через СБП? Нужно свериться с их API-доками.
2. Что происходит, если автосписание не удалось (недостаточно средств, пользователь отозвал согласие в банке)? Нужна ли логика retry, грейс-период?
3. Нужно ли показывать пользователю экран согласия/отзыва согласия на автосписание отдельно от общей подписки?
4. Можно ли мигрировать существующих подписчиков с карты на СБП, или это только для новых подписок?
5. Нужна ли поддержка смены способа оплаты (карта → СБП и обратно) в рамках активной подписки?
6. Как обрабатывать возврат средств (рефанды) через СБП — есть ли у шлюза API для этого?
7. Есть ли юридические/комплаенс требования (152-ФЗ, хранение данных о согласии на автоплатеж)?
8. Приоритет: mobile и web нужны одновременно в релизе, или можно разнести по спринтам?
9. Нужна ли аналитика/метрики по конверсии в оплату СБП отдельно от карты (для бизнеса)?
10. Какой SLA ожидается на обработку колбэков от шлюза (критично для retry-логики и мониторинга)?

Без ответов на 1, 2, 6 — оценка ненадёжна, т.к. они определяют объём работы на порядок (спайк обязателен).

---

2. Декомпозиция задач

0. Spike: исследование API шлюза для СБП-подписок

DoD: Задокументированы: флоу создания подписки, формат колбэков, обработка неуспешных автосписаний, тестовая среда проверена вручную (создан платеж, получен колбэк).

Backend

Frontend (веб-кабинет)

Mobile (Flutter)

Тестирование

Инфраструктура/DevOps

---

3. Оценка в идеальных днях (PERT)

Формула: E = (O + 4M + P) / 6, дисперсия σ = (P−O)/6

Суммарно по backend (B1–B6): ~18.2 идеальных дня → на 2 backend-разработчиков параллельно, но с зависимостями (B2→B3→B4), реально ~12-14 календарных дней при разделении работы.

Frontend (F1-F3): ~4.8 идеальных дня на 1 разработчика.

Mobile (M1-M3): ~7.5 идеальных дня на 1 разработчика.

QA (T1-T3): ~5.9 идеальных дня, но QA общий на 3 команды — узкое место.

Общая PERT-оценка задачи: ≈ 48 идеальных дней (сумма всех E).

Вывод по срокам

При спринте 2 недели (10 рабочих дней) и текущей команде задача не влезает в один спринт. Реалистично:

• Спринт 1: Spike + B1-B3 + начало F1/M1 (backend-ядро)
• Спринт 2: B4-B6, F2-F3, M2-M3, тестирование
• Итого 2 спринта, при условии что spike не выявит сюрпризов в API шлюза.

---

4. Риски и зависимости

Ключевая зависимость: F2/M1 не могут начаться полноценно, пока не готов B2 (API создания подписки) — минимум нужен контракт API (можно мокировать после spike).

---

5. Что выпустить первым (MVP)

Минимальная версия для первого релиза:

1. Оплата через СБП только на вебе (мобильное — вторым этапом, т.к. there's дополнительная сложность с диплинками и SDK на 2 платформы).
2. Только первичная оплата + автопродление без смены способа оплаты (без миграции карта↔СБП).
3. Без грейс-периода/сложного retry — при неудаче автосписания сразу уведомление пользователю и статус "требует действия" (упрощённая логика B4).
4. Фичафлаг на пилотную группу пользователей (I1) для контролируемого раскатывания.

Что отложить:

• Mobile-реализация (M1-M3) — следующий спринт после стабилизации веба.
• Рефанды через СБП (если шлюз это поддерживает отдельно).
• Расширенная аналитика конверсии (вопрос 9).

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

Отличная задача, тимлид! Давайте разберем ее по полочкам.

---

1. Вопросы к Продакт-менеджеру

Прежде чем приступать к декомпозиции и оценке, нам критически важно получить ответы на следующие вопросы. Без них любая оценка будет крайне ненадёжной.

1. Пользовательский опыт (UX) и флоу:
2. Как пользователь будет инициировать оплату через СБП? (Кнопка "Оплатить через СБП", выбор метода оплаты на экране подписки?)
3. Какой будет флоу для автопродления? Пользователь должен явно дать согласие на автопродление при первой оплате СБП? Как это будет выглядеть?
4. Как пользователь будет отключать автопродление? Где будет доступна эта опция?
5. Какие сообщения мы показываем пользователю на разных этапах оплаты (успех, неудача, ожидание)?
6. Нужен ли QR-код на веб-странице для оплаты с мобильного? Или только кнопка "Открыть приложение банка"?
7. Как мы обрабатываем сценарий, когда пользователь закрыл приложение банка, не завершив оплату?
8. Как мы обрабатываем сценарий, когда пользователь не успел оплатить по QR-коду/ссылке за отведенное время?

1. Интеграция с платежным шлюзом:
2. Уточните, пожалуйста, "API для подписок через СБП". Это означает, что шлюз сам умеет управлять рекуррентными платежами СБП (подписками), или мы должны сами инициировать каждую следующую оплату через СБП?
3. Если шлюз сам управляет: Как он уведомляет нас об успешных/неуспешных автопродлениях? (Webhook, pull-API?)
4. Если мы сами управляем: Какой механизм для этого предоставляет шлюз? (Сохранение токена СБП, привязка к идентификатору пользователя?)
5. Какие статусы платежей и подписок мы можем получать от шлюза?
6. Есть ли тестовый стенд у платежного шлюза для СБП и автопродлений?

1. Бизнес-логика и правила:
2. Какие тарифы подписки будут доступны для оплаты через СБП? Все или только определенные?
3. Как обрабатываются возвраты средств для СБП-платежей? (Это может быть отдельная задача, но важно знать, что она будет).
4. Какие данные о платеже и подписке нам нужно хранить? (ID платежа в СБП, ID подписки в шлюзе, дата следующего списания, статус автопродления, согласие пользователя на автопродление).
5. Есть ли какие-то специфические требования к отчетности по СБП-платежам?

1. Приоритеты и MVP:
2. Что является минимально жизнеспособной версией (MVP)? Оплата СБП без автопродления? Или автопродление обязательно с первого релиза?
3. Если автопродление обязательно, то для каких платформ оно должно быть доступно в первую очередь? (Например, сначала веб, потом мобильные).

1. Юридические аспекты:
2. Есть ли какие-либо юридические требования к отображению информации об автопродлении СБП? (Например, особые формулировки согласия).

---

2. Декомпозиция и критерии готовности

Предполагаем, что мы получили ответы на вопросы и понимаем, что шлюз поддерживает рекуррентные платежи СБП, и мы будем использовать его функционал для автопродления.

Общие задачи:

1. Исследование API платежного шлюза для СБП и подписок (Spike)
2. Описание: Глубокое изучение документации API шлюза по СБП-платежам и механизмам автопродления/рекуррентных платежей. Понимание флоу, необходимых параметров, возможных ответов и ошибок.
3. Критерий готовности: Подготовлен документ с описанием API шлюза (endpoint'ы, параметры, примеры запросов/ответов) и предложенной схемой взаимодействия. Проведены тестовые запросы к тестовому стенду шлюза (если доступен).

Backend (Java 17, Spring Boot, PostgreSQL)

1. Интеграция с API платежного шлюза (СБП)
2. Описание: Реализация HTTP-клиента для взаимодействия с платежным шлюзом. Методы для инициации СБП-платежа, получения статуса платежа, отмены подписки.
3. Критерий готовности: Написан клиент для шлюза, покрыт unit-тестами. Возможность инициировать тестовый платеж и получить его статус.

1. Разработка сервиса СБП-платежей
2. Описание: Создание нового сервиса (или расширение существующего) для обработки логики СБП-платежей. Включает:
3. Генерация запроса на оплату СБП (сбор данных, вызов шлюза).
4. Обработка колбэков/вебхуков от шлюза об изменении статуса платежа/подписки.
5. Обновление статуса подписки пользователя в нашей системе.
6. Логика для автопродления (если шлюз не управляет полностью, то инициирование следующего платежа).
7. Критерий готовности: Сервис способен принимать запросы на создание СБП-платежа, взаимодействовать со шлюзом, обрабатывать его ответы/колбэки. Покрыт unit/integration-тестами.

1. Модификация сервиса подписок
2. Описание: Расширение существующего сервиса подписок для поддержки нового метода оплаты. Включает:
3. Добавление поля "метод оплаты" (СБП/Карта) к подписке.
4. Логика для активации/деактивации подписки через СБП.
5. Логика для отмены автопродления СБП.
6. Критерий готовности: Сервис подписок корректно обрабатывает подписки, созданные через СБП, позволяет их активировать/деактивировать и отменять автопродление.

1. API для фронтенда и мобильного приложения
2. Описание: Разработка REST API для взаимодействия с фронтендом и мобильным приложением.
3. POST /api/v1/subscriptions/sbp/initiate: Инициировать СБП-платеж для подписки. Возвращает ссылку на оплату (deep link) или QR-код.
4. GET /api/v1/subscriptions/sbp/{paymentId}/status: Проверить статус СБП-платежа.
5. POST /api/v1/subscriptions/{subscriptionId}/sbp/cancel-autorenewal: Отменить автопродление СБП-подписки.
6. Критерий готовности: Все необходимые API-эндпоинты реализованы, документированы (например, через Swagger/OpenAPI), покрыты интеграционными тестами.

1. Обработка ошибок и логирование
2. Описание: Реализация детального логирования всех этапов взаимодействия с платежным шлюзом и обработки СБП-платежей. Обработка возможных ошибок от шлюза и внутренних ошибок.
3. Критерий готовности: Логирование информативно, ошибки корректно обрабатываются и возвращаются пользователю/фронтенду.

Frontend (Веб-кабинет)

1. Интерфейс выбора метода оплаты
2. Описание: Добавление опции "Оплата через СБП" на странице выбора тарифа/оплаты подписки.
3. Критерий готовности: Кнопка/чекбокс "Оплатить через СБП" присутствует на странице оплаты.

1. Флоу оплаты СБП
2. Описание: Реализация пользовательского флоу:
3. При выборе СБП, вызов API initiate.
4. Отображение QR-кода и/или кнопки "Открыть приложение банка" (deep link).
5. Инструкции для пользователя по оплате.
6. Механизм проверки статуса платежа (например, опрос API status с интервалом).
7. Отображение результата оплаты (успех/неудача).
8. Критерий готовности: Пользователь может инициировать СБП-платеж, получить QR-код/ссылку, перейти в банк, и после оплаты увидеть результат.

1. Управление автопродлением
2. Описание: Добавление возможности отмены автопродления для СБП-подписки в личном кабинете пользователя.
3. Критерий готовности: Пользователь может отменить автопродление СБП-подписки через UI.

Мобильное приложение (Flutter)

1. Интерфейс выбора метода оплаты
2. Описание: Добавление опции "Оплата через СБП" на экране выбора тарифа/оплаты подписки.
3. Критерий готовности: Кнопка/чекбокс "Оплатить через СБП" присутствует на экране оплаты.

1. Флоу оплаты СБП
2. Описание: Реализация пользовательского флоу:
3. При выборе СБП, вызов API initiate.
4. Открытие приложения банка по deep link.
5. Механизм проверки статуса платежа после возвращения в приложение.
6. Отображение результата оплаты (успех/неудача).
7. Критерий готовности: Пользователь может инициировать СБП-платеж, перейти в банк, и после оплаты увидеть результат в приложении.

1. Управление автопродлением
2. Описание: Добавление возможности отмены автопродления для СБП-подписки в профиле пользователя.
3. Критерий готовности: Пользователь может отменить автопродление СБП-подписки через UI.

Миграции и База данных (PostgreSQL)

1. Изменение схемы БД
2. Описание: Добавление/изменение таблиц для хранения информации о СБП-платежах и подписках (например, payment_method_type в таблице subscriptions, таблица sbp_payments для истории транзакций).
3. Критерий готовности: Созданы и протестированы миграции для PostgreSQL. Схема БД обновлена.

Тесты (QA общий)

1. Написание тестовых сценариев
2. Описание: Разработка детальных тестовых сценариев для всех флоу: успешная оплата, неуспешная оплата, отмена автопродления, проверка статусов, обработка ошибок.
3. Критерий готовности: Полный набор тестовых кейсов для СБП-оплаты и автопродления.

1. Функциональное тестирование
2. Описание: Ручное и/или автоматизированное тестирование всех реализованных функций на всех платформах (веб, мобильное).
3. Критерий готовности: Все тестовые сценарии выполнены, найденные баги зафиксированы и исправлены.

1. Интеграционное тестирование
2. Описание: Тестирование взаимодействия между всеми компонентами системы (backend-шлюз, backend-frontend, backend-мобильное).
3. Критерий готовности: Интеграционные тесты пройдены, взаимодействие между компонентами корректно.

Инфраструктура

1. Настройка Webhook-ов (если применимо)
2. Описание: Настройка публичного эндпоинта для приема колбэков/вебхуков от платежного шлюза, обеспечение его доступности и безопасности.
3. Критерий готовности: Эндпоинт для вебхуков настроен, протестирован, работает в тестовой среде.

1. Настройка секретов и конфигурации
2. Описание: Добавление ключей API платежного шлюза и других чувствительных данных в безопасное хранилище конфигурации.
3. Критерий готовности: Все необходимые секреты и конфигурации настроены в тестовой и продакшн-средах.

---

3. Оценка подзадач в идеальных днях (Оптимистично, Реалистично, Пессимистично) и общая оценка по PERT

Идеальный день = 8 часов чистого кодинга/работы.
Команда: 2 BE, 1 FE, 1 Mobile, QA (общий на 3 команды, поэтому его время нужно учитывать как ресурс, который нужно "забронировать").

Backend (2 разработчика)

Frontend (1 разработчик)

Мобильное приложение (1 разработчик)

Миграции и База данных

Тесты (QA - общий ресурс)

• Важно: Оценка QA здесь - это время, которое QA потратит на эту задачу, а не время, которое задача будет ждать QA.
• Мы должны заложить время QA на тестирование после того, как разработка будет завершена.
• Предполагаем, что QA будет тестировать параллельно по мере готовности частей, но основное регрессионное тестирование будет в конце.

Инфраструктура (часть работы Backend/DevOps)

---

Общая оценка по PERT

Формула PERT для ожидаемой оценки (E) = (a + 4m + b) / 6
Общая оценка проекта будет суммой оценок по PERT для каждой подзадачи.

Backend:

• Исследование: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Интеграция: (2 + 4*3 + 5) / 6 = 19 / 6 = 3.17
• Сервис СБП: (3 + 4*5 + 8) / 6 = 31 / 6 = 5.17
• Модификация подписок: (2 + 4*3 + 4) / 6 = 18 / 6 = 3
• API: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Ошибки/логи: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Итого PERT Backend: 2 + 3.17 + 5.17 + 3 + 2 + 2 = 17.34 идеальных дней

Frontend:

• Интерфейс: (0.5 + 4*1 + 1.5) / 6 = 6 / 6 = 1
• Флоу: (2 + 4*3 + 5) / 6 = 19 / 6 = 3.17
• Управление: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Итого PERT Frontend: 1 + 3.17 + 2 = 6.17 идеальных дней

Мобильное:

• Интерфейс: (0.5 + 4*1 + 1.5) / 6 = 6 / 6 = 1
• Флоу: (2 + 4*3 + 5) / 6 = 19 / 6 = 3.17
• Управление: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Итого PERT Мобильное: 1 + 3.17 + 2 = 6.17 идеальных дней

Миграции:

• Схема БД: (0.5 + 4*1 + 1.5) / 6 = 6 / 6 = 1
• Итого PERT Миграции: 1 идеальный день

Инфраструктура:

• Webhook-и: (0.5 + 4*1 + 2) / 6 = 6.5 / 6 = 1.08
• Секреты: (0.5 + 4*1 + 1.5) / 6 = 6 / 6 = 1
• Итого PERT Инфраструктура: 1.08 + 1 = 2.08 идеальных дней

QA:

• Сценарии: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Тестирование Web: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Тестирование Mobile: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Интеграционное: (1 + 4*2 + 3) / 6 = 12 / 6 = 2
• Итого PERT QA: 2 + 2 + 2 + 2 = 8 идеальных дней

---

Общая оценка по PERT (суммируем по ролям, учитывая параллельность):

• Backend: ~17.34 идеальных дней. (2 BE-разработчика, значит, это примерно 17.34 / 2 = 8.67 рабочих дней на каждого, если они работают полностью параллельно).
• Frontend: ~6.17 идеальных дней.
• Мобильное: ~6.17 идеальных дней.
• Миграции: ~1 идеальный день (скорее всего, сделает BE-разработчик).
• Инфраструктура: ~2.08 идеальных дня (скорее всего, сделает BE-разработчик).
• QA: ~8 идеальных дней (это время, которое QA потратит, но оно будет распределено по спринту и после разработки).

Реальная оценка для 2-недельного спринта (10 рабочих дней):

• Backend: 17.34 идеальных дней. С учетом 2 разработчиков, это ~9 рабочих дней на каждого, если они могут полностью работать параллельно. Это очень плотно, но возможно.
• Frontend: 6.17 идеальных дней. Это ~6-7 рабочих дней. Вполне укладывается.
• Мобильное: 6.17 идеальных дней. Это ~6-7 рабочих дней. Вполне укладывается.
• QA: 8 идеальных дней. Это ~8 рабочих дней. Учитывая, что QA общий на 3 команды, это может быть узким местом. Нужно заранее договориться о выделении времени.

Вывод по спринту:
С учетом PERT-оценок, задача выглядит очень плотной для одного двухнедельного спринта.
Backend-часть занимает почти весь спринт для двух разработчиков. Frontend и Mobile укладываются, но их работа зависит от готовности Backend API. QA - это отдельный риск.

Предложение:
Я бы предложил разбить это на два спринта, либо рассмотреть MVP, который можно выпустить в первом спринте.
Если все же пытаться уместить в один спринт, то потребуется очень тесная координация и минимальное количество отвлечений.

---

4. Риски и зависимости, которые могут сдвинуть срок

Зависимости:

1. API платежного шлюза:
2. Доступность и стабильность тестового стенда шлюза.
3. Полнота и актуальность документации API.
4. Оперативная поддержка со стороны шлюза при возникновении вопросов/проблем.
5. Наличие всех необходимых функций (оплата, автопродление, отмена, статусы) в API шлюза.
6. Backend -> Frontend/Mobile:
7. Готовность Backend API для начала работы Frontend и Mobile разработчиков.
8. Разработка -> QA:
9. Доступность QA для тестирования по мере готовности компонентов.
10. Качество тестовых данных на тестовом стенде.

Риски:

1. Неполная/неактуальная документация шлюза: Приведет к дополнительному времени на исследование и отладку.
2. Сложности с интеграцией шлюза: Неожиданные проблемы с авторизацией, форматами данных, обработкой ошибок.
3. Отсутствие тестового стенда шлюза или его нестабильность: Затруднит разработку и тестирование.
4. Неожиданные требования от продукта/бизнеса: Изменение флоу, дополнительные поля, особые условия.
5. Проблемы с производительностью/масштабируемостью: Если СБП-платежи будут очень частыми, могут потребоваться оптимизации.
6. Юридические/комплаенс требования: Могут всплыть дополнительные требования к отображению информации, хранению данных.
7. Нагрузка на QA: Поскольку QA общий на 3 команды, может возникнуть "бутылочное горлышко" на этапе тестирования, что задержит релиз.
8. Проблемы с deep links на мобильных: Различия в поведении разных ОС/браузеров при открытии банковских приложений.
9. Сложности с обработкой асинхронности: СБП-платежи асинхронны. Корректная обработка статусов, тайм-аутов, повторных попыток.
10. Проблемы с автопродлением: Если шлюз не полностью управляет автопродлением, а мы должны инициировать платежи, это добавляет сложности (шедулер, обработка неудачных списаний).

---

5. Что выпустить первым как минимальную версию (MVP)

Самый логичный и безопасный MVP:

MVP: Оплата подписки через СБП без автопродления.

Что это включает:

• Backend:
• Интеграция с API платежного шлюза для инициации СБП-платежа и получения его статуса.
• Сервис СБП-платежей для создания и обработки разовых платежей.
• API для фронтенда/мобильного для инициации и проверки статуса.
• Миграции БД для хранения информации о СБП-платежах.
• Базовая обработка ошибок и логирование.
• Frontend (Веб-кабинет):
• Интерфейс выбора метода оплаты с опцией "СБП".
• Флоу оплаты СБП: вызов API, отображение QR-кода/ссылки, опрос статуса, отображение результата.
• Мобильное приложение (Flutter):
• Интерфейс выбора метода оплаты с опцией "СБП".
• Флоу оплаты СБП: вызов API, открытие deep link, проверка статуса, отображение результата.
• QA:
• Тестирование флоу разовой оплаты СБП на обеих платформах.
• Инфраструктура:
• Настройка секретов и конфигурации.

Почему это MVP:

1. Снижение сложности: Убирает самую сложную часть — логику рекуррентных платежей, их статусов, отмены, уведомлений.
2. Быстрый запуск: Позволяет быстрее получить обратную связь от пользователей и проверить работоспособность основной интеграции.
3. Меньше рисков: Меньше юридических и финансовых рисков, связанных с некорректной работой автопродления.
4. Фокус: Позволяет команде сосредоточиться на стабильной работе базового платежного флоу.

Что останется на следующий этап:

• Реализация автопродления через СБП (как на стороне шлюза, так и на нашей стороне).
• Интерфейсы для управления автопродлением (включение/отключение).
• Дополнительные уведомления пользователям об автопродлении/неудачных списаниях.
• Возможно, более сложная отчетность.

Такой подход позволит нам выпустить ценность быстрее и с меньшими рисками.