Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией:
система показателей эффективности работы
понимание числовых показателей результатов работы
ориентацию «на время» – умение работать в режиме дедлайн
понимание временных аспектов проектной работы
И как эти показатели можно выяснить у кандидата на собеседовании?
Здравствуйте, kotenkamyr, Вы писали:
K>Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией: K>система показателей эффективности работы K>понимание числовых показателей результатов работы K>ориентацию «на время» – умение работать в режиме дедлайн K>понимание временных аспектов проектной работы K>И как эти показатели можно выяснить у кандидата на собеседовании?
Дык эта.
Вы судя по всему HR?
Вот и поспрашивайте у кандидатов эти вопросы, буквально по этому списку.
Они вам и расскажут.
Как говорится, "век живи, век учись".
Здравствуйте, kotenkamyr, Вы писали:
K>понимание числовых показателей результатов работы
"сколько строчек кода в час вы можете написать?"
K>ориентацию «на время» – умение работать в режиме дедлайн
спросить: "есть ли у вас семья?"/"готовы ли вы к переработкам?"/"чем планируете заниматься в свободное время?" ))
K>понимание временных аспектов проектной работы
Вы там диссертацию что-ли пишите?
Попытаюсь чуть-чуть помочь.
K>система показателей эффективности работы
У нас ведётся несколько рейтингов-показателей. Наиболее важные из них.
1. Зарплата. Чем зарплата ниже, тем лучше рейтинг сотрудника. Так как умение работать за низкую зарплату свидетельствует об отличной самомотивации сотрудника и умении работать на перспективу.
2. Зарплата делённая количество срок кода в месяц. Самый важный показатель! Этот показатель сразу даёт представление о ценности сотрудника.
3. Отношение времени, проведённого в офисе, ко времени зафиксированном в time spend reports. Очень хорошо показывает лояльность сотрудников. Самые лояльные сотрудники компании указывают в отчётах в 2 раза меньше времени, чем они фактически потратили.
K>ориентацию «на время» – умение работать в режиме дедлайн
Прежде всего у нас это относится к умению работать на выходных и сверхурочно. Умение работать без отпусков — тоже очень важная характеристика.
K>И как эти показатели можно выяснить у кандидата на собеседовании?
Очень просто:
1. Необходимо рассказать кандидату о том, что проект очень сложный, и первые 5 месяцев, пока он будет втягиваться в работу, получать он будет половину указанной в вакансии зарплаты. Кандидат, который согласится на такие условия — однозначно сильный претендент.
2. Необходимо расспросить кандидата о его хобби и о том, как он проводит свободное время. Лучший кандидат — тот у кого хобби программирование.
3. Спросить, как кандидат относится к работе на выходных и к отпуску 2 недели в году. Здесь всё очевидно.
P.S. Раньше у нас в компании ничего этого не было. Поэтому был полный разброд и шатание. Потом мы наняли отличного HR, который выстроил всю эту систему с нуля. К сожалению, нам не удалось удержать этого HR, ей предложили очень высокооплачиваемую должность в крутой компании в Москве...
Здравствуйте, kotenkamyr, Вы писали:
K>Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией: K>система показателей эффективности работы K>понимание числовых показателей результатов работы K>ориентацию «на время» – умение работать в режиме дедлайн K>понимание временных аспектов проектной работы K>И как эти показатели можно выяснить у кандидата на собеседовании?
Спросить, владеет ли он слепым десятипальцевым методом печати.
Спросить, какие KPI были на предыдущем месте работы и как он их обходил.
Спросить, сдавал ли он в институте сессию вовремя.
Посмотреть, носит ли он на руке часы. Неожиданно спросить "Который час?". И посмотреть на скорость ответа.
Здравствуйте, De-Bill, Вы писали:
DB>1. Необходимо рассказать кандидату о том, что проект очень сложный, и первые 5 месяцев, пока он будет втягиваться в работу, получать он будет половину указанной в вакансии зарплаты. Кандидат, который согласится на такие условия — однозначно сильный претендент.
Это до кризиса можно было делать. Щас кризис — пора возможностей . Первые 5 месяцев можно не платить вообще, кандидату то все равно деваться некуда, а чтоб не потерять квалификацию пусть поработает бесплатно DB>2. Необходимо расспросить кандидата о его хобби и о том, как он проводит свободное время. Лучший кандидат — тот у кого хобби программирование.
У хорошего кандидата на хобби времени не должно быть вообще, свободного времени тоже. Какое такое свободное время, когда его можно и нужно потратить на ликвидацию ошибок руководства? Свобожное время на том свете будет. DB>3. Спросить, как кандидат относится к работе на выходных и к отпуску 2 недели в году. Здесь всё очевидно.
На это слишком многие согласятся, опять, не используем все возможности. Надо так — да, отпуск 2 недели, и в отпуске можно на работе сидеть всего 8 часов. Тоже самое с выходными .
Здравствуйте, kotenkamyr, Вы писали:
K>Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией: K>система показателей эффективности работы K>понимание числовых показателей результатов работы K>ориентацию «на время» – умение работать в режиме дедлайн K>понимание временных аспектов проектной работы K>И как эти показатели можно выяснить у кандидата на собеседовании?
Видите, kotenkamyr, как агрессивно встречают эти вопросы IT-шники?
Мотайте на ус, все эти ответы во время собеседования остаются в головах, в то время как кандидаты выкручиваются отвечать на них.
Может, не стоит их выяснять у кандидатов?
Ну хотя бы, ни под каким соусом не задавайте вопроса K>ориентацию «на время» – умение работать в режиме дедлайн
Он вызывает реаккцию "Твою ж мать" (С) South Park.
Потому что хотя все хоть раз работали в этом режиме, многие реально могут ночами пахать пока продукт не заработает (так сказать, дело чести), но даже аккуратное выяснение этого (да, впрочем, и остальных) вопросов заранее, еще на первичном собеседовании, попахивает рабовладением. И вызывает защитную агрессию.
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, Gradient, Вы писали: G>Видите, kotenkamyr, как агрессивно встречают эти вопросы IT-шники? G>Мотайте на ус, все эти ответы во время собеседования остаются в головах, в то время как кандидаты выкручиваются отвечать на них. G>Может, не стоит их выяснять у кандидатов? G>Ну хотя бы, ни под каким соусом не задавайте вопроса K>>ориентацию «на время» – умение работать в режиме дедлайн G>Он вызывает реаккцию "Твою ж мать" (С) South Park. G>Потому что хотя все хоть раз работали в этом режиме, многие реально могут ночами пахать пока продукт не заработает (так сказать, дело чести), но даже аккуратное выяснение этого (да, впрочем, и остальных) вопросов заранее, еще на первичном собеседовании, попахивает рабовладением. И вызывает защитную агрессию.
Помойму она наврятли поняла что ничего не смыслит в найме программистов и попытки ей делать что-то сверх перечисленного тут
Здравствуйте, Nik_1, Вы писали:
G>>Потому что хотя все хоть раз работали в этом режиме, многие реально могут ночами пахать пока продукт не заработает (так сказать, дело чести), но даже аккуратное выяснение этого (да, впрочем, и остальных) вопросов заранее, еще на первичном собеседовании, попахивает рабовладением. И вызывает защитную агрессию.
N_>Помойму она наврятли поняла что ничего не смыслит в найме программистов и попытки ей делать что-то сверх перечисленного тут
— лишь саботировать процесс поиска кандидатов, вреда будет больше чем пользы Но помойму случай слишком тяжелый и наврятли она хоть что-то поняла
все наверно проще — идет review time of the year и надо что-то придумать эдакое. столы по феншую уже расставили — а количество багов на девелопера осталось прежним — нужны новые подходы =)
Здравствуйте, De-Bill, Вы писали:
DB>Попытаюсь чуть-чуть помочь.
K>>система показателей эффективности работы
DB>У нас ведётся несколько рейтингов-показателей. Наиболее важные из них. DB>1. Зарплата. Чем зарплата ниже, тем лучше рейтинг сотрудника. Так как умение работать за низкую зарплату свидетельствует об отличной самомотивации сотрудника и умении работать на перспективу. DB>2. Зарплата делённая количество срок кода в месяц. Самый важный показатель! Этот показатель сразу даёт представление о ценности сотрудника. DB>3. Отношение времени, проведённого в офисе, ко времени зафиксированном в time spend reports. Очень хорошо показывает лояльность сотрудников. Самые лояльные сотрудники компании указывают в отчётах в 2 раза меньше времени, чем они фактически потратили.
Вот я не понял, ты это всерьез? А название конторы не озвучишь? А какой средний возраст девелоперов? случайно не 18-20 лет? А как, текучка кадров не беспокоит? Если люди работают не то время о котором говорят в time spend reports у ваших менеджеров проблем с планированием не возникает? А если рейтинг (и зарплата) напрямую зависят от строк кода, то во время багфиксинга они вообще буз зарплаты сидят? (по своему опыту знаю, что при багфиксинге можно несколько дней долбаться с поиском баги, а потом ее зафиксить заменив один символ).
Пожалуйта ответь на все эти вопросы, уж очень любопытно.
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
kotenkamyr пишет: > > Подскажите пожалуйста, что у Вас на фирме подразумевают под такой > терменологией:
> система показателей эффективности работы > понимание числовых показателей результатов работы
Скорее всего имеются в виду метрики проекта (размер в SLOC, defect
density и т.п.). Их действительно имеет смысл собирать (какие именно —
зависит от проекта). Анализируются ("понимаются" в вашей интерпретации)
они либо просто в динамике (размер проекта) либо и в сравнении со
средними по компании/отрасли значениями (defect density). Основное что
представляет интерес — влияние тех или иных принятых решений на показатели.
Измерение метрик должно быть автоматизировано, лучше всего если этим
(сбором и представлением информации) занимается вообще посторонний к
проекту человек или отдел.
Keywords: KPI, project metrics
> ориентацию «на время» – умение работать в режиме дедлайн
Умение расставить правильные приоритеты для задач. Сначала сделать
важные и срочные, на конец работы оставить неважные. Уметь измерять (в
т.ч. количественно) глубину погружения проекта в ж.. и динамику её
изменения.
Keyword: timeboxing, Getting Things Done и прочий тайм-менеджмент
> понимание временных аспектов проектной работы
ВрЕменных ? Тлен всё и суета, мы и сами не вечны а проекты тем
более. Без понимания этой истины ПМ будет плохо спать ночами, волнуясь о
судьбе проекта. Это не замедлит сказаться на качестве его работы.
> И как эти показатели можно выяснить у кандидата на собеседовании?
Эти показатели у кандидата может выяснить только _опытный_ ПМ.
Все вышеперечисленные вопросы — нужны только для найма ПМ, разработчикам
это всё не нужно вообще. С тем подмножеством, которое нужно им — их
ознакомит тимлид или ПМ.
Здравствуйте, kotenkamyr, Вы писали:
K>И как эти показатели можно выяснить у кандидата на собеседовании?
Я специалист далеко не по собеседованиям но мне кажется что чёрта с два вы это оцените на собеседовании. Разве что на глаз за счёт "большого жизненнгог(HR-ского) опыта", умения "разбираться в людях" и "чувствовать шестым чувством и пятой точкой". Тестами вы этого не выявите точно. Получасовым разговором?... ну ИМХО очень мало вероятно.
K>Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией: K>система показателей эффективности работы K>понимание числовых показателей результатов работы K>ориентацию «на время» – умение работать в режиме дедлайн K>понимание временных аспектов проектной работы
Вобще с формальной точки зрения у нас это делают так: Есть набор квалификационных требований к разним позициям изложенный в виде таблички. Например, грубо говоря, Джуниор должен уметь:
1. Писать вменяемый код
2. выполнять задания вовремя
3. понимать чего от него хотят
4. знать Х языков програмирования, технологий, буквосочетаний
и тд
Мидл левел девелопер — должен кроме всего описанного выше:
1. разбираться в архитектуре системы
2. знать У патернов
3. Уметь планировать своё время
4. Уметь работать без присмотра или с минимальным присмотром
5. Уметь спроэктировать и реализовать и интегрировать подсистему
6. иметь знания експертного уровня в каких-то технологиях
И тд
Сеньёр должен кроме вышеперечисленного
1. Уметь спроэктировать и реализовать целую отдельную систему — подпроэкт
2. разбить задачу на части, донести до младшего персонала, проконтролировать работу
3. Уметь планировать время подчинённых
4. Иметь знания експертного уровня в....
и тд.
Переодично проводится формальный ревью. Во время этого ревью каждый оценивает себя по этим пунктам согласно своей позиции. оценку ставит ДА-НЕТ-"НУ ТИПА ДА". То же самое делает его непосредственный начальник. Оба пишут коментарии, если надо. Потом происходит митинг с HR, оцениваемым, оценивающим и начальником департамента где эта оценка обсуждается.
Но есть один ньюанс.
Делается это по результатом полугода-года совместной работы а не по результатам получасового интервью с HR. А как такое можно на интервью оценить с вменяемой долей точности, да ещё и в цифрах в большем диапазоне чем (могу, не могу) я не представляю.
Здравствуйте, De-Bill, Вы писали:
DB>У нас ведётся несколько рейтингов-показателей. Наиболее важные из них.
Шеф, ты это — ты ж секретную информацию разглашаешь . Наверняка ж бумажки подписывал. Хоть фирму и не назвал, а ноухау все раскрыл, нехорошо. Смотри, в суд тебя за то, что другие фирмы щас начнут передовые технологии применять, из-за чего твоя фирма конкурентное преимущество потеряет и обанкротится — будешь убытки из своего кармана компенсировать .
Бабошин Андрей пишет: > > K>понимание числовых показателей результатов работы > > "сколько строчек кода в час вы можете написать?"
"Сколько знаков в секунду вы печатаете?" Как-то так, обычно хр этому на
каких-нибудь курсах да учились, посему знают как правильно спросить.
Здравствуйте, kotenkamyr, Вы писали:
K>Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией: K>система показателей эффективности работы K>понимание числовых показателей результатов работы K>ориентацию «на время» – умение работать в режиме дедлайн K>понимание временных аспектов проектной работы K>И как эти показатели можно выяснить у кандидата на собеседовании?
Как показала практика, все количественные показатели по-большому гамбургскому счету бесполезны.
Ну может кроме статистики открытых на девелопера багов и особенно процент переоткрытия после фиксов.
Этого на собеседовании никто даже под страхом смертной казни не скажет =)
А для того чтобы с очень большой долей вероятности оценить скиллы и способности человека нужно включать интуицию и по косвенным данным а также наводящим вопросам выяснять что же он реально делал, чего добился, к чему стремится и что ему интересно.
Поэтому очень рекомендую вам идти именно в этом направлении, а не в количественно-цифровом.
Расскажите, пожалуйста, о том какие у Вас были типичные и авральные ситуации и о том, как вышли из них, как, по Вашему мнению, было бы правильно выйти из них.
Мне это нужно для того , что бы составить кейс для кандидатов.
K>Расскажите, пожалуйста, о том какие у Вас были типичные и авральные ситуации и о том, как вышли из них, как, по Вашему мнению, было бы правильно выйти из них.
Правильно в них не попадать. А если эти ситуации становятся типичными, следует уволить менеджера за несоответствие должности. K>Мне это нужно для того , что бы составить кейс для кандидатов.
Очень хороший кейс, продолжайте. Большая просьба на эти вопросы по интернету просить ответить, а не на собеседовании лично спрашивать. Даже если денег на вакансию ну очень много предлагают, увидев такое в вопросах — надо валить сразу, не дай боже там работать придется. Лучше уж в Макдональдс идти, если уж совсем деваться некуда.
K>Расскажите, пожалуйста, о том какие у Вас были типичные и авральные ситуации и о том, как вышли из них, как, по Вашему мнению, было бы правильно выйти из них.
Ситуация: надо выпустить релиз к определённому сроку, видим, что реализовать всё запланированное не успеваем.
Как справились: перенесли часть багов на следующий релиз.
Как правильно: возможно, правильнее было бы перенести релиз.
Но вообще, что делать в данной ситуации, решают скорее руководители, а не программисты. То есть, что будут делать в подобной ситуации программисты, зависит от руководства, а не от них самих.