Безусловно, каждый в команде разработчиков делает всё возможное для выпуска крутого продукта. Но в случае неудачи все шишки сыплются на одного человека — менеджера по продукту. Конечно, на орехи достанется не только ему. Но именно для менеджера по продукту эта неудача — не просто «рабочий момент», а крест на всей проделанной работе.

Как вообще становятся менеджерами по продукту? Кто этот человек на самом деле? Чем именно он занимается целыми днями, из-за чего переживает? Как, в конце концов, строятся его взаимоотношения с продуктом, коллегами, пользователями и объективной реальностью? Мы перевели для вас статью об этом.

Перевод статьи выполнен компанией-локализатором Alconost.

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

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

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

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

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

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

До недавнего времени стоимость поездки в такси тоже была плавающей. Даже онлайн-сервисы рассчитывали сумму лишь примерно — окончательная стоимость формировалась только в конце пути. Тариф, как правило, включает три компонента: стоимость посадки (иногда с включенными километрами и/или минутами), стоимость километра и стоимость минуты. Конечно, можно было рассчитать примерную цену за поездку и раньше, но в конце она могла измениться из-за того, что, например, по пути водитель задержался в пробке. Понятно, что пассажирам это не всегда нравилось.

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

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



Все понимают, что для работы над продуктом, особенно в IT, знания технологий так или иначе необходимы. Для менеджера не должны быть новыми слова «бэкенд», «верстка», «база данных». Чтобы отлавливать баги или видеть точки роста в продукте, нужно не просто постоянно им пользоваться, но и понимать, как он устроен. К разработчикам лучше приходить с формулировками «на мобильном интернете долго отдаётся вёрстка» или «при таком сценарии не загружается часть данных», а не говорить «вот тут что-то тормозит, посмотри». Таким образом менеджер перекладывает генерацию и проверку гипотез о том, что же происходит в проблемном месте, на разработчика, у которого «такая же точно нога, но не болит».

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

Этим летом в Яндексе пройдет уже седьмая Школа менеджеров. Каждый год на участие в ней претендует несколько сотен человек. У большинства из них бывает очень много вопросов о том, что из себя представляет работа менеджера в Яндексе и что нужно делать, чтобы в принципе быть хорошим менеджером.



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

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