Карьера → Оценка эффективности сотрудника

На этот пост меня вдохновил блог Вредина и собственная ситуация на работе. А работал я в компании HitLine. Программистом, разработчиком проектов. Естесственно, у руководителя любой уважающей себя фирмы, рано или поздно возникнет вопрос: а что полезного делают сотрудники компании? У маркетологов Хитлайна возник тот же вопрос по отношению ко мне. Казалось бы, лёгкий такой вопросик. Но всё оказалось гораздо сложнее. А теперь давайте разберёмся:

Допустим, у нас есть абстрактный IT-работник, очень сильно смахивающий на программиста, который, вытирая пот со лба, без устали создаёт не менее абстрактный продукт в некой компании таких же абстрактных работников. Как оценить его работу, эффективность его труда и ценность работника для компании? Первое, что приходит на ум маркетологу, которому поручено заняться этим, это вывести вполне четкие и элементарные показатели труда. В данном случае, по его мнению, это время и количество кода. Чем больше кода создает работник, за определённый временной промежуток, тем этот работник ценнее и профессиональнее. Все это хорошо, но это не работает. Совсем не работает.


*****


А не работает это по одной простой причине: задачи бывают разные, сложность разная. Одно задание программист уже реализовывал ранее, ему легко её реализовать снова, нарыв исходники. Ещё даже время останется на навороты а-ля "спец-эффекты, фенечки и рюшечки". А над другой задачей надо попотеть: продумать алгоритм в голове, просчитать разные пути решения, набросать шаги и поэтапно выполнять и отлаживать. А потом ещё оттестить это дело на десятке друзей в аське и в конце концов вылить это на суд остальным юзерам.

Ага, подумает, маркетолог, значит нам надо внести изменения в формулу оценки. Надо, наверное, взять некий коэффициент сложности задачи и умножать количество написанного кода на этот коэффициент. Чем больше сложного кода за определённый временной промежуток пишет работник, тем он эффективнее. Формулировка отличная, только опять не работает. Можно за неделю сделать 4 простых сайта и заработать пицот денег. А можно 3 недели делать сложный сайт и заработать тысячу денег. Во втором случае уникального кода будет гораздо больше, а вот денег для фирмы сотрудник принесёт меньше. А бывает такое, что за исходную неделю сотрудник не делает сайты, а фиксит ошибки других сотрудников. В итоге получается что кода он за неделю вообще не написал, ну разве что переписал пару строчек чужого кода. Значит он плохой сотрудник?

В итоге толк от этих рассчетов будет нулевым. Проблема кроется в показателях. Если время, а точнее скорость работы, еще можно использовать как показатель, то количество кода — отнюдь нет. Это вообще не показатель эффективности. Это у копирайтеров чем больше букв тем больше денег.

Многие компании, на заре развития IT-индустрии, платили программистам за количество строк, которые они написали. Но программисты — народ не такой тупой как многие думают. Они быстро это дело прохавали и начали писать различного рода фигню, которая не влияла на результат работы кода, но добавляла этому самому коду очень много символов — лишних символов. Ведь чем их больше было, тем больше платили.


Так что же делать?

Получается — тупиковая ситуация. Фирма не может проконтролировать эффективность работы сотрудника.

Второе, что приходит в голову маркетологам — это контролировать время прихода на работу сотрудника и время его ухода. Ведь по правилам офисного планктона, все должны приходить на работу вовремя и уходить тоже вовремя. Но тут вновь палка о двух концах. Представьте ситуацию: поломалось что-то в без-пятнадцати шесть вечера, рабочий день к концу подходит. И сотрудник уходит домой, оставляя проект неработоспособным. Или, например, сотрудник внедряет в систему новые функции, работы осталось ещё на пару часов, но тут звенит "звонок" и он уходит, оставляя в паблике не до конца работоспособный модуль. И это ещё пол-беды: ведь завтра ему прийдётся с утра за чашкой кофе около часа вникать в то, на чём он остановился вчера и пытаться вспомнить всё то, что он задумал но не успел реализовать. В итоге он потратит ещё не 2 часа а больше четырёх, а для пользователей неработоспособность проекта в итоге составит больше 20 часов.

Лично для меня показатели эффективности работника совершенно другие. Некоторые из них носят субъективный характер, и я это не отрицаю, а многие лежат на совести работника. И в формулировке этих показателей мне помог ХабраХабр:


Меньше ошибок — более эффективный работник

Чем меньше ошибок допускает программист в коде, тем более качественный его труд. Качество кода легко превращается в удовольствие пользователей, которые могут выбрать ваш продукт именно за этот показатель. Второй плюс качественного кода заключается в минимизации затрат на поддержку, тестирование и прочее. Да, человек не идеален, но если он не протестировал самостоятельно результаты своего труда, а уже отрапортовал о завершении работы, то его лень приведет к целой цепочке неэффективных телодвижений в компании. За ошибки работников компания платит из собственного кармана, а это потом отражается на благосостоянии самих же работников.


Чем больше работник распространяет полезную информацию в коллективе, генерирует идеи и делится ими с другими работниками, тем он эффективнее и полезнее.

В команде разработчиков всегда должен происходить информационный обмен. Работники должны делиться между собой полезной информацией об удобных конструкциях кода или приемах, об удачной реализации какого-то функционала, о новых технологиях, о результатах своих исследований, о проблемах и их решениях… Если человек не генерирует информацию, он перестает быть эффективным работником, так как его знания не помогают другим. Это не касается новичков в команде, но даже новички могут создавать положительный информационный фон и вносить новые веяния в коллектив.


Генераторы идей много раз эффективнее потребителей идей.

Мастер-класс от Людвига Быстроновского в Британской Высшей Школе научил меня одной простой истине: идея может быть проста как трусы за руб-двадцать, она может родиться за секунду, но последствии перевернуть весь мир. Работники, которые могут самостоятельно генерировать идеи, на мой взгляд, самые ценные работники. Им не нужно писать детальных ТЗ, не нужно скрупулезно пояснять отличие одного подхода от другого, и почему стоит выбирать другой путь, а не тот, который они где-то прочитали. Эти работники придумают 10 способов решения нетривиальных задач, и найдут 10 причин, почему каждый из них не будет работать. Мало того, они придумают себе ещё 10 задач, а на пути их создания придумают к ним ещё по 10 усовершенствований! Они тащат за собой весь коллектив и не боятся трудностей. Потому что им интересно изобретать велосипеды, и ни в коем случае нельзя отбирать у них эту возможность. Нельзя их ограничивать и ставить в жесткие рамки. Иначе они "сдуются" и потеряют хватку или попросту начнут создавать идеи для других компаний.


Чем более абстрактное мышление, тем эффективнее работник

Чем более простыми абстракциями оперирует человек, тем проще задачи он может решать. Умение управлять сложными абстракциями приводит к потрясающему эффекту. Для такого человека перестает быть важным язык программирования, инструменты, подходы, алгоритмы. Любая, даже сложнейшая система, для него не будет представлять никакой сложности, потому что он умеет смотреть в корень, а не на ботву. Обычно, такие люди становятся архитекторами ПО, разрабатывают спецификации, занимаются аналитикой.


Эффективность работника прямо пропорциональна его самомотивации

Бывают два типа работников: «уставшие» и «агрессивные». «Уставшие» работники стремятся как можно меньше делать и как можно больше получать денег. Им не интересно ни развиваться, ни изучать что-то новое. Усталость их не от того, что на них взвалили много работы, или они неэффективно распределяли свое время, и приходилось перерабатывать. Их усталость от потери интереса или мотивации в работе.

«Агрессивные» наоборот, стараются как можно бытсрее пройти путь обучения, развития, становления, чтобы получить доступ к еще большему количеству ресурсов, чтобы развиваться, развиваться, развиваться. Они жадно впитывают знания, учатся, пробуют, делают ошибки, и над ними не нужно выстраивать пирамиду менеджеров, чтобы подстегивать к работе.
«Агрессивные» чаще всего вызывают недовольство у менеджеров и маркетологов, потому что у них есть свой мозг и своя точка зрения, что не всегда на руку мотивам управленцев.
«Уставшие» стараются найти работу в больших компаниях, где эффект от их работы не виден вообще. Именно таких называют офисным планктоном. «Агрессивные» находят себя в стартапах, маленьких компаниях, потому что там проще получать все, что им требуется. А требуются в первую очередь им зачастую не деньги а возможность творить.


Чем быстрее работники выполняют доработку кода, тем они эффективнее

Потому что они как минимум предусмотрели масштабируемость кода, реализовали на качественном уровне сам код, используя понятные конструкции и названия переменных, могут быстро читать «чужой» код, создали предсказуемую и понятную архитектуру, в которой легко делать отладку. Столь простая характеристика может рассказать о коде гораздо больше, чем количество строк в единицу времени.

Это далеко не все методы оценки, но они наиболее важны для отбора персонала и для оценки эффективности работы работников в компании.