Хороший руководитель знает о планируемом уходе своего сотрудника заранее. Отмечу, что у хорошего руководителя никогда не бывает не запланированных уходов сотрудников. Поэтому он даёт задание HR службе заранее и у него, к моменту ухода специалиста, уже есть несколько претендентов на освобождающееся место.
Рекомендация первая. Поддерживайте контакт со своими сотрудниками.
Как: Варианты разные. Регулярно проводить тимбилдинги внутри отдела (да именно так называет ИТ менеджер эту статью в бюджете, когда думает о походе в паб со своими сотрудниками (шутка, хотя...)). Вы ведь выбили деньги на такую статью бюджета? Тимбилдингом может быть неформальный выезд на шашлыки, велопрогулка, поход, прохождение квест-комнаты или игра в лазер-таг. Ключевое слово — регулярно. Обязательно надо периодически общаться с глазу на глаз с каждым сотрудником. Периодичность зависит от размера команды, но не реже чем раз в квартал. Во время этой встречи сначала узнайте у сотрудника о существующих проблемах и вопросах, и только потом дайте обратную связь и оценку его работы (про правило «бутерброда», я вам не буду напоминать).
Рекомендация вторая. Справедливая оценка труда.
Как: Подразумевается, во-первых, соблюдение ТК РФ (т.е. никаких оплат в конвертах и попыток надурить с начислениями). Во-вторых, чёткие и понятные должностные обязанности. ИТ-шники очень не любят, когда их постоянно заставляют делать не свойственную им работу. Разово допустимо привлечь к переезду офиса или генеральной уборке, но не более того. Регулярные испытания на самого сильного программиста приведут к уходу человека. В-третьих, если вы используете KPI, то не забывайте о том, чтобы они соответствовали SMART (конкретные, измеримые, достижимые, актуальные, ограниченные во времени). Также учтите, что системные администраторы, разработчики и ИТ аналитики очень не глупые люди. Они умеют хорошо считать, поэтому не надо играть в игры с такими людьми, пытаясь манипулировать цифрами и условиями, для подведения к невозможности достичь планируемых показателей. Эти люди сначала обидятся, а потом найдут место где их не обманывают (поверьте, такие места есть, даже в кризис!). Ещё — KPI не догма, то есть надо на регулярной основе делать анализ насколько они актуальны и соответствуют вашим нуждам и нуждам компании.
Рекомендация третья. Развитие и профессиональный рост.
Как: Без перспектив развития ваши люди разбегутся, даже если вы будете им платить хорошую зарплату. Точнее так — разбегутся профи, а останется шлак, готовый сидеть от звонка до звонка. Поэтому стоит задуматься о создании системы обучения персонала, если у вас её ещё нет. Если у вас грамотная служба HR в организации, то система обучения у вас должна уже быть. Но даже если она и есть, вам в любом случае придётся поработать. Необходимо продумать систему грейдирования. Это отражение уровней компетенции сотрудника. Примеры: инженер 2 категории — инженер 1 категории — ведущий инженер — главный инженер или junior developer — middle developer — senior developer — tech lead. Мало продумать грейды, вам надо продумать матрицу компетенций для каждого уровня (skills matrix). Это описание технологий, инструментов, качеств сотрудника и т.п., которые должны быть проявлены на данном уровне. Часто ещё применяют градацию проявления каждого качества (пример — читает со словарём до владеет в совершенстве). И это ещё не всё, надо продумать какие то бонусы, как материальные так и не материальные, которые будет получать сотрудник при переходе из грейда в грейд. Продумать процедуры оценки и формальные критерии. Составить для своих сотрудников PDP (персональный план развития). Продумать возможность выделения бюджетов под обучение своих сотрудников. Так же не стоит забывать, что надо постоянно им доверять всё более и более важные проекты. В общем, есть чем заняться.
Рекомендация четвёртая и последняя. Если люди подобраны правильно, они не нуждаются в мотивации. Всё, что нужно — это обеспечить отсутствие демотивирующих факторов © Джим Коллинз
P.S. Не забывайте про картинку в заголовке поста — просто не будьте м… и и не работайте с такими людьми. Прежде чем внедрять что-то новое в мотивации и оплате труда примерьте новшество на самого себя, поставьте себя на место вашего девелопера или системного администратора. Вам комфортно? Ваш доход не стал меньше? Вы можете достичь показателей, которые приведут вас к получению премии? И вас будут любить ваши сотрудники, и вы постигните дзэн и переродитесь в следующий жизни на какой-то другой планете, где этих(из книжки) нет вообще — в принципе.
Комментарии (100)
hmspns
05.09.2016 16:54+4P.S. Не забывайте про картинку в заголовке поста — просто не будьте м… и и не работайте с такими людьми.
Одна из немногих книг, которую я бросил, не дочитав. Сплошное нытьё автора и ничего дельного.
it_manager
05.09.2016 17:12+1Читать эту книгу, я тоже не советую. Вы абсолютно правы :-) Просто картинка была «в тему».
IvanCher
05.09.2016 17:20+9А еще вставьте куда-нибудь в текст, пожалуйста, про опен спейс :) Это реально напрягает. Или пусть их делают так, чтобы хоть какое-то было ощущение личного пространства.
pan_KOST
05.09.2016 18:00Я бы сам не отказался от вариантов сложения опен спейса и личного пространства ( но не как в клерки в фильмах и не индивидуальные кельи )
snuk182
05.09.2016 23:04-2У опенспейса есть преимущество — всех знаешь, кто чем занимается и у кого что болит. А то бывает такое, что узнаешь об изменении состава компании только на тимбилдингах раз в год.
Rivethead
05.09.2016 23:58+3Ну если например ПМ узнает о том кто чем занят только исходя из наблюдений в опенспейсе — гнать таких спецов надо. Для других эта информация тоже непонятно зачем нужна. Короче не довод ни разу.
Neikist
06.09.2016 07:15Опенспейс тот еще кошмар. У консалта постоянно телефоны звонят, постоянно какие то разговоры, по теме и нет, одновременно по 3 группы совещающихся пытающихся друг друга перекричать. Даже наушники не спасают.
IvanCher
06.09.2016 08:37+4Мне, как разработчику, совершено всё ровно на изменения состава компании. Есть люди, с которыми я пересекаюсь в рамках своих задач, а есть еще больше десятка, которые я даже не знаю чем занимаются и на какой должности. И все мы сидим в одной комнате.
И, по-моему, то, что Вы сказали, это и есть самое ужасное в опен спейсе — ты еще в добавок ко всему шуму знаешь у кого что болит… О ужас, зачем мне еще чужие проблемы знать ?!snuk182
06.09.2016 10:00Сейчас просто тенденция такая — ходить на работу за задачей и зарплатой. Работодатель тоже относится к сотруднику не как к человеку, а как к записи в базе данных. Всех всё устраивает. Место работы не воспринимается как коллектив, все равно
все каждый год разныев среднем сотрудник-аутсорсер на одном месте проводит около двух лет. И от социальной функции, которой как раз опенспейс и способствует, почти ничего и не осталось.IvanCher
06.09.2016 10:34+2Я так и думал, что кто-нибудь подобное начнет писать.
Ну вот я интраверт. Я хоть и люблю общаться и всё такое, но очень устаю от большого кол-ва людей на протяжении долгого времени. К работе я отношусь совершенно не так, как Вы описали.
Вы понимаете, что люди разные бывают. У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид… Понимаете, я не хочу близко общаться с некоторыми людьми. И не потому, что я не люблю их, а просто ну слишком у нас разные ценности. Зачем нас садить рядом и пытаться подружить? Мы так только врагами сможем стать. При том, что мы по работе вообще не пересекаемся.
На мой взгляд, намного лучше проводить тематические встречи, на которых будут сближаться сотрудники по интересам. Это намного продуктивнее и интереснее.snuk182
06.09.2016 10:59> Вы понимаете, что люди разные бывают. У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид…
Совершенно верно. Именно поэтому интровертам, таким как я (может даже и Вы), куда уместней краем уха послушать, о чем говорят представители того, с чем я добровольно никогда не пересекусь, и тем более не пойду на тематические встречи. Потому как быть слишком узким специалистом это хорошо для карьеры только пока есть на такую специализацию спрос, но мне даже в голову не придет задавать специфические для несмежной отрасли вопросы без соответствующего контекста, а откуда контексту взяться, если все пути для его проникновения закрыты?
Кстати о разных людях. Имел удовольствие работать в широко известной в узких кругах компании, где опенспейс это принцип (у нас — 80+ человек в одном помещении). Безусловно, там были вот эти все:
> У нас вот есть такие, кто любит понудеть, есть высоко патриотичные люди, есть низко технологичные люди, есть те, кто любит ООП, есть те, кто любит функциональщину, кто-то визжит в истерике, когда хвалят мак или айфон, кто-то ненавидит андроид…
Никто. Никогда. Ни с кем. Не конфликтовал.
ИМХО это уже совсем должно быть дно — лезть в ссоры из-за разногласий. Обычно таких людей отсекали еще на собеседованиях. Если же каким-то образом такой человек получил оффер, независимо от его уровня квалификации надолго он не задерживается, потому что сложные задания требуют командной работы, а с ним вся команда разбежится в течение месяца. Возможно Вам просто не везло с коллективом.IvanCher
06.09.2016 11:49+2Вы толи сам маркетолог, толи находитесь под их влиянием… Зачем Вы мне пытаетесь доказать, что опен спейс так хорош и помогает нам всем общаться друг с другом и сближаться? Причем… на работе(!) в рабочее время(!!).
Вот опен спейс представляяет из себя именно мешанину всего в одно — работа, личные беседы десятков людей, которые слышат зачем-то все, попытка всех сдружить, сблизить, плюс увеличить коммуникативность команды, плюс еще какая-нибудь неведомая хрень.
Мне, как сотруднику программисту тим-лиду, опен спейс создает массу неудобств в работе и в общении. Когда я хочу пошутить или пообщаться на личные темы, то мне не комфортно, потому что это слышат еще десятки непонятных людей. Когда я хочу поделиться прочитанным про новинки в ИТ, то опять опасаюсь это сделать, а то услышит какой-нибудь нудила, влезет в разговор и обломает всю нашу беседу. Когда я хочу сосредоточиться и решить сложную задачу, то кто-то рядом неожиданно хочет пошутить или поболтать.
Вообщем, дискуссия ни о чем. Вы пытаетесь навязать какую-то неведомую теоритическую мысль про опен спейс, в которую очевидно верите, или хотите верить.
Но я не могу её принять, потому что не хочу логически для себя обдумывать почему мне это должно нравится. Мне это просто не нравится и я себя чувствую в этом не комфортно.
Только не думайте, что я прям работаю и мучаюсь в этом. Я работаю за большие деньги, у меня интересные задачи, замечательный коллектив, отличный директор. Я работал в крупных компаниях, в прогрессивных командах и т.д. и т.п. Но если убрать опен спейс, то просто будет на 1 плюсик больше ко всему, а пока это минус.snuk182
06.09.2016 16:42Ваша точка зрения слишком субъективна и авторитарна. Доказательством тому служат непонятно откуда взятые выводы:
> на работе(!) в рабочее время(!!)
> Вы толи сам маркетолог, толи находитесь под их влиянием
Впрочем вам конечно же виднее. Я всего лишь старался объяснить, что не так страшен опенспейс, как о нем любят рассказывать, особенно те, кто в нем никогда не работал. Точно так же субъективно у меня после данной работы в опенспейсе остались только самые лучшие впечатления, не в последнюю очередь благодаря такой организации пространства.
MaxAkaAltmer
05.09.2016 18:21+3Когда вижу в вакансии слово «тимбилдинг» — становится тошно. Обычно вместо того, чтобы решить реальные проблемы (например заменить дырявые окна, или сделать вентеляцию в помещении, вонючий ленолеум заменить, монитор нормальный поставить, купить удобную клавиатуру и мышку) — начинается тимматьегобилдинг…
pan_KOST
05.09.2016 18:25А если все окна сделали, ремонт месяц назад закончили, все компы на уровне?
Razaz
05.09.2016 18:30+3Поднять зарплату или дать премию. Кому надо — сами сбилдядтся в баре/на шашлыках ;)
pan_KOST
05.09.2016 18:37Всем подряд одинаково тоже нельзя поднимать — иначе будут разговоры — «я же лучше, чем он работаю, а подняли нам одинаково».
А премию надо давать, как и писали выше, не потому, что так захотелось — а на основе заранее известных правил, которые всеми приняты
4orever
05.09.2016 20:27-5Вопрос зарплаты в любой компании сотрудниками обсуждаться не должен. Если ко мне приходит сотрудник и говорит, что у Пети зарплата выше, будет уволен Петя. Это прописывается в договоре.
qw1
05.09.2016 21:16+6Приходим к боссу и спрашиваем, почему у него зарплата выше. Босс сам себя увольняет :)
JekaMas
05.09.2016 21:32+5Простите, но разве договор может быть выше законов страны? Зарплату можно говорить всегда, как бы обратного не хотелось определенным руководителям.
0serg
05.09.2016 22:27-2Если Вы собираетесь воевать с руководством, а не сотрудничать с ним, то конечно.
Но я Вас уверяю что гораздо приятнее работать в компаниях где с руководством хочется сотрудничатьJekaMas
05.09.2016 23:24+4Гораздо приятнее работать в компаниях, где зарплата формируется прозрачно.
Поясню: грош цена руководству, если оно не в состоянии объяснить, почему Ивана повысили в должности и зарплате, или почему у двух разработчиков зарплаты отличаются на 20%.
Неподдельная радость работать там, где не надо выбирать, с кем «сотрудничать» и где сам понимаешь, что Вася крут и заслуженно получил свою надбавку.
И отвратительно работать там, где руководство боится собственных работников и старается их разобщить.qw1
05.09.2016 23:34+2Я думаю, в таких случаях руководство не старается разобщить работников, а банально сэкономить.
Например, одному разработчику не хватает денег на оплату кредита, он приходит к руководству — так и так, или повышайте, или пойду в другое место. Куда деваться, повышают. Но если всё в компании прозрачно, тут же прибежит толпа коллег, которые и не задумывались о повышении, и отказать им будет нельзя — почуствуют несправедливость.
0serg
06.09.2016 00:41Объяснить — можно. Только обиженные все равно будут. Даже в идеальном случае когда начальство назначает оценки абсолютно объективно.
Про разобщение вообще не понял. Как незнание зарплаты соседа разобщает коллектив? Вот обида на несправедливую зарплату запросто может коллектив разобщить. А незнание зарплаты-то как?JekaMas
06.09.2016 15:29+3Незнание зарплаты, кроме того, что это нарушение законов нашей страны, которые позволяют делиться этой информацией с кем угодно, делает самое главное — ставит работников в неравные условия с руководством. Руководство знает условия работы работников, а работники не знают всех условий работы.
В итоге получаем такое положение дел: каждый считает, что зарплата более-менее у всех одинаковая, а на деле у Коли, который клево говорит, но фигово работает, зарплата на 40% выше. Руководству же весьма удобно делать любые «непрозрачные» дела, пользуясь разобщенностью сотрудников. Да хоть откровенную дискриминацию по возрасту, полу, происхождению. Все думают, что на одной должности у всех доход более-менее одинаков, хотя на деле у одной категории работников доход может сильно отличаться, просто за «красивые глаза».
На мой взгляд, любые попытки врать про то, что разглашение зарплаты противозаконно — это грязный трюк и работодатель это чувствует, ведь как правило идет не объяснение в стиле «я, ваш руководитель, считаю, что это разобщит нас, как коллектив», а вранье про «разглашать свои зарплаты запрещено договором!».
Если побуждения руководства благородны и продиктованы заботой о коллективе, то зачем использовать подобные хитрые и нечистоплотные трюки?0serg
07.09.2016 01:33-3Работники всегда были, есть и будут в неравных условиях с руководством в отношении доступа к информации. Они разные задачи решают, им не надо знать многие вещи специфичные для руководителей (а руководству — не надо знать многие вещи специфичные для разработчиков). Есть и просто закрытые проекты где я, к примеру, и с другими девелоперами определенной информацией о новой разработке делиться до анонса этой разработки не имею права. Вы говорите здесь о бессмысленном анархизме: «незнание плохо потому что все должны знать все».
Возьмите свой пример и предположите что зарплата Коли станет известна. И что дальше? Руководство снизит зарплату Коле? Нет конечно, оно искренне считает что Коля ее заслуживает. И возникнет конфликт. Нафига? Плохие аспекты я здесь явно вижу, а положительных — ни одного. Разве нет?
Сотруднику, по большому счету, достаточно знать три простые вещи: собственную зарплату, то как она изменяется, и средний уровень по индустрии (сколько денег он получит если уйдет работать в другое место). ВСЁ. Эти три величины уже дают адекватное понимание своего положения в компании. Зачем знать во всех подробностях сколько получает сосед?
И где Вы видите вранье-то? Соглашение о неразглашении зарплаты — это договор и есть, самый натуральный, подписываемый на этапе заключения трудового соглашения. Там четко и понятно объясняется все правила игры. Причем этих правил там, как правило, много, и неразглашение зарплат — лишь одно из них. Я не знаю конечно с кем Вам приходилось иметь дело, но сомневаюсь что кто-то говорил именно что-то о «противозаконности» подобных действий, а не о банальном «нарушении заключенного ранее договора который Вы читали и подписывали».JekaMas
07.09.2016 10:36+2этот пункт договора не имеет законной силы. Думаю, каждый руководитель должен это знать.
Эта информация НЕ относится к перечню того, что указано в ФЗ о коммерческой тайне, кроме того ограничивает работника в законных правах, таких как право на обращение в суд, поскольку при иске о, например, взыскании зарплаты, величину этой самой зарплаты придется огласить третьим лицам, то есть нарушить договор.
Достаточно известный факт с легконаходимой судебной практикой по нему.
Касательно остального, то у такому работодателю просто не надо идти, коль он ставит свое величество выше законов. Тут стоит отсылка к обозначенной в статье книге.0serg
08.09.2016 09:32-2Кто спорит-то, простите, с тем что в РФ этот пункт не имеет законной силы (во многих других странах, что характерно — имеет)? Я говорю про то что это часть контракта. Не хотите его заключать — пожалуйста не заключайте. Идите к другому работодателю. Но обман-то работника где Вы в этом увидели или апелляцию работодателя к законодательству? Вы упорно апеллируете к букве закона специфичного для РФ (что вообще говоря сомнительный плюс) тогда как я пытаюсь обратить Ваше внимание на а) целесообразность и практическую пользу таких ограничений и б) то что сотрудник с ними заранее знакомится и добровольно дает на них свое согласие
JekaMas
08.09.2016 11:30Прикольная индульгенция для работодателей для подсовывания незаконных контрактов.
Собственно вопрос свелся к тому что важнее для каждого: выгода предприятия любой ценой и плевать на общие законы или все же подпись под незаконным контрактом никакой силы не имеет, поскольку контракт силы не имеет в силу своего противорения с законами.
На мой взгляд, если в контракте есть пункт о рабстве или согласии на опыты по превращению в человеческую многоножку, то подпись под ним ничего не значит. Если для кого-то значит, то выгода явно прощает все.
qw1
08.09.2016 11:38+1Тут вопрос не в запрете, а в том, какие санкции следуют за его нарушение, законны ли эти санкции.
Например, выше написано: «Если ко мне приходит сотрудник и говорит, что у Пети зарплата выше, будет уволен Петя». Если будет уволен на законных основаниях, со всеми причитающимися выплатами, то почему бы и нет. А если без выходного пособия, то такой договор — способ в любой момент не платить по желанию левой пятки.JekaMas
08.09.2016 12:38Ответ на вопрос «почему бы и нет» опять-таки лежит в ТК РФ, где есть очень точный перечень причин для увольнения.
На мой взгляд, обсуждаемый пункт при его наличии в договоре уже говорит, что работодатель оставляет место для маневра своей левой пятки и строит отношения работник-руководитель на обмане.qw1
08.09.2016 12:54Ответ на вопрос «почему бы и нет» опять-таки лежит в ТК РФ, где есть очень точный перечень причин для увольнения
Разве работодатель не может уволить людей по причине сокращения штатного расписания? Разумеется, с выплатой средней з/п за 3 месяца. Все хитрованы не хотят выполнять последний пункт, но если он выполнен, то что не так?JekaMas
08.09.2016 13:05Может, но после он не может нанять новых. Сокращение штатного расписания, так сокращение.
Есть пути обойти и это, конечно.
Проводят же тренинги для HR-директоров по темам «как уволить беременную сотрудницу или сотрудницу в декретном отпуске». Но все эти случаи прекрасно подходят к названию обозначенной в статье книги.qw1
08.09.2016 13:12-1Разве частота изменения бизнес-планов (и вместе с ним, штатного расписания) ограничена законом?
Хотел бы я такой ошейник на особо креативных менеджеров. А то прибегают с горящими глазами: срочно! всё бросаем и делаем новую идею. Через 3 дня — ну, сделал, принимай. А они — а, отстань, сейчас голова другим занята. Сами как-нибудь внедряйте…
JekaMas
08.09.2016 13:07Дабы не быть голословным про вранье:
вот выдержка из hh странички одной компании, где, как понятно по нашей с вами беседе, подобные хитрости в договоре — это нормально:
«Работа в соответствии с ТК РФ в стабильно развивающейся компании.»0serg
09.09.2016 08:57Если Вас интересуют юридические детали, то контракт там единый для всей компании (а компания, на минуточку, американская), оригинал его составляется на английском языке и в нём есть пункт о том что национальное законодательство (российское в данном случае) в случает расхождений с контрактом имеет приоритет. И таки да, ТК в компании соблюдается — в отличие от всех остальных российских компаний в которых мне (и моей жене) доводилось работать. В числе прочего я не знаю ни одного человека которого как либо карали бы за разглашение этой информации. Тем не менее о зп в компании говорить не принято в силу добровольного согласия на то сотрудников. Потому что компания блин нормальная. Я Вас читаю и такое впечатление складывается, что с нормальными компаниями Вы никогда не имели дело. Полное ощущение того что Вы видите в работодателе персонажа который спит и видит как бы Вас, эм, обмануть. А я вот пишу сейчас эти строки из Норвегии куда поехал на конференцию. Я здесь раньше никогда не был, мне интересно здесь побывать и я попросил остаться здесь на лишнюю пару дней за свой счет (компания оплачивает дорогу и мое пребывание в дни конференции, остальное оплачиваю я). И никаких проблем. Компания не обязана была мне этого разрешать в рамках всех Ваших ТК РФ, но мне без малейших возражений пошли навстречу. Нафига мне вот это дословное следование букве закона если я работаю в компании в которой отношения лучше чем это регламентирует законодательство? К примеру по ТК РФ я имею право на отгул только если отработал ранее выходной день и дата отгула определяется заранее на усмотрение работодателя. У нас это не так. Нужен отгул — просто берешь его. Без необходимости предварительной отработки (и в пределах 5 дней в год вообще без необходимости отработки). Даже в тот же день. Плохо себя чувствуешь — позвонил, предупредил, в пределах трех дней больничного не нужно. Рабочий график свободный хотя опять же ТК РФ подразумевает от сотрудника несколько иное поведение. Идея понятна? Компания идет навстречу сотрудникам, сотрудники идут навстречу компании. И получается действительно здорово. А Вы конечно можете искать свою идеальную контору где работодатель нагибает своих сотрудников по ТК РФ в рамках которого опоздание на 10 минут на работу есть достаточный повод для написания объяснительной, а неоднократное опоздание — достаточный повод для увольнения, а работники в ответ организуют итальянскую забастовку, но стоит ли?
JekaMas
09.09.2016 09:29+2Добровольное согласие, после которого Петю, рассказавшего о своей зарплате, уволят без оснований. Ну-ну.
0serg
09.09.2016 16:23-1По-моему Вам явно не везло с работодателями. Я работаю в компании где нет подобных практик. Правда похоже что и люди у нас работают другие, которые с начальством дружат, а не воюют.
Envek
05.09.2016 22:20Вот этого я никак не понимаю, почему так неистово стараются держать зарплату в секрете и всем говорят «никогда и никому не говори, сколько ты получаешь, это ай-яй-яй».
Razaz
06.09.2016 00:05+1Я за оклады, которые позволяют не думать о премии, а думать о проекте. Ну и общегодовой перфоманс бонус всей компании :)
terrier
05.09.2016 23:28+1Отмечу, что у хорошего руководителя никогда не бывает не запланированных уходов сотрудников. Поэтому он даёт задание HR службе заранее и у него, к моменту ухода специалиста, уже есть несколько претендентов на освобождающееся место.
Это как, простите? Под словосочетанием «несколько претендентов на освобождающееся место.» имеется в виду «есть несколько e-mail'ов человек, с которыми вроде бы можно поговорить на эту тему»? Или HR натурально при работающем сотруднике приглашает людей собеседоваться на его место и втирает им «Наш начальник считает, что через некоторое время у нас появится вакансия. Как вы отнесетесь к тому, чтобы через неопределенное время начать работать у нас? Только, пожалуйста, говорите шепотом и выходите через черный вход, вас никто не должен здесь видеть»it_manager
06.09.2016 00:07+1Возможно я не ясно выразился. У меня сейчас живой пример — один сотрудник при проведении квартального ревью предупредил, что он отработает в компании ещё год и уйдёт (так сложились обстоятельства). Он же сам участвует в собеседованиях с кандидатами на его должность. И это норма — предупреждать заранее о своём уходе, помогать в подборе и передавать свои знания преемнику. Так должно быть, если у компании нормальные отношения с сотрудниками. Если же у вас сотрудник пишет просто заявление и уходит через две недели или вообще уходит в отпуск с последующим увольнением, то значит надо что-то менять.
terrier
06.09.2016 01:07+4Это говорит об исключительной добродетельности сотрудника, а не о том какой у него хороший или плохой руководитель.
Тут две стороны медали: то, что сотрудники предупреждают заранее об уходе — это очень мило ( с их стороны ), но как только руководитель начнет считать про себя «Я такой хороший, меня все любят и об уходе предупредят за год» реальность жестоко разобьет его розовые очки. Случаи разные бывают — вот прямо сейчас гендиректор «Вымпелкома» уволился одним днем. И никого-то он об этом не предупреждал, мне кажется.it_manager
06.09.2016 10:07+1За 10 лет работы в качестве менеджера в ИТ, в разных компаниях и на разных уровнях, у меня не было ни одного такого случая и мои «розовые очки» пока целы :-) Может они из небьющегося стекла, а может мне просто везёт на хороших людей :-)
pan_KOST
06.09.2016 11:04-1Уже третья статья, читая обсуждения которой, подчёркиваешь не меньше, чем из самой статьи.
И несколько грустно видеть, как аудитория, которая была на мегамозге в лице менеджеров, управленцев и просто предпринимателей размывается
огромным числом специалистов со сформировавшимся взглядом и очень сложно рассматривающих любые управленческие вопросы. Особенно много таких среди молодых специалистов, у которых ещё много сил, времени и желания сделать мир лучше и твёрдо делящие мир на белое и чёрное.
Конечно, это несколько неправильно делить всех на слои, но взгляд на систему с точки зрения участника системы и управляющего системой всегда будет различный ( специалист- менеджер).
Лично я — сторонник сбалансированного, прозрачного и справедливого управления.У меня есть своя точка зрения и я буду её отстаивать, при этом оставаясь в готовности внести в неё изменения при наличии аргументов или информации, доказывающих, что я не прав в целом. И одновременно признаю, что существует множество других также правильных точек зрения — они просто ДРУГИЕ.
По KPI — как их не называй, они есть у всех. Но они могут быть разным — хорошими или плохими, простыми или сложными, но они всегда должны быть SMART.
А если о показателях в целом — всегда должно быть больше 3-4 показателей, оценивающих РАЗНОЕ и по разному ( т.е. смешение объективных и субъективных, статистических и экспертных и т.д. ).
НУ и не стоит забывать — что для каждой компании и цели, есть разные средства: не стоит забивать отбойным молотком один гвоздь, как и не стоит использовать лопату там, где нужен карьерный экскаватор.
it_manager
06.09.2016 11:06-3Хотя вру, очки розовые подразбились, после написания этой статьи ))) Карму кто-то слил. Даже плюсовать комментарии не могу теперь )))
ilfate
06.09.2016 13:00+3Я не удивлен. У меня сложилось впечатление, что вы не в IT работаете, а бюрократичной гос-конторе… которая может сколько угодно пилить какой-нить код, только IT от этого она не станет.
«Начну с того, что это нормально, когда человек уходит из компании через 3-4-5 лет работы» — Я бы начал с того что в IT нормально если разработчик меняет работу раз в год. Если он конечно не lead.
Самое главное, что некоторые идеи из статьи верны, но наверно вам надо было в начале написать, что эти советы только валидны только для компаний которые управляют более чем 200 разрабочиками. Для малых отделов и современных методик разработки они ну никак не пригодны.it_manager
06.09.2016 16:32Моё личное мнение — это не нормально, если разработчик меняет работу раз в год. Пример из личного опыта: 3 месяца уходит, чтобы новый девелопер прошёл процесс передачи знаний и влился в компанию, примерно через 4-6 месяцев он начинает выдавать улучшения в существующих системах и коде, а не просто делать рутинные задачи. Получается, что если такой девелопер уйдёт через год, то продуктивно он поработает максимум 8 месяцев, и надо снова начинать всю эту карусель. Если знать стоимость подбора нормального девелопера, так мало кто будет делать из более-менее серьёзных игроков, таких «попрыгунчиков» просто не берут в штат. Сколько угодно пилить код моему подразделению инхаус-разработки никак нельзя, они выдают новый функционал владельцам каждые 10 дней (скрам не даёт сильно расслабиться :-) )
ilfate
06.09.2016 16:53-4Может джуниор и вливается 3 месяца. Или человек который вообще не знаком с процессами в IT или работал раньше с другими языками. Но любой senior developer, который работал в смежной сфере адаптируется за 2 недели. А то и меньше. Но вы говорите про своих «серьезных игроков», не знаю какие именно вы имеете ввиду компании, но очевидно совершенно не те которые знаю я. А я знаком и с Российским с Европейским рынком IT. Так что еще раз бы вам советовал учитывать, что то что вы считаете за истину существует только в вашей песочнице, а других все по другому. Только тимбилдинг будет полезен возможно всем. (кроме отметившихся выше интровертов, которые могут просто на него не ходить).
it_manager
06.09.2016 17:46+2Я вам искренне завидую :-) Ваша категоричность в суждениях не особо к месту — не находите? Я везде указываю, что всё что пишу — моё личное мнение. Вы можете написать Свою статью, о Вашем опыте, когда адаптируются за две недели и меньше и опыте удержания сотрудников в компании. Мне, да и многим другим, это было бы очень интересно. Основная цель моей статьи — донести до начинающих менеджеров необходимость работать со своими сотрудниками, слышать их и быть лидерами команд, а не «боссами и начальниками». Мериться у кого опыт больше я не очень жажду, не красиво это и ни к чему. Все вроде взрослые люди.
qw1
07.09.2016 12:54Наоборот, джуниор вливается быстрее. Потому что к нему меньше ожиданий.
А чтобы писать «сеньорский» код, нужно знать не только язык, платформу и фреймворк, но и специфику предметной области и все вспомогательные классы/функции проекта.
Иначе будут вопросы:
— Почему ты этот метод заново написал, когда у нас уже есть метод для этого, причём у тебя только частный случай?
— Зачем ты вычисляешь это значение, когда оно у нас для скорости использования уже закешировано вон в той таблице?Razaz
07.09.2016 13:351. Если по вашей организации кода тяжело найти какой-то метод — вопрос не к сеньору ;) Нормальный кстати спросит как минимум.
2. Очень спорный тезис. Если оно закешировано -то это должно быть в описании задачи(обсуждении) и опять же — можно просто спросить.
Все сводится к коммуникациям и просто наввыку анализа чужого кода :)
pan_KOST
07.09.2016 13:55Я думаю, всё зависит от сложности проекта/продукта и длительности его истории.
В старом продукте с длинной историей — сотрудник хорошо, если через 6 месяцев сможет выйти на уровень своего предшественника.
А в случае типовых задач/проектов с длительностью 3-6 месяцев да, всё будет быстро.
PS. При наборе специалистов, я также, как и it_manager обращаю внимание на то, сколько человек работал на предыдущих местах работы. Если он каждый год меняет работу и это были не стартапы, то с высокой долей вероятности, я его не возьму — т.к. считаю, что реальная отдача сотрудника начинается примерно ко второму году его работы в компании.Razaz
07.09.2016 14:05Старый проект != плохая организация кода и куча технологических долгов.
Я смотрю на причины. Может попасться две шараги подряд — не работать же в них по два года ;)pan_KOST
07.09.2016 14:06Это то естественно — поэтому стандартный вопрос на собеседованиях — почему ушёл человек оттуда, а со своей стороны обязательно надо проверять — чем же те компании занимаются
qw1
07.09.2016 16:38+1Если по вашей организации кода тяжело найти какой-то метод — вопрос не к сеньору
MSDN отлично организован, но чтобы хорошо знать WinAPI, нужно прочитать хотя бы заголовки всех разделов, чтобы знать что в принципе есть, и какими способами что делается. И это документация, код читать подряд «от и до» тяжелее
Нормальный кстати спросит как минимум
Есть ли у вас в проекте ф-ция валидации e-mail?
Есть ли у вас в проекте ф-ция расчёта суммы контракта с учётом скидок клиента на его дисконт-карте?
Есть ли у вас…
qw1
07.09.2016 16:45+1Если оно закешировано -то это должно быть в описании задачи(обсуждении)
В тасках вы пишете требования или способ реализации с точностью до обращения к каждому кешу? Заодно и алгоритмы напишем, чтобы вдруг за N2 не стали делать, если есть способ N·logN
и опять же — можно просто спросить.
Нельзя, потому что заранее не предугадаешь что может быть где закешировано (только при наличии опыта в конкретно в этом проекте понимаешь, что это поле используется часто, поэтому неплохо бы считать отдельно). Или это превратиться в постоянные вопросы с 99%-м ответом «нет».Razaz
10.09.2016 01:09-1Валидация — поиск по Validate(or,es) + Email не? :) — найдет либо коммент либо сам валидатор…
При корректном именовании вполне реально найти. Ну на самый край спросить. В большинстве случаев это будет пачка стратегий или вариаций на тему.
С инструментами типа решарпер можно искать дубликаты достаточно быстро.
А чем плохо требование на алгоритмическую сложность? Это между прочим может быть критичное требование.
Кеш вообще то проговаривается, так как это может иметь огромное значение. Например нужен ли прогрев кеша, как будет использоваться кеширование, где будет кеш, стратегия инвалидации и тд.
При наличии опыта можно запускать инструмент для анализа производительности, смотреть hot paths и делать выводы.
У меня просто как раз пример лида перед глазами. Меньше чем за месяц разобрался в приличном по размерам codebase. Периодически спрашивает высокоуровневые вопросы или обсуждает варианты реализации. С джуниором года через 3 можно было бы что-то обсуждать так же. Хотя зависит от проекта, задач и качества кода. Я повидал ужасов и возможно при очень низком качестве кода джуниору будет проще с чистого листа, чем человеку, который будет осознавать весь тлен и тщетность бытия :)))
Пока не убедили в общем:)Razaz
10.09.2016 01:17WinApi кстати не совсем корректный пример. Таких codebase в большинстве проектов нет даже близко. Плюс на таких проектах команды занимаются изолированной частью проекта, соответственно их скоуп ограничен, а вопросы можно найти в доке, если вы документируете то что вы делаете и ваш проект структурирован так, что бы было понятно что и где искать, или спросить в слаке/групчате в скайпе :)
qw1
10.09.2016 15:37-1Это мои субъективные ощущения. Если у вас есть пример, спорить конечно бессмысленно.
Arslanbekov
Господи, неужели в IT компаниях еще не убивают за KPI? Зачем об этом вообще писать…
pan_KOST
KPI могут быть разными.
Если мерить количество строк кода, это бред, а не KPI.
Нормальны KPI разработчика ( команды) в обязательном порядке содержит взаимоотношения следующих параметров:
Параметров много. Но бизнесу разработчики не нужны, которые вечно делают идеальный мир. Бизнесу нужны качественные результаты, помогающие дальнейшему развитию компании и решающие конкретные «боли» клиентов.
Arslanbekov
Да ладно Вам, не несите чепухи.
Я бы посмотрел как ваши 4 показателя в реальной жизни снимаются. Это же смешно и не работало никогда.
pan_KOST
Спокойно и легко. Пример — любая крупная аутсорсинговая компания.
Но для этого необходимо поставить соответствующие процессы в компании, а не работать по бригадно-подрядному принципу в состоянии вечного хаоса.
Если же распределение задач происходит на утреннем митинге «Вася делает А, Ваня делает Б, а Коля тестирует их результат», то да, все метрики не нужны
По факту, все измерения очень легко сделать ( супер-упрощённо):
Если все данные заносить в соответсвующие системы или хотя бы Excel, то всё легко вычисляется
Arslanbekov
Удачи Вам! :)
pan_KOST
Спасибо
У каждого свой Путь
pan_KOST
Кстати,
Как минимум Team Foundation Server и, если я правильно помню, JIRA позволяют снимать все нужные данные
Razaz
Это все едет по швам при первом же хитром баге в стороннем софте, фреймворке, старой имплементации, ОС и тд.
Или если ваша задача зависит от предоставления данных/аналитики клиентом.
Или клиент вдруг захотел на красное, а круглое.
Или А зависит от Б, а Ваня заболел/сидит с ребенком и тд.
Такие процессы вообще редкость и я сталкиваюсь с негативным отношением к такой формализации процесса у тех же скандинавских компаний.
pan_KOST
Для каждого проекта можно применять удобный процесс и всё . А по поводу имплементации, ОС и т.д. — в чём именно всё падает? При разумно описанном процессе, всё ОК
Для этого и есть менеджеры, которые должны управлять рисками.
Это проблема менеджера продукта или проекта, чтобы доносить до команды нормальные требования
Скандинавские компании слишком суровы. Я, наоборот, в России сталкивался и сталкиваюсь с достаточным количеством компанией, у которых внутренние процессы отлично формализованы и они достаточно гибкие. В качестве примера ( не реклама) могу привести Яндекс, Лаборатория Касперского
Razaz
1. KPI метрики то как подбирать? MS вот отказался нафиг от этого.
2. Интересно посмотреть на управление риском — заболел ребенок и сижу дома с ним неделю.
3. Требования могут меняться заказчиком. Проблема не в донесении, а в перзистентности.
4. Ничего сурового. Наобород очень расслабленная стартап атмосфера у достаточно серьезных компаний. Я когда работу искал — первым делом говорили — мы не Российские компании, у нас неформальный процесс и готов ли я работать без лишней формализации. И работать в самом деле приятно.
pan_KOST
1. Не совсем понял вопрос. MS не отказался — он сказал — «вот вам инструменты для отчётов и делайте свои метрики сами», тот же Burndown может дать много полезного
2. А также, другого разработчика сбила машина, а девушка-тестер ушла в декрет. Управление хотя бы самое простое — заранее предусмотреть некоторую вероятность переброса другого человека на Вашу работу ( если проект большой, естественно). А если проект ОЧЕНЬ большой ( на 150-300 человек, то даже половина отдела может внезапно исчезнуть и на проекте это скажется не очень сильно)
3. Для этого и есть процесс подписания ТЗ заказчиком, а также актов работ и вообще построения взаимоотношений с заказчиком. Команду разработки такие вопросы вообще не должны волновать. Если менеджер продукта/проекта докупускает кардинальные изменения проекта в процессе — значит он плохой менеджер. А если заказчик продавливает изменения — то меняются и сроки проекта и его цена для заказчика.
4. Мне такие, к сожалению, не встречались. А вообще — это правильны подход — оградить от формализации всех специалистов. Это всё задача менеджеров. Ну и всё зависит от того, как работает компания и её размер.
С точки зрения здравого смысла — для меня компания со штатом 1000+ и слабо формализованная — это утопия и идеальный мир, которого не существует
Neikist
3. За два года ни разу не встречался проект на котором требования бы не менялись в самый неподходящий момент, бывало на такие изменения недели разработки уходят, хотя в первоначальной формулировке задача на пару дней была. И не помню ни одного случая когда это увеличило бы для заказчика стоимость проекта. Но это 1с-франчайзи, возможно за пределами 1с мир светлее.
Razaz
1. Может. Но только по нему определять эффективность не всегда корректно.
2. Есть нюанс. Такие проекты обычно бьются на маленькие команды по 6-8 человек. Если требуется какая-то специфичная специализация — тяжело просто взять и перекинуть кого-то.
3. Заказчики они такие… А менеджер может хоть ухотеться — поставят вопрос ребром и быстро на все согласится ;)
4. А зачем формализация в отделе разработки? :) Часть компании может быть формальной — разработка быть отдельной единицей. Плохо когда всю тысячу пытаются подогнать под один стандарт без учета специфики(начиная от дресскодов и заканчивая жестким крафиком).
qw1
Какие риски? «А» не набил свои KPI, потому что Ваня, от которого зависит часть работы, заболел.
И дальше 2 варианта — наказать «A», честно засчитав низкий KPI, либо сделать «дыру» — исключение в правилах, но тогда вечно будут отговорки: вот тогда сделали исключение, а у меня сейчас тоже проблемы, и мне сделайте.
bogolt
Степень участия в проекте это очень субьективный парметр. Ну если не считать его по числу коммитов в код. Вот Вася коммитит много, а Петя за чаем объясняет джуниорам разные полезные вещи. А Серега вроде и коммитит мало, и джунов троллит, зато поднимает дух всей команде, да еще и находит самые хитровывернутые баги.
Кто из них лучше а кто хуже?
Про количество багов туда же. В команде большинство багов общие. Во-первых код обычно проходит ревью у других разрабов, во-вторых баги часто сложные, когда совпала фаза луны, два недобага и недоработка конфигурации. На кого это повесим? Тут виноват и архитектор который придумал не идеальную схему изначально, и три исполнителя сразу же. Причем по отдельности каждый не винтоват, и ничего страного не сделал.
Соотвествие сроков работ. Ну тут сразу 99% получат жирный минус. Удобная штука.
pan_KOST
О степени участия — это человеко-часы( в любой проектной компании по другому и нельзя).
А об оценке — опять же, я и говорю -взаимосвязь показателей.. Да и оцениваться Вася и Петя должны по разному. Да и в целом, ещё раз повторю — это ОДИН из показателей, но не единственный
Количество багов — клиенту без разницы, кто виноват — ему нужен работающий продукт, решающий его проблемы. И это командный показатель.
По срокам — опять же, всё зависит от того, как считать.
Если в проекте на 1000 человеко-часов зафейлить 3 дня — так даже снимать никто ничего не будет.Это нормально и укладывается в риски.
А если в проекте на 40 человеко-часов зафейлить 3 дня — это разработчик где то не прав.
hexploy
Согласен с тем, что KPI — это хорошо, но он него не должна зависеть величина премии.
В противном случае, люди начинают работать не на проект, а на KPI. И из своего рабочего дня выбрасывают всё что в него не включено.
Помощь коллегам по команде? Помощь другим проектам? Ревью кода? И прочее прочее прочее.
Всего не учесть, а грамотный инженер *правильно* проэксплуатирует формулу.
И вроде бы показатели растут, а проект
в жзагибается.zenkz
По-моему KPI — это то, что демотивирует работников (особенно IT-шников). Т.к. чаще всего KPI — это не стимулирующий, а карательный инструмент. К тому же разжигающий конкуренцию и вражду в коллективе. Лучше уж просто премии выписывать за успешный выпуск продукта в срок/за окончание проекта и т.д. (Т.е. быть ориентированным на результат, а не на достижения сомнительных цифр, которые не принесут пользы ни работникам, ни бизнесу.
А предложенными вами KPI очень легко довести разработку до абсурда и имитации бурной деятельности. Вот примеры:
1. Количество выполненных требований. (Работники будут заносить в требования абсолютно всё. К тому же количество требований и их сложность — разные вещи, и можно выполнить 1 требование за период, но которое координально улучшает продукт, а можно 1000, но это просто будет перестановка кнопок местами.
2. Степень участия в проекте — не соответствует SMART. Этот показатель субъективен и его нельзя измерить.
3. Количество багов разработчика — Зависит от сложности задачи и работы отдела тестирования. Разработчики будут стараться спихнуть сложные задачи на других и отдать свою работу самому бездарному тестировщику, чтобы тот нашёл как можно меньше багов.
4. Соответствие соблюдения сроков работ, заявленным самим разработчиком — С момента внедрения этого требования оценки разработчиков вырастут в разы. Освободившееся время будет тратиться на KPI номер 3 из списка. В результате имеем продукт с вылизанным существующим функционалом, но огромное отставание по реализации новых фич.
pan_KOST
1 и 2 — взаимосвязанные. Трудоёмкость проекта на выходе — 100 часов. 10 требований по 1 часу и 1 требование на 90 часов.
3.Я имею ввиду баги после РЕЛИЗА, найденные клиентами. И команда одна — не тестеры отдельно, разработчики отдельно, а они вместе накосячили. Клиенту без разницы
4. А это уже вопрос к руководителю. производства отдельно и к менеджеру продукта отдельно
zenkz
Соглашусь про баги после выпуска продукта — вполне разумное измерение. (При условии, что баги не «разработчика», а «команды» (в первом коментарии было именно «разработчика»).
Степень участия проекта даже в изменённой интерпретации всё равно неизмерима. Если мерить только по задачам, то остаётся неучтёным менторинг и помощь коллегам, внедрение новых технологий и методов разработки в проект, организация процессов и т.д.
Вообще KPI — это для менеджеров. А для разработчиков — это лишнее. Тем более когда это отражается на зарплате.
Мне как разработчику важно получать стабильный доход, который не зависит от внешних факторов/настроения руководства/зафейлившего проект проектного менеджера и т.д.
Другое дело что приятно получить что-то по результатам своей работы раз в год/квартал или по окончанию проекта/выпуску билда. (Вот для этих целей можно и KPI использовать для создания видимости справедливости)
pan_KOST
Соглашусь, изначально я выбрал неправильную формулировку, под понятием разработчик понимая команду.
По поводу степени участия — а для этого есть и другие метрики и правила.
По стабильности дохода — я придерживаюсь «белых» принципов начисления:
1. Зарплату по закону нельзя уменьшать — всё согласно договору. И платиться она ежемесячно в полном объёме в соответствии с требованиями рынка.
2.Квартальная премия, которую надо заработать в размере хотя бы 1 оклада. И отсюда как раз и вытекают показатели качества, эффективности и т.д. Пример «с потолка» по распределению 100% премии: 30% — количество багов после релиза, 30% — целевые задачи ( та же помощь остальным, менторинг и т.д.), 30% — соблюдение внешнего SLA при багфиксе. 10% — за конкретные улучшения в проекте/процессе.
Итого — у сотрудника всегда есть хороший оклад и он может заработать больше, делая что то, чуть больше или чуть лучше в рамках своего рабочего времени.
it_manager
Убивают не за KPI, а за неадекватные KPI. У сотрудника должно быть понимание, что он получает некую «плюшку» за чёткий, достижимый и прозрачный показатель. Если премию дают или не дают в зависимости от настроения руководства, без всяких KPI/КПЭ/Целей/Вклада/Оценки, то вот за это можно начинать «убивать».
Arslanbekov
Я вам по секрету скажу. Если хороший разработчик увидит в вакансии аббревиатуру «KPI», то он (опять же, мы о хорошем разработчике) — в здравом рассудке закроет и никогда больше не обратится к вакансиям Вашей компании.
Не зря же хорошие компании пишут в вакансиях, что у них нет KPI ;)
pan_KOST
Я буду удивлён, если мне скажут, что в ТОП-100 компаниях не будет KPI для разработчиков ( если в компании более 80-100 человек )
В Enterprise — мире KPI есть всегда.
Если это стартап, то да, там может не быть этого
0serg
ALGN, более 4000 сотрудников (более 300 девелоперов), один из лидеров рынка. Лучшая фирма где я когда-либо работал.
KPI (в понимании по количеству багов и т.п.) нет.
И уходить скажем к kaspersky отсюда мне ну воообще не хочется. Именно из-за паршивого отношения к девелоперам, по слухам, сопровождающего «хорошо отлаженный бизнес-процесс» Касперского.
it_manager
Ммм… очень интересно. То есть вообще нет KPI у 300 девелоперов? Голый оклад? Вы что-то недоговариваете. Может назвали другими словами? Цели квартальные или бонусные баллы или ачивки или ещё как? А формулировки KPI они разные бывают, количество багов как раз пример плохого KPI (сугубое IMHO).
0serg
Там есть естественно Performance Evaluation по итогам года, постановка целей в начале года, список формальных критериев «что хорошо а что нет» с градациями позволяющими примерно оценить результат по соответствию ожиданиям, но сам процесс проходит в форме довольно неформального общения и только один раз в год. Т.е. KPI вообще говоря есть, но он совсем не такой как его описывает pan_KOST, если судить по комментариям.
it_manager
То есть KPI всё же есть. Я не вполне согласен с pan_KOST в формулировках и в статье также не упоминал о формальных и вредных KPI. В статье я указал, что они должны соответствовать SMART и не быть догмой. В этом случае они принесут пользу. К сожалению, во многих российских компаний их вводят в качестве «карающего меча», для среза надбавок или премий и они приносят один вред. Основной же их смысл — давать объективную оценку труда сотрудника и мотивировать его. Часто про это забывают, превращая их в инструмент демотивации.
qw1
Как я понял, речь не о формальных оценках, а о субъективных.
Например, руководитель может сказать по итогам года: Вася — молодец, потому что сделал А, Б, Ц (и это не все пункты из таск-трекера, которых можно набивать побольше, руководитель сам выбирает, что отметить, а что игнорировать), а Петя — вола пинал весь год (и опять это субъективно, по ощущениям оценщика).
Может, это и плохо, если с оценкой Петя не согласится и будет обижен, но это не KPI.
Razaz
Еще бы эти плюшки были осязаемыми и весомыми, а не абстрактной фигней :)
pan_KOST
Обычно это рассчитывается в виде премии )
Razaz
Обычно когда начинаешь впахивать на адекватный размер премии, ее начинают резать ;)
it_manager
Встречаются такие «хитрованы» среди работодателей. От таких надо просто уходить.
pan_KOST
Если схема премии непрозрачна, то вообще такой работодатель идёт лесом.
И если он режет премию без причин — то уходить надо ещё быстрее =)
Razaz
К сожалению обычная логика такова — раз может работать в таком режиме, то почему не работает так же за зарплату. И таких хитрованов — подавляющее большинство. Да и премии серьезные мало кто платит сейчас, не говоря уже о зарплате.
pan_KOST
Ищущий найдёт.
И опять же — смотря в какой сфере чем заниматься
Artem_Manaenko
Могу я поинтересоваться, а повышать сотрудников Вы предлагаете по каким критериям? Личным ощущениям?