Варианты анализа эффективности сотрудника

Руководители всё чаще встречаются с непростой проблемой из сферы IT: как правильно проанализировать эффективность работника. Где-то полвека назад она не становилась камнем преткновения для менеджеров или экономистов, т.к. предлагала предельно простое решение – если сотрудник выполнил 40 задач – это плохо, а если 120 – отлично! Однако со временем произошла революция в сфере IT, а с ней и ошибки из-за неправильной оценки эффективности.

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

Ошибка подобного анализа в том, что он не учитывает сложность задач. К примеру, одно задание можно выполнять пару недель, а второе – двадцать минут. «Может тогда поменять формулу оценки?» – спросит руководитель. Можно, конечно, умножать какой-либо разработанный коэффициент сложности на то, сколько написано кода. То есть чем сложнее код за краткий срок написан, тем сотрудник работает эффективнее.

Но и тут кроется ошибка – работник может делать три лёгких задания, одно тяжёлое и три средних. Согласно формулировке – это снижает его эффективность.

В итоге, реального показателя так и не выявлено. Притом проблема не во времени, которое ещё можно рассчитывать, а в количестве кода, размер которого никак не определяет эффективность.

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

Новые подходы

Мы привыкли рассматривать другие показатели эффективности, и хотя некоторые из них имеют субъективный характер, в большинстве своём они показывают отличные результаты.

Число ошибок

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

Сотрудник тем эффективнее, чем чаще он даёт компании полезную информацию

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

Что лучше: потреблять или генерировать идеи?

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

Абстрактное мышление – показатель высокой эффективности

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

Самомотивация важна для карьеры

Чаще всего работников можно разделить на два типа: перегоревших и жаждущих знаний. Первые хотят мало работать и много получать, они не ищут что-то новое, не развивают навыки. И их внутренняя усталость возникает не из-за количества работы, а из-за отсутствия интереса.

Жаждущие знания наоборот стремятся быстро закончить обучение, чтобы открыть для себя доступ к новым ресурсам и развивать свои навыки. Они всегда открыты для новых задач, рады пробовать что-то совершенно незнакомое, а значит, их не нужно постоянно дёргать и заставлять работать. Чаще всего, перегоревшие идут в большие компании, чтобы их вклад не был сильно заметен в то время, как жаждущие знания проявляют свои способности в стартапах, так как там легче найти то, что им нужно.

Скорость доработки кода – ещё один показатель эффективности

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

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