Еще со школьных времен мы привязаны к различным системам оценок. Учителя оценивали наши знания по пятибалльной (или какой-либо другой) шкале, и если по какому-либо предмету мы получали неудовлетворительный балл, ситуацию нужно было срочно исправлять. Далее тенденция продолжилась в университете, но довольно часто система оценок никак не используется на рабочих местах. Люди просто работают, выполняют задания, а вечером уходят домой. Я бы хотел порассуждать на тему, нужны ли системы оценок на рабочих местах и как их лучше организовать.
Перейду сразу к примеру, а именно – работа такси. Хочу сравнить положительный опыт с отрицательным, а затем сделать определенные выводы на тему системы оценок. Закончу некоторыми мыслями на тему того, как можно применять систему оценок для оценки работы разработчика в компании.
Итак, начну с положительного опыта заказа такси. Когда я покидал Прагу, я заранее заказал такси до аэропорта через местный сервис на 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 вносит что-то вроде элемента геймификации, когда сотрудники компании стремятся стать более профессиональными и получить более высокие оценки. Хотя, конечно, стремление к становлению профессионалом высокого уровня никак не должно зависеть от наличия или отсутствия грядущего выставления оценок, но, тем не менее, такой момент может присутствовать.
Резюмируя пост, выскажу свое мнение – часто мы нуждаемся в системе оценок для того, чтобы улучшить качество предоставляемых услуг. Но везде должна быть своя система оценок. Допустим, поездку в такси довольно просто оценить по пятибалльной шкале, в то время как работа разработчика, менеджера проекта, тестировщика или аналитика требует более комплексной оценки.
Комментарии (38)
Asphodeline
15.01.2017 18:56Если говорить о повышении мотивации программиста стать лучше, мне кажется, эффективнее единой оценки или рейтинга будет система достижений. Вообще для не топовых разработчиков (а им отдельная мотивация не нужна, они свой профессионализм итак повышают) приемы игрофикации должны сработать.
RPG18
15.01.2017 19:20+4приемы игрофикации должны сработать.
На них квартиру не купишь, в Тайланд не слетать.
Asphodeline
15.01.2017 19:44+1Мотивация деньгами безусловно работает. Но не только она.
Merkat0r
15.01.2017 21:57только она, я, как и сказали выше, за *вау какой ты классный спец- молодцом* на канары не слетаю
sleeply4cat
16.01.2017 00:12+2А мне на данный момент нравится. Зп чуть выше средней по городу, зато проекты «с нуля», минимум мозгодавки (могу отчитываться только о прогрессе выполнения) и возможность лапать разные среднеинтересные железки. Вроде как и в карман такое не положишь, а приятно.
vvpoloskin
15.01.2017 22:23Работает обязательно денежная + какие-нибудь дополнительные плюшки. Считаете, что деньги можно заменить чем-то другим? Подойдите к руководству и скажите, мне больше денег не надо, поставьте мне лучше теннисный стол и сделайте ДМС. И семье с двумя детьми, и родителям-пенсионерам так объясните.
igorch96
15.01.2017 23:05+1Ну Генри Форд про мотивацию так сказал: Только два стимула заставляют работать людей: жажда заработной платы и боязнь ее потерять…
RPG18
15.01.2017 23:33Естественно, есть еще: дмс со стоматологией; компенсация питания; компенсация занятий спорта; корпоративный иностранный язык; оплата курсов, книг, конференций. Профит понятен: поддерживаю здоровье; получаю полезные знания и навыки.
А какой профит от игрофикации?
sumanai
16.01.2017 03:09Вот на меня она уже не работает. Хотя я не так много заработал, и денег особо у меня нет, но нужно мне ещё меньше. В итоге делаю очень мало, а мог бы зарабатывать в пять раз больше текущего.
MaximChistov
15.01.2017 19:01+3В примере с такси оценивать должен клиент, а клиента разработчик софта в общем случае не видит. Зачастую над одним проектом вообще немало разрабов сидит…
sshikov
15.01.2017 19:31+6Во всех случаях, что лично видел подобные системы, на выходе была знатная чушь, не имеющая ничего общего с реальным эффектом от работы человека. Два простых примера:
— в проекте один-два разработчика. Например, не взаимозаменяемых, скажем база и frontend, для примера. Да, можно получить какие-то оценки — только они ничего не дают вообще, потому что не позволяют реально сравнить полезность людей, делающих разную работу. И не позволяют сравнить этих же людей с работающими в другом проекте.
— в проекте 30 разработчиков. Ровно такая же фигня, как в предыдущем случае, только добавляется еще больше разных ролей, скажем QA или devOps. И либо мы их не сравниваем друг с другом (а почему, собственно?), либо система оценок, подобная описанной тут, дает для разных ролей на выходе полную чепуху.
Нужно раз и навсегда для себя понять — все люди разные. Работая в коллективе на результат, они могут приносить пользу совершенно разными способами — один въедливо вникая в мелочи, а другой — давая волю своему полету фантазии, и придумывая нестандартные решения. Кроме того, бывают интраверты и экстраверты, и начиная их сравнивать по «легкости коммуникации с коллегами», мы сразу ставим первых в невыгодное положение. С чего бы это?
А также бывают работники начинающие и опытные (не считая очень опытных), сравнивать которых в плане самообучения и обучения других тоже не имеет никакого смысла.
tmn4jq
15.01.2017 20:37-1Именно поэтому я особо выделил личное общение менеджера по ресурсам/начальника отдела с оцениваемым разработчиком. QPF поможет собрать базовую картину о человеке, и она, конечно, может быть не совсем верной. Но эта картина может быть весьма полезна при подготовке к разговору.
sshikov
15.01.2017 21:07+2При подготовке к какому разговору? :) Ну вот что вы реально собрались из своих оценок извлечь? Размер премии?
Вообще, если у вас есть личное общение (что не всегда бывает по разным причинам) — то никакие формальные оценки вменяемому менеджеру как правило не нужны. А невменяемому ничего не поможет и так.tmn4jq
15.01.2017 21:46-2Еще раз:
Само собой, этот процесс не заменяет человеческого общения: после выставления комплексной оценки, руководитель отдела (или другой человек, резюмирующий все отзывы о разработчике) должен поговорить с самим разработчиком и его тим-лидом. Общение с глазу на глаз поможет лучше понять позиции сторон и частично отсеять субъективные оценки.
Если менеджер вменяемый, то оценки, полученные данным конкретным разработчиком от его коллег, помогут выявить пункты, в которых разработчику необходимо подтянуться. Если 3 коллеги утверждают, что у меня проблемы с качеством кода, что большая часть моих задач возвращается на доработку, может мне стоит быть внимательнее к деталям? Или коллеги утверждают, что со мной сложно общаться – тогда менеджер, вероятно, захочет попробовать подойти ко мне с разных сторон, чтобы найти со мной общий язык и упросить коммуникации внутри команды? Разумеется, итогом разговора не должно быть что-то вроде «садись, пять, премию получишь» или «троечка, уважаемый, троечка, урежем зарплату». Итогом разговора должно быть понимание разработчика, где ему возможно стоит улучшить свои навыки, а также понимание для менеджера, что он может сделать ради улучшения жизни этого разработчика и как он может ему помочь.
Смысл QPF и оценок не в том, чтобы решить, давать кому-то премию или нет. Смысл в том, чтобы улучшить работоспособность всей команды.
Так лучше? Если да, то дайте, пожалуйста знать, я поправлю в тексте поста. Возможно, просто не смог донести мысль о смысле этих оценок.sshikov
15.01.2017 21:54+2>оценки, полученные данным конкретным разработчиком от его коллег, помогут выявить пункты, в которых разработчику необходимо подтянуться.
Не помогут. По очень простой причине — ну не измерите вы таким способом ничего путного. Нету у вас метрик для ваших показателей. Они что-то покажут только в крайних, и без того очевидных случаях, когда и так ясно, что у человека скажем проблемы с качеством. И даже в этом случае не покажут, что нужно делать, чтобы его повысить.
Я не хочу обобщать — это просто мой личный опыт. Но он, поверьте, достаточно обширный и в тоже время однозначный.sshikov
15.01.2017 22:00+1Чтобы улучшить работоспособность команды, нужна в первую очередь голова на плечах. У менеджера. И наличие воли и желания.
А дальше уже все зависит от многого — например, бывают команды, где можно нанимать новых людей, и пытаться усиливать команду таким образом. Бывают такие, где это невозможно — и нужно получать максимум пользы от имеющихся. Но я никогда не видел, чтобы работоспособность команды повышалась путем внедрения формальных оценок для разработчиков (QA, аналитики и пр. — из этой же категории).
blutovi
15.01.2017 23:13+1Почти в каждом месте, где работал, рано или поздно кому-нибудь приходила мысль внедрить или систему метрик, или систему оценок.
Должен заметить, что ни одна система так и не прижилась, но что-то мне подсказывает что это ничего не изменит, и всегда будут находится люди, готовые попробовать еще раз.
napa3um
15.01.2017 19:34+1Автор смешал KPI (систему оценок для возможности оптимизировать бизнес-процессы, разработка которой, конечно, должна начинаться с проектирования этих самых оптимизирующих процессов, опирающихся на оценки, и из которых и вытекает размеренность оценки), и «школьно-мотивационные» (геймефикационные) оценки, которые существуют как бы сами по себе, сразу влияя на человека (но на самом деле тоже вытекают из сложной модели — модели мотивов и лояльности сотрудника). Вывод только один: если не знаете, как будете использовать оценки — даже не начинайте их выдумывать (скорее всего их бессистемное введение сделает только хуже). Лучше начинайте выдумывать оптимизирующие процессы, и на каком-то этапе проектирования этих процессов вам, возможно, уже и понадобятся оценки, чтобы параметризировать эти оптимизирующие процессы.
DrSavinkov
15.01.2017 20:32+2А то мы мало на работе отчётов пишем, давайте добавим ещё один.
tmn4jq
15.01.2017 20:33Это уже особенность конкретной компании. Я только отчитываюсь в Jira, к примеру, много времени не отнимает.
vvpoloskin
15.01.2017 22:37Для чего и для кого эти оценки? При адекватном начальнике руководитель, коллеги да и сам потенциальный аттестуемый и так знают, кто и как работает. Если мне кажется, что кто-то плохо выполняет свой функционал, я спокойно говорю руководителю об этом, и тот выдает директивное указание этому сотруднику (или мне=))
Вот для сварщиков и слесарей разряды есть, наверно имело бы смысл внедрить что-то такое и для программистов и админов. Тут тебе и система мотивации, и оценка деятельности.tmn4jq
16.01.2017 00:06Вот для сварщиков и слесарей разряды есть, наверно имело бы смысл внедрить что-то такое и для программистов
Градации junior, regular, senior. Пользуйтесь на здоровье.vvpoloskin
16.01.2017 00:19Это градации все на уровне одной организации, на усмотрение руководителей. Нет, вот если бы был инженер-программист ruby 4 разряда с четкими требованиями к квалификации. А для повышения разряда прописаны жесткие условия, в том числе, что человек должен знать и уметь, сколько опыта у него должно быть.
sumanai
16.01.2017 03:11+3Проблема в том, что разработка ПО сейчас настолько динамичная отрасль, что эти требования устареют где-то в момент публикации.
vvpoloskin
16.01.2017 12:03-1Ну и чего же в ней такого динамичного, что нельзя классифицировать? Что так сильно изменилось в HTML, CSS, PHP, системах контроля версий за последние лет 10, какие основные принципы поменялись? А требования к перчаткам и пассатижам, как и знания новых моделей инверторов и газовых баллонов в разрядах сварщиков никогда не фигурировали.
sumanai
16.01.2017 15:54+3Что так сильно изменилось в HTML, CSS, PHP, системах контроля версий за последние лет 10, какие основные принципы поменялись?
Примерно всё?
10 лет назад на iframe верстали (условно), а сейчас везде AJAX и SPA.
10 лет назад все использовали CSS выражения и кучу костылей для IE, а сейчас почти всегда следуют стандартам.
10 лет назад в PHP не было многих нужных вещей, про стандарты никто не слышал, как и про модульность, а сейчас там правят стандарты кодирования, композёр, а сам язык развился во многих направлениях, как ООП, так и в функциональном, и заметно прибавил в производительности.
Системы контроля версий? Github.http3
17.01.2017 10:46+11. Был уже тогда AJAX (как он был под капотом- это уже другой вопрос)
2. Особо не использовал костылей. :) Но этот ужас что ли, должен быть вечным? :)
3. Каких же таких нужных вещей не было в PHP? :)
Вы не на то обращаете внимание. :)
Вы смотрите на фичи языка.
Нужно смотреть на умение решать задачи.
Кардинально ничего не поменялось. Добавились просто новые фичи. :)sumanai
17.01.2017 16:40Был уже тогда AJAX (как он был под капотом- это уже другой вопрос)
Поэтому и в скобках было условно. Но страницы на клиенте никто не рендерил, современных JS фреймворков и близко не было. А работа с фреймворком кардинально отличается от работы с чистым JS.
Но этот ужас что ли, должен быть вечным? :)
Нет. Но раньше без них никуда, а сейчас без них отлично.
Каких же таких нужных вещей не было в PHP? :)
Пространства имён, замыкания, типизация параметров функций, да много чего. Тот же композёр, хоть и не является частью PHP, но сильно влияет на программирование на нём.
Вы смотрите на фичи языка.
Нужно смотреть на умение решать задачи.
Всё на то я смотрю. Программирование типа «50 строк инклюдов и сотня глобальных переменных» и «подключаем зависимости через DI и держим параметры в YAML» кардинально различаются. При этом раньше был только первый подход, так как язык не давал удобных инструментов для разбития на компоненты, и первый подход считался нормальным. Сейчас же благодаря развитию языка и сообщества вокруг него первый подход кроме как говнокодом не назовут, и рулит второй.http3
17.01.2017 17:36Но страницы на клиенте никто не рендерил, современных JS фреймворков и близко не было.
При желании можно было рендерить.
Да и сейчас мало кто рендерит. :)
Пространства имён
Появилось в 2009 году, модно сказать 10 лет назад. :)
Для чего они Вам? Для автозагрузки или для отсутствия конфликтов? :)
типизация параметров функций
Что-то вроде было. Ну и не особо оно и нужно. :)
Тот же композёр, хоть и не является частью PHP, но сильно влияет на программирование на нём.
Ну появился композер. Программисту стало нужно иметь меньше знаний? :)
так как язык не давал удобных инструментов для разбития на компоненты
Типа для автозагрузки или для чего?
Или для изоляции классов? :)
DI
Он возник 10- лет назад?
Он снизил требования к программистам? :)sumanai
17.01.2017 19:43При желании можно было рендерить.
Но никто так не делал.
Да и сейчас мало кто рендерит. :)
Трафику этих мало кого можно только позавидовать.
Для чего они Вам? Для автозагрузки или для отсутствия конфликтов? :)
Для всего сразу?
Он возник 10- лет назад?
Он просочился на PHP, даже меньше 10 лет назад. По крайней мере стал популярным, маргинальные наколенные подделки я не учитываю.
:)
Слишком много смайлов. Вы ведь не серьёзно писали? :)http3
20.01.2017 22:27Слишком много смайлов. Вы ведь не серьёзно писали? :)
Серьёзно.
Просто у меня была тогда улыбка на лице. :) Поэтому и смайлы.
vvpoloskin
17.01.2017 11:03Дополню высказывание http3. Принципиально ничего не поменялось — HTML/CSS/JS как был, так и остался, принципы работы с ним не изменились, появились лишь некоторые удобства. Тот же git как одна из самых современных систем контроля версий появился в 2005, я не говорю про RCS, hg, да стала удобнее, как и любой инструмент.
У слесаря в должностных навыках не написано «умение стучать молотком с полимерной рукояткой по железному гвоздю», но указано так: «пользоваться простым измерительным и слесарно-сборочным инструментом». Вот и для программистов подошла бы какая-нибудь похожая градация категорий, от которых зависела бы зарплата и ответственность.tmn4jq
17.01.2017 16:49+1Ну да, вообще в программировании мало чего меняется. Те же нули и единички, что были 50 лет назад. Просто раньше писали на ассемблере, а теперь появились некоторые удобства.
Утрирую, конечно. Не смог сдержаться.
slonoslon
16.01.2017 18:28+2Любая оценка — это упрощение, соответственно там, где мы заменяем более полные сведения на оценку — происходит потеря информации. Чем более сложный процесс мы оцениваем — тем значительнее эта потеря, и вдобавок теряются обычно более глубокие и трудноуловимые аспекты. Оценка нужна там, где мы не можем себе позволить иметь дело с более полной информацией — она просто недоступна или (чаще) у нас нет ресурсов на ее обработку. Например, в компании в 1000 человек директор не знает большинство сотрудников лично, и ему нужна какая-то упрощенная оценка их деятельности, а руководитель отдела в 10 человек должен бы знать и видеть больше нюансов про каждого из подчиненных, чем дает любая система количественной оценки.
Из-за того, что для оценки берется только часть информации, оптимизировать под оценку часто проще, отсюда множество искажений: учащиеся, получающие хорошие оценки на тестах, но пасующие перед задачами в реальной жизни; товары и услуги посредственного качества, успешно раскрученные и продаваемые и т.д и т.п.
qwertyRu
16.01.2017 18:28+1На самом деле, оценка только одна.
Устраивает ли данный человек на этой должности руководство или нет.
Оценки — это поиск повода для уменьшения трат.
Есть индикатор, если в компании введены субъективные метрики, то работы там будет меньше чем «понтов». Два человека могут объединиться против третьего, потому что он один действительно знает как надо правильно делать и хочет что бы правильно делали все. Вот они его и убрали из компании.
Suvitruf
Проходили, знаем. Все эти системы оценок/рейтинги обладают большим недостатком — человек начинает работать не на результат, а на баллы. Создать систему подобную, чтоб подходила всем сотрудникам (ведь личностные качества у всех разные, подход ко всем разный должен быть), довольно проблематично. Помнится, в том же MS в своё время была рейтинговая система, но они её пару лет назад отменили.
RouR
Вместо рейтинга, надо вводить стандарты качества и дискретную оценку — соответствует или нет.
В случае такси это может быть набор характеристик: соблюдение ПДД, пунктуальность, вежливость, чистота авто и водителя и т.п.
sleeply4cat
Тоже не очень показательно. Например, сейчас я пишу красивый код, тесты и javadoc'и для «ядра» проекта и переиспользуемых компонентов, изгоняя оттуда костыли других разработчиков, в то же время зачастую ляпая «на скорую руку» откровенный говнокод в тех местах, неправильная работа которых будет очевидна и легко исправится. Так что метрики качества кода у меня так себе, хех. Увы, у нас нет ресурсов на найм ещё двух меня, чтобы красиво было всё :(