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

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

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

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

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

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

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

Попробуйте сократить время рабочего дня и регламентировать перерывы. Наверняка тоже самое будут чекать.
Сейчас они от усталости балду гоняют и ждут окончания рабочего дня.
Ответ написан
OnYourLips
@OnYourLips
Как по мне, адекватная выработка должна составлять минимум 55 часов за две недели.
При хорошей работе менеджеров, BA и QA - да. При плохой до 25-30 упадёт.

Как вы считаете, как лучше в таких случаях мотивировать разработчиков?
Устранять отвлекающие внимание фаторы: митинги, созвоны, аналитику.
Разработчику самому в кайф работать эффективно - это тупо не напрягает. Если разработчик имеет много зависимостей, то он начинает быть менее эффективным.

Если у разработчика нет отвлекающих факторов и он плохо работает - выгонять. Скорее всего он на расслабоне и к рабочему компу изредка подходит, занимаясь своими делами.
Если же таких разработчиков заметная доля, то проблема обычно не в них, а в бардаке со стороны менеджмента: им не дают нормально работать. Некоторые умеют это превозмогать, но это изначально некомфортная обстановка.

Ваш вопрос не на пустом месте возник и это носит массовый характер?

P.S. Удаленка или не удаленка - пофиг. Офисный работник так же будет штаны просиживать, если домотивирован. Хабр, ютуб, перекуры, кикер и т.д.
Ответ написан
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 часа. супер мидл
Ответ написан
bakotin
@bakotin
Бекенд-разработчик
Именно по этой причине менеджмент команды, всегда должна состоять из двух людей (продуктового менеджера и проджект менеджера с техническим беком). Продуктолог говорит, что делать. Проджект менеджер контролирует процесс и оценивает работу технических специалистов.

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

Иногда бывает так, что решение задачи в 2-3 строчки, а анализ и решение задачи - 2-3 дня. Когда прямо какая-то жопа с тем, что никто ничего не знает, нет нужных кред, нет какого-то кейса и прочее. Если задача обычная, и на неё идет много времени, то это уже вопросы.

Рекомендации:

1) Снизить спринг с двух недель до одной (лучше всего делать входящий созвон и ставить какие-то цели на неделю, беря сроки от самих же разработчиков).
2) Пинговать разработчиков в течение недели с вопросами "Как у вас дела, мы укладываемся ли в сроки?".
3) Попросить тим-лида отдела разработки посмотреть код и оценку задачи, чтобы он сказал, норм не норм.
4) Если он скажет, что не норм, то созвон с разработчиком с выяснением, что не так. Потом какие-то рекомендации, испытательный срок и либо реабилитация, либо слив в утиль.

P.s. обратить внимание на что разработчик тратиn время. Возможно, он кучу времени сливает на какие-то созвоны по дизайну, подготовку каких-то материалов, или фикс багов. Т.е. надо здраво понять - это слив продуктивности и нежелание работать, либо у вас идет организация через жопу, что он тратит время неэффективным способом.
Ответ написан
Я сталкивалась с ситуацией, когда разработчик забывал вписывать часть часов. Как-то раз я сама прошла по его рабочим перепискам и только на переписках нашла еще 10 часов за 2 недели, перемножила на рейт, показала ему, какую сумму он прос.... С тех пор он внимательнее относится к трекингу.
Ответ написан
dyfran
@dyfran
Назначить самого сильного и адекватного миддла экспертом группы, снизить нагрузку бизнесовыми задачами, взамен накинуть управленческой административки.

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

В любом случае оценка будет и он с ней согласится. Далее ты по этим оценкам планируешь. Сдвиги и риски будут, но не такие как сейчас в 2 раза, а если же и будут, то встает вопрос о качестве работы этого сотрудника и дальнейшего сотрудничества с ним.
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
08 дек. 2019, в 10:14
10000 руб./за проект
08 дек. 2019, в 06:49
3000 руб./за проект
08 дек. 2019, в 05:56
2000 руб./за проект