Как ты пришёл в разработку?

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

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

Программирование было моим хобби со школы. Я изучал его самостоятельно, с помощью книг и технических форумов. На первых курсах вуза мы с другом делали сайты на заказ: он отвечал за дизайн, я — за разработку. Чтобы разобраться с незнакомыми темами, я проводил много времени на форумах. Когда я учился на четвёртом курсе вуза, мне написал администратор одного из форумов — и предложил работу в Яндексе.

В 2008 году я пришёл в сервис «Куда все идут»: на нём пользователи смотрели рейтинг мероприятий и выбирали, как провести досуг. Позже мне поручили объединить этот продукт с Яндекс Афишей и написать новый сервис. А после я начал работать над Яндекс Телепрограммой. Но на проекте поменялась команда, и мою версию не запустили. Это меня укололо, но я знал, что хочу работать в Яндексе. Мне нравилось находиться среди интересных и умных людей. Тогда я перешёл во внутренние сервисы, стал разрабатывать системы, которыми пользуются все сотрудники Яндекса.

Когда ты понял, что хочешь отвечать за продукт?

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

Через полгода я вернулся в разработку: занимался только техническими вопросами и руководил программистами. Но я хотел расти дальше и отвечать за продукт. Я ещё раз попробовал погрузиться в эту профессию через два года. И у меня получилось!

А чего не хватило, когда ты стал руководителем продукта в первый раз?

Я думал, что управление продуктом — следующая ступень развития для разработчика. Но это не так. Это другая профессия, которая требует особых навыков.

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

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

Что помогло тебе вернуться в управление продуктом?

Думаю, есть несколько факторов, которые сделали вторую попытку успешной:

• Анализ ошибок. Я изучил дополнительные материалы и посетил продуктовые курсы Яндекса.

• Поддержка от нового руководителя. Он помог мне адаптироваться и уделил больше внимания. Это залог успеха: не только личные качества и мотивация, но и правильная среда с грамотным наставником.

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

Хорошо. Но как ты поймёшь, что стал опытным продуктовым руководителем?

В разработку я пришёл самоучкой, и у меня получилось добиться успеха. Но из-за отсутствия фундаментальных знаний настал момент, когда я упёрся в потолок развития. Например, я сталкивался с задачами, для решения которых требовалось знать теорию computer science. Мне не хватало подготовки, поэтому моя эффективность заметно падала. Я искал информацию в книгах и блогах. Подписывался на разработчиков из Америки, Европы, России и повторял их опыт в своих задачах.

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

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

Интересно, спасибо. Расскажи, что объединяет разработку и управление продуктом?

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

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

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

Классная метафора. Что посоветуешь тем, кто только выбирает, куда расти?

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

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