Как оценить работу программиста

Как оценить работу программистов и разработчиков

Как оценить работу программиста? Можно проанализировать конечный результат. Проверить качество, удобство восприятия кода. Но, если вы не технический специалист, разобраться в содержании программы трудно.

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

Существуют критерии оценки программистов, которые помогают понять, чего стоит конкретный сотрудник.

KPI или Как Платить ИТ-специалисту

Бизнес мечтает о введении KPI (ключевых показателей эффективности) для кодеров. Иначе попробуй, пойми, работает программер или занимается ерундой, мало ему платишь или много. Большинство компаний выставляют собственные критерии эффективности программиста:

• ранжировка, отличная от общепринятой (например, junior, junior+, senior, senior+, middle);
• объем закрытых за определенный период задач (оплата почасовая, в некоторых фирмах разработаны системы оценки, где стоимость часа зависит от сложности задачи);
• экзамены, курсы, повышение скилла;
• самостоятельность, инициативность, переработку.

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

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

Как оценивать программистов при приеме на работу

Интервью с кодером обычно состоит из трех частей. В первой рекрутер проверяет, соответствует ли впечатление от резюме действительности. Во второй определяет опыт соискателя. В третьей дает небольшие задачки или вопросы по направлению.

Навыки и качества кандидата анализируют с учетом особенностей разработки в конкретной организации. Например, могут понадобиться:

• способность работать с монотонной рутиной или искать неожиданные решения;
• исполнительность или самостоятельность;
• умение трудиться в команде, коммуникабельность и пр.

По каким базовым критериям выбирают программиста

Определить, подходит ли вам кандидат, можно по пунктам:

1. Отношение к программированию, увлеченность, кругозор. Как воспринимает IT-специалист свою деятельность: как средство заработка или дело всей жизни. Чем занят в свободное время: изучает новые технологии, лежит на диване или увлекается посторонним хобби. Страсть к профессии — однозначный показатель, что человек будет работать увлеченно и выдаст максимальный результат.
2. Обучаемость — с какой скоростью человек усваивает новое, не вызывает ли у него сильный дискомфорт, вплоть до увольнения, необходимость разбираться в незнакомой технологии.
3. Наличие личных трудов, степень их завершенности.
4. Образование. Высшее/среднее техническое (или самоучка), знание методов и средств разработки, языков программирования, опыт.

Как оценить разработчика по подходу к написанию кода? Уточните, планирует ли айтишник архитектуру решения или сразу приступает к делу, переписывая код в процессе из-за неправильно выбранной тактики. Это влияет на скорость и результат.

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

Многое зависит от уровня. Новичкам засчитывается энтузиазм, желание разбираться, учиться, расти. У айтишников рангом повыше существенна отдача: насколько быстро выполняется работа, не приходится ли потом переделывать решения. Имеет значение соотношение затрачиваемых ресурсов (время на код, время на тестирование, аналитику), и пользы выполненной работы. Для «мамонтов»-middle важно, насколько код ориентирован на будущие нужды.

Техническая оценка разработчиков

Отсеять нецелевых кандидатов помогут вопросы о специализации. Смотрят на направление, перспективы, общее направление мыслей, логику. Примерные варианты:

1. На какой области, технологии вы специализируетесь?
2. Какие инструменты вы выберете для проекта с нуля?
3. Версия «рабочего» языка, которая вам больше всего нравится.
4. Есть ли будущее у вашего направления, приведите аргументы.

Вопросы для личностной оценки программистов

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

1. Определение идеального ИТ-специалиста с вашей точки зрения.
2. Самые интересные для вас задачи.
3. Какой коллектив/команда наиболее комфортен для вас.
4. Опишите работу мечты, идеальный рабочий процесс.

Подходить к оценке нужно осторожно. Неправильный выбор кандидата ударит по общей производительности, равно как и несправедливое отсекание интеллектуала заставит потратиться на дальнейшие поиски.

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

По всем вопросам свяжитесь с нами любым удобным способом:

Как оценить профессионализм программиста за 5 вопросов — отвечают эксперты

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

На мой взгляд, достаточно всего трёх вопросов.

Каковы причины ухода с прежнего места работы?

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

Какой ваш самый интересный реализованный проект?

По ответу на этот вопрос можно определить уровень разработчика: какие задачи он считает действительно сложными, какие решения называет удачными. Если это его личный проект, можно узнать, как программист совмещал роли аналитика, разработчика, тестировщика, как решал вопросы интеграции данных и нагрузки. Рассказ о командном проекте позволяет оценить навык совместной разработки и уровень развития soft skills.

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

Расскажите про свои увлечения

Хороший показатель увлечённости именно программированием — чтение и просмотр профильных статей и подкастов. В том числе интересно, что человек читал или смотрел в последнее время. Это хороший показатель интереса к новым технологиям: даже если программист работает в компании с давно запущенными продуктами, где много legacy-кода, он должен интересоваться нововведениями в области технологий.

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

Любое собеседование в нашей компании — это разговор не только о технологии. Мы стараемся прежде всего узнать и понять человека, который к нам пришел. Впишется ли он в нашу культуру? Будет ли нашей команде комфортно работать с ним в будущем? Не противоречат ли принципы человека принципам компании? От этого зависит, сможет ли человек работать с нами долго и насколько продуктивным будет это сотрудничество.

Поэтому мы начинаем с самого простого, но важного: «Как вы пришли в разработку?». Этот вопрос помогает оценить кругозор соискателя в программировании и понять уровень его вовлечённости. По ответу становится ясно, заинтересован ли человек расти в этой профессии или для него это только «дань моде» и средство заработка.

Следующим вопросом, скорее всего, будет «ваша самая интересная/сложная решённая задача». Позволяет понять, что кандидат считает сложным и как подходит к решению таких задач.

Дальше можно переключиться на темы, связанные с фундаментальными знаниями: паттерны программирования, основы объектно-ориентированного программирования, ключевые принципы разработки (SOLID, DRY, OR, KISS и другие).

Оставшиеся вопросы связаны с направлением разработки (frontend, backend, mobile application) и характерной для него специфической областью знаний. Они позволяют выяснить много важных вещей: например понимание принципов взаимодействия пользовательского интерфейса с бэкендом, REST, API, работы с памятью устройств (в случае мобильного приложения) и многое другое. После обсуждения этих моментов уже можно переходить к типовым вопросам конкретной технологии.

Наши программисты занимаются как созданием собственных решений, так и разработкой на заказ, а также сервисами сопровождения, обновления нетиповых конфигураций 1С. Работа построена в небольших командах по 3–4 человека, каждая со своей специализацией: например кто-то глубже знает определённую конфигурацию 1С, кто-то лучше разбирается в обновлениях, свёртках информационных баз.

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

Почему он захотел стать разработчиком?

Этот вопрос помогает «разбить лёд» в начале разговора, найти точки соприкосновения. Позволяет понять, как человек принимает решения, что побуждает его к изменениям, что для него важно в профессии.

Какие личностные качества помогли ему стать разработчиком и какие из них наиболее значимы?

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

Кем он видит себя (на какой должности) через 1 год, 2 года, 5 лет (не обязательно работая в нашей компании)

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

Какие 5 его любимых книг и почему именно они?

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

Чем он может быть полезен нашей компании? Что он сможет привнести нового в работу компании?

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

На мой взгляд, оценить профессионализм по 5 вопросам нельзя. Нужно видеть результат работы кандидата, в какие сроки и при каких ограничениях он достигнут. Поэтому мы часто предлагаем 2-недельную оплачиваемую стажировку в компании, чтобы посмотреть на кандидата в деле.

Если же можно только 5 вопросов, то я всегда спрашиваю о проектах, в которых участвовал кандидат.

1. Дошли ли они до промышленной эксплуатации?
2. Как был организован процесс разработки? Кто и как ставил задачи? Как тестировалось? Кто принимал решение о том, что задача выполнена?
3. Что не устраивало кандидата в процессе разработки? Предлагал ли он идеи по улучшению процесса?
4. Как документировался код?
5. Привык ли кандидат автоматизировать свою деятельность?

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

1. Какие структуры данных и алгоритмы вам приходилось применять в прошлых проектах и в чём польза их использования?
2. Расскажите о плюсах и минусах вашего языка программирования. Почему вы выбрали именно этот язык?
3. Важно ли, чтобы код, написанный вами, был понятен другим? Если да, то почему?
4. Опишите процесс разработки и внедрения программного продукта на прошлых местах работы.
5. Напишите или расскажите словами алгоритм градиентного бустинга над деревьями. Как вариант: метод обратного распространения ошибки в нейронных сетях.

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

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

Формат вербального собеседования в отношении программистов, если он реализуется в виде простого опросника, даёт валидность верификации профессионализма на уровне не более 30 %. Решение практических задач — минимум 80 %.

У нас на собеседовании обязательно попросят рассказать о своих последних проектах. Вопрос может быть сформулирован, например, так: «Чем вы занимались на прошлой работе? Как выглядела команда? И какую роль вы в этой команде занимали?». Из ответа станет понятно, как кандидат идентифицирует себя в команде, как работает внутри неё, насколько он командный игрок.

Следующим вопросом вас могут попросить рассказать о проекте, который разочаровал или наоборот воодушевил? И спросят: «Что бы вы изменили при работе над этим проектом?». Это даст HR понимание того, как человек анализирует свои ошибки, может ли что-то впоследствии изменить, или, возможно, из раза в раз допускает похожие промахи. Кроме того, косвенно из ответа станет понятно, готов ли собеседник к дальнейшему росту и какому более — профессиональному или карьерному.

Ещё один важный вопрос: «Работали ли вы напрямую с заказчиком или взаимодействовали с ним на каких-то этапах проекта?». Здесь мы предварительно тестируем наличие особенно ценных сейчас коммуникативных навыков. Нам важна привычная для кандидата структура коммуникаций: были ли это еженедельные очные или телефонные митапы с заказчиком, или же человек больше привык к письменным отчётам. Затем, скорее всего, последует ряд вопросов: «Готовы ли вы защищать свой код на уровне заказчика? И что происходило в случае неудачной коммуникации?». Например, эскалация проблемы тимлиду или же отстранение от решения проблемы. Эта часть интервью посвящена коммуникации с заказчиком.

Ещё хороший вопрос: «Как описали бы вас другие разработчики или ваш РП?». Ответ на этот вопрос расскажет нам о самооценке будущего сотрудника, о том, что он лично думает о своих результатах и работе в целом. Здесь я всячески рекомендую говорить правду. Ведь даже ответ: «У всех бывают косяки. Но мы в команде всегда работаем над этим», — даёт HR правильный посыл о личных качествах и верном настрое на диалог.

Также показательный вопрос: «Что в программировании для вас самое сложное?». Ответ на этот вопрос позволяет нам выявить слабые технические стороны кандидата. Честный рассказ о слабостях показывает, что человек адекватно оценивает свои возможности и готов в них развиваться. Например, ответ: «Сложностей нет, я просто с этим не работал», — однозначно говорит о том, что сложности в названной области явно есть.

Несмотря на то, что меня просили назвать пять вопросов, я бы добавил к ним ещё один: «Как вы следите за последними тенденциями в разработке?». Или как вариант этого же вопроса: «Какие последние три книги или статьи вы прочитали?». Если хоть одна из статей или книг касалась разработки или профессиональной области, то для нас это знак, что кандидат действительно интересуется техническими темами за пределами сугубо рабочих задач.

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

Как измерить эффективность труда программиста

В любой организации, имеющей в штате одного или нескольких разработчиков ПО, рано или поздно встает вопрос, как оценить их эффективность, какие KPI можно применить к разработчикам, кто должен оценивать.

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

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

Возникает вопрос, какие единицы оценки задач можно применить. Существует два подхода: во-первых, задачу можно оценить в человеко-часах, которые потратит на решение некий эталонный разработчик; во-вторых, оценка в абстрактных единицах. В литературе по организации разработки в команде встречается термин Story Point для обозначения условных единиц стоимости задачи.

Рассмотрим плюсы оценки задач в Story Point по сравнению с человеко-часами:

• бывают простые задачи, которые требуют значительных затрат по времени, а бывают сложные задачи, решение которых требует особых знаний и компетенций сотрудника. Такие задачи не могут стоить одинаково, но в человеко-часах эталонного разработчика оценка может совпасть;
• система оценки задач в условных единицах позволяет уйти от личных оценок: оценка по задаче в человеко-часах и фактическое время, потраченное на ее решение, могут сильно отличаться. Разница может оказаться как в пользу исполнителя, так и наоборот, что может вызвать недовольство исполнителя или стать предметом манипуляций со стороны заказчика («может быть, вы одним пальцем программируете»).

В нашей группе разработки используются оценки задач при помощи Story Point. В качестве элементов оценки берем степени числа 2 (1/2, 1, 2, 4, 8). Есть договоренность, что простые задачи имеют оценку 1/2 или 1. Задачи посложнее — 2 или 4. Самые сложные и объемные задачи оцениваем в 8 баллов. Если задачу не удается оценить при помощи данной шкалы, необходимо разбить ее на более мелкие либо вывести в разряд проектных разработок.

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

Кто должен оценивать работы?

Очевидно, что сложность работ по конкретной задаче должен оценивать человек квалифицированный, ведь кто-то умеет красиво подать свою работу, а кто-то нет. В большинстве случаев заказчик задачи не обладает необходимыми знаниями для корректной оценки ее сложности. Заказчик может оценить качество работ (заявленный функционал работает без ошибок, работа данного функционала облегчает труд и ускоряет выполнение собственных задач заказчика), сроки реализации задачи (задача выполнена в сроки, оговоренные заказчиком и исполнителем, и на момент сдачи работ имеет ценность для заказчика). Но сложность каждой задачи может определить только квалифицированный специалист. Наиболее распространены следующие варианты оценки задач: задача оценивается ответственным (руководителем группы, тимлидом, ведущим специалистом); задачу оценивает вся команда разработки. Каждый способ имеет свои плюсы и минусы. Если сложность задачи оценивает ответственный, такая оценка всегда субъективна и основана на опыте конкретного специалиста. В свою очередь, при командной оценке есть вероятность, что один или несколько членов команды знают более быстрый способ решения такой задачи, чем ответственный. А может быть и наоборот: при решении аналогичной задачи кто-то из команды сталкивался с подводными камнями, о которых другие члены команды не подозревают. Но идеальная оценка задач командой имеет один существенный минус: мы тратим время всей команды, чтобы вникнуть в суть задачи и обсудить ее решение. Каждая ли задача стоит таких затрат?

Оценка результата работы по периодам

По итогам интересующего нас периода выполняется анализ проделанной специалистами работы и оценки всех выполненных задач за период суммируются.

При помощи данного подхода мы определили эффективность работы каждого члена команды, а также такую величину, как мощность (производительность) команды, то есть количество Story Point, которые команда может сделать за единицу времени. После этого можно выразить полученные результаты в денежном эквиваленте либо в виде нематериального поощрения сотрудников.

Гаянэ Арутюнян,
руководитель отдела информационных технологий OPEN Group