О работе менеджера проекта: заказчик должен тебе доверять фото
Личная практика Личная практика

О работе менеджера проекта: заказчик должен тебе доверять


Ирина Гафарова, project manager TAGES.

«У меня в жизни было всего 3 собеседования…»

— Расскажи, пожалуйста, чем ты занималась раньше, до продуктовой деятельности, и за что отвечала?

— Когда я закончила университет, то сразу же устроилась на работу в небольшой региональный банк на позицию кредитного специалиста – принимать заявки на потребкредиты из магазинов. С IT это вообще никак не было связано. Потом возникла необходимость ведения бухучета этих кредитных операций, и я погрузилась в документы, одновременно налаживая работу с магазинами и пр. С точки зрения организации взаимодействия и контроля процесса, наверное, именно это и дало мне базовые навыки. Я знала, что мне нужно получить от людей, чтобы сформировать дела, как получить и что с этим дальше делать. Это все связано с деньгами и ответственностью, нельзя было допускать ошибки. По мнению руководства, я прекрасно справлялась. И так как я зарекомендовала себя как неплохой сотрудник, на которого можно положиться, меня отправили управляющим открывать новый офис. Там я занималась обслуживанием юридических и физических лиц — абсолютно вся линейка банковских продуктов, опять же никак не связанная с IT. Потом я вывела на уровень рентабельности другой «погибающий» офис и вот тут уже пришлось налаживать внутренние процессы и выстраивать коммуникации с людьми, уровень мотивации которых стремился к минус бесконечности.

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

«И тут начался мой путь в настоящий IT»

- С чего же началось твое движение в сторону разработки?

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

И вот с этим опытом, проработав 14 лет в банке, т.е. на стороне заказчика разработки, я пришла в TAGES после того, как уволилась. И вот тут началось самое интересное.

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

— Дальше ты целенаправленно искала IT-компанию или просто так звезды сошлись?

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

ВРЕЗ. У меня в жизни было всего 3 собеседования: в банк, потом в TAGES  и тут, когда я поняла, что вообще не понимаю, чем они занимаются, я запаниковала и убежала на собеседование номер три – снова в банк. Но потом очухалась. Работать в банке я точно больше не хотела. Вернулась к TAGES .

— Многому пришлось научиться?

— Конечно! 90% вещей, которые я сейчас со знанием дела использую – это все за последние два года «прилетело». Чтобы что-то значить, нужно на одном языке с разработчиками разговаривать и разбираться в том, что происходит. Было непросто, потому что почти сразу меня поставили на проект, хоть и не одну, я перенимала его у нашего технического директора Ильи Рачкулика, но это было непросто. Учиться приходилось буквально на ходу и в авральном режиме.

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

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

— Как не перегнуть палку? Есть какой-то секрет?

— Ребята, которые у нас работают, они профессионалы. У них такой уровень компетенции, что всем дай бог! И когда PM начинает с ними что-то обсуждать с целью показать, что он тоже не лыком шит, а не с тем, чтобы найти решение – вот это и вызывает отторжение. Никому не нравится, когда кто-то пытается там самоутверждаться, когда цель коммуникации совсем иная.

— Какие ресурсы тебе помогали в обучении на первых этапах? Может, какие-то книжки, курсы, блоги?

— У меня не было времени что-то особенное читать. У нас есть своя база знаний – на первых этапах это кладезь нашей разработки. Сейчас уже там есть и мои материалы, но тогда я большую часть знаний «снимала» с технических специалистов, задавала вопросы. Мне очень повезло, что первый мой проект в TAGES я перенимала у CTO Ильи Рачкулика. Он умеет на пальцах так объяснить сложные вещи, что у тебя мгновенно паззл в голове складывается, как надо. И команда на проекте была большая и сильная. Ребята с пониманием, помогали, как могли, видя мой искренний интерес. Поддержка команды очень многое мне дала. Так что теория теорией, но она в любом случае натягивается на какие-то реальные кейсы, которые компания проходила. И база знаний тоже не в один день родилась. 

— Какие задачи стояли перед тобой в роли менеджера продукта и каким продуктом ты занималась? 

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

— Где взять продуктовый опыт, когда ты на старте карьеры? 

— Команда и с головой в проект. Держать open mind, даже банальные базовые навыки пользователя разных гаджетов бывают полезны и необходимы.

— Как начинающему менеджеру продукта получить первую работу? Где искать, на каких ресурсах, и как подойти к прохождению собеседования, тестовых заданий?

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

— Какие важные качества должны быть у пиэма?

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


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

— Что самое сложное в работе менеджера по продуктам?

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

3 совета новичкам PM от Ирины Гафаровой:

  1. Читать базу знаний.

  2. Не бояться показаться некомпетентным и задавать вопросы, потому что лучше переспросить, чем накосячить.

  3. Внимательно слушать и во все тыкать, все пробовать на себе.

3 совета практикующим пиэмам:

  1. Никогда никому не верить на слово. Сама зайди, сама проверь, сама увидь и убедись, а потом говори.

  2. Заказчик должен тебе доверять. Нужно завоевать его доверие, чтобы он знал: ты за свои слова отвечаешь, если ты что-то советуешь, так оно и должно быть.

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

Подписывайтесь на нас в соцсетях, если хотите быть в курсе последних событий в сфере бизнеса и технологий.

Не менее интересные публикации