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