Комментарии 121
> Самое удивительное, что все эти мелочи позволяют с большой долей вероятности сразу определить подходит человек или нет. Если бы я учился на психолога, то, наверное, смог бы эту тему раскрыть, а пока мне приходится довольствоваться дилетантскими выводами и определениями.
Где-то читал, что проводили такой эксперимент. Записывали собеседования на видео, а потом сделали нарезки разной длины, причем самая короткая запись включала только несколько первых секунд, сразу после входа в кабинет. Эти видео показывали опытным hr-менеджерам и обнаружили практически 100% корреляцию между результатами просмотра полного видео и первых нескольких секунд.
Где-то читал, что проводили такой эксперимент. Записывали собеседования на видео, а потом сделали нарезки разной длины, причем самая короткая запись включала только несколько первых секунд, сразу после входа в кабинет. Эти видео показывали опытным hr-менеджерам и обнаружили практически 100% корреляцию между результатами просмотра полного видео и первых нескольких секунд.
И что это значит, что менеджеры на самом деле принимают решения на основе первых секунд, а всё остальное, на вроде вопросов, тестов, это их жалкие оправдания?
В теории…
Вполне вероятно, что и на практике тоже, просто не всегда это осознают.
Если честно, надеюсь что нет. Иначе выходит, что приходишь на собеседование, нервничаешь, стараешься, отвечаешь на каверзные вопросы, а на самом деле все зря. Обидно как-то :)
Мне приходилось летом заниматься подбором персонала для босса, нужны были веб-программеры. Хотя я и не был ПМ, а выполнял роль тех. консультанта, прекрасно наблюдал чем все закончилось.
Выбраны были те, с кем приятнее и легче было работать ПМу, и с этим я полностью был согласен.
Выбраны были те, с кем приятнее и легче было работать ПМу, и с этим я полностью был согласен.
Удивительно, но это так. Подтверждаю из после своей сотни собеседований — очень редко когда мнение менялось после первого впечатления. Хотя я всячески стараюсь быть беспристрастным. Тут надо все же уточнять, что первое мнение — это не только одежда, волнение или даже умение держаться. Что бы ни говорили, профессионализим человека проникает в мгновенное восприятие человека достаточно сильно.
НЛО прилетело и опубликовало эту надпись здесь
С нетерпением ждём появления хабрапользователя habracut
подбор кадров – это скорее вопрос интуиции, опыта и умения «видеть людей»
а данная статья хороший практический опросник-шпаргалка
Вопросы удивительным образом похожи на те, что задаю я. Иногда просто диву даёшься, насколько похожи могут быть подходы.
Помимо этого мне нравится такой вопрос: «Вы — руководитель проекта, который начинается с завтрашнего дня и заканчивается ровно через год. Все планы утверждены, команда подобрана, роли определены. И вдруг… Становятся известны результаты проведенного маркетингового исследования, которые говорят о том, что конкурирующая компания планирует выпуск такого же продукта с той же функциональностью, но месяцем раньше. Ваш топ-менеджмент настаивает на завершении проекта тремя месяцами раньше.»
Из ограничений: нельзя уменьшать функциональность и качество, увеличивать объём ресурсов и стоимость.
Попробуйте в следующий раз, иногда находятся очень интересные мысли.
Помимо этого мне нравится такой вопрос: «Вы — руководитель проекта, который начинается с завтрашнего дня и заканчивается ровно через год. Все планы утверждены, команда подобрана, роли определены. И вдруг… Становятся известны результаты проведенного маркетингового исследования, которые говорят о том, что конкурирующая компания планирует выпуск такого же продукта с той же функциональностью, но месяцем раньше. Ваш топ-менеджмент настаивает на завершении проекта тремя месяцами раньше.»
Из ограничений: нельзя уменьшать функциональность и качество, увеличивать объём ресурсов и стоимость.
Попробуйте в следующий раз, иногда находятся очень интересные мысли.
Вот так вот всегда и бывает, сокращаем срок разработки вдвое, функционал урезать нельзя, ресурсов дополнительных 0 =). Мне интересно как бы вы ответили на данный вопрос
Знаете, проектная деятельность наполнена таким количеством сюрпризов, что сокращение на 25% в начале проекта это сравнительно хороший сценарий. Однозначно «правильного» ответа на этот вопрос не существует, он позволяет обнаружить, насколько интервьюируемый способен переключиться из области в управления проектами (если решений для неё не существует) в другую предметную область и поискать ответы там. Там их найти возможно.
>что сокращение на 25% в начале проекта это сравнительно хороший сценарий
нельзя уменьшать функциональность и качество,
как-то не вяжется.
нельзя уменьшать функциональность и качество,
как-то не вяжется.
Если бы не было этого условия, задача решалась в лоб =)
Мда, вообщем не интересный пример.
Возможно, мне пока никто решения не дал.
С учётом тройного ограничения проекта ваша задача не решается «в теории». В конечном счёте всё равно либо придётся вносить изменения в функциональность (не обязательно в сторону ухудшения, но однозначно в сторону уменьшения трудоёмкости), либо находить «из воздуха» дополнительные ресурсы (не те, за которые платит компания): увеличение рабочего дня на энтузиазме (что плохо), привлечь десяток студентов-программистов на практику, организовать юзабилити-конкурс на лучшее решение сложной задачи и т. п. Так или иначе, за эти ресурсы просто заплатят другие: сотрудники, студенты, участники конкурса.
Да, действительно, с точки зрения управления проектами при таком количестве ограничений (из которых я назвал не все), задача не решается.
Нужен маркетинговый ход, который позволит в сложившейся ситуации извлечь максимальную выгоду.
Нужен маркетинговый ход, который позволит в сложившейся ситуации извлечь максимальную выгоду.
решается, см. ниже — цикличность запуска новых версий обеспечит конкурентное преимущество
Выпустить через полгода крутую бесплатную бету с частью функциональности, например. Конкуренты начнут торопиться и выпустят дерьмо. К концу года пользователи замучаются с дерьмом конкурентов и будут с нетерпением ждать полной версии вкусной программы.
Угробить проект конкурентов? =)
НЛО прилетело и опубликовало эту надпись здесь
клевый вопрос, даже достойный отдельного поста =)
варианты разные есть:
1) вторым быть проще (не помню, где читал)
2) вы не уточняете, увеличивать стоимость чего нельзя. если речь идет только о разработке, то можно увеличить маркетинговый бюджет
3) есть утопические варианты вроде саботажа =)
4) группировка функциональности и запуск «облегченной» версси продукта за 6 месяцев, и выпуск полной за 12.
ну и всякое разное…
варианты разные есть:
1) вторым быть проще (не помню, где читал)
2) вы не уточняете, увеличивать стоимость чего нельзя. если речь идет только о разработке, то можно увеличить маркетинговый бюджет
3) есть утопические варианты вроде саботажа =)
4) группировка функциональности и запуск «облегченной» версси продукта за 6 месяцев, и выпуск полной за 12.
ну и всякое разное…
Задача в такой постановке не имеет решения.
Если бы это было бы возможно, то, успешно уменьшив сроки на 3 месяца, можно было бы сразу поставить вторую задачу — уменьшить сроки еще на 3 месяца, и так вплоть до нуля.
Ответ на данный вопрос возможен лишь такой: «мало информации, нужно знать детали». Например, часто сократить сроки действительно возможно, скажем, полностью сменив только что подобранную команду столичных разработчиков-ламеров на намного более опытных, но из регионов. Это лишь пример.
Если бы это было бы возможно, то, успешно уменьшив сроки на 3 месяца, можно было бы сразу поставить вторую задачу — уменьшить сроки еще на 3 месяца, и так вплоть до нуля.
Ответ на данный вопрос возможен лишь такой: «мало информации, нужно знать детали». Например, часто сократить сроки действительно возможно, скажем, полностью сменив только что подобранную команду столичных разработчиков-ламеров на намного более опытных, но из регионов. Это лишь пример.
Решение может быть таким — материальное поощрение сотрудников. Причем, никакого увеличения стоимости нет, т.к. срок сокращен на 25%. Соответственно, 25% ФОТ остаются свободными и могут пойти на премии. А временной ресурс частично можно получить максимально форсировав стадию вхождения в проект — раскачку.
«Вот пусть теперь е--тся маркетологи»
Критерии оценки эффективности разработчиков. Как оценить – эффективно ли работает разработчик или нет
А как вы оцениваете эффективность работника?
А как вы оцениваете эффективность работника?
А какие реальные шансы найти человека отвечающего всем критериям?
И как часто такие люди работу меняют? В том смысле, что если такой человек отвечает всем приведённым выше критериям, как техническим так и социальным, то это очень(!) ценный сотрудник получается. Которым фирма, где он работает, должна сильно дорожить.
Поэтому я думаю, что такие сотрудники, это тот идеал, который никогда не встречается.
И как часто такие люди работу меняют? В том смысле, что если такой человек отвечает всем приведённым выше критериям, как техническим так и социальным, то это очень(!) ценный сотрудник получается. Которым фирма, где он работает, должна сильно дорожить.
Поэтому я думаю, что такие сотрудники, это тот идеал, который никогда не встречается.
Как я и написал — сложно, но можно, требования не такие уж и нереальные на самом деле. Пока все вакансии закрывались успешно, поиск занимал от месяца до трёх.
все-таки это подход далеко не панацея и не идеален. из личного опыта знаю нескольких руководителей которые успешно управляют многомиллионными ИТ-бизнесами, но понятия не имеют чем отличается ооп, и о признаках хорошей верстки тоже никогда не слышали, потому как это проблема верстальщика или кодера. главное уметь управлять людьми
ну например сейчас под кризис на рынке появляются реальные дядьки. Принимает скажем Моторола закрыть отдел разработки в России и пожалуйста!
Когда у нас открывалась первая вакансия после начала кризиса — я с предвкушением потирал руки, вот сейчас как попрут — успевай выбирать. В итоге, всё оказалось намного грустнее. Хорошие специалисты не спешат менять работу, компании сбрасывают в основном балласт, так что по моим личным наблюдениям на рынке всё не сильно улучшилось, кроме разве что зарплатных ожиданий.
НЛО прилетело и опубликовало эту надпись здесь
«умение продавать себя» отдает бесчисленными ток-шоу просмотренными в детстве от скуки. это если торгового агента брать, типа коммивояжера, то наверное да. даже продавцам это часто не требуется. а требовать это от руководителя проектами. надо ли?
и потом, не надо забывать, что на собеседовании не только фирма оценивает сотрудника, но и сотрудник фирму. так что адекватность рекрутера может способствовать/мешать поиску ценных кадров, к коим, безусловно, относится хороший РП :)
и потом, не надо забывать, что на собеседовании не только фирма оценивает сотрудника, но и сотрудник фирму. так что адекватность рекрутера может способствовать/мешать поиску ценных кадров, к коим, безусловно, относится хороший РП :)
сколько вы платите человеку, которого таки нанимаете?
До кризиса зарплата РП этого уровня была в районе 100к рублей, сейчас 80-90.
Это сравнимо с зарплатой старшего программиста? Что то кроме зарплаты, еще мотивирует РП? Кроме роста и перехода на более высокооплачиваемую работу?
почитайте: habrahabr.ru/blogs/pm/51010/
один из вариантов…
один из вариантов…
Вам не кажется, что это заниженная оценка РП подобного уровня в денежном эквиваленте? Ведь они, обладая всеми перечисленными выше навыками, могут спокойно открыть собственный бизнес и получать подобные суммы.
Очень хороший текст! Было интересно почитать.
Не плохая статья, спасибо. Дает возможность прикинуть свои возможности)
Скажите, а зачем такие требования к опыту разработки? И что вы делаете, если человек подходит по остальным параметрам, имеет содержательное представление о веб-технологиях, но сам никогда ни строчки кода не написал? Или написал, но давно?
Такие требования, потому что мой опыт и мои задачи говорят о том, что такой человек будет выполнять поставленные задачи эффективнее «чистого» РП:) Повторюсь, я говорю исключительно про свой опыт и свои задачи, ни в коем случае не утверждаю, что «чистые» РП — плохие РП:)
на самом деле, есть отдельная проблема РП, пришедших «от сохи»: не пытаться закрыть собой все дыры. точнее, понять, что это невозможно. я, помнится, по началу регулярно порывался сам влезть в код и начать писать, потому что «сроки горят, задачи стоят». на выходе, на сколько увеличивал объем написанного кода и реализованного функционала, настолько и сбивал своими вклиниваниями программеров, да и отрывал время от основных своих задач, которых тоже по умолчанию больше, чем времени.
Когда два человек (РП и разработчик) понимают сколько времени и сил надо для какой-то задачи это эффективнее, на мой вгляд, чем оценка одного и неведение другого (никто не говорит что у нас идеальная команда ответственных разработчиков).
+ никогда не бывает хуже когда РП может помочь советом девелоперу.
+ никогда не бывает хуже когда РП может помочь советом девелоперу.
Тогда РП должен профессионально разбираться в дизайне, вёрстке, программировании, психологии, финансах и куче других областей…
ИМХО, в компании должны быть арт-директор и технический директор, которые могут оценивать сроки, помогать дизайнерам и девелоперам советом, контролировать работы с профессиональной точки зрения и т. п. Арт- и технический директора участвуют в нескольких проектах одновременно. Задача РП — это соблюдение ограничений по срокам, составу продукта и ресурсам. За контроль качества нести ответственность должны соответствующие профессионалы.
ИМХО, в компании должны быть арт-директор и технический директор, которые могут оценивать сроки, помогать дизайнерам и девелоперам советом, контролировать работы с профессиональной точки зрения и т. п. Арт- и технический директора участвуют в нескольких проектах одновременно. Задача РП — это соблюдение ограничений по срокам, составу продукта и ресурсам. За контроль качества нести ответственность должны соответствующие профессионалы.
Куда вакансия-то? Берите меня!
«После более чем 100 собеседований разработчиков и РП» — что-то здесь не так. Как не считай, многовато получается, если только это (HR) не основной вид деятельности.
В среднем на одну вакансию я просматриваю около 10 человек (имеются ввиду именно собеседования), только на последних трёх местах работы было открыто 12 вакансий (если мне память не изменяет).
Ничуть не много, для закрытия одной вакансии зачастую и два десятка собеседований приходится провести, вот и считайте.
А грамотный подход, спасибо.
Сам PM и невольно примерял ваши критерии под себя, честно говоря не по всем пунктам подхожу. :)
Сам PM и невольно примерял ваши критерии под себя, честно говоря не по всем пунктам подхожу. :)
Насколько повышается шанс у кандидата, если он «высок и голосист»?
— Cколько женщин в Калуге ходят на каблуках?
— ммм… сорок две?
— ммм… сорок две?
В целом статься гуд. Но мне кажется, что автору следует разделить в проектной команде роли менеджера проекта и технического менеджера. Таким образом один и тот же человек сможет участвовать/руководить несколькими/большим числом проектов.
да и PMом я был тоже не плохим :)
к вопросу о «женщинах на каблуках в Калуге»: очень рекомендую почитать The Guerrilla Guide to Interviewing. там есть несколько таких вопросов, да и в целом, очень и очень толковая статья.
а так… помнится, мне в своё время задали вопрос про количество настройщиков роялей в городе, я источник вспомнил, начал рассказывать, как бы решал такую задачу. смотрю, интервьюер улыбается, радуется… в конце собеседования я не выдержал, сказал, что тоже читаю Джоэля. после некоторой паузы интервьюер ответил: «что ж, чтение грамотных авторов — тоже показатель»
а так… помнится, мне в своё время задали вопрос про количество настройщиков роялей в городе, я источник вспомнил, начал рассказывать, как бы решал такую задачу. смотрю, интервьюер улыбается, радуется… в конце собеседования я не выдержал, сказал, что тоже читаю Джоэля. после некоторой паузы интервьюер ответил: «что ж, чтение грамотных авторов — тоже показатель»
Полезный материал. Приму на заметку :)
Правда, с другой целью немного. Признаюсь честно, у меня есть такое развлечение — ходить по собеседованиям для встряски, общения и заодно, чтобы быть в курсе тенденций на рынке труда. Иногда довольно забавно давать себя исследовать, наблюдать за ходом мысли человека, проводящего интервью, давать ему зацепки и наблюдать, как он прореагирует, подмечать, какие книжки человек читал по подбору персонала и т.п. Вот такое извращенное развлечение… мда… :)
Правда, с другой целью немного. Признаюсь честно, у меня есть такое развлечение — ходить по собеседованиям для встряски, общения и заодно, чтобы быть в курсе тенденций на рынке труда. Иногда довольно забавно давать себя исследовать, наблюдать за ходом мысли человека, проводящего интервью, давать ему зацепки и наблюдать, как он прореагирует, подмечать, какие книжки человек читал по подбору персонала и т.п. Вот такое извращенное развлечение… мда… :)
Я не один такой :-) Я правда только пару раз был.
Еще плюс такого метода: чувствуешь себя намного легче, так как от любого исхода собеседования все равно хуже не будет.
Еще плюс такого метода: чувствуешь себя намного легче, так как от любого исхода собеседования все равно хуже не будет.
ваш работадатель вкурсе вашего хобби?
Ух-ты, я тоже люблю! Очень интересно проводить собеседование работодателей — многому учишься сам, когда видишь как все это выглядит со стороны. Пора писать обратную статью — Как правильно выбрать работодателя.
А вот давайте рассмотрим вопросы, особенно хотелось бы услышать ответы автора.
* Какие преимущества даёт ООП и даёт ли вообще? Плюсы и минусы двух подходов – объектного и процедурного.
Первое это реимущества ООП, над другими видами программирования (http://ru.wikipedia.org/wiki/Категория: Парадигмы_программирования). Второе, это противопоставление парадигмы ООП против процедурного. Так же интересен вопрос, почему из десятка парадигм, противопоставление идёт именно против него. Ну и естественно ответ на этот вопрос с точки зрения johnny_palec.
* Что означает понятие AJAX, как это работает, какие действия нужно произвести для того, чтобы на сайте X появилась форма регистрации с серверной валидацией полей без перезагрузки страницы?
Далее у нас идёт жёсткое ограничение, чисто техническое задание на знание конкретной технологии. Вероятно, кандидаты уже знают, чем будут её использовать, то есть на какой платформе и с применением каких библиотек. Так что этот вопрос мало интересен.
* Как отличить плохой код от хорошего?
Читал я книжку «Совершенный код», вот только пересказывать её довольно утомительно. Что должен сказать кандидат?
* Какие знаете способы борьбы с высокими нагрузками?
Тоже интересно, хотя скорее всего здесь как и в вопросе про AJAX, тот кто спрашивает вероятно ждёт ответа про конкретную технологию, а не про программирование в целом.
* Как функционирует веб-сервер, расскажите максимально подробно? Какая разница между apache и nginx?
Вопрос для администратора.
* Какие паттерны знаете?
Что-то типа этого:
forum.vingrad.ru/index.php?showtopic=263090&view=findpost&p=1901472
опять же жду комментариев johnny_palec и что он хочет услышать на свой вопрос.
* Какие признаки у хорошей вёрстки?
Какие?
* Что такое система контроля версий, какие знаете, умеете ли использовать? Какие преимущества они дают команде?
На это ответ наверное не нужен, неинтересный вопрос. Жду правильные ответы.
* Какие преимущества даёт ООП и даёт ли вообще? Плюсы и минусы двух подходов – объектного и процедурного.
Первое это реимущества ООП, над другими видами программирования (http://ru.wikipedia.org/wiki/Категория: Парадигмы_программирования). Второе, это противопоставление парадигмы ООП против процедурного. Так же интересен вопрос, почему из десятка парадигм, противопоставление идёт именно против него. Ну и естественно ответ на этот вопрос с точки зрения johnny_palec.
* Что означает понятие AJAX, как это работает, какие действия нужно произвести для того, чтобы на сайте X появилась форма регистрации с серверной валидацией полей без перезагрузки страницы?
Далее у нас идёт жёсткое ограничение, чисто техническое задание на знание конкретной технологии. Вероятно, кандидаты уже знают, чем будут её использовать, то есть на какой платформе и с применением каких библиотек. Так что этот вопрос мало интересен.
* Как отличить плохой код от хорошего?
Читал я книжку «Совершенный код», вот только пересказывать её довольно утомительно. Что должен сказать кандидат?
* Какие знаете способы борьбы с высокими нагрузками?
Тоже интересно, хотя скорее всего здесь как и в вопросе про AJAX, тот кто спрашивает вероятно ждёт ответа про конкретную технологию, а не про программирование в целом.
* Как функционирует веб-сервер, расскажите максимально подробно? Какая разница между apache и nginx?
Вопрос для администратора.
* Какие паттерны знаете?
Что-то типа этого:
forum.vingrad.ru/index.php?showtopic=263090&view=findpost&p=1901472
опять же жду комментариев johnny_palec и что он хочет услышать на свой вопрос.
* Какие признаки у хорошей вёрстки?
Какие?
* Что такое система контроля версий, какие знаете, умеете ли использовать? Какие преимущества они дают команде?
На это ответ наверное не нужен, неинтересный вопрос. Жду правильные ответы.
Полагаю, тут прикол в том, что правильных ответов не существует. В этом-то и интерес, с какой стороны кандидат зайдёт к ответу.
В том то и дело, что существуют, но они просто огромны. Я знаю где искать ответы, но не смогу запомнить даже малую их часть. Некоторые из них описываются в десятках книжек, хотя другие здесь есть довольно простые. Скорее всего масса критериев и тестов, которые были здесь приведены действительно несут в себе лишь единственную цель, понять «нравится» человек, «не нравится», мало объективности.
Так чем же парадигма ООП лучше?
Или она хуже?
Или все же it depends?
Или она хуже?
Или все же it depends?
Есть же ещё мультипарадигмальные языки, навроде C++. Не обязательно следовать только одной парадигме, можно использовать сразу много. ООП разделяет систему на части и дальше идёт их использование и создание из частей новых частей.
Если разделение прошло правильно, то можно совершенствовать одни куски кода и быть абсолютно уверенным, что другой код не зависит от них, и не изменит своего поведения в зависимости от сделанных нами изменений в других местах.
ООП объёмно в изучении. Научиться синтаксису описания классов это практически ничему не научиться с точки зрения ООП, Из-за этого те кто думают, что используют ООП, на самом деле пишут в другой парадигме, а это всё можно назвать псевдо ООП.
Я думаю преимущества ООП огромны, но и усилия потраченные на его понимание не меньше.
Если разделение прошло правильно, то можно совершенствовать одни куски кода и быть абсолютно уверенным, что другой код не зависит от них, и не изменит своего поведения в зависимости от сделанных нами изменений в других местах.
ООП объёмно в изучении. Научиться синтаксису описания классов это практически ничему не научиться с точки зрения ООП, Из-за этого те кто думают, что используют ООП, на самом деле пишут в другой парадигме, а это всё можно назвать псевдо ООП.
Я думаю преимущества ООП огромны, но и усилия потраченные на его понимание не меньше.
А у меня вопрос немного не по статье.
johnny_palec, подскажи, с чего нужно начать человеку, который в будущем хочет стать менеджером проектов?
Пройти спец. обучение? Работать, работать, работать до повышения? Или может быть это дар свыше? Что посоветуете?
johnny_palec, подскажи, с чего нужно начать человеку, который в будущем хочет стать менеджером проектов?
Пройти спец. обучение? Работать, работать, работать до повышения? Или может быть это дар свыше? Что посоветуете?
>Пройти спец. обучение? Работать, работать, работать до повышения? Или может быть это дар свыше? Что посоветуете?
А зачем быть менеджером проектов, когда лучше быть тем, кто выбирает менеджеров проектов. А ещё лучше стремиться сразу стать мегабосом.
А зачем быть менеджером проектов, когда лучше быть тем, кто выбирает менеджеров проектов. А ещё лучше стремиться сразу стать мегабосом.
И как это сделать?
Если бы я знал, то сам бы уже им стал. Одно я могу сказать точно, чтобы стать мегабосом, вкалывать в качестве создателя систем с утра до ночи вовсе не нужно.
Продавать наркотики и шлюх, потом вывести деньги через офшоры и заняться белым бизнесом.
как варианты:
— торговать оружием;
— заняться рейдерством;
— поучаствовать в политическом перевороте;
— украсть бюджетного бабла
— …
предлагаю продолжить
как варианты:
— торговать оружием;
— заняться рейдерством;
— поучаствовать в политическом перевороте;
— украсть бюджетного бабла
— …
предлагаю продолжить
Прочитать об этом книгу
НЛО прилетело и опубликовало эту надпись здесь
Хм… Сколько людей — столько мнений. Я менеджер проекта, но так как надо мной никого нет (кроме генералитета) — то фактически — руководитель. Поэтому хочу заметить автору, что он забыл 2 важные составляющие проекта — маркетинговую и юридическую (если за вас это кто-то делает — вам крупно повезло). Умение решать такие вопросы очень крупно помогает, особенно при работе с очень крупными заказчиками/подрядчиками.
Я считаю, что хороший РП — прежде всего хороший организатор. При этом ему совсем не обязательно разбираться в ООП, серверах и т.д. (предчувствую минусы). Это уже вопросы программерам.
Я считаю, что хороший РП — прежде всего хороший организатор. При этом ему совсем не обязательно разбираться в ООП, серверах и т.д. (предчувствую минусы). Это уже вопросы программерам.
Мое мнение — хороший руководитель проекта это тот, кто способен этот проект сделать качественно и в срок, сделать своими руками плюс руками вверенной ему команды спецов (или своей собственной команды). Все. Точка.
Он может может с первого раза не найти дорогу в офис, может выглядеть неуверенным в себе, одет неопрятно, может нечаянно опрокинуть предложенный ему кофе…
Но это неважно, так как если например не найдет дороги — Вы вызовите ему такси или даже заскочите на своем автомобиле лично, а если нужно представить серьезному клиенту — найдете способ объяснить этому клиенту отсутствие у специалиста пиджака и галстука, и т.д., это не проблема. Главное — этот человек необходим бизнесу Вашей IT компании, необходим для того, чтобы делать проекты качественно и в срок, и не более чем.
Он не будет говорить на собеседовании о художественной литературе. На вопрос про преимущества ООП посмотрит на спрашивающего как на идиота. А если ему зададут вопрос про количество каблуков в Калуге, он ответит: «я — профессионал, пожалуйста не отнимайте мое время».
На самом деле, именно такие люди нужны IT компаниям. Которые известны на локальных рынках труда, которые штамповали проекты нужного класса как на конвейере, и которые, возможно, почитаемы в своих кругах, имеют последователей…
Он никогда не пришлет резюме сам, Вы этого человека сами найдете, и будете переманить из другой компании. Он не станет распинаться и тратить два часа собеседования на пустые вопросы типа преимуществ ООП, при малейшем подобном вопросе он скажет что ему некогда, нужно продолжить работу. Затем встанет и уйдет. Навсегда.
Вы это понимаете, и именно поэтому все два часа он будет лишь слушать, как Вы будете его уговаривать работать в Вашей компании, расписывая все более заманчивые перспективы. Возможно, Вам повезет, и он ответит: «да, мы хорошо поработаем вместе, и этим проектом можно будет гордиться!».
А приведенное в статье рассчитано на фильтрацию приходящих с улицы новичков, которые думают что они матерые руководители проектов, и спамят своими резюме всех подряд. IMHO.
Он может может с первого раза не найти дорогу в офис, может выглядеть неуверенным в себе, одет неопрятно, может нечаянно опрокинуть предложенный ему кофе…
Но это неважно, так как если например не найдет дороги — Вы вызовите ему такси или даже заскочите на своем автомобиле лично, а если нужно представить серьезному клиенту — найдете способ объяснить этому клиенту отсутствие у специалиста пиджака и галстука, и т.д., это не проблема. Главное — этот человек необходим бизнесу Вашей IT компании, необходим для того, чтобы делать проекты качественно и в срок, и не более чем.
Он не будет говорить на собеседовании о художественной литературе. На вопрос про преимущества ООП посмотрит на спрашивающего как на идиота. А если ему зададут вопрос про количество каблуков в Калуге, он ответит: «я — профессионал, пожалуйста не отнимайте мое время».
На самом деле, именно такие люди нужны IT компаниям. Которые известны на локальных рынках труда, которые штамповали проекты нужного класса как на конвейере, и которые, возможно, почитаемы в своих кругах, имеют последователей…
Он никогда не пришлет резюме сам, Вы этого человека сами найдете, и будете переманить из другой компании. Он не станет распинаться и тратить два часа собеседования на пустые вопросы типа преимуществ ООП, при малейшем подобном вопросе он скажет что ему некогда, нужно продолжить работу. Затем встанет и уйдет. Навсегда.
Вы это понимаете, и именно поэтому все два часа он будет лишь слушать, как Вы будете его уговаривать работать в Вашей компании, расписывая все более заманчивые перспективы. Возможно, Вам повезет, и он ответит: «да, мы хорошо поработаем вместе, и этим проектом можно будет гордиться!».
А приведенное в статье рассчитано на фильтрацию приходящих с улицы новичков, которые думают что они матерые руководители проектов, и спамят своими резюме всех подряд. IMHO.
Стать таким человек и жить в описанной вами реальности — мечта любого подростка, но реальность оказывается намного суровее, чем хотелось бы:)
Про мечты подростка — тут я не в курсе дела, возможно, Вам виднее. А про реальность — так и есть, эта самая реальность действительно сурова. Но сурова в первую очередь к тем, кто ничего собой не представляет. А по мере накопления жизненного опыта и уровня мастерства она становится все более и более благосклонной…
Ну ладно, это все вода, теперь по делу.
Итак, проведя более 100 собеседований по 2 часа, Вы тем самым потратили более 1 человеко-месяца своего продуктивного рабочего времени, которое могли бы провести с большей пользой. Например, вкладывая его в развитие своей команды.
Ну вот посмотрите, скажем, нашли спеца, который уже сделал пару проектов типа того, который нужно сделать Вашей компании. Эти его проекты уже в продакшене, и ими пол страны пользуется. Но при этом он, скажем, на вопрос о художественной литературе отвечает, что она его вообще не интересует. А на примитивный, известный каждому школьнику вопрос типа каблуков в Калуге, с юмором отвечает: «нужна дополнительная информация, а именно, сколько слонов в Африке?». Что, не возьмете такого спеца? Так зачем было его и свое время терять…
=============================
А теперь мое собеседование руководителя проекта. Сначала — минут 15-20 общения по телефону или скайпу. Знакомство всегда начинаю с поиска возможных общих знакомых, потом это пригодится. Задаю только высокоуровневые, но ключевые технические вопросы (вопросы менеджмента не интересуют, если что, в этом вопросе поможем), и только практические, по возможности по его прошлым успешным проектам, по существу (владение теорией не интересует, у нас производство, а не научный центр, впрочем у спецов такого уровня теория обычно и так всегда в порядке). На этом — отсев большинства кандидатов.
Далее обзвон знакомых, кто с этим кандидатом сталкивался или слышал о нем. Если никто его не знает — при наличии других кандидатов предпочитаю не рисковать, хотя бывают исключения. Недолгое гугление по имени-фамилии и контактам. Если ничего не настораживает — приглашение в офис, и собеседование опять-таки минут 15, но уже, в основном, отвечаю на его вопросы, а сам присматриваюсь, будет ли ребятам с ним комфортно работать. Например, если чересчур резкий, непримиримый и независимый, или еще какой экстремум типа серьги в губе (был такой случай!) — скорее всего не подойдет. Все, этого достаточно, рекомендую или наоборот не рекомендую брать этого человека на испытательный срок (1 неделя).
Ну ладно, это все вода, теперь по делу.
Итак, проведя более 100 собеседований по 2 часа, Вы тем самым потратили более 1 человеко-месяца своего продуктивного рабочего времени, которое могли бы провести с большей пользой. Например, вкладывая его в развитие своей команды.
Ну вот посмотрите, скажем, нашли спеца, который уже сделал пару проектов типа того, который нужно сделать Вашей компании. Эти его проекты уже в продакшене, и ими пол страны пользуется. Но при этом он, скажем, на вопрос о художественной литературе отвечает, что она его вообще не интересует. А на примитивный, известный каждому школьнику вопрос типа каблуков в Калуге, с юмором отвечает: «нужна дополнительная информация, а именно, сколько слонов в Африке?». Что, не возьмете такого спеца? Так зачем было его и свое время терять…
=============================
А теперь мое собеседование руководителя проекта. Сначала — минут 15-20 общения по телефону или скайпу. Знакомство всегда начинаю с поиска возможных общих знакомых, потом это пригодится. Задаю только высокоуровневые, но ключевые технические вопросы (вопросы менеджмента не интересуют, если что, в этом вопросе поможем), и только практические, по возможности по его прошлым успешным проектам, по существу (владение теорией не интересует, у нас производство, а не научный центр, впрочем у спецов такого уровня теория обычно и так всегда в порядке). На этом — отсев большинства кандидатов.
Далее обзвон знакомых, кто с этим кандидатом сталкивался или слышал о нем. Если никто его не знает — при наличии других кандидатов предпочитаю не рисковать, хотя бывают исключения. Недолгое гугление по имени-фамилии и контактам. Если ничего не настораживает — приглашение в офис, и собеседование опять-таки минут 15, но уже, в основном, отвечаю на его вопросы, а сам присматриваюсь, будет ли ребятам с ним комфортно работать. Например, если чересчур резкий, непримиримый и независимый, или еще какой экстремум типа серьги в губе (был такой случай!) — скорее всего не подойдет. Все, этого достаточно, рекомендую или наоборот не рекомендую брать этого человека на испытательный срок (1 неделя).
Придерживаюсь такого же мнения.
Когда увидел что на собеседование отводится 2 часа — аж передернуло. Если уж вдруг придется вновь идти на собеседование, надо добавить к своему вопроснику к работодателю вопрос о продолжительности собеседования.
Когда увидел что на собеседование отводится 2 часа — аж передернуло. Если уж вдруг придется вновь идти на собеседование, надо добавить к своему вопроснику к работодателю вопрос о продолжительности собеседования.
Прошу прощения, что не совсем по теме, но хочу спросить: не подскажет ли кто-нибудь литературу по теме управление сотрудников IT-отдела, психология айтишников. Заранее благодарен.
Интуиция — лучший друг и заменитель по сути задач для искуственного интелекта: когда-то в универе был курс и мы писали курсовые по теме, как посчитать женщин на каблыках или какой болезнью болеет больной. Так вот интуиция именно этим и занимается — дает доволно однозначный ответ Да/Нет на вопрос Подходит кандидат?
Можно пожалуйста еще немного покритикую?
> Опыт и навыки, указанные в резюме.
IMHO на собеседовании достаточно спросить только то, что нужно для текущего проекта. Остальное неважно, пусть хоть что пишет, будет на его совести.
В принципе, если где-то что-то значительно «преукрасит», это будет заметно. Например, когда 23-летний паренек пишет в резюме что у него 8 лет опыта Java/J2EE, из них 4 года — управление проектами.
> На сколько твёрдо человек держится своих позиций – пытаюсь переубедить человека в том или ином вопросе.
А смысл? Если твердо держится — это неплохо для руководителя, вызывает уважение. Если не держится, и очень податливый — тоже неплохо, с ним комфортно работать. Все люди разные, и это — не то качество, которое мешает руководителю проекта. Мы же не харизматичного фюрера выбираем.
> Причины ухода из предыдущих компаний.
Все всегда отвечают «нет перспектив». Ну или сейчас добавилось еще «сокращение из-за кризиса». Кто-то хоть раз отвечал что-то другое?
> Опыт или знания в смежных областях – интернет маркетинг, проектирование интерфейсов, дизайн, вёрстка.
Это вообще не нужно. Повлияет ли любой вариант ответа на то, возьмете ли человека или нет, если остальное в порядке?
> Какие преимущества даёт ООП и даёт ли вообще? Плюсы и минусы двух подходов – объектного и процедурного.
Вопрос абсолютно не практичный, в реальной работе использоваться никогда не будет. В любом случае, даже если ответит что в больших проектах при грамотном проектировании ООП не дает преимуществ — сможете возразить? Не нужны эти священные войны на собеседовании, лучше оставьте эту тему на тимбилдинг под пиво, а в текущем проекте в любом случае, как архитекторы определят, так проект и будет делаться.
> Что означает понятие AJAX, как это работает, какие действия нужно произвести для того, чтобы на сайте X появилась форма регистрации с серверной валидацией полей без перезагрузки страницы?
Есть ли смысл задавать этот вопрос Мастеру, команда которого сделала десяток успешный проектов на AJAX, которые можно посмотреть в инете, и на которых пасутся десятки тысяч пользователей?
> Как отличить плохой код от хорошего?
Это тоже священные войны. Но все же тема очень важна, поэтому вопрос заменяем на: «какие требования к коду Вы предъявляете своей команде? что хотели бы улучшить?» В этом случае отвечают на такой вопрос обычно с удовольствием.
> Какие знаете способы борьбы с высокими нагрузками?
Это уже хороший вопрос для собеседования. Только он подразумевает долгое раздумье, и долгий ответ. Да и немного непонятно, что значит «бороться с высокими нагрузками»… выключить сервер?
Желательно поконкретнее бы, например:
— «что использовали для балансировки, с какими недостатками столкнулись?»,
— «что именно кешировали?»,
— «что использовали для кеширования, с какими недостатками столкнулись?»,
— «какой установили уровень изоляции транзакций?»
и т.д.
> Как функционирует веб-сервер, расскажите максимально подробно? Какая разница между apache и nginx?
Как функционирует веб-сервер, да еще и максимально подробно… бррррр. Потеря времени.
Вместо разницы между apache и nginx лучше спросить, например, «что использовали для отдачи статики, с какими недостатками столкнулись?».
> Какие паттерны знаете?
Абсолютно бесполезный с практической точки зрения вопрос руководителю проекта, так как носит скорее справочный характер.
Но в любом случае, сейчас основные паттерны не знает только ленивый, и спрашивать Мастера об этом — моветон. Знаете ли хотя бы одного современного руководителя проектов, кто не знал бы ни одного паттерна? А того, кто знает все-все паттерны?
Но даже если бы не знал вообще ни одного паттерна (я такое могу себе представить разве что если до этого его команда делала софт для микропроцессоров, в машинных кодах), помешало бы это ему работать? Нет. Да и узнать все что нужно по этому вопросу можно буквально за несколько часов.
Примечание: вопросы про паттерны принципиально важны на собеседовании архитектора.
> Какие признаки у хорошей вёрстки?
Заменяем на: «какие требования к верстке Вы предъявляете своей команде?». Такой вопрос может быть полезен, если верстка в Вашем проекте занимает значительное место.
> Что такое система контроля версий, какие знаете, умеете ли использовать? Какие преимущества они дают команде?
Ооо… у человека в резюме написано, скажем, 10+ лет опыта работы, стоят магические слова ClearCase, SourceSafe, Perforce, SVN, CSV, а ему такой вопрос… Уместно ли?
P.S. Если что, прошу прощения за критику и небольшую иронию. Моя цель — обратить внимание, что собеседование высококвалифицированого мастера несколько отличается от собеседования обычного кодера.
> Опыт и навыки, указанные в резюме.
IMHO на собеседовании достаточно спросить только то, что нужно для текущего проекта. Остальное неважно, пусть хоть что пишет, будет на его совести.
В принципе, если где-то что-то значительно «преукрасит», это будет заметно. Например, когда 23-летний паренек пишет в резюме что у него 8 лет опыта Java/J2EE, из них 4 года — управление проектами.
> На сколько твёрдо человек держится своих позиций – пытаюсь переубедить человека в том или ином вопросе.
А смысл? Если твердо держится — это неплохо для руководителя, вызывает уважение. Если не держится, и очень податливый — тоже неплохо, с ним комфортно работать. Все люди разные, и это — не то качество, которое мешает руководителю проекта. Мы же не харизматичного фюрера выбираем.
> Причины ухода из предыдущих компаний.
Все всегда отвечают «нет перспектив». Ну или сейчас добавилось еще «сокращение из-за кризиса». Кто-то хоть раз отвечал что-то другое?
> Опыт или знания в смежных областях – интернет маркетинг, проектирование интерфейсов, дизайн, вёрстка.
Это вообще не нужно. Повлияет ли любой вариант ответа на то, возьмете ли человека или нет, если остальное в порядке?
> Какие преимущества даёт ООП и даёт ли вообще? Плюсы и минусы двух подходов – объектного и процедурного.
Вопрос абсолютно не практичный, в реальной работе использоваться никогда не будет. В любом случае, даже если ответит что в больших проектах при грамотном проектировании ООП не дает преимуществ — сможете возразить? Не нужны эти священные войны на собеседовании, лучше оставьте эту тему на тимбилдинг под пиво, а в текущем проекте в любом случае, как архитекторы определят, так проект и будет делаться.
> Что означает понятие AJAX, как это работает, какие действия нужно произвести для того, чтобы на сайте X появилась форма регистрации с серверной валидацией полей без перезагрузки страницы?
Есть ли смысл задавать этот вопрос Мастеру, команда которого сделала десяток успешный проектов на AJAX, которые можно посмотреть в инете, и на которых пасутся десятки тысяч пользователей?
> Как отличить плохой код от хорошего?
Это тоже священные войны. Но все же тема очень важна, поэтому вопрос заменяем на: «какие требования к коду Вы предъявляете своей команде? что хотели бы улучшить?» В этом случае отвечают на такой вопрос обычно с удовольствием.
> Какие знаете способы борьбы с высокими нагрузками?
Это уже хороший вопрос для собеседования. Только он подразумевает долгое раздумье, и долгий ответ. Да и немного непонятно, что значит «бороться с высокими нагрузками»… выключить сервер?
Желательно поконкретнее бы, например:
— «что использовали для балансировки, с какими недостатками столкнулись?»,
— «что именно кешировали?»,
— «что использовали для кеширования, с какими недостатками столкнулись?»,
— «какой установили уровень изоляции транзакций?»
и т.д.
> Как функционирует веб-сервер, расскажите максимально подробно? Какая разница между apache и nginx?
Как функционирует веб-сервер, да еще и максимально подробно… бррррр. Потеря времени.
Вместо разницы между apache и nginx лучше спросить, например, «что использовали для отдачи статики, с какими недостатками столкнулись?».
> Какие паттерны знаете?
Абсолютно бесполезный с практической точки зрения вопрос руководителю проекта, так как носит скорее справочный характер.
Но в любом случае, сейчас основные паттерны не знает только ленивый, и спрашивать Мастера об этом — моветон. Знаете ли хотя бы одного современного руководителя проектов, кто не знал бы ни одного паттерна? А того, кто знает все-все паттерны?
Но даже если бы не знал вообще ни одного паттерна (я такое могу себе представить разве что если до этого его команда делала софт для микропроцессоров, в машинных кодах), помешало бы это ему работать? Нет. Да и узнать все что нужно по этому вопросу можно буквально за несколько часов.
Примечание: вопросы про паттерны принципиально важны на собеседовании архитектора.
> Какие признаки у хорошей вёрстки?
Заменяем на: «какие требования к верстке Вы предъявляете своей команде?». Такой вопрос может быть полезен, если верстка в Вашем проекте занимает значительное место.
> Что такое система контроля версий, какие знаете, умеете ли использовать? Какие преимущества они дают команде?
Ооо… у человека в резюме написано, скажем, 10+ лет опыта работы, стоят магические слова ClearCase, SourceSafe, Perforce, SVN, CSV, а ему такой вопрос… Уместно ли?
P.S. Если что, прошу прощения за критику и небольшую иронию. Моя цель — обратить внимание, что собеседование высококвалифицированого мастера несколько отличается от собеседования обычного кодера.
Сорри, опечатка, *CVS.
Да, еще хочу добавить, ряд очень важных тем, которые обычно должны подниматься на собеседовании, не затронуто.
Например, очень важный вопрос — владение английским языком.
Для многих проектов это чуть ли не самое важное из всего, если руководителю проекта нужно взаимодействовать с иностранным клиентом.
В этом случае можете часть технического собеседования провести на английском языке, если чувствуете в себе силы. Или же можете провести дополнительное собеседование 5-10 минут, подключив хорошего переводчика.
Да, еще хочу добавить, ряд очень важных тем, которые обычно должны подниматься на собеседовании, не затронуто.
Например, очень важный вопрос — владение английским языком.
Для многих проектов это чуть ли не самое важное из всего, если руководителю проекта нужно взаимодействовать с иностранным клиентом.
В этом случае можете часть технического собеседования провести на английском языке, если чувствуете в себе силы. Или же можете провести дополнительное собеседование 5-10 минут, подключив хорошего переводчика.
НЛО прилетело и опубликовало эту надпись здесь
Где на такие собеседования записываться?) Тоже хочу!)
Правда, судя по «географии» в вопросах, мы далековато друг-друга… :(
Правда, судя по «географии» в вопросах, мы далековато друг-друга… :(
Статья интересная…
Я работал РП одного большого проекта до того как бахнул кризис. Меня никто так не собеседовал (я там вырос с менее интересной должности)
Когда начал работать и подбирать команду разработчиков то собеседование тоже проводилось и по 2 часа…
Задавались вопросы по тому какие есть методы оптимизации, как бороться с нагрузками и т.д. Ни одного вопроса по программированию на конкретном языке… У человека должно быть правильно понятие как решать задачу, а уже потом думать с помощью каких инструментов.
На счет таких вопросов для РП я соглашусь только в том случаи если проект не большой и в команде нет ТимЛида, в этом случаи РП должен быть и ТимЛидером. А тут без общих технических понятий никак.
Я работал РП одного большого проекта до того как бахнул кризис. Меня никто так не собеседовал (я там вырос с менее интересной должности)
Когда начал работать и подбирать команду разработчиков то собеседование тоже проводилось и по 2 часа…
Задавались вопросы по тому какие есть методы оптимизации, как бороться с нагрузками и т.д. Ни одного вопроса по программированию на конкретном языке… У человека должно быть правильно понятие как решать задачу, а уже потом думать с помощью каких инструментов.
На счет таких вопросов для РП я соглашусь только в том случаи если проект не большой и в команде нет ТимЛида, в этом случаи РП должен быть и ТимЛидером. А тут без общих технических понятий никак.
РП должен хорошо ориентироваться в технической части не для того, чтобы рулить в этом плане командой, а для того, чтобы контролировать результаты и решения того же самого тим-лида, ориентироваться в ходе проекта, не надеясь на того же тим-лида. Опять же, РП не должен таскать за собой тим-лида на все совещания с руководством и при определении бизнес-задач. И я в который раз повторюсь — требования мои личные под задачи моей компании и под мои проекты, это не картина идеального РП на все случаи жизни.
> Что означает понятие AJAX, как это работает, какие действия нужно произвести для того, чтобы на сайте X появилась форма регистрации с серверной валидацией полей без перезагрузки страницы?
> Какие паттерны знаете?
> Какие признаки у хорошей вёрстки?
Это вопросы для веб-разработчика, и специалист по разработке сложных проектов на с/с++ этого может и не знать. Глупо задавать такие вопросы человеку, который будет писать код далекий от веб.
> Какие паттерны знаете?
> Какие признаки у хорошей вёрстки?
Это вопросы для веб-разработчика, и специалист по разработке сложных проектов на с/с++ этого может и не знать. Глупо задавать такие вопросы человеку, который будет писать код далекий от веб.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Собеседуем руководителя проектов