Еще со школьных времен мы привязаны к различным системам оценок. Учителя оценивали наши знания по пятибалльной (или какой-либо другой) шкале, и если по какому-либо предмету мы получали неудовлетворительный балл, ситуацию нужно было срочно исправлять. Далее тенденция продолжилась в университете, но довольно часто система оценок никак не используется на рабочих местах. Люди просто работают, выполняют задания, а вечером уходят домой. Я бы хотел порассуждать на тему, нужны ли системы оценок на рабочих местах и как их лучше организовать.
Перейду сразу к примеру, а именно – работа такси. Хочу сравнить положительный опыт с отрицательным, а затем сделать определенные выводы на тему системы оценок. Закончу некоторыми мыслями на тему того, как можно применять систему оценок для оценки работы разработчика в компании.
Итак, начну с положительного опыта заказа такси. Когда я покидал Прагу, я заранее заказал такси до аэропорта через местный сервис на 6 часов утра. В 5:55, когда я выписывался из гостиницы, ко мне на ресепшене подошел солидного вида мужчина в костюме и в пальто, с аккуратной прической. Он задал мне лишь один вопрос: “Taxi?”. После моего положительного кивка он попросил меня проследовать за ним до автомобиля, стоящего прямо у выхода из гостиницы. Он довел меня до идеально чистого автомобиля, будто только что с мойки, и открыл мне дверь, приглашая внутрь. Затем сел сам, тихонько включил местное радио и спросил, не против ли я. К стилю вождения данного гражданина у меня претензий тоже не возникло. Когда мы доехали, он предложил мне несколько видов расчета на выбор: кроны, евро или банковская карта. Когда я заплатил за услугу, он снова открыл мне дверь и пожелал приятного полета. Вроде ничего особенного он и не сделал, но сервис оставил очень положительное впечатление.
Когда я прилетел в свой город, я получил в самолете купон на скидку в аэропортовом такси. Когда я подошел к точке заказа машин, мне озвучили цену с учетом скидки и попросили оставить им свой номер телефона. Цена меня устроила, и через минуту на мой номер пришло сообщение с информированием о том, что на мой заказ назначена такая-то машина с таким-то номером. А еще через минуту позвонил бот и уведомил, что машина подъехала к выходу из аэропорта и ждет меня. So far so good, как говорится. Я вышел и машины у выхода не обнаружил, поэтому пришлось чуть прогуляться. Я так и не понял, что водителю мешало подъехать прямо к выходу, ведь никаких препятствий для этого не было, благо наш аэропорт не пропускает через себя десятки тысяч пассажиров ежедневно. Автомобиль стоял чуть поодаль, метрах в 50 от выхода. Когда я подходил к нему, то с трудом разглядел номера из-за налипшей на них грязи. Впрочем, к грязи я особых претензий не испытываю, погода была довольно слякотная, и надраивать машину в такую погоду нет особого смысла. Мои внутренние претензии начались дальше. Когда я сел в автомобиль, водитель еще раз уточнил адрес, и мы тронулись. Сабвуфер и колонки находились сзади, а я сел как раз на заднее сиденье. Я узнал эту новость про саб сразу после того, как водитель включил музыку настолько громко, что у меня возникли дискомфортные ощущения в голове. Я промолчал, но спустя 10 минут мне все же стало слишком неприятно, поэтому я попросил его убавить громкость. Мне без разницы, включают ли водители музыку или камеди-радио или едут в полной тишине, но до боли в ушах громкая музыка меня не впечатлила. Стиль вождения данного водителя мне тоже не понравился – он все время стремился всех обогнать, и часто выезжал на встречку ради очередного обгона. Это был один из тех немногих случаев, когда я просто был рад тому, что доехал до дома.
Так вот, при чем же тут система оценок. В пражском такси можно было дать оценку водителю. В нашем местном – нет. Водитель видел меня в первый и последний раз в жизни, и после окончания поездки я никак не мог повлиять на его дела. Если наш аэропорт введет подобную систему оценок, то со многими водителями можно было бы провести воспитательные беседы по итогам поездок. Думаю, многие замечали, что если использовать популярные сервисы такси уровня Gett, Uber или Яндекс, то водители все чаще подходят к своей работе более профессионально и клиентоориентированно. И все потому, что водители беспокоятся о своем рейтинге, это и дает им мотивацию сделать все для комфортной поездки пассажира.
Но с оценкой работы разработчика (впрочем, и любой другой позиции тоже) все несколько сложнее. Разработчик не может быть оценен по результатам выполнения одной конкретной задачи или по результатам спринта. На мой взгляд, оценка разработчика – это комплексная величина, построенная на относительно длинном промежутке времени. Лично я считаю, что отличный вариант оценки разработчика – это ежеквартальные оценки. Я увидел этот метод в одной из компаний, в которых работал, и состоит он в следующем:
- Разработчик пишет о себе краткое резюме, где описывает свои достижения и, возможно, неудачи за прошедший квартал.
- Оценивает себя по ряду метрик по пятибалльной шкале:
- Качество выполнения задач. Имеется в виду, как часто задачи отправлялись на доработку командой QA после их выполнения разработчиком.
- Скорость выполнения задач или продуктивность.
- Легкость в коммуникации с коллегами.
- Корректность оценок задач, соответствие этой оценки реальному времени выполнения.
- Самообучение, как много времени уделялось этому.
- Обучение коллег, менторинг, участие в code-review.
- Решение проблем или Problem Solving.
- Способность разработчика погрузиться в задачу и докопаться до настоящей причины, а не довольствоваться поверхностным решением (костылем).
- Профессиональные навыки.
- Возможны другие критерии.
- Коллеги оценивают разработчика по аналогичным критериям и тоже пишут о нем краткое резюме.
Ответственное лицо или группа лиц обрабатывают результаты и создают комплексную оценку работы разработчика.
В общем, данный метод известен как QPF или Quality Performance Feedback, возможно у него есть еще несколько названий. Потенциально узкие места, конечно, тоже присутствуют:
- Субъективность оценок каждого ревьюера + субъективность резюмирующего.
- Есть проекты, где работают 1-2 человека. В таком случае приходится притягивать все за уши, дабы соответствовать процессам. Вас может оценить человек, с которым вы никогда не работали, и эта оценка будет взята с потолка.
- На многие вопросы зачастую тяжело ответить. Например, самообучение – моим коллегам может быть неизвестно, сколько времени я этому уделяю.
Но в целом я считаю, что при грамотной реализации QPF поможет создать более-менее адекватную профессиональную картину разработчика. Само собой, этот процесс не заменяет человеческого общения: после выставления комплексной оценки, руководитель отдела (или другой человек, резюмирующий все отзывы о разработчике) должен поговорить с самим разработчиком и его тим-лидом. Общение с глазу на глаз поможет лучше понять позиции сторон и частично отсеять субъективные оценки.
В завершение скажу, что еще один замечательный метод оценки и улучшения профессиональных навыков разработчика одновременно – это code-review. Этот процесс должен на обязательных правах присутствовать в любой компании. Причем разработчик должен как и сам отдавать свой код на ревью, так и сам просматривать пулл реквесты по его проекту.
В целом я даже считаю, что code-review гораздо более важны, чем временами абстрактные QPF. Но стоит отметить, что довольно часто QPF вносит что-то вроде элемента геймификации, когда сотрудники компании стремятся стать более профессиональными и получить более высокие оценки. Хотя, конечно, стремление к становлению профессионалом высокого уровня никак не должно зависеть от наличия или отсутствия грядущего выставления оценок, но, тем не менее, такой момент может присутствовать.
Резюмируя пост, выскажу свое мнение – часто мы нуждаемся в системе оценок для того, чтобы улучшить качество предоставляемых услуг. Но везде должна быть своя система оценок. Допустим, поездку в такси довольно просто оценить по пятибалльной шкале, в то время как работа разработчика, менеджера проекта, тестировщика или аналитика требует более комплексной оценки.
Автор: tmn4jq
