Несомненно, некоторые UX-руководители становятся по-настоящему компетентными и мудрыми в отношении бизнес-стороны работы, за которую они ответственны. Это, в свою очередь, приводит к принятию обоснованного решения о том, переходить ли на более ориентированную на бизнес должность, такую как менеджер продукта, или остаться в сфере UX и хранить эти знания как еще одну сверхспособность в своем арсенале.
Некоторые из нас проходят через ряд других ролей. Есть инженеры, которые становятся UX-дизайнерами, а затем начинают видеть в управлении продуктом возможность объединить эти способности.
В любом случае это самые веские причины изучить возможности смены ролей, поскольку они продиктованы вашими внутренними и природными потребностями и интересами. В то же время они сами по себе не гарантируют успешного перехода, который принесет удовлетворение, если не будет поддержки в компании.
Являются ли эти причины вескими?
Все эти причины законны и имеют свои нюансы и последствия. Чтобы изучать потенциальную возможность для роста, вам не нужна веская причина. Но все же уделите некоторое время тому, чтобы обдумать компромиссы и издержки упущенной выгоды при выборе карьеры менеджера продукта или решения остаться в UX.
Присмотритесь особо внимательно, не поддались ли вы заблуждению «трава зеленее», которое романтизирует преимущества альтернативного пути или невыбранной дороги и преуменьшает усилия по скашиванию, прополке и разбрасыванию удобрений, благодаря которым и зеленеет газон у вашего соседа.
А UX-специалисты, рассматривающие для своего карьерного развития направление управление продуктом, тоже должны хорошо понимать повседневные реалии выполнения этой работы.
Но что именно вы здесь делаете?
Когда UX-специалисты вынуждены пихаться локтями с менеджерами продукта, они начинают ясно осознавать и, возможно, даже беспокоиться о той серой области, где их обязанности пересекаются. Конечно, в действительности у этих двух ролей есть много общих ценностей (ориентация на пользователя, исследования, итерации, тестирование/измерение и так далее). Эти общие обязанности могут несколько затушевывать различия между ролями, поэтому вы должны знать, что в действительности работы довольно разные.
Любой, кто рассматривает управление продуктом как этап в карьере, для начала должен задать себе три вопроса.
1. Люблю ли я электронные таблицы?
2. Я могу хорошо писать?
3. Глубоко ли меня интересует динамика межличностных отношений?
Управление продуктом – это не работа дизайнера. Она требует некоторого знакомства с дизайном и глубокой чувствительности к проблемам пользовательского опыта, но повседневные задачи и специализированные работы в управлении продуктом редко подразумевают перемещение пикселей.
Конечно, иногда приходится составлять диаграммы, и есть много менеджеров продукта, которые рисуют макеты и даже прототипы. Но и они большую часть своего времени тратят на работу со словами и данными, а не рисунками.
Поэтому если вы любите целыми днями сидеть в Figma, Sketch или Swift, то вы, возможно, не обрадуетесь тому, что придется бросить все эти занятия или их большую часть ради задач и обязанностей по управлению продуктом. Вместо того чтобы жить в творческом процессе создания программ, вам придется тратить кучу времени на инструменты управления проектами по гибким методологиям, например Jira (обычно с Confluence), и выполнять, допустим, такие задачи:
• писать техническую документацию;
• разбивать эпики на пользовательские истории;
• приводить в порядок бэклог;
• планировать предстоящие спринты;
• отвечать на вопросы разработчиков по тикетам;
• проверять демоверсии, а потом одобрять их или отправлять на доработку;
• изучать данные автоматического тестирования;
• просматривать график оставшихся работ и другие визуализации прогресса;
• проводить ретроспективы.
На что еще вы будете тратить время? На почту (или Slack, но писать и отвечать на большое количество сообщений вам придется неизбежно) и на приложение календаря, где вы будете планировать встречи таким образом, чтобы не занимать самое продуктивное время дня у сотрудников, и организовывать ритуалы гибких методологий обычно с периодичностью раз в две недели (планирование, ежедневные стендапы, демонстрации и ретроспективы); на отчетность для крупных компаний, руководства или совета директоров; на ежеквартальное или даже ежемесячное обновление дорожных карт.