«Product owner должен уметь мыслить стратегически, играть вдолгую и не хвататься за сиюминутные цели»
Мы продолжаем цикл публикаций про ИТ-профессии. В этот раз мы поговорили с Павлом, product owner'ом «Планеты. Аналитики» IBS. Он рассказал о том, чем его должность отличается от РП, как проработал на пяти разных ролях, и почему «сделать хорошо или уложиться в срок» — одна из самых сложных управленческих дилемм.
Product owner (владелец продукта) — это специалист, который управляет созданием продукта и отвечает за итоговый результат.
Чем занимается такой специалист
— Расскажи, как ты видишь позицию product owner?
— Каждый воспринимает эту роль по-своему. Если вспомнить scrum, то это специалист, ставящий команде верхнеуровневые задачи — задачи-цели.
Например, мы хотим получить определенную фичу. Product owner может не знать, как её реализовать и даже как она должна выглядеть в конечном итоге. Но он объясняет команде, что должно появиться. Специалисты реализуют эту идею, и product owner решает, подходит ему то, что получилось, или нет.
Product owner в общем понимании — это специалист, который должен мыслить стратегически и заботиться о развитии продукта. Держать верхнеуровневый бэклог продукта, составлять дорожную карту на ближайшие горизонты: среднесрочные и долгосрочные.
— Можешь всё-таки подробнее объяснить, чем владелец продукта отличается от РП?
— Он отличается ровно тем, чем отличается продукт от проекта. У product owner-а есть продукт, срок жизни которого неограничен. Соответственно, думать ему надо больше стратегически, чем конкретными сроками.
Для РП главное — добежать до финала проекта. Он точно знает, какой нужен результат. И, соответственно, может для этого предпринять какие-то действия. Когда РП входит в проект, он выбивает бюджет, который нужен для его реализации.
С продуктом всё не так. Никакой видимой финишной черты нет. Если у пользователей возникают новые пожелания, в отличие от РП, владелец продукта не может на них не обращать внимания. Он заинтересован в том, чтобы люди всё больше и больше «общались» с продуктом. Поэтому часто делается немного больше, чем нужно, чтобы потом пользователи увидели новую фичу, развитие продукта.
— Назови три главных качества, которыми должен обладать хороший product owner?
— Во-первых, он должен разбираться в сфере, для которой предназначен продукт. То есть должен хорошо понимать пользователя, состояние рынка и технологий. Например, мне сам по себе был интересен BI (business intelligence), поэтому и продукт стал интересен. А что-то другое, возможно, не получилось бы или не привлекло бы моего внимания.
Во-вторых, ты должен уметь мыслить стратегически. Уметь играть вдолгую и не хвататься за сиюминутные цели.
И, в-третьих, владельцу продукта необходимо умение действовать в условиях максимальной неопределенности. Потому что в самом начале создания продукта у тебя полная сингулярность. Если у РП есть хотя бы бюджет, в рамках которого он может нанять людей, то у тебя нет ни людей, ни денег — ничего. Надо уметь выкручиваться.
Карьера в IBS. Хобби. Аспирантура
— Ты работаешь у нас уже очень давно, при этом в разных ролях. Как так получилось?
— На предыдущем рабочем месте я занимался базами данных, десктоп-разработкой и 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 в первую очередь должен отлично понимать, как устроен процесс разработки его продукта. Поэтому я не могу представить на этой позиции человека без прошлого в программировании. Придется пройти этот путь хотя бы по одной из веток, а лучше сразу по нескольким. Чем шире у тебя кругозор, тем проще будет потом понимать, из каких кусков должен состоять твой продукт, что можно сделать, а что нельзя.