«Если дизайнер просто перекрашивает кнопки, то, скорее всего, у него нет никакой мотивации. И это косяк менеджера». Как product-менеджер может мотивировать членов своей команды?

Олег Лебедев работает на позиции product-менеджера в Kolesa Group больше года. Он ведет проекты для одного из продуктов компании — Market.kz, и управляет командой в 10 человек. Накануне ИT-конференции Kolesa Conf’22, где Олег будет одним из спикеров, Digital Business пообщался с ним и узнал, как соблюдать дедлайны перед заказчиками, почему важно прояснять понимание задачи у сотрудников и какую песню называют гимном всех product-менеджеров.

«PM не должен браться за работу, не поговорив с клиентом и не согласовав с ним понимание задачи»

— Олег, чем вы занимались до того, как стали PM в Kolesa Group?

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

Меня это заинтересовало. И я попробовал внедрить некоторые практики, но встретил сопротивление со стороны руководства: топ-менеджеры считали, что исполнитель должен закрывать исключительно свои обязанности и не совать нос куда не надо. Так я ушел из бухгалтерской сферы и оказался в диджитал-агентстве на позиции начинающего PM. В моей команде было всего 2 человека: разработчик и дизайнер. Вместе с ними мы пилили сайты и несколько образовательных платформ для фармацевтов. После агентства меня занесло в организацию, которая внедряет CRM-системы.

А дальше я записался на Kolesa Upgrade. Прослушал курсы, успешно справился с тестами и прошел отбор на стажировку в рамках Kolesa Academy. И теперь я уже год как product-менеджер в этой компании, улучшаю работу Market.kz.

— Если растешь быстро, ошибки неизбежны. Как было у вас?

— Да, факапов было много. Это самая болезненная и интересная часть карьеры. Почти каждый день работа подкидывает новые ситуации, и часто ты ошибаешься. Это нормально! Важно не наступить на те же грабли в дальнейшем и учиться на собственном опыте. А еще сохранять уверенность в себе. Об этом, кстати, хорошо спела группа Anacondaz в песне «Факап». Мне вообще кажется, что это гимн всех PM.

Первые серьезные косяки начались в диджитал-агентстве: фаундер поговорил с клиентом и передал мне собственное понимание клиентской задачи. А я по неопытности взял все на себя и ничего не уточнил. Цель была — сделать сайт для продаж. Мы старались, пилили, даже успели до дедлайна. А потом заказчик сказал, что он хотел совсем другое. Были длительные серьезные переговоры, поиск компромисса. В итоге работу приняли, а я как product-менеджер сделал для себя первый серьезный вывод: никогда нельзя браться за работу, не поговорив с клиентом и не согласовав с ним понимание задачи.

В начале работы в Kolesa Group была еще одна история, связанная с коммуникацией. Начинался большой и сложный проект, и перед этим я отдельно поговорил с разработчиками, аналитиками, тестировщиками. Пообщался с людьми, раздал подзадачи и ушел. И вроде все идет, работа делается. А потом члены команды вернулись с вопросами типа «Что?», «Как?», «Зачем?». И в этот момент ты осознаешь: люди не понимают, что и для чего делают.

— А в чем опасность ситуации? Есть четко поставленная задача — так бери и делай.

— Это косяк менеджера. Люди должны понимать, зачем они делают ту или иную задачу. Если исполнитель просто перекрашивает кнопки, то, скорее всего, у него не будет никакой мотивации. А если объяснить, что с помощью этого действия мы хотим повлиять на Click Rate и продажи, человек сразу включает изобретательность, ищет какое-то решение и увлекается. Вот эта погруженность мотивирует человека и делает более эффективным. А если у члена команды нет понимания важности собственной задачи, то рано или поздно он может выгореть или разочароваться.

«Нельзя идти на поводу у клиента или начальства, которое предлагает вам нереалистичные дедлайны»

— Хочу поговорить о дедлайнах. Можно ли их нарушать, и если да, то в каких случаях?

— Сложная тема. С одной стороны, менеджеру нужно отвечать за свои слова. Он берет на себя ответственность, называет срок выполнения задачи и должен исполнить все так, как было оговорено. Это в идеальном мире. Но все мы понимаем, что в реальности иногда происходят обстоятельства непреодолимой силы. Сроки могут сдвигаться — это нормально. И нужно донести это до команды, что не нужно рвать на себе волосы, если что-то идет не так, как задумано, из-за каких-то объективных причин. Ну а если сроки срываются просто так, надо что-то менять в работе PM.

Конечно, есть жесткие дедлайны, от которых зависит судьба команды. Их переносить нельзя. И ты как PM должен сделать что угодно, но выполнить поставленную задачу в срок. И тут есть маленькая хитрость, если вы не успеваете: всегда можно договориться с клиентом о том, что к дедлайну будет сдана часть работы. MVP или сервис, который сможет принимать заявки клиентов. А остальное доделать позже.

— Но это все равно срыв дедлайна, неприятная ситуация. Как этого избежать?

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

«Product Manager должен решать рабочие конфликты. Но для этого нужно лидерство»

— Вы говорили, что начинали карьеру PM в команде из 2 человек. Сейчас у вас 10 человек. Есть ли какие-то различия в управлении?

— Я не вижу большой разницы. Менеджер должен общаться с людьми при любой численности команды, будь то 3 человека или 10. Просто во втором случае нужно выстраивать коммуникацию через тимлидов конкретных подразделений.

Единственное, что мере роста команды может немного падать взаимопонимание между сотрудниками. Некоторые могут воспринимать задачи как приказы, поступающие сверху, а это плохо. Как этого избежать и наладить коммуникацию, я буду подробно рассказывать на Kolesa Conf.

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

— По поводу личностных конфликтов. Сделать так, чтобы они не возникали с вероятностью в 100%, невозможно. Но свести эту возможность к минимуму можно — и это работа HR-отдела компании. Важно, чтобы был жесткий отбор кандидатов по soft skills, чтобы кандидат подходил по своим личностным качествам к существующей команде. Еще один момент для менеджера — не допускать ситуаций, когда рабочие вопросы перетекают в личностные споры.

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

А рабочие ситуации и недопонимания — это норма. И тут должен проявлять себя PM. Менеджеру стоит решать конфликты, а для этого нужно лидерство.

— Что это такое? И как его заработать?

— В Kolesa Group это чуть ли не основное требование к PM. Грубо говоря, это способность взаимодействовать с командой, вести людей за собой и принимать решения. Чтобы стать лидером, нужно отвечать за свои слова. Пообещал что-то члену команды — обязательно выполни это. Казалось бы, базовое правило, да? А о нем помнят далеко не все.

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

«Главный совет — ребята, начните работать. Изучите ваш продукт и людей, которые его создают»

— Олег, дайте напоследок пару советов начинающим product-менеджерам.

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

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

Второй совет — будьте честными со своей командой и ничего от нее не скрывайте. Если что-то идет не так, не скрывайте это. Честно и открыто доносите информацию до команды — это важно. Пусть люди услышат от вас правду сразу, чем когда-нибудь потом.

Третий совет — берите ответственность за свои слова и решения.

Четвертый — мотивируйте и вдохновляйте людей. Вовлеченные сотрудники работают гораздо эффективнее, а не вовлеченные быстрее выгорают.

Пятый совет — не останавливайтесь в развитии. Настоящему PM всегда должно быть мало достигнутого уровня.