Найти в Дзене
Dmitry Nikitin

Как я оцениваю эффективность работы сотрудников

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

Если Вы руководитель отдела, вам хорошо известны проблемы оценки эффективности работы сотрудников по критериям производительности и качества, и ситуация осложняется тем, что:

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

Отсюда встают абсолютно справедливые вопросы о том, как же все-таки понять – эффективно ли работает сотрудник или нет, а 5 задач, что он сделал это много или мало, достаточно ли это быстро или недостаточно медленно, и в итоге насколько это все качественно.

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

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

Поэтому, я являюсь сторонником более простых решений оценки сотрудника, построенных на доверии и довольно простых операциях.

В моей команде разработки мы работаем по методологии Agile Scrum, с некоторым небольшими отличиями. Мы используем трекер задач Atlassian Jira, в котором мы ставим каждому разработчику задачу на выполнение. А каждую пятницу мы проводим, так называемый Planning Poker, на котором всей командой оцениваем среднее время на выполнение той или мной задачи (в часах). Время, к которому мы пришли, автоматически фиксируется как Плановое время выполнения в задаче Jira.

По мере работы над задачей, разработчик в конце дня или по результатам ее выполнения списывает затраченное время в специальное поле в Jira, что дает нам возможность построить отчет производительности, который сравнивает план/факт затраченного времени. Этот отчет, также на еженедельной основе автоматически приходит и самому разработчику, чтобы он понимал, где могло что-то пойти не так и самостоятельно вовремя среагировать на проблему.

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

Но достаточно ли этого для объективной оценки? Наверное, нет.

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

Это и создает проблему в понимании руководителем, все ли нормально с сотрудником.

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

Вся эта информация, дает дополнительное понимание руководителю о возможных проблемах с сотрудником.

Таким образом, мы получаем 3 метода оценки работы сотрудника:

  • Анализ производительности – отчет для сравнения План/Факт.
  • Анализ качества – кол-во ошибок, которые допускает разработчик по ходу выполнения задач.
  • Анализ коммуникаций и прочих проблем посредством опросов, взаимодействовавших с ним сотрудников.

Важно отметить, что итоговые результаты, получаемые по персоналу этими методами, не могут точно отражать картину и нуждаются в дополнительном анализе человеком, так как есть слишком много причин, когда что-то могло пойти не так 😌