Проскочила забавная мысль. Ведущий разработчик может специально валить хороших кандидатов, просто для того, чтобы не увеличивать себе конкуренции в фирме.
Если так вдуматься, то представим себе разленившегося ведущего разработка (я не имею в виду, что все такие, я имею в виду, что такие могут быть). Вероятнее всего с одной стороны он работает очень расслаблено (так как разленившийся), с другой стороны результатов у него все равно больше, чем у окружающей молодежи.
Соответственно найм другого серьезного разработчика, который прийдет на работу и которому надо будет себя показывать его может очень сильно «ударить» обухом. Получается, что новый разрабочик вполне таки через месяцов другой начнет выдавать больше результат, чем ведущий. И спрашивается, нафига ему будут такие раскладыва.
И что он может легко делать, валить потенциальных конкурентов еще того момента как они дойдут до серьезного собеседования, когда все люди с ними будут общаться. Например это можно делать в момент телефонного интервью или чего-нибудь такого.
Мысль странная, но уверен, что имеет вполне под собой реальные случаи 😉
Умный ведущий разработчик наоборот возьмет человека поопытнее, чтобы было у кого поучиться и с кем посоревноваться.
А глупый и ленивый может и валить всех, но велик ли шанс, что такой человек будет ведущим?
Глупный и ленивый человек становится не сразу. Причем достаточно заполучить одно из этих качеств, чтобы вполне валить все что выделяется.
Кстати, валить он скорее всего будет не всех, а только действительно толковых. А вот средних ему как раз выгодно набирать, чтобы серьезно выделяться на их фоне.
У меня был похожий случай на интервью (на 99% уверен), когда потенциальный начальник был явно менее компетентен, чем я, претендовавший тогда на роль тимлидера. В какой-то момент интервью в его глазах я просто прочел страх за свое кресло. Был уверен, что не возьмут, хотя подходил на позицию по всем параметрам. Собственно, так оно и получилось.
Именно- именно :))
Именно страх, именно животный и именно за свое теплое кресло 🙂
Видел подобные ситуации не меньше десятка раз. А особенно, если кандидат придерживается каких-то других методологий, чем интервьюер — тогда «заваливание» кандидата без сопротивления умного engineering manager-а становится делом техники.
Та да.
А особенно печально, что валение может проходить на той фазе, когда менеджер даже этого не видит
— отбор резюме
— телефонное интервью
Надеюсь это скорее отклонение, чем норма.
Мне сразу вспоминается один человек, но эта история скорее вариация на тему.
Он не сильно мешал появлению новых разработчиков, он выдавливал их по ходу.
Разработчик, которого я сам интервьюировал когда-то, быстро стал лидом, но как потом оказалось, на коллег, и особенно, где-то более компетентных, чем он сам, у него была весьма специфическая реакция.
В общении с коллегами и начальством роль в успехе проектов и авторитет других разработчиков часто сильно занижались или ставились им под сомнение, причём не явно, а как бы вскользь, и за их спинами тех, о ком шла речь, постоянно. Его же авторитет должен был быть непререкаемым, что всячески подчёркивалось в спорах.
Кончилось все плохо, два очень квалифицированных разработчика ушли не поняв, почему после удачного завершения большого проекта, который без них не был бы реализован , они получают мизерную зарплату испытательного периода, который пол года как прошёл, потом из под руководства этого человека ушли еще двое разработчиков, из тех кто его когда-то принимал, в том числе и я.
Когда у него в подчинении остался один безропотный сеньер и несколько новых человек, набранных уже при нем, которые вообще не разработчики, он сам ушёл в другую компанию с ростом.
Начальник убитого отдела, до сих пор считает, что потерял своего лучшего за все время разработчика.
Мне же искренне жаль его новых коллег.
Мдя.. Ситуация интересная.
Все же, такая ситуация более редкая. Нужно иметь крепкие нервы, чтобы «выживать» других людей из компании.
Тут у меня есть четкий метод измерения, кто прав, кто не прав.
Если человек ругает и хвалит одинаковое количество подчиненных, то это нормальная ситуация. Как только он начинает заваливаться в ситуации, когда он в белом, а все вокруг в говне… вероятнее всего, проблема таки в нем, а не в окружающих.
Кстати, подчиненные в таком случае должны иметь храбрости пойти к начальству и обсудить ситуацию. Опять же, если они были безмолвными, то естественно менеджер делал выводы по словам этого человека.
Это ненормальная ситуация. Есть центрование нормальных людей и прогибающиеся приспособленцы. Реальное значение для обычного специалиста не должно быть выше 1 к 2, иначе как-то странно распределили людей по командам.
Для техлида же (как человека обладающего минимальными лидерскими способностями) отношение не должно быть выше 1-2 людей на группу непосредственных подциннёных, иначе он не управляет, а борется с партизанами.
Извиняюсь, не совсем понял, отношение 1 к 2 чего к чему.
Да я был не прав, скорее я хотел сказать, что количество довольства и недовольства должно как-то уравновешиваться. Согласен, что пожалуй количество руганей и хвалений должно таки быть со сдвигом в сторону хвалений, но все же со сдвигом, а не с диким перекосом.
Сталкивался с такой ситуацией, но не среди разработчиков, а среди продавцов (с формулировками «А как же я его пинать буду?»).
Там это реально привело к полной остановке роста.
Да, в общем это применимо к любому отделу.
Валить при приеме на работу можно кого угодно, так как фактически нету метода оценки того, насколько хорош будет человек, кроме общения с этим человеком.
В больших организациях такие сутуации предотвращаются а) консолидированным решением о приеме на работе (делать предложение или нет); б) зависимостью карьерного роста начальника от роста его подчиненных. Это как один из вариантов 🙂
nik
p.s. Понятно, что это не панацея, на для больших организаций нужно что-то работающее в весьма разнообразных ситуациях.
Мне кажется, хорошо звучит на бумаге, плохо реализуемо в жизни.
Насчет консолидированных решений. Обычно это происходит уже после личного интервью. Обычно до этого есть несколько стадий, когда главный программист может отклонить кандидата, без чьего либо дополнительного мнения.
Насчет зависимости карьерного роста. В этом есть странная особенность (что в маленьких компаниях, что в больших).
Предположим есть младший программист, есть старший. Так вот старший не может назначить младшего старшим, так как для этого ему нужно освободить свое кресло. Тоже самое с старшим программистом и менеджером и т.п.
Как результат, чаще всего твой начальник это как и есть, то что останавливает тебя от роста. Так как его место и есть чаще всего следующая ступенька. То есть можно (и так чаще всего и происходит) надеяться, что он
а) Уйдет в другую компанию
б) Сам пойдет на повышение (но для него стоит та же проблема с его начальством)
Согласен с предыдущим постом. Не все так просто при приеме на работу. Обычно те, что нанимают на работу кадровики, во-первых заинтересованы, в том чтобы взять квалифицированного работника, во-вторых, они не нанимают скажем опять же работников отдела кадров, чтобы не было недобросовестной конкуренции. Конечно в жизни такие случаи бывают, сам наблюдал не раз недобросовестную конкуренцию такого рода, но в хороший фирмах при налаженном рабочем процессе, количество таких случаев безусловно ничтожно.
ok. Как организовать рабочий процесс так, чтобы никто не мог им воспользоваться в своих целях.
Проблема тут возникает, что либо нужно добавлять дублирование (просмотров резюме, общения с кандидатом по телефону). Это обычно не выгодно, так как первичный отбор кандидатов, достаточно ресурсоемкая работа.
А если дублирования нет, то в результата один человек занимающийся фильтровкой может влиять на исход кого будут приглашать на личное собеседование, а кого нет.
Насчет ничтожно — это спорный вопрос. Зачастую в фирме и не предполагают, что они происходит такая ситуация. Вон, чуть выше человек описывал похожую ситуацию, когда разработчика, который всех «выживал» считали самым ценным кадром.
«When I was CTO of a web design firm, I noticed in staff meetings that we only ever talked about process when we were avoiding talking about people. «We need a process to ensure that the client does not get half-finished design sketches» is code for «Greg fucked up.»»
http://many.corante.com/20030801.shtml
Может не нужен на этом месте рабочий процесс, а просто конкретную проблему с тем конкретным человеком решить?
Это не всегда возможно. Допустим, этот конкретный человек — shareholder? Или в компании есть приказ — не нанимать новых людей, даже если старые уйдут. Что тогда?
А как тогда процесс поможет?
Компания, где я работаю, недавно перешла из фазы 20 человек в фазу 70 человек. Так нашлись наивные коллеги, предлагавшие «под шумок» процессы в надежде через них повлиять на shareholder-ов. В результате процессы приняты, а shareholder-ы и их любимчики (я в том числе) их игнорируют.
Процесс нужен для того, чтобы не повторять ошибку много раз.
Потому, что сегодня Greg fucked up, завтра Peter fucked up, а после завтра еще кто-нибудь.
Так, что с одной стороны, если человек лажанул — то, конечно нужно говорить и о человеке. Но важно еще думать то, как организовать бизнес, чтобы такая фигня не происходила.
Все идеи о том, что правильные люди сами все правильно сделают — это полная фигня. Правильные люди, имеют абсолютно разное представление о том, что так правильно и вполне таки высылают, полу готовые скетчи.
Я всегда говорил, что 80% любого крупного промаха — это вина начальства, а не подчиненного. Подчиненный, что-то плохо делал, но он не один вообще работает в фирме. А вот если начальство не увидело и не поправило, то это полностью их вина, так как другого начальства, которое будет контролировать подчиненного нету.
«Процесс нужен для того, чтобы не повторять ошибку много раз»
Это-то понятно. Но является ли процесс единственной возможностью предотвратить ошибку?
Я почему интересуюсь. Процесс, он ведь не только ошибку предотвращает, но и инициативу тоже. Потому что «делаем только вот так». И только в самом лучшем случае «делаем только вот так, а чтобы по-другому, иди сначала поменяй процесс и добейся для этого buy-in у начальства и коллег».
У меня почему-то есть мнение, что а) иногда можно добиться того, чтобы разные люди имели одинаковое представление о том, что правильно, не вводя процесс и б) определенный процент ошибок, которые можно было бы предотвратить процессом, не только не повредит, но и поспособствует как конкретным людям, так и компании в целом. Знаешь, типа как прививка.
Что касается конкретной проблемы, то я могу наблюдать на работе, что у начальника одного нашего филиала упорно не появляются программисты, лучше чем он сам (даже если измерять «лучшесть» по количеству лет опыта). Но ему-то чего бояться, он не только начальник, но и совладелец фирмы. Так что может тут дело не в рациональном расчете, а в чем-то, работающем на уровне подсознания. Ну, там, альфа-самцы и т.п. Но тогда и бороться с этим бесполезно, тем более формальными процессами. Нужно принять как фичу поведения индивидов в коллективах и двигаться дальше 🙂
Итак по пунктам
>Но является ли процесс единственной возможностью предотвратить ошибку?
Нет, не единственная возможность. Однако, достаточно эффективная возможность и возможность, которую можно накапливать вне голов людей.
> Процесс, он ведь не только ошибку предотвращает, но и инициативу тоже.
Это смотря как процессами пользоваться. Нож тоже может быть и для отрезания хлеба и орудием убийства. Но запрещать ножи или отказывать от них по этому поводу не стоит.
Плюс, фактически все методологии (терпеть не могу это слова, но оно тут подходит) по настройки процессов указывают две вещи
а) Нужно настроить процессы
б) Нужно постоянно их улудшать
Как раз пункт б) придуман для того, чтобы не застрять с идиотскими процессами.
>иногда можно добиться того, чтобы разные люди имели одинаковое >представление о том, что правильно, не вводя процесс и
Как? Особенно важно, как это сделать на больших объемах людей, еще не дай бог рассредоточенных в пространстве (разные офисы) и времени (один ушел из фирмы, другой нанялся).
>б) определенный процент ошибок, которые можно было бы предотвратить >процессом, не только не повредит, но и поспособствует как конкретным >людям, так и компании в целом.
Я писал о ошибках. Да, ошибки важная и хорошая вещь и пытаться их исключить вообще — нельзя (да и не получиться). Однако, они хороши, до тех пор пока она не происходит три раза. Если проект заваливается по одной и той же причине в трех разных отделах — это уже не прививка, это уже болезнь.
>начальника одного нашего филиала упорно не появляются программисты, >лучше чем он сам (даже если измерять “лучшесть” по количеству лет опыта).
Никто не говорит, что всех надо выровнять по линейке. Если у начальника филиала сейчас 40 лет опыта в IT (так как он приехал с штатов и участвовал еще в разработке первого Крея), то ясно что он никогда не наймет человека с большим, чем он опытом.
Вопрос состоит в том, где провести линию между фичей и проблемой. Если процессов нет, то проводится линия каждый раз как бог на душу положит.
Положительность процесса в том, что появляются измеряемые входные данные и измеряемые выходные данные и можно измерять эффективность.
Отсутствие процесса — это попытка измерять эффективность не имея не входных, не выходных данных.
Кстати, следующую статью об этом напишу. Плюс, я к этому подбирался уже в одном месте.
Процес не обязательно выглядит как лыжня, скорее как горнолыжная слаломная трасса — задаёт только ключевые точки.
Например, знаменитые контрольные списки в которые забивают самые распростронённые ошибки — они не указывают что делать, но помогают отсекать те самые распространённые ошибки. И немного управляют: «Я не знаю как ответить на этот вопрос. Может стоит переделать, чтобы ответ был?».
Да элементарно, процес предусматривает, что при внесения изменения в интерфейс компонента уже используемого другой группой, необходимо встретиться с ними (группой) за обедом и об этом рассказать. Не надо указывать процессов коммитетного решения и ты пы. Другой группе об этом рассказанно — потери знаний не будет. Рассказанно за обедом — у обеих сторон есть возможность обсудить вопрос в расслабленной обстановке без начальника. Не сумели в такой ситуации договорится — надо разбиратся с тимлидами.
У нас перед началом разработки релиза в чеклисте всегда отмечается, если есть:
— изменения shared компонентов и модулей
— изменения структуры БД
— изменения структуры SalesForce (мы её используем в хвост и гриву)
Если есть хоть один «да», начинаются прыжки с бубном.
И, конечно же, менеджер продукта координирует изменения со всеми группами. Это долго и не всегда радостно, т.к. вещи, которые нужны одной группе, будут сделаны другой только через 3-4 месяца, но лучше так, чем работа вразнобой.
[…] например, в IT индустрии ведущий разработчик может специально валить хороших кандидатов, чтобы не плодить конкуренцию. Я неоднократно был […]
[…] Browse other articles in Менеджмент, О большом и малом, Персонал, Эффективность categories. « Мысля о найме. […]
Как уже упоминалось, придерживаюсь мнения, что таким образом валить будет именно слабый руководитель. Обосную…
Сильному человеку нужно постоянно поддерживать себя в тонусе. Что для этого необходимо? Соревнование! С кем?
Поначалу хватает соревнования с самим собой на выполнение сложных задач, но в какой-то момент набирается ряд шаблонных решений, которые пытаешься применить ко всем задачам. Это прекращает профессиональный рост.
Когда сложные задачи заканчиваются, нетривиальные решения становятся тривиальными, вот тогда возникает необходимость в появлении некоего «соперника», человека, если технически не более грамотного, то умеющего находить новые, нестандартные решения, который все еще развивается.
Ну а далее спорный момент:
Слабый специалист решит, что текущего уровня вполне хватает, зп приличная, и так он сможет жить вечно, конкуренты ему не нужны. Будет валить сильного кандидата.
Сильный специалист для дальнейшего роста будет выбирать кандидата посильнее.
Решение? На собеседовании должен присутствовать еще один человек (видимо, менеджер на ступеньку выше), который заинтересован в более сильном работнике, но для которого непосредственной «опасности» кандидат не несет. На таком собеседовании может выявиться необходимость в поиске нового тимлида.
Кроме того, вы забываете еще про такой момент как разные психотипы. Один будет рваться вверх, не обязательно при этом совершенствуясь в профессиональном плане, другому этот карьерный рост до лампочки, его будет интересовать профессиональный рост, обучение по узкой специализации, решение интересных задач, смысла нет бояться такого сотрудника.
Да, я полностью согласен — такое поведение — это поведение слабого человека попавшего на высокий (слишком высокий) для него пост.
Проблема не всегда решается присутсвием кого-то на собеседование.
Во первых есть до собеседованья фаза отсеивания. Второе руководитель высшего эшелона, может быть недостаточно технически подкован, чтобы отделить реально отсеивание кандидатов от валения.
На самом деле проблема решается таким способом не особо то сложно. Редко встречаются случаи рабочих групп, где все участники группы друг от друга не зависят (в любом случае это очень плохая практика). Также редко встречаются случаи, когда кроме этого тимлида в группе никого нет.
Практика показала, что очень хорошим вариантом является собеседование, на котором присутствуют:
1. Представитель отдела кадров (если таковой имеется). Цель? Отслеживание психологических моментов, сколько человек продержится на этом месте, насколько велико будет его желание ппродвигаться по карьерной лестнице. Идеально присутствие психолога, но это великая роскошь для малого бизнеса.
2. Непосредственный руководитель потенциального работника.
3. Если это возможно руководитель этого самого непосредственного руководителя.
4. Все, чья работа каким либо образом зависит от этого потенциального работника.
Кроме того, желательно готовить приблизительный список вопросов. Или наши тимлиды настолько суровы, что для грамотного специалиста находу придумают мега-вопросы?
> Второе руководитель высшего эшелона, может быть недостаточно технически подкован, чтобы отделить реально отсеивание кандидатов от валения.
Если руководитель высшего эшелона присутствует на всех собеседованиях, то тут только слепой не заметит сильного напора на более сильного кандидата. Тут получится как раз наоборот, при одном списке вопросов, если будет особо сильный напор на мощного кандидата, то это как раз поднимет его оценку.
Предварительный отсев… да, тут уж проблему решить труднее, но опять же, думаю, возможно.
Все таки я бы сконцентрировался именно на проблеме предварительно отсева.
Проблема выбора хороших кандидатов, действительно решается групповым собеседование. Тогда одному человеку тяжело как завалить, так и вытянуть любого кандидата.
Но, вот, что делать с предварительным отсевом — ума не приложу. Единственное, что приходит в голову раскидывать предварительный отсев на несколько разных человек.
Однако это тоже не лучший выход. Все таки самый эффективный человек в предварительном отсеве именно team lead. И давать отсеивать кому-то из более молодых (по умениям) разработчикам не хорошо. Давать отсеивать менеджменту — тоже не дело.
Хорошо, давай сузим множество ситуаций до небольшого отдела 5-15 человек. Как правило в таких группах имеют место частые личные беседы (если этого нет, группа развалится сама собой).
1. Отсев по резюме.
Резюме рассылается/раздается всем зависимым участникам процесса (руководитель высшего звена не участвует). Каждый отмечает «за», «против», «воздержался». В первых двух случаях желательно с обоснованиями. В случае серьезного несоответствия вакансии необходимость в обосновании отпадает сама. После этого «самые отрицательные» отправляются в корзину сами собой, по остальным проводится эдакая 15-минутная дискуссия, после чего отсеивается еще половина. Ну а дальше уже смотрим в зависимости от правил. Если необходим минимум в 3-5 кандидатов, а после этих отсевов осталось 50, то выбираем просто лучших и отмеченных как «интересно было бы попробовать» (бывают и такие кандидаты, у которых резюме не очень, но создается ощущение, что у него большой потенциал).
2. Телефонные звонки.
В принципе можно проводить парные звонки, т.е. с каждым кандидатом кроме руководителя должен общаться еще как минимум 1 специалист. Отсев опять же идет только после обсуждения.
3. Отсев по резюме в условиях ОЧЕНЬ большого конкурса.
Ну тут просто отсеиваем неугодных (можно порциями раскидывать по всем зависимым сотрудинкам), не соответствующих вакансии. После этого отсева возвращаетмся к п.1.
Однако это все приходит к тому, что все это может работать только в случае, если руководитель уверен в себе, если нет, то он сделает все, чтобы не реализовать ни один из этих пунктов.
Все таки предварительный отсев — достаточно емкая процедура. Я бы сказал в начале находится 10 резюме, из них идут 3 телефонных разговора и их них одно личное интервью.
Получается, если мы даем делать интервью 3-4 человекам это нормально. Но вот если мы начнем рассылать резюме одно и тоже 3-4 человекам, то это начнем серьезно есть время.
Тут на самом деле все упирается именно в время. Сделать то можно все что угодно, хоть всей компанией оценивать резюме. Но решаю одну проблемы, мы выкапываем себе другую.
Насчет реализации пунктов. Собственно водворять таки вещи должно высшее менеджментсво. Ясно, что сам человек себе на голову такое не придумает (причем даже хороший team lead).
Говорил я тебе Витя прочитать законы Паркинсона, а ты так и не прочитал 😛
1. чиновник множит подчиненных, но не соперников;
2. чиновники работают друг для друга.
Чтобы освоить фактор 1, вообразим, что некий чиновник A жалуется на перегрузку. В данном случае неважно, кажется это ему или так оно и есть; заметим, однако, что ощущения A (истинные или мнимые) могут порождаться и упадком сил, неизбежным в среднем возрасте. Выхода у него три. Он может уйти; он может попросить себе в помощь чиновника B; он может попросить двух подчиненных, С и D. Как правило, А избирает третий путь. Уйдя, он утратил бы право на пенсию. Разделив работу с равным ему В, он рискует не попасть на место W, когда оно наконец освободится. Так что лучше иметь дело с двумя подчиненными. Они придадут ему весу, а он поделит работу между ними, причем только он один будет разбираться и в той, и в другой категории дел. Заметьте, что С и D практически неразлучны. Нельзя взять на службу одного С. Почему же? Потому что он разделил бы работу с А и стал бы равен ему, как отвергнутый В, и даже хуже, он метил бы на место А. Итак, подчиненных должно быть не меньше двух, чтобы каждый придерживал другого, боясь, как бы тот его не обскакал. Когда на перегрузку пожалуется С (а он пожалуется), А с его согласия посоветует начальству взять и ему двух помощников. Чтобы избежать внутренних трений, он посоветует взять двух и для J. Теперь, когда под его началом служат еще и Е, F, G, H, продвижение А по службе практически обеспечено.
А вот и не угадал 🙂 Я таки прочитал законы Паркинсона 🙂
Насчет разделении работы между подчиненных — так оно обычно и делается, чтобы не лезли наверх.
Но все таки, не всегда все в руках человека сколько и на какие позиции нанимается.
Вспомнилось:
«Не нанимайте 4-очников, а то они понанимают 3-ечников».
Хотя, фраза очень известная и популярная, но мне кажется не все так просто.
Во первых часто тяжело отличить отличника от хорошиста. Во вторых, никто не гарантирует, что отличник будет нанимать только отличников. А в третьих — бывают еще финансовые ограничения, которые не позволяют нанимать только отличников.
[…] Блог об IT бизнесе » Blog Archive » Мысля о найме. Послать ссылку на этот обзор другу по ICQ или E-Mail:Разместить у себя на ресурсе или в ЖЖ:На любом форуме в своем сообщении: Tags: Грамотное разделение пространства офиса Category: Awaria You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. Leave a Reply » Log in […]