Управление продуктом для UX-специалистов. От дизайна интерфейсов к успешному развитию в мире продуктов. Кристиан КрамлишЧитать онлайн книгу.
нравились головоломки, хотя и не под давлением осознания, что на кону большие деньги. Время от времени эти вопросы вновь появляются на собеседованиях, поэтому, немного поискав, вы сможете найти уже использовавшиеся примеры. Например, меня спросили, как может работать эффективный алгоритм генерации пятизначного кода доступа на клавиатуре, учитывая заданные правила или ограничения относительно чисел (набранные с повтором и так далее). Как я уже сказал, это было почти весело.
И, честно говоря, сегодня бóльшая часть приличных организаций, которые предлагают подобного рода задачи, сотрудничает с вами и помогает направить в нужное русло ваши размышления. (Если такая роль – ваша цель, но вы не информатик, то есть книги, которые помогут быстро[10] освоить эти темы. Подробнее о выборе карьеры вы прочитаете в главе 2 «Хотите ли вы стать менеджером продукта?».)
В Yahoo отделы, занимающиеся продуктом, были равны по рангу и полномочиям инженерным структурам. С самого начала веб-сайты Yahoo были запланированы и созданы людьми, которые назывались продюсерами (заимствованный термин из средств массовой информации и вещания).
За несколько лет эти должности усложнились и в конечном счете разделились на две разные роли, одна из которых сосредоточилась на планировании и определении направления того, что нужно создать (менеджер продукта), а другая занималась собственно созданием продукта (в частности, фронтенд-разработчики). На самом деле потребовалось некоторое время, чтобы фронтенд-разработчики были приняты на равных в инженерных организациях, особенно учитывая предубеждения против HTML и других языков для фронтенд-разработки, но здесь важно то, что роли продуктов и программистов, по крайней мере в одной из технологических интернет-компаний эпохи 1990-х («доткомы»), имели общего предка.
Перенесемся в настоящее – эта роль по-прежнему остается весьма технической. Сильный UX-специалист испытывает серьезный интерес к технологии, с помощью которой и для которой он проектирует, подобно тому как художники стараются разобраться в своих материалах. Но в то же время дизайнер в состоянии исследовать возможности, не беря в расчет очевидные ограничения существующего технического стека и кодовой базы.
Менеджеры продуктов (и не только «технические»), напротив, должны глубже вникать в суть, свойства и ограничения технологий, с которыми они работают, и никогда не позволять себе роскоши отодвигать все эти факторы на второй план. (ПМ также тратят намного больше времени на прямое взаимодействие с инженерами, нежели UX-дизайнеры, что создает еще бóльшую необходимость демонстрировать доскональное знание технических вопросов, которые всплывают при любом принятии сложного решения.)
Новая гибридная инженерно-бизнесовая модель продукта на практике по-прежнему оставляет желать лучшего, поскольку большинство компаний по-прежнему разрабатывают ПО по водопадной схеме и командуют разработчиками в стиле «начальник всегда прав», но примерно в первое десятилетие нашего века несколько влиятельных
На самом деле эти темы в первом приближении изучают два-три младших курса на математических специальностях вузов. Так что либо быстро, либо освоить.