Классный Евгений и собеседование на IT Project Manager.

[@maxsyniuchenko3765]

Благодарю за видео, было интересно

[@sonatamylife]

За 2,5 часа этого видео, я узнала больше, чем за 3 месяца учебы на курсах для PM! Лучшее, что мне попадалось на просторах ютуб, огромная благодарность и Евгению за смелость и особенно Роману, за огромный важный объем информации и грамотные, интересные вопросы.

[@igorbelousov9439]

Роман, спасибо за ваши интервью. Это очень интересно и полезно. Евгению тоже спасибо, как бы не прошло интервью - это смелый поступок. Я бы просто под запись для ютуба наверное сыканул. Так что тут респект. Вопрос к Роману: не является ли критичным то что менеджер работает больше года в проекте и не знает стек технологий своего проекта? На моем опыте, я прошёл свыше 30 собеседований, это было бы супер странно и возможно со мной бы быстро закончили интервью. Также очень часто было «не знаю», что тоже приводит к плачевным последствиям, всё-таки интервью даже технические не превышают одного часа в 99% случаев. То есть всегда мало времени чтобы проявить себя и выделиться на фоне других кандидатов. В ходе интервью упоминалось, что для Евгения вопросы и их глубина на уровне мидла. У вас в первом интервью была Софья, которая в целом на все вопросы, даже о которых мало что-то знает - попадала хорошо и видно что есть понимание и что человек погружён в проект и его техническую составляющую. Вы оценили её на уровень джуниор. По моему субъективному мнению у неё знаний гораздо больше и практики тоже. Как в итоге вы производите эту оценку, опираясь на матрицу? Такое ощущение, что у Евгения хороший навык расположить к себе, но чаще всего этого не хватает для успешного проекта. Прошу прощения что так сумбурно, надеюсь вы поняли мой посыл, буду рад получить ответ. Спасибо большое.

[@Zhulpo]

По матрице, да и по ощущениям я оценил Евгения на уровень Junior+, но до мидла конечно не дотягивает. В разных компаниях, разный уровень требований к техническому бэкграунду. В случае с Евгением, он вообще играет роль PM/PO и фактически не погружается в управление командой, но управляет проектном из вне, на уровне бюджетов, сроков, приоритетов для заказчика. Такая конструкция вполне имеет место быть. По матрице и диаграмме видно, что Евгений вытягивает как раз за счёт софт скиллов и кейсовых ситуаций. А в моей системе координат, 60/40 где больший вес имеют СофтСкиллы + Опыт/Кейсы, И меньшую знания по менеджменту и IT Background.

[@igorbelousov9439]

@@Zhulpo понял, спасибо за ответ.

[@dmitriyromakh214]

@@Zhulpo Хмм, а где эту матрицу можно глянуть?

[@GarryAndrewson]

У Жени нормальные софт скиллы. Софты это больше про миддлов и синьоров. А харды можно добрать достаточно быстро (особенно если ты погружён в процесс)

[@elina1421]

как раз прохожу курс teachmeskills и думаю, что в целом похожа на Евгения: матчасть слабая, но софт скиллы люди хвалят 😄 спасибо за интервью, постепенно смотрю каждое ваше видео, очень помогает!

[@Verbalcka]

Вот это интервью можно отнести к отличным. Прекрасные вопросы, удачные ответы.

[@sorrocking]

Все жду, когда будут вопросы про риск-менеджмент, стейкхолдер-менеджмент, критический путь, пипл и тим-менеджмент)

[@АлексейЗуевский-в3т]

Лучшее интервью! С таким прокаченным молодым менеджером не хватило разве что блока с английским. Кажется, Евгений и здесь был бы в порядке)

[@alekseifomichev3228]

Классный видос, очень полезный и лайк за флаг на заднем фоне!

[@mikeseleznev3096]

На 59:00 у вас очень распространённая и тиражируемая ошибка. Фаза проекта - совокупность логически связанных операций проекта, завершающихся достижением одного или ряда поставляемых результатов. Так что инициация, планирование, исполнение, мониторинг и контроль, закрытие - это группы процессов управления проектов, которые присутствуют от фазы к фазе. Проверить легко: у вас в "фазе" мониторинга и контроля результатом не будет поставляемого результата проекта (что бы это вообще могло быть?) потму что это не фаза, а группа процессов ;)

[@Zhulpo]

Михаил, спасибо за внимательность! Соглашусь с вами, что применительно к PMI и PMBok более корректная формулировка - это группа процессов. Но если мы не на экзамене PMP, думаю вполне можно себе позволить и формулировку фаза проекта. Тем более сами PMI себе это позволяют ) www.pmi.org/learning/library/project-management-middle-five-stages-6969

[@ElenaEfimova-i9r]

Действительно, классный! Приятный в общении, абсолютно равен себе - софт скилы, логичный, умеет построить стратегию. Таким и должен быть РМ. Расти есть куда, но это и понятно.

[@АндрейАнатольевич-я8ф]

Насчет перевода слова требования как specification поспорил бы, это более широкое понятие в русском это так и будет как спецификация и будет применимо к любому уточнению любого этапа. Здесь скорей requirements.

[@dmitriy8200]

Без обид, но яркий пример того, что само наличие сертификатов ПО и СМ еще не значат, что человек понимает саму суть того, что делает :)

[@Сергей-с2л4ч]

Мда, вроде мнение сначала одно было.. Как, проработав в сфере IT, имея цель на карьерный рост и результат, не заниматься самообучением, познаванием того, с чем работаешь ты, как руководитель, и твои коллеги, которым ставишь прямые задачи?

[@dmitriy8200]

@@Сергей-с2л4ч who knows)

[@маринашвец-й3с]

Как же Евгений работает и что он делает, если он 90% процесса не понимает? Очень поверхностные знания. Такое сложилось впечатление

[@smproby]

Спасибо огромное за крутое интервью! Офигенный стимул повторять теорию и знать основные понятия. Имея достаточно большой опыт в менеджменте, я настолько забила на теорию, что даже не думала ничего повторять. Слушаю и понимаю, что 5 лет назад конкретно по теории я знала почти все по менеджменту. А потом забила. Точно начну повторять:) А матрица кандидата для меня просто находка

[@АзаматКасымович-н4ы]

Вот, а Евгений переживал)))) Правильно сделали что опубликовали)))

[@RoyJonesBest]

Роман так потер бороду когда услышал про смысл жизни. Сразу видно, что у романа это смысл жизни

[@live_man]

Непонимаю чем Евгений классный и восторженные комментарии: на многие вопросы он не знал ответа, в чём прямо и признаётся

[@live_man]

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

[@Zhulpo]

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

[@todayfriday4331]

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

[@NikKochergin]

Ох, тяжко... Теперь понимаю зачем людям it образование и почему оно не проходит мимо.

[@xCopper55]

А можно больше примеров? Формулировка "те или иные решения" пронизывает каждое интервью. А конкретику, если это возможно. В целом как всегда круто! Спасибо.

[@Zhulpo]

Тут тоже нужно больше конкретики )) Что вас интересует? Какие решения или ответы нужно детализировать?

[@xCopper55]

@@Zhulpo справедливо) скорее ответы больше детализировать. Возможно приводить больше примеров конкретных фич со сложностями реализации или метрик которые позволили оптимизировать работу команды. Скажем с точки зрения теории, супер полезные видео. Я выписываю, что не знаю и ищу в интернете инфо. А если возможно чуть больше практических примеров.

[@Zhulpo]

Я подумаю, спасибо за рекомендацию. Но тут все-таки формат интервью, и так они разрастаются по времени, а если ещё пойдём в детализацию кейсов и решений, боюсь вообще в формат лекций перейдём )

[@ВасилийПопов-х4л]

посмотрел блок IT Background - очень, мягко говоря, поверхностные знания у человека. не представляю как он может управлять командой, слабо так ориентируясь что там они делают и как. И не совсем понял, как он может быть Продакт Овнером - если они занимаются заказной разработкой и Продакт Овнер там очевидно есть свой на стороне заказчика или сам заказчик, исходя из рассказа о функциях метрики он тоже не отслеживает, анализ рынка и конкурентов не делает, новые фичи не внедряет, а\б тесты не проводит, то есть непосредственным развитием продукта не занимается, так где тут Продакт то? по мне так это вообще другая степь абсолютно. возможно я не прав, умные люди поправят))

[@IntegMarco]

Везёт тому, кто везёт

[@Egor1988ful]

Немного резануло мне слух, когда Роман сравнил kanban который используется на конвейере в Тойоте с kanban методом, к которому мы привыкли. Это все же разные вещи, есть даже такое мнение что это абсолютно разные вещи)

[@Zhulpo]

Почему разные? Можете объяснить разницу?

[@Egor1988ful]

@@Zhulpo Да, постараюсь обосновать свою точку зрения. У современного канбан есть автор Дэвид Андерсон. Полное его название «Канбан метод» как инструмент в it менеджменте он впервые его представил в 2005 году, в компаниях Microsoft. Большее распространение он получил в 2007 году. Канбан в том виде в котором мы привыкли его видеть очень молод, намного моложе agile и scrum. Основная разница между этими двумя "канбанами" в том, что канбан с тойоты, это про лин и про бережливое производство. Да, сам термин был придуман на заводе Тойта, что означает «сигнал» или «карточка» и собственно на заводах такие карточки использовались для того, чтоб передавать информацию с одного этапа работ на следующий о том, что требуются те или иные детали, в каком кол-ве и т.п. Канбан метод же, нацелен на то, чтоб визуализировать поток интеллектуальной работы, для того чтоб сделать процесс более прозрачным, прогнозируемым, путем сокращения кол-ва незавершённой работы в момент времени. Здесь, доска, карточки выступают как инструмент для сбора данных на основании анализа которых в будущем можно делать прогнозы и принимать на себя какие-то обязательства.

[@Zhulpo]

Отлично! Спасибо за детальный комментарий. Но, я пока так и не услышал в чем разница ) Попробуйте сформулировать. А я потом подискутирую с вами 😉

[@Сергей-с2л4ч]

Ну, в материалах преподносят это так)

[@ДмитрийКромов-о8и]

Роман, подскажите зачем руководителю проекта знать про git-flow? Как он может влиять на процесс разработки?

[@svetlanalana2778]

Ребята, хэлп! Какие есть процедуры реализации айти проектов и пакеты проектной документации? Как бы вы ответили?

[@TheSweettooth94]

Product Owner - это роль в Scrum. Не совсем понятно, когда начинают рассуждать на тему того, что я буду развиваться как PO, считая это специальностью/профессией. Здесь корректнее употребить Product Manager

[@Zhulpo]

Тут можно с этим согласиться и не согласиться. Ведь сегодня очень массово используют Scrum, соответсвенно вполне естественно, что появляются и профессии по этому фреймворку. Вы вполне найдёте сегодня вакансии на должность и Scrum-Master и Product Owner и люди специально на это учатся и развиваются.

[@boWwiing]

К сожалению не понимаю как такой больошй проект может менеджерить человек, который не имеет даже базовых знаний в IT. И для этого не нужно быть техническим ПМ-ом. Но по факту такой человек не может оценить скоуп работ, спланировать и пройтись по остальным этапам проекта. В такому случае дев может налить любую фигню (по типу на задачу нужно 2 недели, а по факту там 2 метода реализовать). Как в такому случае менеджер может контролировать процес если он ничего не понмает? Выходит именно в этому случае человек просто передает слова заказчика, у которого при этом свой PO. И назревает вопрос, а зачем тогда такой человек в цепочке? Хочу что бы меня правильно поняли, я пишу без негатива и сам только на пути становления ПМ-ом, и тоже сталкиваюсь с трудностями. Конкретно для меня хороший ПМ в идеале долджен обладать техническими знаниями и отличным английским, (дополнительно можна включить в этот список способсность организовать команду). Без этого не вижу смысла в ПМ-е.

[@RyabaaHD]

Крутой чел! Молодец!

[@unrealme]

Удивительно много пробелов после 2 лет работы.

[@MariaSTP]

честно говоря просто не верится, что человек действительно работал два года и путает Rest Api с фреймворком и не знает ни одной СУБД. обычно даже чтобы нормально участвовать в разговоре с командой приходится гуглить такие вещи. получается он не только не притрагивался к ним, но даже не интересовался.

[@Pallamalla]

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

[@ez7530]

ТЗ это наверное scope of work in English?

[@Zhulpo]

Не совсем Scope of Work = SOW там обычно фиксируются юридические детали контракта (стоимость, сроки и тп), а вот в technical specification уже могут быть зафиксированы технические требования и ограничения. Еще, конечно, есть документ SRS = System requirements specification - это еще более подробный документ.

[@ez7530]

@@Zhulpo благодарю за разъяснение

[@iCristalrose]

@@Zhulpo SoW - это же Statement of work

[@NOWMENKINO]

Беларусь наш!

[@iogurthome]

«Пощупал немного разработку, ничего сложного» 😂😂😂 Действительно, вообще фигня)

[@digkillneko]

аффтар экстремист

[@den3v]

Парню явно не хватает опыта. Плавает довольно сильно но все впереди