В этом материале рассказываем, что важно знать продакт-менеджеру о жизненном цикле разработки ПО и какую роль он выполняет в этом процессе.
Жизненный цикл разработки программного обеспечения (Software Development Life Cycle, SDLC) — это упорядоченный процесс, который используется при создании продуктов и фичей в IT и смежных сферах. Он состоит из нескольких этапов, которые позволяют пройти путь от провалидированной гипотезы до реализации фичи или продукта.
Процесс SDLC вовлекает разные команды и специалистов (разработка, аналитика, дизайн и др.), и роль продакт-менеджера — управлять этим процессом так, чтобы в конечном итоге продуктовые изменения приносили ценность пользователям и выгоду бизнесу.
Рассмотрим все этапы жизненного цикла разработки ПО и задачи, которые решает продакт на каждом из них.
Этот материал стал результатом совместной работы с Вадимом Купцовым, директором по продукту в Ostrovok.
В прошлом разработчик, Вадим — один из экспертов нашего курса «Профессия: продакт-менеджер». В рамках обучающей программы он подробно рассказывает о технических навыках, необходимых продакт-менеджеру, и о том, как эффективно их освоить.
Узнайте больше о нашем курсе, если вам интересен карьерный переход в продакт-менеджмент.
Основные этапы цикла разработки
Мы выделяем следующие основные этапы жизненного цикла разработки ПО:
Продакт-менеджер вовлечен на протяжении всего цикла, а его работа на каждом из этапов состоит из пяти основных задач:
1) Определять приоритет задачи и доработок
2) Находить компромиссы во всех возникающих конфликтах
3) Уточнять требования
4) Определять границы проекта
5) Следить за сроками
! Важно, что в некоторых компаниях за определение границ проекта и сроки его выполнения отвечает проджект-менеджер. В этом материале мы будем исходить из того, что эти задачи на себя берет продакт-менеджер.
Рассмотрим каждый этап подробнее.
Создание PRD и сбор требований
В этом разборе мы будем говорить об этапах SDLC на примере фичи, но описываемые процессы применимы и для более масштабных проектов.
Разработка начинается тогда, когда продуктовая гипотеза уже провалидирована — например, в ходе исследования потребность пользователей в определенной фиче подтвердилась.
На первом этапе продакт-менеджеру необходимо подготовить подробное описание фичи. Документ, который содержит всю информацию о предстоящей работе над фичей, называют Product requirements document (PRD). PRD отвечает на вопросы:
— зачем фича нужна пользователям? какие предпосылки для ее внедрения?
— зачем фича нужна бизнесу? какую выгоду он получит от нее?
— как будет выглядеть фича в продукте?
— как мы убедились, что нашли оптимальное решение?
— какие команды затронет реализация фичи?
— как мы измерим успех от внедрения фичи?
— какие риски мы видим?
— сколько времени потребуется на реализацию фичи?
Таким образом, документ выступает единым местом, в котором собрана вся информация о результатах работы на этапе Discovery. Конечно, список вещей выше — неполный и не универсальный для любого PRD: детали зависят от специфики продукта и компании.
В этой от Ленни Рачицки (Lenny Rachitsky) вы можете найти различные варианты шаблонов PRD: от одностраничных документов до более подробных. Для начинающих мы рекомендуем обратить внимание на ссылку .
Более подробно о нюансах подготовки PRD мы рассказываем в программе «Профессия: продакт-менеджер».
При подготовке PRD продакт-менеджер взаимодействует с другими специалистами, чтобы составить наиболее полную картину. В частности:
— С разработчиками продакт определяет, какие сервисы и части продукта нужно будет доработать для реализации фичи и как.
— С тестировщиками продакт обсуждает, какие сценарии и кейсы будет необходимо протестировать, чтобы убедиться в работоспособности фичи.
— С дизайнерами продакт создает макет (мокап) того, как фича будет выглядеть в продукте для пользователя, и продумывает флоу для этой фичи.
Другие важные аспекты работы над PRD — первичная оценка трудозатрат на разработку и составление критериев приемки. Последнее подразумевает условия и требования, которым должен отвечать конечный результат разработки. Эти условия и требования могут касаться функциональности продукта или фичи (она работает согласно ожидаемому), безопасности пользовательских данных, совместимости с разными системами и устройствами и так далее.
Кроме того, PRD необходим не только для тех команд, которые будут задействованы в рамках работы над фичей, но и для презентации стейкхолдерам, если такая потребность есть. В емком формате документ помогает защитить необходимость планируемых работ перед руководством.
Резюме этапа
Мы знаем:
— для кого мы делаем фичу;
— кто будет вовлечен в работу;
— как будет выглядеть фича;
— сколько времени это займет приблизительно;
— все эти аспекты зафиксированы письменно.
Пройти симуляторы от GoPractice можно в группе с опытным ментором.
Что вы получите:
✅ Онлайн-встречи для обсуждения прогресса и разбора вопросов
✅ Общение в закрытом чате для постоянной обратной связи с ментором и одногруппниками
✅ Дополнительные кейсы от ментораПоддержка ментора доступна при обучении:
→ в «Симуляторе управления продуктом на основе данных»
→ в «Симуляторе управления ростом продукта»
→ в «AI/ML-симуляторе для продакт-менеджеров»
Планирование
Цель этого этапа — обсудить вопросы с разработкой, оценить задачи и сформировать план разработки, передать задачи в работу.
Далее проводится декомпозиция задач, описанных в документе, с их распределением между командами. Разработчики проводят оценку сроков выполнения этих задач, а при необходимости продакт-менеджер обсуждает вместе с тимлидами команд обоснование сроков и возможности ускорить работу. Кроме того, продакту важно заложить дополнительное время на незапланированные ситуации и работы.
Таким образом, ключевая цель продакт-менеджера на этом этапе работы — добиться того, чтобы разработчики всех команд, отвечающие за куски продукта, в которые вносятся изменения, дали оценки сроков задач и подтвердили, что взяли их в работу.
Резюме этапа
Задачи конкретизированы и распределены между участниками команд, понятны сроки их выполнения. Задачи занесены в таск-трекер.
