В этом материале рассказываем, что важно знать продакт-менеджеру о жизненном цикле разработки ПО и какую роль он выполняет в этом процессе.

Жизненный цикл разработки программного обеспечения (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: от одностраничных документов до более подробных. Для начинающих мы рекомендуем обратить внимание на ссылку “My personal 1-pager template”.

Более подробно о нюансах подготовки PRD мы рассказываем в программе «Профессия: продакт-менеджер».

При подготовке PRD продакт-менеджер взаимодействует с другими специалистами, чтобы составить наиболее полную картину. В частности: 

— С разработчиками продакт определяет, какие сервисы и части продукта нужно будет доработать для реализации фичи и как.

— С тестировщиками продакт обсуждает, какие сценарии и кейсы будет необходимо протестировать, чтобы убедиться в работоспособности фичи.

— С дизайнерами продакт создает макет (мокап) того, как фича будет выглядеть в продукте для пользователя, и продумывает флоу для этой фичи. 

Другие важные аспекты работы над PRD — первичная оценка трудозатрат на разработку и составление критериев приемки. Последнее подразумевает условия и требования, которым должен отвечать конечный результат разработки. Эти условия и требования могут касаться функциональности продукта или фичи (она работает согласно ожидаемому), безопасности пользовательских данных, совместимости с разными системами и устройствами и так далее.

Кроме того, PRD необходим не только для тех команд, которые будут задействованы в рамках работы над фичей, но и для презентации стейкхолдерам, если такая потребность есть. В емком формате документ помогает защитить необходимость планируемых работ перед руководством.

Резюме этапа

Мы знаем: 

— для кого мы делаем фичу; 

— кто будет вовлечен в работу; 

— как будет выглядеть фича; 

— сколько времени это займет приблизительно;

— все эти аспекты зафиксированы письменно.

Планирование 

Цель этого этапа — обсудить вопросы с разработкой, оценить задачи и сформировать план разработки, передать задачи в работу.

Далее проводится декомпозиция задач, описанных в документе, с их распределением между командами. Разработчики проводят оценку сроков выполнения этих задач, а при необходимости продакт-менеджер обсуждает вместе с тимлидами команд обоснование сроков и возможности ускорить работу. Кроме того, продакту важно заложить дополнительное время на незапланированные ситуации и работы.

Таким образом, ключевая цель продакт-менеджера на этом этапе работы — добиться того, чтобы разработчики всех команд, отвечающие за куски продукта, в которые вносятся изменения, дали оценки сроков задач и подтвердили, что взяли их в работу.

Резюме этапа

Задачи конкретизированы и распределены между участниками команд, понятны сроки их выполнения. Задачи занесены в таск-трекер.

Разработка

Разработчики, дизайнеры и другие смежные специалисты взяли задачи в работу — что дальше?

Часто бывает так, что у разработки возникают дополнительные вопросы: что-то не учли, что-то не продумали, упали более срочные задачи и так далее. И вновь задача продакта — находить компромиссы и эффективные решения возникающих сложностей и разрешать возможные конфликты. Например, стоит ли привлекать дополнительные ресурсы и уместно ли увеличить сроки разработки.

«В процессе разработки может возникнуть необходимость отказаться от части запланированной функциональности. В таком случае разработка фичи может продолжаться без нее, а продакт-менеджер берет в дополнительную проработку ту часть, от которой пришлось отказаться. Например, так может случиться, если функциональность завязана на внешних поставщиков информации, но не все из них передают ее корректно. И продакт может потребоваться в том числе провести кастдев среди поставщиков, чтобы устранить причины проблемы».

То, как именно продакт управляет и отслеживает процессы на этом этапе, во многом будет зависеть от типа команд (кросс-функциональные, функциональные, платформенные). В этом материале мы не будем заострять внимание на этом вопросе, поскольку он требует отдельного обсуждения.

Итог работы всех команд на этом этапе — выполнить критерии приемки, обозначенные в PRD. Решение о том, выполнены ли они, в конечном итоге принимает продакт.

Резюме этапа

Фича разработана и отвечает требованиям, указанным в PRD.

Тестирование

Этот этап проводится для того, чтобы убедиться, что разработанная фича работает как задумано и не создает сложностей и непредвиденных ситуаций в продукте для пользователя. 

Вместе с QA-специалистами продакт-менеджер обсуждает, какие методы тестирования будут применяться (ручное или автоматизированное), какие сценарии будут проверены, верно ли настроена аналитика и т.д. В дополнение к этому может проводиться нагрузочное тестирование, которое проверяет работоспособность продукта и фичи при высоких нагрузках. 

Тестировщики проверяют, есть ли корнер-кейсы (редкие ситуации с определенными условиями, которые могут привести к некорректной работе продукта), есть ли нарушения логики, есть ли баги и т.д. При обнаружении проблем тестировщики относят правки в разработку. Продакт на данном этапе обсуждает с разработкой, какие изменения можно сделать после релиза, а на какие необходимо заложить время прямо сейчас. Таким образом, продакт-менеджер вновь выступает посредником и ищет компромиссы между тестировщиками и разработчиками.

«Вместе с командой QA продакт обсуждает, что именно необходимо протестировать, опираясь на PRD. Этот документ может обновляться, если появляется необходимость важного тестирования, но в целом одна из важных задач продакта — следить, чтобы тестирование не выходило за рамки необходимого. Это важно для соблюдения сроков».

Резюме этапа

Фича протестирована должным образом, все найденные баги и сложности устранены.

Релиз

Следующий за тестированием этап — релиз фичи, ее выкатка на прод.

Если продукт крупный, то чаще всего фича релизится на тестовую группу пользователей (а в случае с глобальными компаниями это могут быть и отдельные рынки). Это позволяет отловить не обнаруженные на предыдущем этапе баги и ошибки и оперативно отправить продукт на доработку. 

Не все обнаруженные проблемы можно будет исправить оперативно, и в данном случае продакту предстоит принимать решение о том, насколько критично выпустить фичу в неидеальном состоянии на всех пользователей, чтобы доработать ее позднее. 

Продакту также необходимо синхронизировать релизы разных команд и синхронизироваться с другими командами по поводу обновления (в том числе с маркетингом, поддержкой и PR).

Резюме этапа

Успешный релиз фичи на всю аудиторию продукта (или на всех пользователей, которым адресована фича).

Ретроспектива

Этот этап необходим для того, чтобы отрефлексировать все процессы на протяжении создания фичи и понять, какие улучшения стоит внести на будущее.

В рамках ретроспективы (ретро) продакт делится первыми результатами фичи и обсуждает с смежными командами возможности для ее дальнейшего улучшения, предлагая всем участникам работы поделиться своим фидбеком.

Помните, что ретроспектива — это возможность не только обсудить негативные моменты и заострить внимание на том, что пошло не так, но и возможность поблагодарить и мотивировать коллег за проведенную работу.

В этом материале — гайд о проведении ретро. 

Резюме этапа

Удалось обсудить результаты проведенных работ и поделиться фидбеком на перформанс коллег, подсвечивая как негативные, так и позитивные стороны.

Заключение

Опора на основные этапы SDLC помогает продакт-менеджеру и всей команде делать процессы разработки упорядоченными и предсказуемыми. Он нивелирует риски того, что команда не уложится в сроки, а финальный результат не будет отвечать заявленным требованиям.

И несмотря на то что работа продакт-менеджера не требует навыков разработки как таковых, его роль подразумевает погружение в ключевые аспекты разработки ПО и понимание того, как связанные с разработкой процессы влияют на скорость и качество реализации продуктовых изменений.

Узнайте больше

В этом материале — разбор того, что важно знать продактам о разработке.

Автор иллюстрации к материалу — Анна Гольде