Классный Евгений и собеседование на IT Project Manager.
Vložit
- čas přidán 27. 06. 2024
- Публичное онлайн собеседование на позицию IT Project Manager - Евгений Шуршуков еще один Беларус в Польше.
Отличное интервью о том как войтивИТ на позицию менеджера проектов. Пообщались с Евгением и на тему новой комбинации PM+PO или как outsource/outstaff подстраивается под Scrum.
Структура интервью:
0:00 - Блок о себе
6:30 - Как пришел в профессию (новичкам смотреть обязательно!)
18:00 - Текущая позиция и обязанности
22:00 - Блок вопросов на IT Background
58:25 - Блок вопросов по Project Management
1:47:50 - Блок вопросов по Management Experience
2:09:45 - Вопросы на Soft Skills
2:28:55 - Обратная связь
Ссылка на матрицу кандидата, в документе разрешены комментарии
docs.google.com/spreadsheets/...
Ссылка на наш профильный чат в Telegram
t.me/+Pk144YatOyo1Nzk6
Идеи и сотрудничество:
Roman@Zhulpo.com
За 2,5 часа этого видео, я узнала больше, чем за 3 месяца учебы на курсах для PM! Лучшее, что мне попадалось на просторах ютуб, огромная благодарность и Евгению за смелость и особенно Роману, за огромный важный объем информации и грамотные, интересные вопросы.
Все жду, когда будут вопросы про риск-менеджмент, стейкхолдер-менеджмент, критический путь, пипл и тим-менеджмент)
Вот это интервью можно отнести к отличным. Прекрасные вопросы, удачные ответы.
Не смогла дослушать. Роман, спасибо за Ваши вопросы, помогли задуматься о своих пробелах в знаниях.
Спасибо огромное за крутое интервью! Офигенный стимул повторять теорию и знать основные понятия. Имея достаточно большой опыт в менеджменте, я настолько забила на теорию, что даже не думала ничего повторять. Слушаю и понимаю, что 5 лет назад конкретно по теории я знала почти все по менеджменту. А потом забила. Точно начну повторять:) А матрица кандидата для меня просто находка
Вот, а Евгений переживал)))) Правильно сделали что опубликовали)))
как раз прохожу курс teachmeskills и думаю, что в целом похожа на Евгения: матчасть слабая, но софт скиллы люди хвалят 😄 спасибо за интервью, постепенно смотрю каждое ваше видео, очень помогает!
Как же Евгений работает и что он делает, если он 90% процесса не понимает? Очень поверхностные знания. Такое сложилось впечатление
Без обид, но яркий пример того, что само наличие сертификатов ПО и СМ еще не значат, что человек понимает саму суть того, что делает :)
Мда, вроде мнение сначала одно было..
Как, проработав в сфере IT, имея цель на карьерный рост и результат, не заниматься самообучением, познаванием того, с чем работаешь ты, как руководитель, и твои коллеги, которым ставишь прямые задачи?
@@user-fu3he5no9c who knows)
Роман, спасибо за ваши интервью. Это очень интересно и полезно. Евгению тоже спасибо, как бы не прошло интервью - это смелый поступок. Я бы просто под запись для ютуба наверное сыканул. Так что тут респект.
Вопрос к Роману: не является ли критичным то что менеджер работает больше года в проекте и не знает стек технологий своего проекта? На моем опыте, я прошёл свыше 30 собеседований, это было бы супер странно и возможно со мной бы быстро закончили интервью. Также очень часто было «не знаю», что тоже приводит к плачевным последствиям, всё-таки интервью даже технические не превышают одного часа в 99% случаев. То есть всегда мало времени чтобы проявить себя и выделиться на фоне других кандидатов. В ходе интервью упоминалось, что для Евгения вопросы и их глубина на уровне мидла.
У вас в первом интервью была Софья, которая в целом на все вопросы, даже о которых мало что-то знает - попадала хорошо и видно что есть понимание и что человек погружён в проект и его техническую составляющую. Вы оценили её на уровень джуниор. По моему субъективному мнению у неё знаний гораздо больше и практики тоже. Как в итоге вы производите эту оценку, опираясь на матрицу? Такое ощущение, что у Евгения хороший навык расположить к себе, но чаще всего этого не хватает для успешного проекта.
Прошу прощения что так сумбурно, надеюсь вы поняли мой посыл, буду рад получить ответ. Спасибо большое.
По матрице, да и по ощущениям я оценил Евгения на уровень Junior+, но до мидла конечно не дотягивает. В разных компаниях, разный уровень требований к техническому бэкграунду. В случае с Евгением, он вообще играет роль PM/PO и фактически не погружается в управление командой, но управляет проектном из вне, на уровне бюджетов, сроков, приоритетов для заказчика. Такая конструкция вполне имеет место быть.
По матрице и диаграмме видно, что Евгений вытягивает как раз за счёт софт скиллов и кейсовых ситуаций.
А в моей системе координат, 60/40 где больший вес имеют СофтСкиллы + Опыт/Кейсы,
И меньшую знания по менеджменту и IT Background.
@@Zhulpo понял, спасибо за ответ.
@@Zhulpo Хмм, а где эту матрицу можно глянуть?
У Жени нормальные софт скиллы. Софты это больше про миддлов и синьоров. А харды можно добрать достаточно быстро (особенно если ты погружён в процесс)
Классный видос, очень полезный и лайк за флаг на заднем фоне!
Крутой чел! Молодец!
Лучшее интервью! С таким прокаченным молодым менеджером не хватило разве что блока с английским. Кажется, Евгений и здесь был бы в порядке)
Везёт тому, кто везёт
Насчет перевода слова требования как specification поспорил бы, это более широкое понятие в русском это так и будет как спецификация и будет применимо к любому уточнению любого этапа. Здесь скорей requirements.
На 59:00 у вас очень распространённая и тиражируемая ошибка. Фаза проекта - совокупность логически связанных операций проекта, завершающихся достижением одного или ряда поставляемых результатов. Так что инициация, планирование, исполнение, мониторинг и контроль, закрытие - это группы процессов управления проектов, которые присутствуют от фазы к фазе. Проверить легко: у вас в "фазе" мониторинга и контроля результатом не будет поставляемого результата проекта (что бы это вообще могло быть?) потму что это не фаза, а группа процессов ;)
Михаил, спасибо за внимательность! Соглашусь с вами, что применительно к PMI и PMBok более корректная формулировка - это группа процессов. Но если мы не на экзамене PMP, думаю вполне можно себе позволить и формулировку фаза проекта. Тем более сами PMI себе это позволяют )
www.pmi.org/learning/library/project-management-middle-five-stages-6969
Непонимаю чем Евгений классный и восторженные комментарии: на многие вопросы он не знал ответа, в чём прямо и признаётся
Прошу прощения за прямоту, но не выдержал слушая запись. Хотел несколько уровнять баланс в комментариях, поддерживая тех, кто считает также
Евгений просто хорошо располагает к себе и с ним приятно было проводить собеседование. И Евгений понравился интервьюеру. А это уже пол дела ) Так что частно на софт скиллах можно далеко уехать, даже с пробелами по базовым знаниям.
на 1000% cоглашусь с вами. да, безусловно, парень харизматичный и располагающий, но, имхо, не знать базовую базу для проджекта- это моветон.
Роман так потер бороду когда услышал про смысл жизни. Сразу видно, что у романа это смысл жизни
А можно больше примеров? Формулировка "те или иные решения" пронизывает каждое интервью. А конкретику, если это возможно. В целом как всегда круто! Спасибо.
Тут тоже нужно больше конкретики ))
Что вас интересует? Какие решения или ответы нужно детализировать?
@@Zhulpo справедливо) скорее ответы больше детализировать. Возможно приводить больше примеров конкретных фич со сложностями реализации или метрик которые позволили оптимизировать работу команды. Скажем с точки зрения теории, супер полезные видео. Я выписываю, что не знаю и ищу в интернете инфо. А если возможно чуть больше практических примеров.
Я подумаю, спасибо за рекомендацию. Но тут все-таки формат интервью, и так они разрастаются по времени, а если ещё пойдём в детализацию кейсов и решений, боюсь вообще в формат лекций перейдём )
Действительно, классный! Приятный в общении, абсолютно равен себе - софт скилы, логичный, умеет построить стратегию. Таким и должен быть РМ.
Расти есть куда, но это и понятно.
Роман, подскажите зачем руководителю проекта знать про git-flow? Как он может влиять на процесс разработки?
Немного резануло мне слух, когда Роман сравнил kanban который используется на конвейере в Тойоте с kanban методом, к которому мы привыкли. Это все же разные вещи, есть даже такое мнение что это абсолютно разные вещи)
Почему разные? Можете объяснить разницу?
@@Zhulpo Да, постараюсь обосновать свою точку зрения.
У современного канбан есть автор Дэвид Андерсон. Полное его название «Канбан метод» как инструмент в it менеджменте он впервые его представил в 2005 году, в компаниях Microsoft. Большее распространение он получил в 2007 году. Канбан в том виде в котором мы привыкли его видеть очень молод, намного моложе agile и scrum.
Основная разница между этими двумя "канбанами" в том, что канбан с тойоты, это про лин и про бережливое производство. Да, сам термин был придуман на заводе Тойта, что означает «сигнал» или
«карточка» и собственно на заводах такие карточки использовались для того, чтоб передавать информацию с одного этапа работ на следующий о том, что требуются те или иные детали, в каком кол-ве и т.п.
Канбан метод же, нацелен на то, чтоб визуализировать поток интеллектуальной работы, для того чтоб сделать процесс более прозрачным, прогнозируемым, путем сокращения кол-ва незавершённой работы в момент времени. Здесь, доска, карточки выступают как инструмент для сбора данных на основании анализа которых в будущем можно делать прогнозы и принимать на себя какие-то обязательства.
Отлично! Спасибо за детальный комментарий. Но, я пока так и не услышал в чем разница ) Попробуйте сформулировать. А я потом подискутирую с вами 😉
Ну, в материалах преподносят это так)
посмотрел блок IT Background - очень, мягко говоря, поверхностные знания у человека. не представляю как он может управлять командой, слабо так ориентируясь что там они делают и как. И не совсем понял, как он может быть Продакт Овнером - если они занимаются заказной разработкой и Продакт Овнер там очевидно есть свой на стороне заказчика или сам заказчик, исходя из рассказа о функциях метрики он тоже не отслеживает, анализ рынка и конкурентов не делает, новые фичи не внедряет, а\б тесты не проводит, то есть непосредственным развитием продукта не занимается, так где тут Продакт то? по мне так это вообще другая степь абсолютно. возможно я не прав, умные люди поправят))
Product Owner - это роль в Scrum. Не совсем понятно, когда начинают рассуждать на тему того, что я буду развиваться как PO, считая это специальностью/профессией. Здесь корректнее употребить Product Manager
Тут можно с этим согласиться и не согласиться. Ведь сегодня очень массово используют Scrum, соответсвенно вполне естественно, что появляются и профессии по этому фреймворку. Вы вполне найдёте сегодня вакансии на должность и Scrum-Master и Product Owner и люди специально на это учатся и развиваются.
Ребята, хэлп! Какие есть процедуры реализации айти проектов и пакеты проектной документации? Как бы вы ответили?
Беларусь наш!
ТЗ это наверное scope of work in English?
Не совсем Scope of Work = SOW там обычно фиксируются юридические детали контракта (стоимость, сроки и тп), а вот в technical specification уже могут быть зафиксированы технические требования и ограничения. Еще, конечно, есть документ SRS = System requirements specification - это еще более подробный документ.
@@Zhulpo благодарю за разъяснение
@@Zhulpo SoW - это же Statement of work
Удивительно много пробелов после 2 лет работы.
«Пощупал немного разработку, ничего сложного» 😂😂😂 Действительно, вообще фигня)
честно говоря просто не верится, что человек действительно работал два года и путает Rest Api с фреймворком и не знает ни одной СУБД. обычно даже чтобы нормально участвовать в разговоре с командой приходится гуглить такие вещи. получается он не только не притрагивался к ним, но даже не интересовался.
У такого проджекта разрабы поводья управления заберут чисто на автомате. Потому что любую позицию можно подкрепить парой "умных" технических слов, и pm'у без знаний останется только головой кивать - "да, понял, надо именно вот так делать, окей".
Удобно для программистов, но неудобно для бизнеса. Управление должно сверху вниз идти, не наоборот
Парню явно не хватает опыта. Плавает довольно сильно но все впереди