В этом материале рассказываем, что важно знать продакт-менеджеру о жизненном цикле разработки ПО и какую роль он выполняет в этом процессе.
Жизненный цикл разработки программного обеспечения (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 необходим не только для тех команд, которые будут задействованы в рамках работы над фичей, но и для презентации стейкхолдерам, если такая потребность есть. В емком формате документ помогает защитить необходимость планируемых работ перед руководством.
Резюме этапа
Мы знаем:
— для кого мы делаем фичу;
— кто будет вовлечен в работу;
— как будет выглядеть фича;
— сколько времени это займет приблизительно;
— все эти аспекты зафиксированы письменно.
Планирование
Цель этого этапа — обсудить вопросы с разработкой, оценить задачи и сформировать план разработки, передать задачи в работу.
Далее проводится декомпозиция задач, описанных в документе, с их распределением между командами. Разработчики проводят оценку сроков выполнения этих задач, а при необходимости продакт-менеджер обсуждает вместе с тимлидами команд обоснование сроков и возможности ускорить работу. Кроме того, продакту важно заложить дополнительное время на незапланированные ситуации и работы.
Таким образом, ключевая цель продакт-менеджера на этом этапе работы — добиться того, чтобы разработчики всех команд, отвечающие за куски продукта, в которые вносятся изменения, дали оценки сроков задач и подтвердили, что взяли их в работу.
Резюме этапа
Задачи конкретизированы и распределены между участниками команд, понятны сроки их выполнения. Задачи занесены в таск-трекер.
Разработка
Разработчики, дизайнеры и другие смежные специалисты взяли задачи в работу — что дальше?
Часто бывает так, что у разработки возникают дополнительные вопросы: что-то не учли, что-то не продумали, упали более срочные задачи и так далее. И вновь задача продакта — находить компромиссы и эффективные решения возникающих сложностей и разрешать возможные конфликты. Например, стоит ли привлекать дополнительные ресурсы и уместно ли увеличить сроки разработки.
«В процессе разработки может возникнуть необходимость отказаться от части запланированной функциональности. В таком случае разработка фичи может продолжаться без нее, а продакт-менеджер берет в дополнительную проработку ту часть, от которой пришлось отказаться. Например, так может случиться, если функциональность завязана на внешних поставщиков информации, но не все из них передают ее корректно. И продакту может потребоваться в том числе провести кастдев среди поставщиков, чтобы устранить причины проблемы».
То, как именно продакт управляет и отслеживает процессы на этом этапе, во многом будет зависеть от типа команд (кросс-функциональные, функциональные, платформенные). В этом материале мы не будем заострять внимание на этом вопросе, поскольку он требует отдельного обсуждения.
Итог работы всех команд на этом этапе — выполнить критерии приемки, обозначенные в PRD. Решение о том, выполнены ли они, в конечном итоге принимает продакт.
Резюме этапа
Фича разработана и отвечает требованиям, указанным в PRD.
Тестирование
Этот этап проводится для того, чтобы убедиться, что разработанная фича работает как задумано и не создает сложностей и непредвиденных ситуаций в продукте для пользователя.
Вместе с QA-специалистами продакт-менеджер обсуждает, какие методы тестирования будут применяться (ручное или автоматизированное), какие сценарии будут проверены, верно ли настроена аналитика и т.д. В дополнение к этому может проводиться нагрузочное тестирование, которое проверяет работоспособность продукта и фичи при высоких нагрузках.
Тестировщики проверяют, есть ли корнер-кейсы (редкие ситуации с определенными условиями, которые могут привести к некорректной работе продукта), есть ли нарушения логики, есть ли баги и т.д. При обнаружении проблем тестировщики относят правки в разработку. Продакт на данном этапе обсуждает с разработкой, какие изменения можно сделать после релиза, а на какие необходимо заложить время прямо сейчас. Таким образом, продакт-менеджер вновь выступает посредником и ищет компромиссы между тестировщиками и разработчиками.
«Вместе с командой QA продакт обсуждает, что именно необходимо протестировать, опираясь на PRD. Этот документ может обновляться, если появляется необходимость важного тестирования, но в целом одна из важных задач продакта — следить, чтобы тестирование не выходило за рамки необходимого. Это важно для соблюдения сроков».
Резюме этапа
Фича протестирована должным образом, все найденные баги и сложности устранены.
Релиз
Следующий за тестированием этап — релиз фичи, ее выкатка на прод.
Если продукт крупный, то чаще всего фича релизится на тестовую группу пользователей (а в случае с глобальными компаниями это могут быть и отдельные рынки). Это позволяет отловить не обнаруженные на предыдущем этапе баги и ошибки и оперативно отправить продукт на доработку.
Не все обнаруженные проблемы можно будет исправить оперативно, и в данном случае продакту предстоит принимать решение о том, насколько критично выпустить фичу в неидеальном состоянии на всех пользователей, чтобы доработать ее позднее.
Продакту также необходимо синхронизировать релизы разных команд и синхронизироваться с другими командами по поводу обновления (в том числе с маркетингом, поддержкой и PR).
Резюме этапа
Успешный релиз фичи на всю аудиторию продукта (или на всех пользователей, которым адресована фича).
Ретроспектива
Этот этап необходим для того, чтобы отрефлексировать все процессы на протяжении создания фичи и понять, какие улучшения стоит внести на будущее.
В рамках ретроспективы (ретро) продакт делится первыми результатами фичи и обсуждает с смежными командами возможности для ее дальнейшего улучшения, предлагая всем участникам работы поделиться своим фидбеком.
Помните, что ретроспектива — это возможность не только обсудить негативные моменты и заострить внимание на том, что пошло не так, но и возможность поблагодарить и мотивировать коллег за проведенную работу.
В — гайд о проведении ретро.
Резюме этапа
Удалось обсудить результаты проведенных работ и поделиться фидбеком на перформанс коллег, подсвечивая как негативные, так и позитивные стороны.
Заключение
Опора на основные этапы SDLC помогает продакт-менеджеру и всей команде делать процессы разработки упорядоченными и предсказуемыми. Он нивелирует риски того, что команда не уложится в сроки, а финальный результат не будет отвечать заявленным требованиям.
И несмотря на то что работа продакт-менеджера не требует навыков разработки как таковых, его роль подразумевает погружение в ключевые аспекты разработки ПО и понимание того, как связанные с разработкой процессы влияют на скорость и качество реализации продуктовых изменений.
Узнайте больше
В этом материале — разбор того, что важно знать продактам о разработке.
Автор иллюстрации к материалу —
