зависит от размера проекта и сложности коммуникаций на проекте.
Можно посчитать в условных вебсайта: джун РП делает 1 проект по созданию веб сайта и занят фулл тайм на 3 мес. Миддл может делать их 3 и не продолбать ничего. Синьор сделает 5 (собственно, я как то делал 5). Синьор+ сделает 5 и по пути подружится с заказчиками , поймет, что у них болит и предложит что можно сделать, чтобы решить их боли - то есть биздев
спасибо. по поводу книг - нет, я ничего этого в книгах не видел, увы. Да и ни разу у меня не получалось софтскиллам научиться по книжкам или лекциям. На словах все просто, а попадаешь в реал - и коленки дрожат :)
Бизнес игры - точно тема, была пара игр, где я почувствовал прямо, что чтото делаю не так. Но хороших тренеров трудно найти. Пока что все на опыте ) может быть я смогу запилить курс, где все это будет, но надо думать :)
Я по всем темам, написанным мной в статье могу написать по статье. И напишу, для этого и начал писать. Я уверен, что на Хабре есть люди и опытнее и умнее меня. Я с радостью послушаю их опыт и научусь новому.
Для конструктивного обсуждения или спора , как угодно, нужна фактура. Ваше мнение я понял, фактуру дадите? У вас другие критерии отбора? Расскажите.
Здравствуйте. Цель статьи: разобрать отличия джунов миддлов и синьоров, чтобы начинающие и не очень РП могли поглядеть, чего им не хватает, чтобы расти дальше.
Статья основана на большом числе реальных примеров из опыта меня , как РП и меня, как руководителя направлений, ПМО и прочих отделов.
По вашим остальным вопросам я с удовольствием вам отвечу, если вы сразу озвучите их цель. Иначе напоминает собеседование в тональности пассивной агрессии. Я и сам так умею, но, считаю, Хабр не для этого, а для обмена опытом.
Если вы - руководитель, и видите тут лажу, просто напишите. Без проблем, обсудим :)
не спора ради, я просто поделился тем, что я вижу на рынке. Если у вас другой опыт - буду рад если поделитесь. Но не за 10 лет, а последний год-полтора. Потому что сейчас на рынке бум.
Я в 2019 году искал работу и не могу найти. Сейчас за нормальными РП очередь.
Моего ведущего РП (по факту он классный миддл конечно) уже год закидывают офферами от 300 тыс. Если вам интересно - напишите в личку, мне интересно, что у вас. Я смотрю на рынок, мне интересно, что происходит и статья - попытка это понять.
вы знаете, я последние полгода ищу менеджеров. HR подгоняют таких. И несколько человек отказались от наших офферов в пользу других.
Мои менеджеры получают офферы со стороны на схожие суммы. Я сам пару раз выходил на рынок, чтобы прикинуть свою цену. Мои выводы такие.
Дальше - вопрос личной выборки, умения сделать резюме и себя продать (грубо говоря, не соглашаться на первый оффер, а походить пару мес по рынку и поглядеть).
Я в начале статьи написал, что это личный вывод. Но я реально очень много искал в последнее время и вижу странности на рынке РП. И если у вас есть качества джуна из статьи выше, я готов поспорить, что вы найдете работу в этой вилке. Если не ищется - чтото не так делаете.
Мне самому очень интересно, что на рынке, так что можете в личку мне написать, я погляжу.
Возможно. Одна из целей статьи - это обменяться опытом. Сам я отбором не занимаюсь, последние несколько лет это делают HR. За ними есть грешок: они могут поднимать зарплаты кандидатов, потому что получают % от зарплаты кандидата в итоге. Так что завышение может быть. Но я также вижу, когда хорошие кандидаты уходят, не приняв наш оффер. Так что вопрос дискуссионный.
По вашему кейсу скажу следующее: мне в линкед ине писали несколько кандидатов, мы как то даже собеседовали СЕО закрывшегося ИТ интегратора на позицию РП. Я не взял никого. Причины разные: или человек вообще не владеет предметом (как в статье про джуна - этого нет), обещая, что научится (но у меня нет столько денег и времени), или психологические особенности кандидатов.
Если хотите - киньте мне ваше CV в ТГ (в профиле), я погляжу и скажу свое мнение.
Ну тут я бы и сам с вами поспорил. Архитектура системы - это результат исполнения функциональных и нефункциональных требований.
a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.[1]
Давайте для начала: речь идет про джуна. Если джуна поставить рулить проектом, где есть хорошие NFR (кроме времени отклика системы), скорее всего, он проект завалит. Туда надо искать другого сотрудника, а этого обучать на проектах попроще (развитие того, что уже существует).
Про администратора - так можно. Но надо же кого то обучать :)
Да, я сам в шоке. На РП и аналитиков прямо сейчас нереальный спрос, я такого не видел никогда. Все ваши замечания для меня - уже синьор :) но тут надо понимать, что я говорю о проектах 20-50 человек. Но 100. Если смотреть на проекты 100+ человек, то там уровень будет другой, разумеется. Но я таких проектов в РФ знаю мало. Может быть выборка хромает, конечно
Хм. Для меня у проекта есть четкие сроки. В госухе всегда есть развитие и эксплуатация. Есть капекс и опекс. Проект заканчивается там, где заканчивается капекс. И обычно это три года (что я знаю, проекты уровня создания ФГИС). Впрочем, Госуслуги уже 15 лет развиваются, так то. Тут надо почитать теорию, я не помню определения.
Экономику ИТ проекта, если он не слишком большой, считать достаточно просто: есть оценка, есть план, есть запасы. Этому я и сам могу научить. Но обычно РП знают это, все таки :)
Может. это в синьоре есть: "может организовать работу 20+ человек" - без делегирования лидам он этого как раз сделать не сможет. Вопрос на собеседовании "расскажите о процессе разработки команды 20 разработчиков и инструментах, где вы его автоматизируете"
Согласен. Тут к вашему первому замечанию. Наверное, уровень упал. Часто РП бывают без опыта предпроектного обследования, оно же пресейл. Но делать "по ТЗ" в целом могут.
Вы знаете, отличия предварительных и приемочных испытаний я сам использовал пару раз, когда надо было сдавать строго по ГОСТ, да и система была сложной. Тут вопрос масштаба. Для меня уже это, скорее, синьор
я и сам head of pmo уже много лет и перелопатил больше 100.
расскажите кого и на сколько вы взяли. Очень интересно не меряться размерами должности, а сравнить реальный опыт. Хабр для этого и создавался, вообще то.
Я примерно каждый год выходил на рынок - просто интересно его было исследовать + ищу сам давно и много. Да, местами я работаю как HR, когда HR у меня нет, но это не мой профиль
Любопытно. Я такого не встречал. Я делал оценки проектов в 15 млн долларов, было дело, на 100 человек на пару лет (плюс-минус). Да, мы прикидывали риски из понимания заказчика, его процессов и слабых мест, оценка заняла тогда 4 недели.
И для меня заказчик, который может прийти и сказать про увеличение в 4 раза после такого выглядит, как факап первичного анализа на стадии оценки. Или заказчик и правда неадекват. Первое я встречал (ошибки оценки), второе - реже, честно. Может, везло.
Разумеется, если заказчик неадекват, то моя статья нерелевантна: если на вас полезли с кулаками, дипломатия не поможет.
Но вообще любопытно, какой у вас подход был.
Классический подход по созданию ФГИС, насколько я его понимаю это:
Разработка нормативки и концепция + ОТЗ: 1-2 года (нормативка разрабатывается годами, это я для простоты)
Затем НИОКР на создание ТЗ для разных частей системы: 1 год
Затем пара этапов на создание: 1-2 года
все вместе занимает 3-4 года. Дробление как раз призвано снизить объем неизвестности на каждый год. То, что говорите вы, отличается: одно ТЗ на несколько лет - рискованная история, конечно.
Хмм. А вы про IT, да? Десятки тысяч чд (только реальных, а не по оценке, оценивать на такие значения я и сам умею) - это реально немало, особенно если за год.
Тут у меня другой вопрос был бы: а кто работал с заказчиком и почему вот так резко, без причины, вырос объем? По моему опыту это просто так не бывает. Бывает: сходили к министру и чето брякнули. Или от них министр потребовал - чего-то такое.
Тут скажу, что у меня до судов не доходило, было рядом, мы договаривались (речь шла не за десятки тысяч чд, просто за тысячи, но весьма реальные)
Посыл в том, что "нет" говорить не надо вообще. Надо обрисовать проблему, показать, какие есть варианты решения и предложить заказчику выбрать самому любой вариант.
Пример из жизни: у заказчика есть 1 млн рублей и невнятное ТЗ на сайт + интеграцию с AD (к примеру, от балды). И надо сделать за 1 месяц. Заказчик говорит - админ есть, он все поможет. И чтобы дизайн был "ух"!
Для меня это как раз отличный пример всего и сразу. Что я делаю. Готовлю варианты
Для классного проработанного дизайна нужна хотябы карта сайта и согласованные блоки - но их нет. Понимая, что вам надо быстро, можем предложить базовые дизайны стандартного движка сайта (в Б24 их дофига, к примеру). Так будет и красиво и быстро и недорого
Опять таки, карты сайта нет, потому я сам предлагаю ограничиться разделами 1,2,3,4 и все - это можно сделать быстро и в красивом дизе
интеграцию в АД сделать вообще не проблема, правда ваш админ сказал, что она не работает, но если он починит - мы сделаем (надо через 2 недели)
Если вас такой подход устраивает - мы готовы сделать.
Смотрите, я не сказал "нет", но я сам очертил границы и задал скоуп, согласовав его. Это работает почти всегда. Исключение - когда заказчик уперся и хочет все таки все все и сразу. Там наступает момент когда можно сказать "коллеги, мы в указанный срок можем сделать Фазу1, а позже - Фазу 2"
Отлично вас понимаю. РП не любят сейлов - те чтото напродавали , а мне - выполняй. Я такое выижу очень часто, да и сам был таким.
Пока не прочитал одну из лучших книжек для РП (я считаю) "черная книга менеджера". Старая уже, но она мне мозги вправила. Сейлз - продает. Если вы не продадите, нам через полгода станет делать нечего и кушать тоже нечего. По крайней мере тут. Так что выгоднее помогать сейлзу, а не ныть. Так и получается командная игра.
За последние 5 лет почти все превратили. Да, иногда ругались с прямым заказчиком (ему надо было быстро), эскалировали на руководство, готовили презентации.
Делать хорошо непросто, но можно.
Я тут увольнялся, мне лид одного направления (душнила) припомнил один модуль, который так и не отрефакторили, хотя я обещал. Было. Но я честно 4 или 5 заходов делал. У бизнеса там строгое понимание, что они не хотят делать нормально, с понятным обоснованием. Ну так бывает.
А вообще, я скажу, что Госуслуги запустились в 2007 году, если мне не изменяет память. И поддержка тогда работала у них через ЖЖ. Оплата штрафов шла у меня 3 месяца )))) это сейчас, спустя >10 лет там идеально вылизанный сервис. Но все постепенно :)
зависит от размера проекта и сложности коммуникаций на проекте.
Можно посчитать в условных вебсайта: джун РП делает 1 проект по созданию веб сайта и занят фулл тайм на 3 мес. Миддл может делать их 3 и не продолбать ничего. Синьор сделает 5 (собственно, я как то делал 5). Синьор+ сделает 5 и по пути подружится с заказчиками , поймет, что у них болит и предложит что можно сделать, чтобы решить их боли - то есть биздев
спасибо. по поводу книг - нет, я ничего этого в книгах не видел, увы. Да и ни разу у меня не получалось софтскиллам научиться по книжкам или лекциям. На словах все просто, а попадаешь в реал - и коленки дрожат :)
Бизнес игры - точно тема, была пара игр, где я почувствовал прямо, что чтото делаю не так. Но хороших тренеров трудно найти. Пока что все на опыте ) может быть я смогу запилить курс, где все это будет, но надо думать :)
спасибо, я понял.
Я по всем темам, написанным мной в статье могу написать по статье. И напишу, для этого и начал писать. Я уверен, что на Хабре есть люди и опытнее и умнее меня. Я с радостью послушаю их опыт и научусь новому.
Для конструктивного обсуждения или спора , как угодно, нужна фактура. Ваше мнение я понял, фактуру дадите? У вас другие критерии отбора? Расскажите.
Критикуя - предлагай, как верно заметили уже
Здравствуйте. Цель статьи: разобрать отличия джунов миддлов и синьоров, чтобы начинающие и не очень РП могли поглядеть, чего им не хватает, чтобы расти дальше.
Статья основана на большом числе реальных примеров из опыта меня , как РП и меня, как руководителя направлений, ПМО и прочих отделов.
По вашим остальным вопросам я с удовольствием вам отвечу, если вы сразу озвучите их цель. Иначе напоминает собеседование в тональности пассивной агрессии. Я и сам так умею, но, считаю, Хабр не для этого, а для обмена опытом.
Если вы - руководитель, и видите тут лажу, просто напишите. Без проблем, обсудим :)
не спора ради, я просто поделился тем, что я вижу на рынке. Если у вас другой опыт - буду рад если поделитесь. Но не за 10 лет, а последний год-полтора. Потому что сейчас на рынке бум.
Я в 2019 году искал работу и не могу найти. Сейчас за нормальными РП очередь.
Моего ведущего РП (по факту он классный миддл конечно) уже год закидывают офферами от 300 тыс. Если вам интересно - напишите в личку, мне интересно, что у вас. Я смотрю на рынок, мне интересно, что происходит и статья - попытка это понять.
вы знаете, я последние полгода ищу менеджеров. HR подгоняют таких. И несколько человек отказались от наших офферов в пользу других.
Мои менеджеры получают офферы со стороны на схожие суммы. Я сам пару раз выходил на рынок, чтобы прикинуть свою цену. Мои выводы такие.
Дальше - вопрос личной выборки, умения сделать резюме и себя продать (грубо говоря, не соглашаться на первый оффер, а походить пару мес по рынку и поглядеть).
Я в начале статьи написал, что это личный вывод. Но я реально очень много искал в последнее время и вижу странности на рынке РП. И если у вас есть качества джуна из статьи выше, я готов поспорить, что вы найдете работу в этой вилке. Если не ищется - чтото не так делаете.
Мне самому очень интересно, что на рынке, так что можете в личку мне написать, я погляжу.
да ладно, это баян из 2000х)) но рад, рад)
Возможно. Одна из целей статьи - это обменяться опытом. Сам я отбором не занимаюсь, последние несколько лет это делают HR. За ними есть грешок: они могут поднимать зарплаты кандидатов, потому что получают % от зарплаты кандидата в итоге. Так что завышение может быть.
Но я также вижу, когда хорошие кандидаты уходят, не приняв наш оффер. Так что вопрос дискуссионный.
По вашему кейсу скажу следующее: мне в линкед ине писали несколько кандидатов, мы как то даже собеседовали СЕО закрывшегося ИТ интегратора на позицию РП. Я не взял никого. Причины разные: или человек вообще не владеет предметом (как в статье про джуна - этого нет), обещая, что научится (но у меня нет столько денег и времени), или психологические особенности кандидатов.
Если хотите - киньте мне ваше CV в ТГ (в профиле), я погляжу и скажу свое мнение.
Ну тут я бы и сам с вами поспорил. Архитектура системы - это результат исполнения функциональных и нефункциональных требований.
a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.[1]
Давайте для начала: речь идет про джуна. Если джуна поставить рулить проектом, где есть хорошие NFR (кроме времени отклика системы), скорее всего, он проект завалит. Туда надо искать другого сотрудника, а этого обучать на проектах попроще (развитие того, что уже существует).
Про администратора - так можно. Но надо же кого то обучать :)
классные замечания, спасибо. по пунктам
Да, я сам в шоке. На РП и аналитиков прямо сейчас нереальный спрос, я такого не видел никогда. Все ваши замечания для меня - уже синьор :) но тут надо понимать, что я говорю о проектах 20-50 человек. Но 100. Если смотреть на проекты 100+ человек, то там уровень будет другой, разумеется. Но я таких проектов в РФ знаю мало. Может быть выборка хромает, конечно
Хм. Для меня у проекта есть четкие сроки. В госухе всегда есть развитие и эксплуатация. Есть капекс и опекс. Проект заканчивается там, где заканчивается капекс. И обычно это три года (что я знаю, проекты уровня создания ФГИС). Впрочем, Госуслуги уже 15 лет развиваются, так то. Тут надо почитать теорию, я не помню определения.
Экономику ИТ проекта, если он не слишком большой, считать достаточно просто: есть оценка, есть план, есть запасы. Этому я и сам могу научить. Но обычно РП знают это, все таки :)
Может. это в синьоре есть: "может организовать работу 20+ человек" - без делегирования лидам он этого как раз сделать не сможет. Вопрос на собеседовании "расскажите о процессе разработки команды 20 разработчиков и инструментах, где вы его автоматизируете"
Согласен. Тут к вашему первому замечанию. Наверное, уровень упал. Часто РП бывают без опыта предпроектного обследования, оно же пресейл. Но делать "по ТЗ" в целом могут.
Вы знаете, отличия предварительных и приемочных испытаний я сам использовал пару раз, когда надо было сдавать строго по ГОСТ, да и система была сложной. Тут вопрос масштаба. Для меня уже это, скорее, синьор
не надо грубить
я и сам head of pmo уже много лет и перелопатил больше 100.
расскажите кого и на сколько вы взяли. Очень интересно не меряться размерами должности, а сравнить реальный опыт. Хабр для этого и создавался, вообще то.
да. все зависит от дерзости, умения запудрить мозги на собеседовании и опыта интервьюера. не то, чтобы я настаиваю, мой опыт - такой.
Зря вы так, другие мои статьи почитайте.
Я примерно каждый год выходил на рынок - просто интересно его было исследовать + ищу сам давно и много. Да, местами я работаю как HR, когда HR у меня нет, но это не мой профиль
Да, точно. на небольших проектах NFR как правило не пишут. Или пишут одной строчкой.
Если вы джуна спросите про нефункциональные требования к системе, он, скорее всего, поломается. Если он отвечает бодро - я бы советовал брать.
Любопытно. Я такого не встречал. Я делал оценки проектов в 15 млн долларов, было дело, на 100 человек на пару лет (плюс-минус). Да, мы прикидывали риски из понимания заказчика, его процессов и слабых мест, оценка заняла тогда 4 недели.
И для меня заказчик, который может прийти и сказать про увеличение в 4 раза после такого выглядит, как факап первичного анализа на стадии оценки. Или заказчик и правда неадекват. Первое я встречал (ошибки оценки), второе - реже, честно. Может, везло.
Разумеется, если заказчик неадекват, то моя статья нерелевантна: если на вас полезли с кулаками, дипломатия не поможет.
Но вообще любопытно, какой у вас подход был.
Классический подход по созданию ФГИС, насколько я его понимаю это:
Разработка нормативки и концепция + ОТЗ: 1-2 года (нормативка разрабатывается годами, это я для простоты)
Затем НИОКР на создание ТЗ для разных частей системы: 1 год
Затем пара этапов на создание: 1-2 года
все вместе занимает 3-4 года. Дробление как раз призвано снизить объем неизвестности на каждый год. То, что говорите вы, отличается: одно ТЗ на несколько лет - рискованная история, конечно.
Хмм. А вы про IT, да? Десятки тысяч чд (только реальных, а не по оценке, оценивать на такие значения я и сам умею) - это реально немало, особенно если за год.
Тут у меня другой вопрос был бы: а кто работал с заказчиком и почему вот так резко, без причины, вырос объем? По моему опыту это просто так не бывает. Бывает: сходили к министру и чето брякнули. Или от них министр потребовал - чего-то такое.
Тут скажу, что у меня до судов не доходило, было рядом, мы договаривались (речь шла не за десятки тысяч чд, просто за тысячи, но весьма реальные)
Посыл в том, что "нет" говорить не надо вообще. Надо обрисовать проблему, показать, какие есть варианты решения и предложить заказчику выбрать самому любой вариант.
Пример из жизни: у заказчика есть 1 млн рублей и невнятное ТЗ на сайт + интеграцию с AD (к примеру, от балды). И надо сделать за 1 месяц. Заказчик говорит - админ есть, он все поможет. И чтобы дизайн был "ух"!
Для меня это как раз отличный пример всего и сразу. Что я делаю. Готовлю варианты
Для классного проработанного дизайна нужна хотябы карта сайта и согласованные блоки - но их нет. Понимая, что вам надо быстро, можем предложить базовые дизайны стандартного движка сайта (в Б24 их дофига, к примеру). Так будет и красиво и быстро и недорого
Опять таки, карты сайта нет, потому я сам предлагаю ограничиться разделами 1,2,3,4 и все - это можно сделать быстро и в красивом дизе
интеграцию в АД сделать вообще не проблема, правда ваш админ сказал, что она не работает, но если он починит - мы сделаем (надо через 2 недели)
Если вас такой подход устраивает - мы готовы сделать.
Смотрите, я не сказал "нет", но я сам очертил границы и задал скоуп, согласовав его. Это работает почти всегда. Исключение - когда заказчик уперся и хочет все таки все все и сразу. Там наступает момент когда можно сказать "коллеги, мы в указанный срок можем сделать Фазу1, а позже - Фазу 2"
(опять нет не сказал, смотрите)
Отлично вас понимаю. РП не любят сейлов - те чтото напродавали , а мне - выполняй. Я такое выижу очень часто, да и сам был таким.
Пока не прочитал одну из лучших книжек для РП (я считаю) "черная книга менеджера". Старая уже, но она мне мозги вправила. Сейлз - продает. Если вы не продадите, нам через полгода станет делать нечего и кушать тоже нечего. По крайней мере тут. Так что выгоднее помогать сейлзу, а не ныть. Так и получается командная игра.
Да, все так и есть. Senior PM должен быть PO в моем понимании. Во внутреннем ИТ до продактов были вообще то Сервис менеджеры (по ИТИЛ) - это их роль.
А во внешнем - дальше можно расти в биздев смело.
про противоречия 223 и 44 реальности хочется сказать очень много, но нельзя :) работаем с тем, что есть :))))
За последние 5 лет почти все превратили. Да, иногда ругались с прямым заказчиком (ему надо было быстро), эскалировали на руководство, готовили презентации.
Делать хорошо непросто, но можно.
Я тут увольнялся, мне лид одного направления (душнила) припомнил один модуль, который так и не отрефакторили, хотя я обещал. Было. Но я честно 4 или 5 заходов делал. У бизнеса там строгое понимание, что они не хотят делать нормально, с понятным обоснованием. Ну так бывает.
А вообще, я скажу, что Госуслуги запустились в 2007 году, если мне не изменяет память. И поддержка тогда работала у них через ЖЖ. Оплата штрафов шла у меня 3 месяца )))) это сейчас, спустя >10 лет там идеально вылизанный сервис. Но все постепенно :)