Нужна ли нам система оценок?
Еще со школьных времен мы привязаны к различным системам оценок. Учителя оценивали наши знания по пятибалльной (или какой-либо другой) шкале, и если по какому-либо предмету мы получали неудовлетворительный балл, ситуацию нужно было срочно исправлять. Далее тенденция продолжилась в университете, но довольно часто система оценок никак не используется на рабочих местах. Люди просто работают, выполняют задания, а вечером уходят домой. Я бы хотел порассуждать на тему, нужны ли системы оценок на рабочих местах и как их лучше организовать.
Перейду сразу к примеру, а именно — работа такси. Хочу сравнить положительный опыт с отрицательным, а затем сделать определенные выводы на тему системы оценок. Закончу некоторыми мыслями на тему того, как можно применять систему оценок для оценки работы разработчика в компании.
Итак, начну с положительного опыта заказа такси. Когда я покидал Прагу, я заранее заказал такси до аэропорта через местный сервис на 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 вносит что-то вроде элемента геймификации, когда сотрудники компании стремятся стать более профессиональными и получить более высокие оценки. Хотя, конечно, стремление к становлению профессионалом высокого уровня никак не должно зависеть от наличия или отсутствия грядущего выставления оценок, но, тем не менее, такой момент может присутствовать.
Резюмируя пост, выскажу свое мнение — часто мы нуждаемся в системе оценок для того, чтобы улучшить качество предоставляемых услуг. Но везде должна быть своя система оценок. Допустим, поездку в такси довольно просто оценить по пятибалльной шкале, в то время как работа разработчика, менеджера проекта, тестировщика или аналитика требует более комплексной оценки.
Комментарии (25)
Suvitruf
15 января 2017 в 17:37
+5↑
↓
Проходили, знаем. Все эти системы оценок/рейтинги обладают большим недостатком — человек начинает работать не на результат, а на баллы. Создать систему подобную, чтоб подходила всем сотрудникам (ведь личностные качества у всех разные, подход ко всем разный должен быть), довольно проблематично. Помнится, в том же MS в своё время была рейтинговая система, но они её пару лет назад отменили.
RouR
15 января 2017 в 21:45
0↑
↓
Вместо рейтинга, надо вводить стандарты качества и дискретную оценку — соответствует или нет.
В случае такси это может быть набор характеристик: соблюдение ПДД, пунктуальность, вежливость, чистота авто и водителя и т.п.
sleeply4cat
16 января 2017 в 00:02
0↑
↓
Тоже не очень показательно. Например, сейчас я пишу красивый код, тесты и javadoc’и для «ядра» проекта и переиспользуемых компонентов, изгоняя оттуда костыли других разработчиков, в то же время зачастую ляпая «на скорую руку» откровенный говнокод в тех местах, неправильная работа которых будет очевидна и легко исправится. Так что метрики качества кода у меня так себе, хех. Увы, у нас нет ресурсов на найм ещё двух меня, чтобы красиво было всё :(
Asphodeline
15 января 2017 в 18:56
0↑
↓
Если говорить о повышении мотивации программиста стать лучше, мне кажется, эффективнее единой оценки или рейтинга будет система достижений. Вообще для не топовых разработчиков (а им отдельная мотивация не нужна, они свой профессионализм итак повышают) приемы игрофикации должны сработать.
RPG18
15 января 2017 в 19:20
+2↑
↓
приемы игрофикации должны сработать.
На них квартиру не купишь, в Тайланд не слетать.
-
Asphodeline
15 января 2017 в 19:44
0↑
↓
Мотивация деньгами безусловно работает. Но не только она.
Merkat0r
15 января 2017 в 21:57
0↑
↓
только она, я, как и сказали выше, за *вау какой ты классный спец- молодцом* на канары не слетаю-
sleeply4cat
16 января 2017 в 00:12
+1↑
↓
А мне на данный момент нравится. Зп чуть выше средней по городу, зато проекты «с нуля», минимум мозгодавки (могу отчитываться только о прогрессе выполнения) и возможность лапать разные среднеинтересные железки. Вроде как и в карман такое не положишь, а приятно.
vvpoloskin
15 января 2017 в 22:23
0↑
↓
Работает обязательно денежная + какие-нибудь дополнительные плюшки. Считаете, что деньги можно заменить чем-то другим? Подойдите к руководству и скажите, мне больше денег не надо, поставьте мне лучше теннисный стол и сделайте ДМС. И семье с двумя детьми, и родителям-пенсионерам так объясните.15 января 2017 в 23:05
0↑
↓
Ну Генри Форд про мотивацию так сказал: Только два стимула заставляют работать людей: жажда заработной платы и боязнь ее потерять…-
RPG18
15 января 2017 в 23:33
0↑
↓
Естественно, есть еще: дмс со стоматологией; компенсация питания; компенсация занятий спорта; корпоративный иностранный язык; оплата курсов, книг, конференций. Профит понятен: поддерживаю здоровье; получаю полезные знания и навыки.
А какой профит от игрофикации?
MaximChistov
15 января 2017 в 19:01 (комментарий был изменён)
+1↑
↓
В примере с такси оценивать должен клиент, а клиента разработчик софта в общем случае не видит. Зачастую над одним проектом вообще немало разрабов сидит…15 января 2017 в 19:31 (комментарий был изменён)
+2↑
↓
Во всех случаях, что лично видел подобные системы, на выходе была знатная чушь, не имеющая ничего общего с реальным эффектом от работы человека. Два простых примера:— в проекте один-два разработчика. Например, не взаимозаменяемых, скажем база и frontend, для примера. Да, можно получить какие-то оценки — только они ничего не дают вообще, потому что не позволяют реально сравнить полезность людей, делающих разную работу. И не позволяют сравнить этих же людей с работающими в другом проекте.
— в проекте 30 разработчиков. Ровно такая же фигня, как в предыдущем случае, только добавляется еще больше разных ролей, скажем QA или devOps. И либо мы их не сравниваем друг с другом (а почему, собственно?), либо система оценок, подобная описанной тут, дает для разных ролей на выходе полную чепуху.
Нужно раз и навсегда для себя понять — все люди разные. Работая в коллективе на результат, они могут приносить пользу совершенно разными способами — один въедливо вникая в мелочи, а другой — давая волю своему полету фантазии, и придумывая нестандартные решения. Кроме того, бывают интраверты и экстраверты, и начиная их сравнивать по «легкости коммуникации с коллегами», мы сразу ставим первых в невыгодное положение. С чего бы это?
А также бывают работники начинающие и опытные (не считая очень опытных), сравнивать которых в плане самообучения и обучения других тоже не имеет никакого смысла.
tmn4jq
15 января 2017 в 20:37
0↑
↓
Именно поэтому я особо выделил личное общение менеджера по ресурсам/начальника отдела с оцениваемым разработчиком. QPF поможет собрать базовую картину о человеке, и она, конечно, может быть не совсем верной. Но эта картина может быть весьма полезна при подготовке к разговору.15 января 2017 в 21:07
+1↑
↓
При подготовке к какому разговору? :) Ну вот что вы реально собрались из своих оценок извлечь? Размер премии?Вообще, если у вас есть личное общение (что не всегда бывает по разным причинам) — то никакие формальные оценки вменяемому менеджеру как правило не нужны. А невменяемому ничего не поможет и так.
-
tmn4jq
15 января 2017 в 21:46 (комментарий был изменён)
0↑
↓
Еще раз:Само собой, этот процесс не заменяет человеческого общения: после выставления комплексной оценки, руководитель отдела (или другой человек, резюмирующий все отзывы о разработчике) должен поговорить с самим разработчиком и его тим-лидом. Общение с глазу на глаз поможет лучше понять позиции сторон и частично отсеять субъективные оценки.
Если менеджер вменяемый, то оценки, полученные данным конкретным разработчиком от его коллег, помогут выявить пункты, в которых разработчику необходимо подтянуться. Если 3 коллеги утверждают, что у меня проблемы с качеством кода, что большая часть моих задач возвращается на доработку, может мне стоит быть внимательнее к деталям? Или коллеги утверждают, что со мной сложно общаться — тогда менеджер, вероятно, захочет попробовать подойти ко мне с разных сторон, чтобы найти со мной общий язык и упросить коммуникации внутри команды? Разумеется, итогом разговора не должно быть что-то вроде «садись, пять, премию получишь» или «троечка, уважаемый, троечка, урежем зарплату». Итогом разговора должно быть понимание разработчика, где ему возможно стоит улучшить свои навыки, а также понимание для менеджера, что он может сделать ради улучшения жизни этого разработчика и как он может ему помочь.
Смысл QPF и оценок не в том, чтобы решить, давать кому-то премию или нет. Смысл в том, чтобы улучшить работоспособность всей команды.Так лучше? Если да, то дайте, пожалуйста знать, я поправлю в тексте поста. Возможно, просто не смог донести мысль о смысле этих оценок.
15 января 2017 в 21:54 (комментарий был изменён)
+1↑
↓
>оценки, полученные данным конкретным разработчиком от его коллег, помогут выявить пункты, в которых разработчику необходимо подтянуться.Не помогут. По очень простой причине — ну не измерите вы таким способом ничего путного. Нету у вас метрик для ваших показателей. Они что-то покажут только в крайних, и без того очевидных случаях, когда и так ясно, что у человека скажем проблемы с качеством. И даже в этом случае не покажут, что нужно делать, чтобы его повысить.
Я не хочу обобщать — это просто мой личный опыт. Но он, поверьте, достаточно обширный и в тоже время однозначный.
15 января 2017 в 22:00
0↑
↓
Чтобы улучшить работоспособность команды, нужна в первую очередь голова на плечах. У менеджера. И наличие воли и желания.А дальше уже все зависит от многого — например, бывают команды, где можно нанимать новых людей, и пытаться усиливать команду таким образом. Бывают такие, где это невозможно — и нужно получать максимум пользы от имеющихся. Но я никогда не видел, чтобы работоспособность команды повышалась путем внедрения формальных оценок для разработчиков (QA, аналитики и пр. — из этой же категории).
15 января 2017 в 23:13
0↑
↓
Почти в каждом месте, где работал, рано или поздно кому-нибудь приходила мысль внедрить или систему метрик, или систему оценок.Должен заметить, что ни одна система так и не прижилась, но что-то мне подсказывает что это ничего не изменит, и всегда будут находится люди, готовые попробовать еще раз.
napa3um
15 января 2017 в 19:34
0↑
↓
Автор смешал KPI (систему оценок для возможности оптимизировать бизнес-процессы, разработка которой, конечно, должна начинаться с проектирования этих самых оптимизирующих процессов, опирающихся на оценки, и из которых и вытекает размеренность оценки), и «школьно-мотивационные» (геймефикационные) оценки, которые существуют как бы сами по себе, сразу влияя на человека (но на самом деле тоже вытекают из сложной модели — модели мотивов и лояльности сотрудника). Вывод только один: если не знаете, как будете использовать оценки — даже не начинайте их выдумывать (скорее всего их бессистемное введение сделает только хуже). Лучше начинайте выдумывать оптимизирующие процессы, и на каком-то этапе проектирования этих процессов вам, возможно, уже и понадобятся оценки, чтобы параметризировать эти оптимизирующие процессы.15 января 2017 в 20:32
0↑
↓
А то мы мало на работе отчётов пишем, давайте добавим ещё один.-
tmn4jq
15 января 2017 в 20:33
0↑
↓
Это уже особенность конкретной компании. Я только отчитываюсь в Jira, к примеру, много времени не отнимает.
-
vvpoloskin
15 января 2017 в 22:37
0↑
↓
Для чего и для кого эти оценки? При адекватном начальнике руководитель, коллеги да и сам потенциальный аттестуемый и так знают, кто и как работает. Если мне кажется, что кто-то плохо выполняет свой функционал, я спокойно говорю руководителю об этом, и тот выдает директивное указание этому сотруднику (или мне=))Вот для сварщиков и слесарей разряды есть, наверно имело бы смысл внедрить что-то такое и для программистов и админов. Тут тебе и система мотивации, и оценка деятельности.
-
tmn4jq
16 января 2017 в 00:06
0↑
↓
Вот для сварщиков и слесарей разряды есть, наверно имело бы смысл внедрить что-то такое и для программистов
Градации junior, regular, senior. Пользуйтесь на здоровье.-
vvpoloskin
16 января 2017 в 00:19
0↑
↓
Это градации все на уровне одной организации, на усмотрение руководителей. Нет, вот если бы был инженер-программист ruby 4 разряда с четкими требованиями к квалификации. А для повышения разряда прописаны жесткие условия, в том числе, что человек должен знать и уметь, сколько опыта у него должно быть.
