«Product owner должен уметь мыслить стратегически, играть вдолгую и не хвататься за сиюминутные цели»

Мы продолжаем цикл публикаций про ИТ-профессии. В этот раз мы поговорили с Павлом, product owner'ом «Планеты. Аналитики» IBS. Он рассказал о том, чем его должность отличается от РП, как проработал на пяти разных ролях, и почему «сделать хорошо или уложиться в срок» — одна из самых сложных управленческих дилемм.

Product owner (владелец продукта) — это специалист, который управляет созданием продукта и отвечает за итоговый результат.

— Расскажи, как ты видишь позицию product owner?

— Каждый воспринимает эту роль по-своему. Если вспомнить scrum, то это специалист, ставящий команде верхнеуровневые задачи — задачи-цели.

Например, мы хотим получить определенную фичу. Product owner может не знать, как её реализовать и даже как она должна выглядеть в конечном итоге. Но он объясняет команде, что должно появиться. Специалисты реализуют эту идею, и product owner решает, подходит ему то, что получилось, или нет.

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

— Можешь всё-таки подробнее объяснить, чем владелец продукта отличается от РП?

— Он отличается ровно тем, чем отличается продукт от проекта. У product owner-а есть продукт, срок жизни которого неограничен. Соответственно, думать ему надо больше стратегически, чем конкретными сроками.

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

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

— Назови три главных качества, которыми должен обладать хороший product owner?

— Во-первых, он должен разбираться в сфере, для которой предназначен продукт. То есть должен хорошо понимать пользователя, состояние рынка и технологий. Например, мне сам по себе был интересен BI (business intelligence), поэтому и продукт стал интересен. А что-то другое, возможно, не получилось бы или не привлекло бы моего внимания.

Во-вторых, ты должен уметь мыслить стратегически. Уметь играть вдолгую и не хвататься за сиюминутные цели.

И, в-третьих, владельцу продукта необходимо умение действовать в условиях максимальной неопределенности. Потому что в самом начале создания продукта у тебя полная сингулярность. Если у РП есть хотя бы бюджет, в рамках которого он может нанять людей, то у тебя нет ни людей, ни денег — ничего. Надо уметь выкручиваться.

— Ты работаешь у нас уже очень давно, при этом в разных ролях. Как так получилось?

— На предыдущем рабочем месте я занимался базами данных, десктоп-разработкой и Java-разработкой под web на специфичном фреймворке — ADF.

В IBS как раз нужен был специалист по ADF, мне это предложение показалось интересным. Какое-то время занимался им, немного криптографией, но потом всё равно вернулся к базам данных. Когда образовался департамент проектирования и разработки, понадобился отдел баз данных. Тогда я начал осваивать роль линейника как руководитель отдела разработчиков баз данных.

Затем появилась разработка аналитической системы, из которой вырос продукт «Планета. Аналитика». В этот момент, как говорил раньше, я увлекся Oracle BI. А здесь нужно было создать собственный BI, что ещё интереснее. Так что я с удовольствием занимался этим в рабочее и личное время. Система начала развиваться как самостоятельный продукт, и я стал product owner-ом.

Сейчас совмещаю роли руководителя отдела разработки баз данных и product owner-а на «Планете. Аналитика».

— Из чего состоит твой обычный рабочий день?

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

— А сам пишешь код?

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

— Что больше всего нравится в своей работе?

— Видеть результат. Как получается то, что ты задумывал, допустим, три года назад. Понимать, что ты правильно всё придумал — молодец. Вот твой продукт живёт и может развиваться дальше.

— Ты часто из Ульяновска ездишь в командировки в Москву. Не думал перебраться на «постоянку»?

— Нет, не думал. Мне кажется, что разработчику, который не общается напрямую с бизнесом, не важно, где находиться. А Москва… Все жалуются, что дорога много времени отнимает, есть и другие неудобства. Пока я не вижу для себя каких-то больших плюсов.

— Как ты переключаешься с рабочего ритма?

— С удовольствием играю в интеллектуальные игры. Вместе с командой «Олимп» в «ЧГК IBS» несколько сезонов сыграли. По-моему, в какие-то годы мы занимали и первое, и второе место.

Когда есть время, играем с коллегами в настолки, в «Мафию». Это не часто удаётся. Сейчас активная фаза развития продукта, и на что-то другое остаётся не очень много времени. Спорт у меня свой — качалка, бассейн, иногда летом большой теннис. Ещё есть аспирантура.

— Что изучаешь?

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

— Какие решения тебе приходится принимать на твоей позиции?

— Самые разные. Всё, что касается выпуска релизов: какие задачи должны войти, что куда включаем, когда выпускаем релиз, оценка новых проектов и новых фич. Плюс всё, что касается команды и развития продукта.

— Можешь вспомнить какие-то решения, которые дались особенно тяжело?

— Тяжесть бывает разная. Бывает моральная, а бывает связанная с физической нагрузкой. Есть ситуации, когда нужно учесть очень много факторов, чтобы принять решение объективно.

Решение, которое физически далось мне тяжелее остальных, — это составление веса бэклога продукта в конце прошлого года. Все задачи по «Планете. Аналитика» нужно было оценить в днях и деньгах. Получилось 300 с лишним задач. Всё надо было вспомнить, систематизировать, убрать лишнее. Получилась объёмная работа.

А морально тяжелые решения — сделать хорошо или уложиться в срок.

— Ты часто с этим сталкиваешься?

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

— А какими решениями ты гордишься?

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

Я думаю, сейчас мы войдём в фазу поиска нестандартных решений, у которых, наверное, нигде нет аналогов. Это уже намного интереснее. И это то, ради чего всё создавалось.

— Как ты следишь за трендами в мире ИТ? Есть ли ресурсы конкретно для продакта?

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

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

Стараюсь слушать лекции «Биржи знаний IBS», в частности, всё, что касается разработки. Считаю, что у нас прекрасный курс управленческого минимума. Такого рода вещи каждый раз тебя заставляют задуматься, применить к своей жизни, что-то попробовать.

— Можешь спрогнозировать, за какими технологиями будущее?

— Хочется верить, что low-code-платформы будут развиваться и давать реальные результаты. Что на них будут создавать нормальные приложения, не топорные и не шаблонные. И это даст свободу аналитикам и тем, кто не пишет код, создавать что-то значимое.

Этим в настоящий момент как раз занимаются ребята в департаменте проектирования и разработки. ADF, которая мне была интересна в своё время, — это такой ранний прототип, платформа, облегчающая и ускоряющая кодирование. А сейчас идет вторая волна уже на более высоком уровне.

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

— Что можешь посоветовать тем, кто хочет попасть в сферу ИТ?

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

В самом начале стоит определить область, куда именно в ИТ ты стремишься. Потому что профессия разработчика тяжёлая, рутинная. Если человек не заточен под разработку, она способна убить в нём желание развиваться дальше. А ведь в ИТ есть дизайнеры, аналитики, тестировщики, РП, владельцы продуктов, дата-сайентисты, дата-инженеры и т.д. В общем, огромный спектр профессий.

— Хорошо, а тем, кто хочет стать конкретно product owner-ом?

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