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