Как джуну стать продактом и не потерять веру в человечество?

в 16:29, , рубрики: junior, product management, product owner, Карьера в IT-индустрии, разработка мобильных приложений, Управление продуктом

О личном опыте

Прежде чем стать Владельцем продукта, я добрых 8 лет оттарабанила в Сбере. К слову, продактом я стала в том же Сбере и несказанно радовалась этому следующие 5 лет.

Любопытно, что работать я начала в 17, в старой-доброй Сберкассе. Как сейчас помню, первую жалобу, написанную в мой адрес клиенткой с таким остервенением, что бумага в некоторых местах была порвана. В ту пору банкоматы были настолько ламповыми, что запускались лишь после доброй дюжины пинков, а о том, чтобы оплачивать платёжки в терминале многие и не думали. Тут, конечно же, на сцену выходила я, в зеленом галстуке и белом пальто, самозабвенно просвещая шарахающихся от банкоматов, аки от адского горнила, людей разных возрастов, рас и вероисповеданий.

Мой карьерный рост был столь стремительным, что за день до своего 19-летия на мои хрупкие плечи обрушился офис банка со штатом в полсотни человек, которым мне надо было каким-то образом руководить. В ход шли все подручные средства от шантажа до рукоприкладства. С той поры у меня на полке пылится черный пояс по "стрессоустойчивости" и первый юношеский разряд по "выживанию в условиях близких к экстремальным".

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

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

Я уверена, что мой кейс, не самый частый, ну в смысле... когда ты начинаешь работать в новой роли и у тебя в голове, кроме обезьянки с литаврами и пары перекати-поле по теме вопроса больше ничего. Вместе с тем вступительная часть была посвящена тому, что даже человек с совершенно, как бы это помягче, нетипичным бэкраудом, может вырасти в senior, но это не точно.

Итак, засучим рукава. Как быть, если ты junior PO?

Купи абонемент к психотерапевту на первый аванс lol

С пониманием к себе

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

Осмотреться на местности

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

Не цепляться за экспертизу

Ты вырос из проектной роли? Самое главное, не фокусироваться остервенело, на своей прошлой экспертизе. Тут ситуация достаточно парадоксальная, ведь с одной стороны, тебя повысили за то, что ты хорошо кодил/анализировал/рисовал/тестировал/писал/подставить свое, с другой - тебе предстоит делать то, в чем экспертизы у тебя нет.

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

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

Босс мой - друг мой

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

Важно с первых дней проинтервьюировать босса на предмет:

  • Его ожиданий от тебя, как от новоиспеченного руководителя.

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

  • Какие риски, на его взгляд, присущи конкретно этому участку работы.

  • Кого он считает ключевыми стейкхолдерами. Каковы основные особенности работы с ними.

  • Если босс погружен в перипетии кадрового вопроса, запросить обратную связь о людях. В эту же кассу - понимание маневров для роста и вознаграждения сотрудников (не плохо бы понять, какие возможности для мотивации людей есть помимо "дружного коллектива" и "перспективной компании")

  • Что случилось с твоим предшественником? Тут прям со всеми вытекающими. Если выпроводили, то почему. Если ушел сам, как это обосновал? Если его повысили, то за что именно?

  • И, наконец, что скажет твой руководитель, оказавшись перед Пу****м?

Задушевные беседы с другими РО

Очень было бы на пользу выбрать РО по душе (вот прям натурально, на кого глаз упадет) и расспросить его по-свойски о тяготах и нюансах работы за стаканчиком смузи. Очевидно, что всего ты не узнаешь, да и к субъективному опыту человека стоит относиться с известной долей недоверия. Но лишний пазл в копилку понимания общего контекста, вовсе не лишний. В целом вопросы могут быть похожи, на перечень выше. К тому же, РО-сосед отличный источник контактов, которые тебе потребуются ниже.

Стэйкхолдеры

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

Команда

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

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

Если в компании есть agile-коуч, то желательно пригласить его на ваши дебютные премьеры церемоний, а как максимум попросить помочь с организацией тебе самому или твоему scrum мастеру.

Лиды компетенций

Узнай и пообщайся с лидами delivery и discovery компетенций. Важно пройтись по:

  • Релизный менеджер. Можно, конечно, закопаться в документацию о производственном процессе (если она есть) или попробовать набить собственные шишки вылетев разок-другой из релиза, но быстрее и приятнее получить информацию из первых рук. Цель: уложить у себя в голове дорожную карту релизного цикла и отметить на ней ключевые вехи, критерии прохождения этих вех, сроки, а так же какие есть планы В для каждой из этих реперных точек. На выходе тебе нужно понимать что, как и когда команда должна сделать начиная с документации и заканчивая полномасштабным тиражом.

  • Архитектор. Важно понимать, что и как тебе придется дорабатывать силами команды и каково окружение смежников, чтобы обозначить для себя потенциальные зависимости.

  • Дизайн лид. Есть ли требования к исследованиям, какими возможностями располагает компания для проведения исследований. Есть ли в кампании UX лаборатория.

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

  • Для самых смелых: безопасники, юристы, риски, казначейство и сопровождение. Тут хорошим тоном будет познакомиться и попросить общие наставления на предмет дальнейшего взаимодействия. Если таковая есть, запросить документацию, описывающую порядок взаимодействия. Это может показаться too much, но британскими учеными доказано, что спотыкание на одной из этих предметных областей грозит полномасштабным разрывом ж**ы.

Следующие вопросы, разные подходы к продуктовому управлению, предлагают ставить в разной последовательности. Так что up to you.

Что за продукт-то?

Простите мне КЭПовщину, но всю документацию которая есть, от технической до бизнес (даже если читая, ты не понимаешь вообще о чем речь) надо будет найти и потребить. Я не буду говорить о том, что если бэклог есть, его надо вдоль и поперек изучить, иначе меня забросают фекалиями. Опять-таки это подходит для кейсов, в которых продукт не пилят с нуля. Если нулевой продукт - это ваш случай, посмотрите на конкурирующее решение, которым компания закрывает потребность as is, benchmarks рынка и конкурентов. А если вы работаете над уже существующим продуктом, то вышеперечисленное так же надо будет проделать.

Кто клиент-то?

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

Какую потребность пользователя мы закрываем?

Важно понять набор потребностей которые закрывает ваше решение, тут в помощь первым делом, глубинки. Определив ЦА, нужно понять ее боли, потребности и ожидания. Глубинки это один из ключевых источников вдохновения. Лучше, разве что, может быть только тырить идеи у конкурентов.

Зачем мы это делаем?

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

План первых трех месяцев работы

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

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

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

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

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

Запоздалый дисклэймер

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

У кого-то от этого списка дел может волосяной покров зашевелиться, а матерые продакты хохотнут над поверхностностью. Важно не это. Важно то, что если ты джун - тебе будет больно и тяжело, но в какой-то момент это пройдет и, будем верить, что ситуация разрешится успешно. Шучу - все точно получится! ✌️

Автор:
sowmaryam

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js