Владислав Шелест: проектный менеджмент, инсайты и рок-н-ролл

Владислав Шелест отлично разбирается в вопросах самомотивации. Посудите сами, ради первого опыта в IT он нашел способ работать удаленно даже во время службы в армии.

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

 

Как ты стал PM?

Я получил 3 высших образования по менеджменту, все с упором на маркетинг, такой себе менеджер-маркетолог. Потом работал в государственном секторе, это был первый опыт в проектном менеджменте, но не в IT. Если ты не в IT — это, считай, вообще другая профессия.

После государственной службы в Киеве я переехал в Одессу и здесь меня случайно «подобрали» в IT стартап (финтек, блокчейн). Забирал девушку с собеседования, умудрился 5 минут поговорить с руководством компании и стал её начальником.

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

Периодически, я слышал от знакомых и команды какие-то профессиональные сленговые слова — Agile, Scrum, Sprint, итерация — и вообще не понимал, что это такое. Когда узнавал, говорил: «Ааа, так это план работ на 2 недели?», ну, образно. Мне отвечали, мол, да, называется Sprint. Со временем я начал чувствовать себя немножко ущербным и решил как-то исправить ситуацию.

 

За какими скиллами шел на DAO PM?

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

Я записался на DAO PM спустя полтора года работы проектным менеджером. Компания выросла с 9 человек до 77, ко мне подошла коллега-дизайнер и посоветовала: «Влад, не хочу тебя обидеть, ты вроде справляешься, но не понимаешь каких-то элементарных вещей».

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

Я прочитал программу курса и через пару дней записался. За 2 месяца я начал разговаривать с командой на одном языке.

Почерпнул очень много нового, особенно по части риск менеджмента, планирования, проектной документации, потому что в основном вел какие-то финансовые документы, но не имел ни малейшего представления о том, что такое тот же устав проекта. Я понимал суть ТЗ и в принципе мог его писать, потому что ТЗ есть не только в IT. Даже в госструктурах на тендерных проектах нужно описывать весь ход проекта, по сути такое себе ТЗ для подрядчика. Например, на выставке приходилось описывать, где стоит стенд и его размеры — все как в IT, только не о программировании.

 

Разработчикам тоже ставил ТЗ, просто техническое?

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

 

Ты говорил, что нашел работу в течение курса.

Мне позвонил знакомый и сказал о вакансии проектного менеджера. Собеседование оказалось достаточно простым: поговорили о составлении плана проекта, распределении ресурсов, желаемой ЗП, после чего мне позвонили и спросили, когда смогу приступать к работе. И понеслась жара, так как нужно было помогать решить все накопившиеся до моего появления проблемы.

 

В какие компании ты бы посоветовал устраиваться Junior PM?

Я в этом вопросе согласен с Денисом Шаматажи, на вебинаре «Как PM-у пройти испытательный срок» он полностью повторил мои мысли по этому поводу.

Для того, чтобы получить запись вебинара, заполните короткую форму.

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

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

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

 

Как устроиться junior PM после DAO PM?

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

 

Какие знания DAO PM ты используешь каждый день в работе?

Все. В основном это документация. 80% полезностей, которые я вынес из DAO PM — это описание документации как правильно составлять различные типы документов.

 

С какими тестовыми сталкивался?

Тестовые задания были очень разными.

Бывало прямо на собеседовании открывали передо мной ноутбук, а там скоуп с недекомпозированными задачами какого-нибудь приложения. И мне говорят, мол, вот нам подрядчик сделал эстимейт, оцени, насколько адекватно они заэстимейтили проект. Тогда я не понял, это вопрос с подвохом или человек сам не понимает суть задачи. Сказал, что не могу посмотреть, правильный эстимейт или нет, потому что я не разработчик. И начал объяснять, что вот по таким задачам (те, которые я понимал) моя прошлая команда справлялась за такое-то время, здесь разница в полчаса, так что оставляем. Это было странное тестовое, на котором в итоге пришлось объяснять некорректность задания для проверки потенциального сотрудника.

Бывали и хорошие задания:

  1. «Напишите письмо на английском языке заказчику, с которым вы работаете по fixed price договору. В тексте письма должно быть оповещение о том, что 4-недельный проект задерживается еще на 6 дней по причине обновления сторонних библиотек, которые от нас не зависят».
  2. Составить скоуп проекта для ios приложения с учетом каких-то условий.
  3. Разработать wireframe по UI/UX части скоупа, который я должен был составить.

Самое сложное на собеседовании — определить, стоит ли вообще идти в эту компанию, навскидку оценить адекватность руководства, от которых не сбежишь после испытательного срока.

Когда тебя уже наняли, вы подписали NDA, и понимаешь, что столкнулся именно с тем, чего боялся, про себя думаешь: «*^%$^&*, опять!». Добавьте к этому тот факт, что не всегда HR может провести грань, подходит ли проектный менеджер команде по стилю, подходу и ритму жизни. К примеру, когда 25-летний проектный менеджер оказывается в команде с 45 летними С++ разработчиками, велика вероятность, что они прислушаются к менеджеру только когда сами того захотят.

 

Насколько сложно работать PM без знания технических нюансов?

Если у вас есть тимлид или техлид, тогда в принципе PM-у достаточно поверхностных знаний и понимания основных технических определений, которые используются в разработке. Вы собираетесь на планерке/митапе/стендапе/созвоне, где присутствует твой тимлид/техлид/СТО — человек, который берет на себя функцию технического описания и понимания задач.

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

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

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

А пошел я на курс Techmind, потому что стал себя слишком неловко чувствовать в тот момент, когда где-то на перекуре или на созвоне ребята разработчики общаются между собой, а я стою, улыбаюсь и киваю головой:«Ага, база данных, ага, Питон, хорошо, круто». Чтобы не выпадать из беседы, я записался на курс Techmind.

Что посоветуешь новичкам PM?

Главное — помните, мы все с чего-то начинали. Глупых вопросов не бывает. Если вы спрашиваете, значит, хотите научиться. Задавайте очень много вопросов, не пытайтесь вырулить сами. Всегда найдется человек, который сэкономит вам уйму времени, если вы правильно сформулируете свой вопрос! Важнейшая задача PM-а — вникнуть в саму суть проблемы/процесса/задачи, а для этого нужно общаться со всеми участниками проекта.