Мотивация программистов на удаленке. Что делать?

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

Я столкнулся с ситуацией, когда один из разработчиков закрывает слишком мало задач в течение ДВУХНЕДЕЛЬНОГО спринта - при работе на фултайме на проекте разработчик билит 30-40 часов на решение задач + 5-8 часов на митинги/созвоны.

Как по мне, адекватная выработка должна составлять минимум 55 часов за две недели.

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

Как вы считаете, как лучше в таких случаях мотивировать разработчиков?
  • Вопрос задан
  • 1587 просмотров
Пригласить эксперта
Ответы на вопрос 9
Sanes
@Sanes
4 часа на задачи и 1 час на менеджмент. Итого 25 часов в неделю.
Всё, что больше, либо обман, либо скоро этот работник уйдет в запой. Из-за высокой нагрузки.

ps. Я бы фултайм ограничил 5-6 часами. Толку всё равно не будет от 8 часов и более.

Попробуйте сократить время рабочего дня и регламентировать перерывы. Наверняка тоже самое будут чекать.
Сейчас они от усталости балду гоняют и ждут окончания рабочего дня.
Ответ написан
Sanasol
@Sanasol
нельзя просто так взять и загуглить ошибку
Так и не понял проблема в том что мало часов или мало задач закрывает.

Мало часов - может он просто не умеет их считать? Cчитает чисто кодинг например, а там как раз и будет в лучшем случае 4-5 часов в день, в зависимости от количестве переговоров/сложности тестирования и другой работы помимо написания кода.

Если мало задач, то может быть не может делать так быстро как вам хочется? В таком случае надо анализировать почему он мало закрывает(а может ли вообще больше?).

4-5 часов кодинга это прям самый максимум при обычном рабочем дне у меня.
6-8 часов кодинга это уже когда рабочий день 10-12+ часов.

Иногда бывают перекосы в сторону времени кодинга, но это когда прям есть большой объём работы и четко знаешь что делать и как правило это какая-то рутина в виде большого рефакторинга или добавления плюс минус одной и той же логики в большой количество мест. Во всех остальных случаях половину времени проводишь в браузере/софте для тестинга/за ковырянием базы/переписками и разными уточнениями.
Ответ написан
Комментировать
@beduin01
Да все эти часы -- абстракция. Некоторые задачи могут требовать в 10-20 раз больше времени чем ожидалось.
Ответ написан
Комментировать
Griboks
@Griboks
слишком мало задач

30-40 часов

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

А что он вам может ответить? У него в контракте записана норма времени?
Ответ написан
@vism
Ну, работая через трекер пришел к тому, что редко когда продуктивно получается больше 25-30 часов в месяц. При этом выполняю намного больше, чем 40+ в офисе. Как потом понял половина времени у всех имитация деятельности и возможности сходить покурить/поиграть/поболтать. Не более 15-20 часов реальной работы было.
Просто честный вам попался, не бидит по 40 часов.
Ответ написан
Комментировать
Robur
@Robur
Знаю больше чем это необходимо
Как по мне, адекватная выработка


Адекватная выработка - это то на сколько вы договорились. Если это 10 часов, то 10 будет адекватно. Если 100 - адекватно будет сто. Если "как по вам" не совпадает с тем как договорились или не договорились никак - обсудите с ним.

Если разработчик обещал работать 55 часов а работает 35-40, в первую очередь спросите почему у него самого. Может быть у него ребенок болеет, выгорел, считает что этого достаточно, стыдно тратить ваш бюджет сверх меры и куча еще причин про которые вы не узнаете пока не спросите.

Дальше - уже по результатам разговора - прична ясна - устраняем или меняем работу с ее учетом, если не ясна - то думать дальше.

Как вы считаете, как лучше в таких случаях мотивировать разработчиков?

Нет правильного ответа - вам могут подсказать варианты, но какой сработает в конкретным человеком вы узнаете только проверив.
Самих вариантов масса - но в итоге все упрется в вашу способность понять человека, вывести его на откровенный разговор, и определить что его угнетает и что его лично мотивирует.
Ответ написан
Комментировать
@jamtuson
Без начальника за спиной очень тяжело мотивировать сотрудника.
Слышал много историй от рабочих на удаленке, который ухитряются ставить программы, которые мышкой дергают за них и клавиши тыкают, чтоб время трекалось. Или смотрят сериал параллельно работе, что тоже влияет на продуктивность.

Мотивируйте или кнутом(угрозой увольнения, понижением рейта) или пряником(премия за досрочную сдачу, повышением рейта за продуктивную работу). Как - то жестко вы, все равно, его не сможете проконтролировать.
Ответ написан
vvpoloskin
@vvpoloskin
Инженер связи
Как-как, вот тебе план - сделать за неделю, не сделал -премия, сделал за три дня +премия.
Вот обычно критикуют наличие нормальных должностей вида инженер/старший инженер/ведущий инженер/эксперт и т.д. а зря. Если прозрачна штатная структура и система назначения, то все отлично. Мы малоактивным инженерам этим примеры роста показывали.
Ответ написан
Miay
@Miay
Full stack engineer
они все врут, если задача интерсная я могу написать все один в реальаймеза 2+-3 часа. супер мидл
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы