Привет, хабровчане! В этот внеочередной выходной день выходного месяца, хотим поделиться с вами интересной статьей, которая была переведена в преддверии старта курса «Team Lead 2.0».
Разработчикам нужна обратная связь, чтобы они могли совершенствовать навыки и получать новые знания. По словам редактора Inc. Magazine, Джеффа Хейдена, традиционные показатели могут быть обманчивы, поскольку они не всегда отражают четкую картину. Раньше оценка работы персонала представлялась сложной задачей, именно потому появились инструменты Git Analytics, такие как Waydev. Этот инструмент предлагает подход к разработке на основе данных, чтобы помочь вам выявить лучшее в своих сотрудниках.
Очень важно измерять правильные показатели и делать это корректно. В свою очередь, выбор показателей зависит от специфики вашего бизнеса и должностных обязанностей каждого инженера-программиста.
Мы расскажем вам об алгоритме, который поможет оценить эффективность работы программистов:
Постановка организационных целей и регулярная проверка того, что все члены команды им следуют, является главным приоритетом с самого начала работы над проектом. Даже если в вашей организации разработка программного обеспечения вынесена на аутсорсинг, команда разработчиков не будет независимой организацией, единственной функцией которой является написание кода и его тестирование. Интеграция технических целей с общими бизнес-целями – это важный шаг на вашем пути. Концептуализация задач на ранних стадиях лежит в основе оценки эффективности работы на более поздних этапах.
Каждая цель должна укладываться в основную идею бизнеса, как на уровне команды, так и на индивидуальном уровне каждого сотрудника.
Измерение производительности сводится к двум основным вопросам – «что» и «как». Вопрос «что» относится к реальным задачам, которые стоят перед командой. Он подразумевает под собой определенный факт и ожидание. Под ответом на вопрос «что» можно подразумевать, например, своевременное написание и тестирование кода. Здесь «своевременность» — четкий факт, а отличное качество кода – неявное ожидание.
Вопрос «как» связан с процессом, то есть, с тем, насколько хорошо программист работал в команде, насколько инновационным был его подход к задаче и так далее.
Оценка фундаментальных «что» и «как» даст вам понимание не только того, над какими задачами работает команда, но и того, насколько хорошо они их выполняют. Waydev обеспечивает вид деятельности ваших работников с высоты птичьего полета с помощью Work Log. Он позволяет вам увидеть каждый коммит или pull request, который разработчик в вашей компании делал в единицу времени.
При разработке программного обеспечения никогда нельзя сосредотачиваться на количественной составляющей разрабатываемого продукта. Лишние строки кода сделают программное обеспечение громоздким, и его будет сложнее поддерживать. И наоборот, минимизация количества строк кода – не панацея: такое программное обеспечение будет трудным для понимания и масштабирования.
Долгосрочный подход, ориентированный на результат, подразумевает, что вместо количественной оценки эффективности продукт оценивается на основе результатов работы команды. Для оценки процессов разработки и релизов необходимо проанализировать стабильность, частоту поставки и частоту обновлений конечного продукта.
Чтобы оценить результативность работы той или иной команды, нужно понять, достигла ли она желаемых результатов. Сосредоточившись на этом, вы не только повысите производительность разработчиков, но и достигните организационных целей, а значит будете получать больше выгоды в долгосрочной перспективе. В Waydev вы можете воспользоваться функцией Project Timeline, чтобы увидеть, как фокус работы и объем меняются с течением времени. Узнайте, на чем сосредоточены разработчики. Идет ли речь о написании нового кода, рефакторинге старого или помощи коллегам? Посмотрите, какие события повлияли на производительность вашей команды, чтобы при вынесении последующих решений, вы могли ориентироваться на полученные данные.
Чтобы оценка имела под собой основу, нужно иметь определенный стандарт, которому вы можете следовать при ее получении. Таким стандартом может послужить должностная инструкция или предполагаемый план работы.
Ознакомьтесь с существующими должностными инструкциями, документами, записями, электронными письмами и любыми другими данными, которые позволят вам сделать вывод об эффективности работы сотрудника.
Если вы в команде недавно, поговорите с тимлидом разработчика, его коллегами и, по возможности, с постоянными клиентами, с которыми он работал.
Успех или неудача зависят не только от человека, но и от условий труда:
С помощью Project Timeline в Waydev вы можете определить наиболее релевантные точки данных в рабочем процессе вашей команды и провести продуктивное обсуждение того, какие знания можно применить к следующему спринту. Project Timeline? поможет вам и вашей команде быстро среагировать на блокировки процессов, которые влияют на состояние здоровья вашей разработки во время разговоров и ретроспективных оценок.
Сравните текущую производительность с желаемой или определенной в должностной инструкции. Если есть видимые результаты, убедитесь, что они отражены в конкретных примерах и определите их ценность:
Если видимых результатов нет, задайтесь следующими вопросами:
Определите, насколько регулярно и эффективно сотрудник применяет свои ключевые навыки в своей работе:
Если разработчику тяжело дается выполнение рабочих задач, а поставленные цели оказываются недостигнутыми, то стоит подумать об организации дополнительного обучения или курсов повышения квалификации.
Все выводы, которые вам удалось сделать в ходе анализа, следует обсудить с самим сотрудником. Сосредоточьтесь на его успехах. Чтобы донести понимание ситуации как можно точнее, используйте конкретные примеры. Начните с положительных аспектов, но обязательно уделите внимание возникшим трудностям. Если цель не была достигнута по причине от разработчика независящей, он ни в коем случае не должен думать, что виноват во всем подряд.
Обязательно задавайте вопросы и внимательно слушайте ответы. Это поможет выявить проблемы и понять, как человек к ним относится: хочет ли он их решить, какие видит выходы из ситуации и что хотел бы изменить.
Основываясь на информации, которую вы получили во время разговора с сотрудником, его менеджером и коллегами, составьте список предложений, которые могли бы повысить производительность разработчика.
Для получения обратной связи необходимы комментарии по проделанной работе. Основываясь на полученных замечаниях, инженер сможет оценить свои сильные и слабые стороны и направить усилия в нужное русло. Помните, что по комментариям можно судить не только о сотруднике, но и о человеке, который их написал. Они должны быть составлены профессионально и объективно.
Комментарии должны отражать следующие моменты:
Комментарии должны обладать следующими свойствами:
Прежде всего нужно понять, появляется ли разработчик на работе вообще. Учитывайте время прибытия, отъезда и отсутствия. Если кто-то из команды приходит на работу поздно, надолго покидает рабочее место, уходит раньше, чем нужно, или берет больничный без уважительной причины, он точно не стремится выкладываться на полную. Помните, что плохая посещаемость может быть вызвана не только банальной ленью, но и более серьезными причинами, например, отсутствием мотивации, проблемами со здоровьем или эмоциональным выгоранием.
Уклонения от выполнения своих обязанностей на работе может стать дурным примером для всей команды. Другим разработчикам из-за этого приходится брать на себя дополнительные обязанности, чтобы как-то компенсировать отсутствие коллеги на рабочем месте. Ситуация усугубляется, если в вашей организации нехватка разработчиков, а проблема застоялась. Начните заниматься ей как можно быстрее, поскольку ее игнорирование может привести к проблемам в личной жизни и здоровье ваших разработчиков.
Мы все сосредоточены на оказании помощи клиентам, но взаимопомощь в команде также очень важна. Konowe & Associates считает, что этот пункт является одним из ключевых показателей эффективности для разработчиков: «Мы спрашиваем, кто в вашем отделе (или компании в целом) был самым отзывчивым и помогал вам больше других за последние полгода? И так получается, что эта анонимная мотивация разработчиков позволяет выявить настоящих фанатов своего дела, а не просто фаворитов руководства.»
Готовность помогать другим – важнейший элемент командной работы. Совместная работа над сложными задачами гораздо эффективнее, чем попытки свернуть горы в одиночку. Функция Review Collaboration позволяет понять, кто делится своими знаниями с другими. Она также предоставляет вам количественные показатели, которые помогут вам оценить состояние рабочего процесса ревью кода.
Все члены команды должны выполнять работу в срок. Они должны уметь правильно распоряжаться временем и ресурсами и правильно расставлять приоритеты, чтобы выполнять свою работу максимально эффективно.
Обращайте внимание на сроки выполнения и качество работы, которое могло пострадать из-за спешки ради того, чтобы уложиться в дедлайн: это поможет понять, насколько эффективно работает сотрудник. Также очень важно учитывать количество времени, затраченного на работу: если человек стабильно перерабатывает, то стоит поговорить с ним о планировании времени.
Хорошо, когда коллеги интересуются, могут ли они вам чем-то помочь. Еще лучше, если они видят цели и предпринимают все необходимые действия для их достижения. Инициативность – это показатель вовлеченности в работу. Определение наиболее активных разработчиков имеет важное значение для растущих компаний, где постоянно появляются новые рабочие места, а человеческие ресурсы быстро перераспределяются. Для наиболее эффективной работы нового отдела лучше всего будет снабдить его самыми инициативными кадрами. Они смогут быстро адаптироваться к новым условиям и работать на опережение.
Чтобы выявить наиболее активных членов вашей команды, «ставьте галочку» каждый раз, когда какой-либо разработчик берет на себя ведущую роль в команде.
Качество работы – это самый важный, но в то же время и самый сложный показатель эффективности, который можно измерить. Инженеры, которые работают качественно и искренне вовлечены в рабочий процесс, скорее всего, покажут лучшие результаты. Такая вовлеченность может стать критерием качества.
Производительность разработчиков не измеряется только в количественных характеристиках разрабатываемого продукта, так проблема не решается. Разработчики, пишущие лишние строки кода просто способствуют усложнению программного обеспечения из-за чего его становится тяжелее поддерживать. Вы должны понимать, на что работают ваши разработчики: на качество или количество?
Эксперты с сайта HR World предлагают оценивать качество конечного результата по количеству функций, которые были отклонены или возвращены на доработку. Вы можете воспользоваться этой методикой или выбрать другую, более подходящую под специфику вашей компании.
Конечно, оценка эффективности в конкретных цифрах важна, однако Шерил Штайн, бизнес-тренер Monster.com, советует не ограничиваться числовыми показателями. В конце концов, члены команды – это живые люди, а не просто ресурсы. Штейн отмечает, что некоторые качества, например, умение найти подход к любому человеку, сейчас ценятся на вес золота, и такие навыки нельзя упускать из виду. Также Штейн пишет о том, как важно обращать внимание на изменение производительности труда, так как она может быть симптомом более глобальных изменений в компании.
«Снижение производительности труда может свидетельствовать об изменениях рынка или несостоятельной маркетинговой стратегии, идеи и ценностях.»
При измерении эффективности важно открыто вести диалог с командой. Люди должны знать, как вы проводите оценку и формируете выводы. Так каждый разработчик будет понимать свое положение в команде. С помощью Waydev вы можете просматривать информацию о конкретных членах команды, видеть их прогресс, помогать им в решении проблем, тем самым обеспечивая лучшую вертикальную коммуникацию внутри организации.
Какие риски таит удалённая работа IT подразделений? Какие подходы нужны для того, чтобы команда работала эффективно без необходимости установки слежки за ними? Почему удалёнке тоже нужен график? Ответы на эти вопросы можно узнать на нашем бесплатном вебинаре, который пройдет 13 мая. Записаться на вебинар.
Разработчикам нужна обратная связь, чтобы они могли совершенствовать навыки и получать новые знания. По словам редактора Inc. Magazine, Джеффа Хейдена, традиционные показатели могут быть обманчивы, поскольку они не всегда отражают четкую картину. Раньше оценка работы персонала представлялась сложной задачей, именно потому появились инструменты Git Analytics, такие как Waydev. Этот инструмент предлагает подход к разработке на основе данных, чтобы помочь вам выявить лучшее в своих сотрудниках.
Очень важно измерять правильные показатели и делать это корректно. В свою очередь, выбор показателей зависит от специфики вашего бизнеса и должностных обязанностей каждого инженера-программиста.
Мы расскажем вам об алгоритме, который поможет оценить эффективность работы программистов:
Постановка целей
Постановка организационных целей и регулярная проверка того, что все члены команды им следуют, является главным приоритетом с самого начала работы над проектом. Даже если в вашей организации разработка программного обеспечения вынесена на аутсорсинг, команда разработчиков не будет независимой организацией, единственной функцией которой является написание кода и его тестирование. Интеграция технических целей с общими бизнес-целями – это важный шаг на вашем пути. Концептуализация задач на ранних стадиях лежит в основе оценки эффективности работы на более поздних этапах.
Каждая цель должна укладываться в основную идею бизнеса, как на уровне команды, так и на индивидуальном уровне каждого сотрудника.
Закладка фундамента
Измерение производительности сводится к двум основным вопросам – «что» и «как». Вопрос «что» относится к реальным задачам, которые стоят перед командой. Он подразумевает под собой определенный факт и ожидание. Под ответом на вопрос «что» можно подразумевать, например, своевременное написание и тестирование кода. Здесь «своевременность» — четкий факт, а отличное качество кода – неявное ожидание.
Вопрос «как» связан с процессом, то есть, с тем, насколько хорошо программист работал в команде, насколько инновационным был его подход к задаче и так далее.
Оценка фундаментальных «что» и «как» даст вам понимание не только того, над какими задачами работает команда, но и того, насколько хорошо они их выполняют. Waydev обеспечивает вид деятельности ваших работников с высоты птичьего полета с помощью Work Log. Он позволяет вам увидеть каждый коммит или pull request, который разработчик в вашей компании делал в единицу времени.
Фокусировка на долгосрочных перспективах
При разработке программного обеспечения никогда нельзя сосредотачиваться на количественной составляющей разрабатываемого продукта. Лишние строки кода сделают программное обеспечение громоздким, и его будет сложнее поддерживать. И наоборот, минимизация количества строк кода – не панацея: такое программное обеспечение будет трудным для понимания и масштабирования.
Долгосрочный подход, ориентированный на результат, подразумевает, что вместо количественной оценки эффективности продукт оценивается на основе результатов работы команды. Для оценки процессов разработки и релизов необходимо проанализировать стабильность, частоту поставки и частоту обновлений конечного продукта.
Чтобы оценить результативность работы той или иной команды, нужно понять, достигла ли она желаемых результатов. Сосредоточившись на этом, вы не только повысите производительность разработчиков, но и достигните организационных целей, а значит будете получать больше выгоды в долгосрочной перспективе. В Waydev вы можете воспользоваться функцией Project Timeline, чтобы увидеть, как фокус работы и объем меняются с течением времени. Узнайте, на чем сосредоточены разработчики. Идет ли речь о написании нового кода, рефакторинге старого или помощи коллегам? Посмотрите, какие события повлияли на производительность вашей команды, чтобы при вынесении последующих решений, вы могли ориентироваться на полученные данные.
Подготовка к оценке
Чтобы оценка имела под собой основу, нужно иметь определенный стандарт, которому вы можете следовать при ее получении. Таким стандартом может послужить должностная инструкция или предполагаемый план работы.
Ознакомьтесь с существующими должностными инструкциями, документами, записями, электронными письмами и любыми другими данными, которые позволят вам сделать вывод об эффективности работы сотрудника.
Если вы в команде недавно, поговорите с тимлидом разработчика, его коллегами и, по возможности, с постоянными клиентами, с которыми он работал.
Успех или неудача зависят не только от человека, но и от условий труда:
- Были ли какие-то форс-мажорные обстоятельства? Например, недооцененная сложность задачи или смена приоритетов? Возможно, именно это и помешало разработчику достичь цели и найти применение своим способностям.
- Каких успехов добилась компания и каков вклад в это конкретного инженера-программиста? Правильно ли он использовал свои ключевые навыки?
С помощью Project Timeline в Waydev вы можете определить наиболее релевантные точки данных в рабочем процессе вашей команды и провести продуктивное обсуждение того, какие знания можно применить к следующему спринту. Project Timeline? поможет вам и вашей команде быстро среагировать на блокировки процессов, которые влияют на состояние здоровья вашей разработки во время разговоров и ретроспективных оценок.
Анализ целей и ключевых навыков
Сравните текущую производительность с желаемой или определенной в должностной инструкции. Если есть видимые результаты, убедитесь, что они отражены в конкретных примерах и определите их ценность:
- Были ли достигнуты/превышены желаемые показатели?
- Мешали ли неблагоприятные условия труда достижению поставленных целей?
- Были ли эти цели достигнуты благодаря тому, что сотрудник работал сверхурочно?
- Был ли результат работы настолько хорошим, что этого сотрудника нужно поощрить?
- Сыграл ли этот разработчик ключевую роль в достижении целей всей команды?
Если видимых результатов нет, задайтесь следующими вопросами:
- Зависел ли успех задачи от этого человека?
- Была ли проблема вызвана такими причинами, как отсутствие необходимого оборудования, слишком большой объем задач, нечеткая постановка задачи или отсутствие иных необходимых ресурсов?
- Может ли более компетентный сотрудник решить эти проблемы?
- Каковы последствия невыполнения задачи?
Определите, насколько регулярно и эффективно сотрудник применяет свои ключевые навыки в своей работе:
- Использует ли сотрудник эти навыки ежедневно?
- Применил ли он все свои способности или только некоторые из них? Какие?
- Как применение навыков помогает разработчику решать рабочие задачи? Как это влияет на рабочий процесс и успех команды?
- Было ли разработчику трудно выполнять задачу? Если да, то как это влияло на ваши цели и рабочий процесс?
Если разработчику тяжело дается выполнение рабочих задач, а поставленные цели оказываются недостигнутыми, то стоит подумать об организации дополнительного обучения или курсов повышения квалификации.
Обсуждение
Все выводы, которые вам удалось сделать в ходе анализа, следует обсудить с самим сотрудником. Сосредоточьтесь на его успехах. Чтобы донести понимание ситуации как можно точнее, используйте конкретные примеры. Начните с положительных аспектов, но обязательно уделите внимание возникшим трудностям. Если цель не была достигнута по причине от разработчика независящей, он ни в коем случае не должен думать, что виноват во всем подряд.
Обязательно задавайте вопросы и внимательно слушайте ответы. Это поможет выявить проблемы и понять, как человек к ним относится: хочет ли он их решить, какие видит выходы из ситуации и что хотел бы изменить.
Рекомендации
Основываясь на информации, которую вы получили во время разговора с сотрудником, его менеджером и коллегами, составьте список предложений, которые могли бы повысить производительность разработчика.
Как писать комментарии и рекомендации
Для получения обратной связи необходимы комментарии по проделанной работе. Основываясь на полученных замечаниях, инженер сможет оценить свои сильные и слабые стороны и направить усилия в нужное русло. Помните, что по комментариям можно судить не только о сотруднике, но и о человеке, который их написал. Они должны быть составлены профессионально и объективно.
Комментарии должны отражать следующие моменты:
- В какой мере разработчик выполнил свою задачу?
- Как часто он при этом демонстрировал профессионализм и ключевые навыки?
- Что улучшилось за период оценивания?
- Что нужно улучшить?
Комментарии должны обладать следующими свойствами:
- Объективность;
- Полнота;
- Правдивость;
- Специфичность относительно предметной области;
- Положительное заключение.
Аспекты, которым нужно уделить внимание
Посещаемость
Прежде всего нужно понять, появляется ли разработчик на работе вообще. Учитывайте время прибытия, отъезда и отсутствия. Если кто-то из команды приходит на работу поздно, надолго покидает рабочее место, уходит раньше, чем нужно, или берет больничный без уважительной причины, он точно не стремится выкладываться на полную. Помните, что плохая посещаемость может быть вызвана не только банальной ленью, но и более серьезными причинами, например, отсутствием мотивации, проблемами со здоровьем или эмоциональным выгоранием.
Уклонения от выполнения своих обязанностей на работе может стать дурным примером для всей команды. Другим разработчикам из-за этого приходится брать на себя дополнительные обязанности, чтобы как-то компенсировать отсутствие коллеги на рабочем месте. Ситуация усугубляется, если в вашей организации нехватка разработчиков, а проблема застоялась. Начните заниматься ей как можно быстрее, поскольку ее игнорирование может привести к проблемам в личной жизни и здоровье ваших разработчиков.
Оказание помощи
Мы все сосредоточены на оказании помощи клиентам, но взаимопомощь в команде также очень важна. Konowe & Associates считает, что этот пункт является одним из ключевых показателей эффективности для разработчиков: «Мы спрашиваем, кто в вашем отделе (или компании в целом) был самым отзывчивым и помогал вам больше других за последние полгода? И так получается, что эта анонимная мотивация разработчиков позволяет выявить настоящих фанатов своего дела, а не просто фаворитов руководства.»
Готовность помогать другим – важнейший элемент командной работы. Совместная работа над сложными задачами гораздо эффективнее, чем попытки свернуть горы в одиночку. Функция Review Collaboration позволяет понять, кто делится своими знаниями с другими. Она также предоставляет вам количественные показатели, которые помогут вам оценить состояние рабочего процесса ревью кода.
Навыки планирования
Все члены команды должны выполнять работу в срок. Они должны уметь правильно распоряжаться временем и ресурсами и правильно расставлять приоритеты, чтобы выполнять свою работу максимально эффективно.
Обращайте внимание на сроки выполнения и качество работы, которое могло пострадать из-за спешки ради того, чтобы уложиться в дедлайн: это поможет понять, насколько эффективно работает сотрудник. Также очень важно учитывать количество времени, затраченного на работу: если человек стабильно перерабатывает, то стоит поговорить с ним о планировании времени.
Инициативность
Хорошо, когда коллеги интересуются, могут ли они вам чем-то помочь. Еще лучше, если они видят цели и предпринимают все необходимые действия для их достижения. Инициативность – это показатель вовлеченности в работу. Определение наиболее активных разработчиков имеет важное значение для растущих компаний, где постоянно появляются новые рабочие места, а человеческие ресурсы быстро перераспределяются. Для наиболее эффективной работы нового отдела лучше всего будет снабдить его самыми инициативными кадрами. Они смогут быстро адаптироваться к новым условиям и работать на опережение.
Чтобы выявить наиболее активных членов вашей команды, «ставьте галочку» каждый раз, когда какой-либо разработчик берет на себя ведущую роль в команде.
Качество
Качество работы – это самый важный, но в то же время и самый сложный показатель эффективности, который можно измерить. Инженеры, которые работают качественно и искренне вовлечены в рабочий процесс, скорее всего, покажут лучшие результаты. Такая вовлеченность может стать критерием качества.
Производительность разработчиков не измеряется только в количественных характеристиках разрабатываемого продукта, так проблема не решается. Разработчики, пишущие лишние строки кода просто способствуют усложнению программного обеспечения из-за чего его становится тяжелее поддерживать. Вы должны понимать, на что работают ваши разработчики: на качество или количество?
Эксперты с сайта HR World предлагают оценивать качество конечного результата по количеству функций, которые были отклонены или возвращены на доработку. Вы можете воспользоваться этой методикой или выбрать другую, более подходящую под специфику вашей компании.
Вывод
Конечно, оценка эффективности в конкретных цифрах важна, однако Шерил Штайн, бизнес-тренер Monster.com, советует не ограничиваться числовыми показателями. В конце концов, члены команды – это живые люди, а не просто ресурсы. Штейн отмечает, что некоторые качества, например, умение найти подход к любому человеку, сейчас ценятся на вес золота, и такие навыки нельзя упускать из виду. Также Штейн пишет о том, как важно обращать внимание на изменение производительности труда, так как она может быть симптомом более глобальных изменений в компании.
«Снижение производительности труда может свидетельствовать об изменениях рынка или несостоятельной маркетинговой стратегии, идеи и ценностях.»
При измерении эффективности важно открыто вести диалог с командой. Люди должны знать, как вы проводите оценку и формируете выводы. Так каждый разработчик будет понимать свое положение в команде. С помощью Waydev вы можете просматривать информацию о конкретных членах команды, видеть их прогресс, помогать им в решении проблем, тем самым обеспечивая лучшую вертикальную коммуникацию внутри организации.
Какие риски таит удалённая работа IT подразделений? Какие подходы нужны для того, чтобы команда работала эффективно без необходимости установки слежки за ними? Почему удалёнке тоже нужен график? Ответы на эти вопросы можно узнать на нашем бесплатном вебинаре, который пройдет 13 мая. Записаться на вебинар.
NeverIn
В данном случае вопрос оценки и построения процессов это вопрос компетентности того, кто за это отвечает. На практике нужно убить в себе хорошего разработчика, чтобы стать таким менеджером. И это проблема, вряд ли хороший девелопер подпишется проводить планерки и следить за счастье команды, вместо того чтобы писать нетленку и получать по 5 оферов в неделю.