После все эти материалы заносятся в описания задач (в Asana), которые будут в следующем спринте для разработчиков. Мы стараемся делать так, чтобы бекенд реализовывал задачи первым
После распределения всех задач по разработчикам (на основе предпочтений и математики с Man Days) проходит предспринтовый созвон
Перед выполнением, но после чтения PRD задачи, разработчик может инициировать созвон с PM этой фичи
После задача уходит в реализацию и PM забывает про задачу до последней четверти спринта.
Когда до завершения принята остаётся 3-4 дня, разрабочики готовят тестовую версию, а после бизнес команда (состоящая из 7 человек) тестируют приложение в течении нескольких часов
1. У бизнес команды нет квалификации, они часто репортят проблемы, связанные с самими платформами или не являющиеся важными для бизнеса
2. Тестирование выполняется в конце спринта, а значит разработчик мог уже забыть как реализовывал первую фичу (если таких 2+)
После того, как разработка перешла за определённую черту (стало больше жалоб от разработчиков), мы решили нанять QA, но пока процесс тестирования и релиза у нас остаются такими, как я описал выше
После первого цикла тестов от бизнес команды, project manager заносит баги на отдельную доску и разработчики должны их править (каждый спринт на правку багов выделяется 0.5-1 Man Day на человека)
После правок повторяется короткий цикл тестирования
1. Активно наблюдать за "product doesn't work" дашбордом (там собраны все метрики, которые характеризуют стабильность: конверсия в регистрацию, скорость загрузки контента, кол-во серверных ошибок и т.п.)
2. Сформировать отдельный дашборд по анализу новых фич (особенно если это A/B тест), который можно будет проанализировать через 1-2 недели
После этого весь описанный тут цикл повторяется: