Процесс продуктовой разработки
Процесс поставки в VentraGo состоит из двух ключевых фаз: Product Discovery и Product Delivery. Разделение позволяет проверить ценность и реализуемость идеи до того, как тратить ресурсы на разработку.
Discovery Delivery
┌──────────┬──────────────────┬──────────┬──────────────┐ ┌──────────┬─────────────┬────┬─────────┬─────────────────┬──────┐
│ Backlog │ Problem Under- │Estimation│Prioritization│→ │Ready │ Development │ QA │ Release │ Value │ Prod │
│ │ standing │ │ │ │to Dev │ │ │ │ Estimation │ │
└──────────┴──────────────────┴──────────┴──────────────┘ └──────────┴─────────────┴────┴─────────┴─────────────────┴──────┘Product Discovery
Цель: сформулировать и проверить ценность и реализуемость идеи, прежде чем потратить ресурсы на разработку.
Этапы Discovery
| # | Этап | Что происходит | Артефакт на выходе |
|---|---|---|---|
| 1 | Backlog | Сбор идей и запросов от бизнеса, пользователей, команды | Сырая идея в бэклоге |
| 2 | Problem Understanding | Формулировка проблемы, описание сценариев (User Story / JTBD), определение критериев приёмки, проработка UX/UI (Figma) | Описание проблемы + макеты |
| 3 | Estimation | Рифайнмент с командой + QA-ревью, оценка сложности в майках (T-shirt sizing) | Оценённая фича |
| 4 | Prioritization | Приоритизация на продуктовом комитете с учётом свободных слотов в delivery | Фича в слоте деливери |
Product Delivery
Цель: обеспечить реализацию и предсказуемую поставку в прод.
Этапы Delivery
| # | Этап | Что происходит | Артефакт на выходе |
|---|---|---|---|
| 1 | Ready to Dev | Фича полностью подготовлена, декомпозирована на технические задачи | Задачи на доске |
| 2 | Development | Разработка, код-ревью | Код в feature-ветке |
| 3 | QA | Тестирование по тест-плану | Протестированная функциональность |
| 4 | Release | Деплой на Stage, проверка | Релиз-кандидат |
| 5 | Value Estimation | Оценка достигнутой бизнес-ценности по метрикам | Отчёт о ценности |
| 6 | Prod | Релиз в production | Фича доступна пользователям |
Критерии входа в продуктовый комитет
Перед тем как фича попадёт на продуктовый комитет, должно быть выполнено:
- Проблема — сформулирована проблематика, описаны сценарии (User Story / JTBD), определены критерии приёмки
- Дизайн — проработан UX/UI, есть макеты в Figma
- Рифайнмент — проведён с командой + QA-ревью
- Бизнес-ценность — посчитан business value, определены продуктовые метрики (опережающие и запаздывающие)
- Оценка — оценён cost по разработке в майках
Зачем такие критерии
- Гарантируем, что решаем важную проблему (проверяем гипотезу) и считаем отдачу через метрики
- Все понимают одинаково, что именно разрабатываем
- Можно проверить результат и подтвердить ценность после поставки
Процессные метрики
Для измерения эффективности процесса поставки отслеживаем три ключевые метрики:
On-Time Delivery
Процент задач, поставленных в сроки, которые были заявлены при планировании. Показывает предсказуемость команды.
Lead Time
Время от точки принятия обязательств (Ready to Dev) до выпуска в production. Показывает скорость потока.
Blockers
Количество блокировок в процессе и их суммарная длительность. Показывает «здоровье» потока и слабые места.
Связь с DORA-метриками
Процессные метрики дополняют DORA / SPACE метрики, которые измеряют техническую эффективность delivery-пайплайна.