Какие данные необходимы чтобы понять что команда в срок сможет запустить маркетплейс?

Какие данные нужны, чтобы оценить, запустит ли команда маркетплейс в срок

Это классический вопрос на планирование и риск-менеджмент. За 10+ лет я видел много проектов, которые срывают сроки. Вот точный набор данных, которые мне нужны для уверенной оценки.

1. Данные о команде

Состав и компетентность:

• Сколько backend разработчиков? Senior/Mid/Junior?
• Сколько frontend? Design? QA?
• Есть ли опыт с маркетплейсами/multivendor системами?
• Кто lead архитектор? Это его первый такой проект?
• Есть ли замена при болезни (bus factor = 1 это риск)

Пример красного флага:

• 2 junior разработчика как основная сила = риск срыва 70%

Пример зелёного флага:

• Senior architect + 4 мид разработчика + опыт похожего проекта = можно доверять

2. Историческая скорость доставки (Velocity)

Что я смотрю:

• Сколько story points закрывает команда за спринт? (обычно 2-недельный)
• Это число стабильно или колеблется?
• За последние 3-4 спринта (не беру 1 спринт, может быть выброс)

Как это считается:

Если в последних 4 спринтах команда закрывала:

• Спринт 1: 32 points
• Спринт 2: 28 points
• Спринт 3: 35 points
• Спринт 4: 30 points

Средняя velocity = (32+28+35+30)/4 = 31.25 points/спринт

Консервативная оценка: беру 80% = 25 points/спринт (на случай сложностей)

3. Детальная декомпозиция маркетплейса

ОЛИ ГЛАВНОЕ! Нужно разбить проект на story и оценить каждый:

Core features маркетплейса:

Backend:

• Vendor onboarding system (registration, verification, KYC) — 13 points
• Product catalog management (bulk upload, SKU handling) — 21 points
• Multi-vendor inventory sync (stock levels, real-time) — 34 points
• Payment routing (split by vendor commission) — 34 points
• Order management (multi-vendor orders) — 21 points
• Vendor analytics dashboard (revenue, orders, trends) — 13 points
• Commission management (automatic payout) — 8 points
• Review system (per vendor, seller rating) — 8 points
• Dispute resolution (support for vendor-buyer conflicts) — 13 points
• Search and filtering (by vendor, rating, price) — 13 points

Итого backend: 178 points (примерно)

Frontend:

• Vendor onboarding UI — 8 points
• Vendor dashboard — 34 points
• Product management UI — 21 points
• Search optimization and vendor profiles — 13 points
• Buyer reviews and ratings UI — 8 points
• Order tracking for multiple vendors — 13 points

Итого frontend: 97 points

Infrastructure/DevOps:

• Multi-tenant architecture (database sharding or isolation) — 34 points
• Webhook system for vendor notifications — 13 points
• Performance optimization (search indexing, caching) — 21 points
• Monitoring and alerting (multi-vendor specific) — 13 points

Итого infrastructure: 81 points

QA/Testing:

• Test plan creation and setup — 5 points
• Functional testing (per vendor flow) — 34 points
• Integration testing (payment, inventory sync) — 21 points
• Load testing (multi-vendor concurrent orders) — 13 points
• UAT support — 13 points

Итого QA: 86 points

ИТОГО ВСЕГО: 442 points

4. Расчёт времени до срока

Дано:

• Velocity команды: 25 points/спринт (консервативно)
• Всего points: 442
• Спринты = 442 / 25 = 17.7 спринтов
• Это примерно 8.8 месяцев (если спринт 2 недели)

Если срок — 6 месяцев (12 спринтов):

• Нужна velocity = 442 / 12 = 36.8 points/спринт
• Текущая velocity = 25 points/спринт
• Дефицит = 47.2% — НЕ СМОЖЕМ В СРОК

Что делать?

Опции:

1. Добавить людей (+2-3 разработчика, но есть ramp-up time)
2. Урезать scope (убрать features)
3. Сдвинуть дедлайн
4. Улучшить процесс (меньше встреч, автоматизация)

5. Риски и буферы

Неизвестные неизвестные (Unknown Unknowns):

Я добавляю буфер 20-30% к оценке на:

• Архитектурные решения, которые приведут к переделке
• Интеграции с внешними системами (платежи, доставка)
• Чтение legacy кода
• Блокировки и зависимости между командами

Формула:

Реальное время = Estimated time * (1 + contingency factor)

Примеры contingency:

• Опытная команда с clear scope: 1.15 (15%)
• Средняя команда, есть неясности: 1.25 (25%)
• Junior команда или новая технология: 1.35 (35%)

В нашем примере маркетплейса:

• 442 points * 1.25 contingency = 552.5 points
• 552.5 / 25 = 22.1 спринта = 11.1 месяцев

Вывод: 6 месяцев — очень оптимистичный сценарий

6. Качественные факторы

Проверяю:

Ясность требований:

• Есть ли детальный PRD?
• Дизайн мокапы готовы?
• Стейкхолдеры согласовали scope?
• Если ответ "нет" на что-то — +2 недели на уточнение

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

• Нужно интегрировать с платежной системой? Есть ли API?
• Нужно менять инфраструктуру? Есть ли DevOps?
• Есть ли внешние зависимости, которые я не контролирую?

Technical debt:

• Нужно ли сначала отрефакторить код?
• Есть ли legacy system, который нужно обновить?
• Как текущая архитектура справится с multi-vendor нагрузкой?

Процесс:

• Как часто встречаемся со стейкхолдерами? (много встреч = потеря productivity)
• Есть ли боттленеки в review/approval?
• Как быстро нанимаем новых людей?

7. Метрики для мониторинга во время разработки

Когда проект стартует, я еженедельно смотрю:

Velocity тренд:

Wk1: 22 points (низко, team settling in)
Wk2: 26 points (норма)
Wk3: 24 points (норма)
Wk4: 18 points (RED FLAG! Упал на 25%, нужно разобраться)
Wk5: 28 points (восстановились)

Если velocity падает — это риск срыва.

Burndown chart:

• Правильный паттерн: линия идёт вниз равномерно
• Проблемный паттерн: прямая в конце спринта, потом скачок вверх на следующий спринт (stories не закрыты)

Bug rate:

• Сколько новых багов появляется в неделю?
• Если растёт — это код низкого качества, чем дольше разработка, тем больше проблем

Backlog stability:

• Сколько items добавилось в backlog за спринт?
• Если много — scope creep (увеличение объёма)

8. Сценарное планирование

Best case (20% вероятность):

• Нет серьёзных архитектурных проблем
• Все интеграции работают с первой попытки
• Не добавляются новые requirements
• Launch = 5.5 месяцев

Base case (50% вероятность):

• 1-2 архитектурные переделки
• Интеграции работают со 2-3 попытки
• Scope слегка ползёт вверх
• Launch = 7-8 месяцев

Worst case (30% вероятность):

• Серьёзная переделка архитектуры
• Множественные интеграционные проблемы
• Scope растёт на 20-30%
• Заболевают key люди
• Launch = 10-12 месяцев

9. Точка невозврата

Опасный момент: когда мы уже потратили 60% времени, а закончили только 40% work. Это значит, что на оставшиеся 60% work у нас есть только 40% времени.

Я мониторю это еженедельно. Если видим, что отстаём на 20%+ от плана — нужно принимать решение NOW, не ждать последнего дня.

10. Как я презентирую риск начальству

Слайд 1: Честная оценка

Цель: запустить маркетплейс за 6 месяцев
Наша оценка: 8-12 месяцев
Вероятность попадания в 6 месяцев: 15%

Слайд 2: Варианты

1. План A: Запустить полный маркетплейс за 12 месяцев (базовый сценарий)

   • Все features
   • Quality ready for production
   • Вероятность: 70%

2. План B: Запустить MVP маркетплейса за 6 месяцев

   • Только базовые features (онбординг, каталог, платежи)
   • Без analytics, disputes, продвинутых фильтров
   • Добавим остальное в V2 через 2 месяца
   • Вероятность: 75%

3. План C: Добавить людей (увеличить velocity)

   • +2 senior разработчика = +15 points/спринт
   • Новая velocity = 40 points
   • Время = 442 / 40 = 11 спринтов = 5.5 месяцев
   • Но ramp-up 2-3 недели, реально 6 месяцев
   • Стоимость: +X в зарплаты
   • Вероятность: 60% (людей сложно найти быстро)

Слайд 3: Мой рекомендация

"Я рекомендую План B: запустить MVP за 6 месяцев, затем iterate. Это даст нам feedback от реальных vendors и buyers, которые помогут приоритизировать V2 features. Вероятность успеха 75%, это лучше, чем гнаться за 100% feature set и рисковать срывом."

Итого

Для оценки вероятности запуска в срок мне нужны:

1. Team: компетентность, состав, опыт
2. Velocity: историческая скорость доставки
3. Scope: детальная декомпозиция на story
4. Dependencies: что блокирует работу?
5. Risks: качественные факторы (ясность, интеграции)
6. Buffers: contingency на неизвестное
7. Monitoring: как отслеживаем во время разработки?
8. Scenarios: best/base/worst case
9. Decision points: когда пересматриваем план?
10. Communication: как честно презентируем риск?

Если у меня есть все эти данные — я могу дать точный прогноз и направить проект в успешный launch.