Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией:
система показателей эффективности работы
понимание числовых показателей результатов работы
ориентацию «на время» – умение работать в режиме дедлайн
понимание временных аспектов проектной работы
И как эти показатели можно выяснить у кандидата на собеседовании?
Здравствуйте, 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>Расскажите, пожалуйста, о том какие у Вас были типичные и авральные ситуации и о том, как вышли из них, как, по Вашему мнению, было бы правильно выйти из них.
Ситуация: надо выпустить релиз к определённому сроку, видим, что реализовать всё запланированное не успеваем.
Как справились: перенесли часть багов на следующий релиз.
Как правильно: возможно, правильнее было бы перенести релиз.
Но вообще, что делать в данной ситуации, решают скорее руководители, а не программисты. То есть, что будут делать в подобной ситуации программисты, зависит от руководства, а не от них самих.
K>Расскажите, пожалуйста, о том какие у Вас были типичные и авральные ситуации и о том, как вышли из них, как, по Вашему мнению, было бы правильно выйти из них.
Авральные ситуации — это головная боль для управлнецев.
Они должны их предупреждать и разруливать.
Программер же должен просто вовремя сообщать о надвигающихся проблемах.
bkat пишет:
> K>Расскажите, пожалуйста, о том какие у Вас были типичные и авральные > ситуации и о том, как вышли из них, как, по Вашему мнению, было бы > правильно выйти из них. > > Авральные ситуации — это головная боль для управлнецев. > Они должны их предупреждать и разруливать. > Программер же должен просто вовремя сообщать о надвигающихся проблемах.
Да, это наверное единственный хороший кейс для разработчиков:
накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы
— (junior|middle|senior developer) | (team lead) случайно узрели там
полный пэ, который вам [не]понятно почему не проявился на тестировании,
но точно проявится в production и это будет (не слишком серьёзно, но
очень visible|очень серьёзно). Ваши действия?
kotenkamyr пишет: > > > Расскажите, пожалуйста, о том какие у Вас были типичные и авральные > ситуации и о том, как вышли из них, как, по Вашему мнению, было бы > правильно выйти из них. > Мне это нужно для того , что бы составить кейс для кандидатов.
Гарантировано отправить спецов подальше — вот к этому вы придете с таким
вопросом.
hrensgory пишет: > > Да, это наверное единственный хороший кейс для разработчиков: > > накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы > — (junior|middle|senior developer) | (team lead) случайно узрели там > полный пэ, который вам [не]понятно почему не проявился на тестировании, > но точно проявится в production и это будет (не слишком серьёзно, но > очень visible|очень серьёзно). Ваши действия?
Во-во, мне именно твой ответ и хочется здесь увидеть.
Все эти раговоры насчет эффективности — обычное вешание лапши на уши и перекладывание с больной головы на здоровую... Есть основное правило гопников, когда они пытаются развести лоха — главное заставить лоха верить, что он виноват, возбудить в нем чуство вины, тогда он сам все отдаст... Когда начинаются такие разговоры — это значит — вас разводят, и неэффективность бизнеса и управления пытаются повесить на плечи программистов...
Здравствуйте, hrensgory, Вы писали:
H>накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы H>- (junior|middle|senior developer) | (team lead) случайно узрели там H>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>но точно проявится в production и это будет (не слишком серьёзно, но H>очень visible|очень серьёзно). Ваши действия?
Скажу — ну поздравляю, у Вас полная жопа — вот тут и тут...
Ну я пошел... мне пора идти на вторую работу, так как тут я зарплату не видел с июня...
Здравствуйте, hrensgory, Вы писали:
>> Программер же должен просто вовремя сообщать о надвигающихся проблемах.
H>Да, это наверное единственный хороший кейс для разработчиков:
H>накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы H>- (junior|middle|senior developer) | (team lead) случайно узрели там H>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>но точно проявится в production и это будет (не слишком серьёзно, но H>очень visible|очень серьёзно).
Довольно стандартная ситуация.
Переодически в нее попадаю.
H>Ваши действия?
Сначала иду к другому коллеге, с которым быстро обсуждаем проблему (мало ли, может я чего не так понял),
а потом идем к руководителю проекта. Сообщаем ему о проблеме и о том,
какие последствия это может иметь с нашей точки зрения, как технарей.
Далее PL обсуждает все это дело с PM, вовлекая все больших начальников, в зависимости от серьезности проблемы.
В итоге:
— либо принимается решение выпускать продукт, поместив в release notes, соответствующую запись
— либо сдвигается сроки...
В общем неприятно, но ничего страшного, если не гнать панику и не суетиться...
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Когда начинаются такие разговоры — это значит — вас разводят, и неэффективность бизнеса и управления пытаются повесить на плечи программистов...
Умение вовремя делать свою работу — это как раз важная штука для профи.
Другое дело, что на интервью про это действительно можно только навешать лапшу на уши.
Проверяется это только в деле...
B>Умение вовремя делать свою работу — это как раз важная штука для профи.
Это не вопрос эффективности отдельного программиста, а вопрос его проф. подготовности.
Да и опять же оценивать подобный скил можно только при условии профессионального и отвественного PM. В любой
компании всегда идет торговля между R&D и S&M (Sales & Marketing). S&M всегда для бизнеса "нужно вчера", "побыстрее" — их задача побыстрее продать, получить свой процент и двигаться дальше... И втакой ситуации если PM "слабый" и не может отстоять человеко-затраты подчиненных на ту или иную работу — то будут постоянно срывы сроков и овралы. Для ПМ, как и для программиста одним из важных качеств является умение трезво и объективно оценивать объем работ, свои (чужие) силы и возможности и уже после этого нести за них ответственность. Очень важным вкладом в эффективность является знание ПМ своей команды, умение грамотно делегировать полномочия... Зачастую лучшие ПМы это не те, кто самые крутые перцы перцы в программировании, а люди умеющие наладить личностно-рабочий контакт с ведущими разработчиками (именно специалистами), не стесняющиеся сказать "ты более лучший специалист в этой области чем я, ты лучше знаешь людей, по этому я тебе поручаю вести это направление, а тебе вот это" и задача ПМ грамотно координировать эти направления, координировать ведущих разработчиков.
Опять же если говорить об эффективности, важным фактором является мотивация — своевременная и четкая выплата заработной платы — что бы человек сосредотачивался на работе, а не думал — где бы стрельнуть сигарет или как он сегодня будет домой добирваться — опять прыгать через турникеты в метро и прочее... Очень важно обеспечение комфортной работы программисту (под этим я понимаю не про монторы, компьтеры, кресла, кофе и другое — это все второстепенно, а четкое, без ошибочное планирование работы, отсутствие незапланированных перекелючений между задачами, четкое ТЗ или налаженный контакт между исполнителем и заказчиком, доведение до понимания конкретным исполнителем, что он делает в общей системе (а не использование в темную), к чему его работа приводит на текущий момент. Крайне важна в эффективности слаженность команд и налаженность рабочих связей между отделами. Должна быть коммандная работа. в общем нормальная работа). Если все это обеспечить, эффективность будет максимальной.
Если убрать хоть один из элементов, эффективность будет экспоненционально падать... И никаким увещиваниями, повышением нагрузки и прочим эффективность не повысить — можно только её понизить и никакие увещивания, угрозы уже не помогут...
Здравствуйте, hrensgory, Вы писали:
H>Да, это наверное единственный хороший кейс для разработчиков:
H>накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы H>- (junior|middle|senior developer) | (team lead) случайно узрели там H>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>но точно проявится в production и это будет (не слишком серьёзно, но H>очень visible|очень серьёзно). Ваши действия?
Какие тут могут быть действия кроме как идти поднимать панику?
Но ни в коем случае об этом нельзя умолчать, даже если этот косяк твой
А вообще надо смотреть, точно ли оно проявится в production, при каких обстоятельствах, насколько они вероятны, что можно с этим сделать, можно ли какое-либо временное решение применить и если это действительно ошибка, то обязательно дополнить тесты, чтобы ловить этот вид ошибок. И только в зависимости от ответов на данные вопросы и от обстоятельств можно принять наиболее адекватное решение, либо забить временно, решить немедленно, применить временный фикс, отложить релиз, выпустить релиз, но после решить проблему в последующем патче, (не)предупредив кастомеров об ошибке, оторвать кому-то руки, сделать себе хараки... тьфу увлекся
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
H>>случайно узрели там H>>полный пэ, который вам [не]понятно почему не проявился на тестировании, H>>но точно проявится в production и это будет (не слишком серьёзно, но H>>очень visible|очень серьёзно). Ваши действия?
H>>- junior|middle
Показать синьеру или тимлиду проблемное место. Либо это неправильное понимание ситуации, либо раельная ж..а, которая эскалируется. H>>senior developer
Разобраться, насколько ж..а глубока, и показать тимлиду это место, с комментариями в каких случаях, по вашему мнению, это проявится, какие есть пути решения проблемы, и сколько они займут времени. H>> (team lead)
Аналогично синьеру разобратиься в серьезности и возможных способах и стоимости решения проблемы, и на пару с ПМ принять решение о дальнейших действиях, которые, надо сказать, зачастую зависят от политики компании а не от полноты ПЭ.
Y>Но ни в коем случае об этом нельзя умолчать, даже если этот косяк твой
+100!
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Vzhyk пишет: >> накануне релиза (QA и UAT успешно прошли), глядя в (свой|чужой) код, вы >> — (junior|middle|senior developer) | (team lead) случайно узрели там >> полный пэ, который вам [не]понятно почему не проявился на тестировании, >> но точно проявится в production и это будет (не слишком серьёзно, но >> очень visible|очень серьёзно). Ваши действия? > Во-во, мне именно твой ответ и хочется здесь увидеть. > > Мой ответ: зависит от ситуации.
Для _разработчика_ — нет, ответ не зависит от ситуации. Необходимо сразу
доложить об обнаруженной проблеме ближайшему из ответственных за релиз
(тимлиду или PM). При этом надо чётко осветить следующие вопросы:
— чем это грозит в production
— почему это не нашли тестировщики (если есть предположения почему)
— как это поправить, сколько времени займёт (если есть предположения как)
Все остальные действия — да, зависят от ситуации.
Чего не стоит делать:
— пытаться сначала исправить косяк, а потом уже докладывать т.к. время
дорого, а решение о судьбе релиза всё равно принимать не вам.
— в случае, если проект заказной, ставить в копию письма с изложением
проблем представителей заказчика. Это — зона ответственности вашего ПМ,
не стоит проявлять "ревность не по разуму"
Естественно всё это применимо только к компаниям с нормальным
менеджментом, где главное — результат а не "награждение непричастных и
наказание невиновных". Но есть ли смысл работать в других?
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>-Очень важно обеспечение комфортной работы программисту (под этим я понимаю не про монторы, компьтеры, кресла, кофе и другое — это все второстепенно, а четкое, без ошибочное планирование работы, отсутствие незапланированных перекелючений между задачами, четкое ТЗ или налаженный контакт между исполнителем и заказчиком, доведение до понимания конкретным исполнителем, что он делает в общей системе (а не использование в темную), к чему его работа приводит на текущий момент. Крайне важна в эффективности слаженность команд и налаженность рабочих связей между отделами.
Эх...
Хочу так работать, причем чтобы это было не на бумаге для аудиторов, а на самом деле
Но в принципе я с тобой согласен. Проблема только в том, что и в описанной тобой идеальной фирме
найдутся те, у которых все равно будут проблемы с мотивацией.
Ну например, они будут чувствовать себя винтиками в отлаженном механизме.
А кто-то как раз будет себя более комфортно чувствовать в хаосе,
потому что ему в кайф приводить хаос в порядок.
На интервью по идее и надо пытаться понять, подходит ли работник фирме,
будет ли работник себя чувствовать в ней комфортно...
Кандидату конечно же тоже стоит оценить фирму со своих позиций.
Здравствуйте, Uzumaki Naruto, Вы писали:
B>>Эх... B>>Хочу так работать, причем чтобы это было не на бумаге для аудиторов, а на самом деле
UN>Мне повезло проработать в такой обстановке 3 года, перед этим 5 лет мучались с никчемными ПМами, недавно команду раздербанили...
А почему раздербанили?
Кто-то решил, что не очень эффективны или бизнес не прибылен?
Направление деятельности было не очень прибыльное... Хотя я отчасти не прав — команда цела, немного изменились внешние условия, сменилось направление деятельности, команда влилась в более крупный коллектив, где наш ПМ и деректора пытаются уже привить то хорошее, что у нас было.
hrensgory пишет: > > > Естественно всё это применимо только к компаниям с нормальным > менеджментом, где главное — результат а не "награждение непричастных и > наказание невиновных". Но есть ли смысл работать в других?
Стоит почитать хотя бы этот форум, чтобы убедиться, что компаний у нас с
нормальным менеджментом исчезающе мало, а вот таких "награждение
непричастных и наказание невиновных" — большинство.
И если удалось выявить оную ненормальность еще на собеседовании — это
хорошо — и этому нам помогают "хрюшки".
Здравствуйте, Alf, Вы писали:
Alf>Как показала практика, все количественные показатели по-большому гамбургскому счету бесполезны. Alf>Ну может кроме статистики открытых на девелопера багов и особенно процент переоткрытия после фиксов. Alf>Этого на собеседовании никто даже под страхом смертной казни не скажет =)
Вообще, чем больше человек делает, тем больше ошибок.
Поэтому у программиста, отвечающего за большой кусок функциональности программы, будет больше открытых багов, чем у того, кто делает малую часть работы.
Здравствуйте, superman, Вы писали:
S>Здравствуйте, kotenkamyr, Вы писали:
K>>И как эти показатели можно выяснить у кандидата на собеседовании? S>Я специалист далеко не по собеседованиям но мне кажется что чёрта с два вы это оцените на собеседовании. Разве что на глаз за счёт "большого жизненнгог(HR-ского) опыта", умения "разбираться в людях" и "чувствовать шестым чувством и пятой точкой". Тестами вы этого не выявите точно. Получасовым разговором?... ну ИМХО очень мало вероятно.
K>>Подскажите пожалуйста, что у Вас на фирме подразумевают под такой терменологией: K>>система показателей эффективности работы K>>понимание числовых показателей результатов работы K>>ориентацию «на время» – умение работать в режиме дедлайн K>>понимание временных аспектов проектной работы
S>Вобще с формальной точки зрения у нас это делают так: Есть набор квалификационных требований к разним позициям изложенный в виде таблички. Например, грубо говоря, Джуниор должен уметь: S>1. Писать вменяемый код S>2. выполнять задания вовремя S>3. понимать чего от него хотят S>4. знать Х языков програмирования, технологий, буквосочетаний S>и тд
S>Мидл левел девелопер — должен кроме всего описанного выше: S>1. разбираться в архитектуре системы S>2. знать У патернов S>3. Уметь планировать своё время S>4. Уметь работать без присмотра или с минимальным присмотром S>5. Уметь спроэктировать и реализовать и интегрировать подсистему S>6. иметь знания експертного уровня в каких-то технологиях S>И тд
S>Сеньёр должен кроме вышеперечисленного S>1. Уметь спроэктировать и реализовать целую отдельную систему — подпроэкт S>2. разбить задачу на части, донести до младшего персонала, проконтролировать работу S>3. Уметь планировать время подчинённых S>4. Иметь знания експертного уровня в.... S>и тд.
S>Переодично проводится формальный ревью. Во время этого ревью каждый оценивает себя по этим пунктам согласно своей позиции. оценку ставит ДА-НЕТ-"НУ ТИПА ДА". То же самое делает его непосредственный начальник. Оба пишут коментарии, если надо. Потом происходит митинг с HR, оцениваемым, оценивающим и начальником департамента где эта оценка обсуждается.
S>Но есть один ньюанс. S>Делается это по результатом полугода-года совместной работы а не по результатам получасового интервью с HR. А как такое можно на интервью оценить с вменяемой долей точности, да ещё и в цифрах в большем диапазоне чем (могу, не могу) я не представляю.
Скажите, пожалуйста, что кроме всего перечисленного должен
Тeam lead
1.
2.
...
и Менеджер проекта?
1.
2.
Очень жду Вашего ответа, заранее спасибо.
Здравствуйте, kotenkamyr, Вы писали:
K>Скажите, пожалуйста, что кроме всего перечисленного должен K> Тeam lead и Менеджер проекта?
ТЛ и ПМ это по нашим понятиям примерно одно и то же самое, во всяком случае требования к ним похожи
Тимлид кроме вышеперечисленного должен уметь
1. Набросать общий дизайн сложной системы
2. Уметь оперделять технические риски и управлять ими
3. Иметь лидерские склонности
4. Иметь опыть Х лет на сеньёрской позиции, У успешных проэктов, знать вагон технологий,
5. Понимать принципы управления проэктом
6. уметь проводить интервью
ПМ по идее то же самое но с меньшим упором в техническую часть а большим в организационную. Хотя стоит сказать что многии конторы Сеньёров-програмёров ПМами называют.. точнее требования у них к ПМам где-то как к сеньёрам, не больше. тут всё зависит.
K>Очень жду Вашего ответа, заранее спасибо.
пожалуста, Вы только не забудте, что это я на пальцах и по-памяти.
ЗЫ: Ой чувствую стану я источником ругаемых на интервью вопросов
. Первые 5 месяцев можно не платить вообще, кандидату то все равно деваться некуда, а чтоб не потерять квалификацию пусть поработает бесплатно 
Но помойму случай слишком тяжелый и наврятли она хоть что-то поняла 
* thriving in a production environment *
