Как устроен Scrum в Atlassian, как нанимать продактов и что делать с множеством разных мнений — спикеры ProductSense Stories ответили на вопросы участников конференции.
- Что лучше: выращивать менеджера продуктов внутри коллектива или нанять специалиста из какой-то известной компании?
- Что вы делаете, если в команде много разных мнений по одному вопросу?
- Как работает Scrum в Atlassian — большой команде, где все считаются разработчиками?
Что лучше: выращивать менеджера продуктов внутри коллектива или нанять специалиста из какой-то известной компании?
Отвечает Barron Ernst, Product Manager, Zenly, ex Director of Product, Booking.com.
Я использую комбинацию обоих методов. Но вообще, все сильно зависит от компании, в которую вы попали. Например, мне очень повезло с командой Zenly — там уже было несколько мощных, сформировавшихся продактов. Но бывало и по-другому. В One Kings Lane я работал с командой, которая первый раз столкнулась с продакт-менеджментом. Кажется, я был их первым руководителем и ментором в этом направлении. Они накопили большой опыт в маркетинге, а у меня было глубокое понимание потребителя. Поэтому для команды One Kings Lane работа со мной была, скорее, возможностью прокачать продуктовые навыки и освоить инструменты продакт-менеджмента, чтобы усилить свой маркетинговый опыт способностью глубоко понимать клиента и стать крепкими продактами.
В общем, у меня нет какого-то шаблона, будто бы продакт-менеджеры — это какие-то особые люди, которые появляются сами собой. В профессию можно войти откуда угодно — например, из разработки. Хотя немало людей приходит в продакт-менеджмент и без технического бэкграунда. Думаю, лучшие менеджеры продукта — это те ребята, которые одновременно способны глубоко погрузиться в потребности клиента и при этом заслужить доверие и расположение команды разработчиков.
И хотя они не всегда являются техническими специалисты, они обязаны понимать проблемы команды и конечный продукт, сравнивать стоимость разных решений, а также чувствовать эмоциональное состояние команды. Только так они смогут привести команду к успеху. Да, это не идеальный ответ на вопрос. Но думаю, что это те самые качества, которые мы обычно хотим видеть в продактах. Мы ищем понимание пользователей, понимание команды, способность достигать результатов. И мне кажется, эти качества можно найти и у готовых специалистов, и у новичков, из которых вы будете растить настоящих продакт-менеджеров.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Что вы делаете, если в команде много разных мнений по одному вопросу?
Отвечает Анна Бояркина, Head of Product, Miro.
Во-первых, если нам нужно принять решение, мы составляем список важных критериев. Например, недавно мы обсуждали, стоит ли открывать офис. Мнения в группе разделились. И мы выписали основные причины для открытия офиса: наши риски, желания людей, количество людей, которые уже не могут сидеть дома и хотят перебраться в офис, коммуникационные процессы, которые нарушены или не нарушены из-за удаленки. Потом мы оцениваем этот список и принимаем решения.
Во-вторых, всегда должен быть тот, кто принимает финальное решение. Потому что без такого человека договориться бывает очень сложно. У нас эта роль называется Directly responsible individuals — тот, кто берет на себя ответственность за решение и потом драйвит процесс. Такой человек учитывает мнения всей команды, но итоговое решение принимает сам.
Как работает Scrum в Atlassian — большой команде, где все считаются разработчиками?
Отвечает Дмитрий Меликов, Senior Product Manager, Jira Cloud, Atlassian.
Мы следуем достаточно стандартным практикам — у нас двухнедельные спринты. Продуктовая группа стандартная: бэкенд-разработчики, фронтенд-разработчики, несколько фулстек-разработчиков. Пожалуй, единственное отличие от других компаний в том, что у нас нет выделенного Q&A, тестировщиков. Тестирование обычно включено в стандартный процесс разработки. Сначала девелоперы тестируют свой код, потом код друг друга. У нас есть для этого ряд практик. Например, когда мы всей командой набрасываемся на одну фичу и тестируем ее все вместе.
У фронтендеров и бэкендеров есть свои тимлиды, которых мы вовлекаем в проработку фичей и планирование. Планирование тоже достаточно стандартное. Есть фичи, которые мы хотим взять в работу, и мы заранее начинаем к ним готовиться. Назначаем им фича-лидов, которые за них отвечают, драйвят весь процесс: управляют проектом, определяют сроки и размер команд — все, что необходимо, чтобы выполнить работу.
Фича-лиды прорабатывают свои фичи, привлекают нужных им людей для оценки и планирования задач. В результате на планинг спринта мы уже выходим с проработанной фичей и готовым фича-лидом, который в этой фиче отлично ориентируется. Он сам презентует задачи на спринт или несколько спринтов команде. В итоге команда с самого начала знает, что это за фича и что надо делать, а планирование спринта уже достаточно формальное — мы просто определяем конкретные виды работ, четкие цели и сроки.
