Мотивация разработчиков в проекте воспринимается как скучно?

20

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

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

РЕДАКТИРОВАТЬ: Спасибо всем за предложения. Итак, вот что мы получили:

  1. Ротация работы в соответствии с интересами разработчика
  2. Гибкая рабочая среда
  3. Отведите время для работы над любимыми проектами
  4. Социальные сети и веселье
  5. Брендинг проекта
  6. Используйте это как трамплин для других проектов
Fanatic23
источник

Ответы:

8

Для проектов в режиме обслуживания подумайте, что будет дальше. Что в конечном итоге сделает их непривлекательными для ваших клиентов? Чтобы избежать устаревания, нужны ли им новые функции, улучшенная производительность или их нужно упростить? Если вы начнете сначала, можно ли объединить несколько проектов? Должны ли они быть построены с использованием различных инструментов, языков или процессов? Есть ли улучшения или направления, которые никто не рассматривал? Пусть ваши разработчики ответят на некоторые из этих вопросов. Сборка прототипов. Попробуйте новый язык или рамки. Дайте проекту новый мобильный интерфейс.

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

Корбин Март
источник
отличное предложение для мобильного интерфейса.
Fanatic23
19

Вы должны предложить им что-то, чтобы занять их время. Проекты в режиме обслуживания часто не требуют 40 часов в неделю от каждого разработчика. Если это произойдет, то, вероятно, что-то не так с программным обеспечением, но, исходя из того, как вы задали вопрос, я предполагаю, что вы ищете идеи, которые могут занять ваших разработчиков, в то время как не так уж много нужно сделать. Я не знаю, каков ваш финансовый бюджет, но я думаю, что некоторые стимулы, такие как отправка их на конференцию по программному обеспечению, могут быть полезны. Другое предложение может включать явное разрешение им изучать свои собственные интересы, скажем, 15 часов в неделю. Кто-то может быть заинтересован в изучении, скажем, алгоритмов сортировки или проектирования баз данных. Возможно, это не имеет прямого отношения к вашему бизнесу, но я не могу представить, что в конечном итоге вы не выиграете от их возросших знаний. Только не заставляйте их работать, ничего не делая. Позвольте им занимать свое время чем-то другим, если не так много работы. Я думаю, что было бы справедливо попросить краткую информацию о том, что они делают, чтобы убедиться, что они не просто беспорядочно просматривают веб-страницы, но позволяют им немного изучить.

Pemdas
источник
+1. Я также думал о сокращении рабочего времени примерно до 30 в неделю.
+1, я согласен, что гибкий график работы должен помочь в таком случае, но не сократить время.
Fanatic23
1
+1 дополнительно: вращайте разработчиков на регулярной основе, следуя прозрачной схеме, например, каждые 6 или 12 месяцев
free_easy
+1 за то, что дал время изучить их интересы. Многие компании (включая Google) следуют этой же практике, чтобы генерировать идеи для новых проектов.
Эван Плейс
7

Сделать это весело для работы над проектом.

На самом деле интересные проекты довольно редки. А исследования показывают, что счастье работников сильно зависит от общения и веселья. Они массово упоминают коллег, когда их спрашивают, почему они не покидают свою нынешнюю работу.

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


источник
6

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

Джесси Милликен
источник
1
И предложите им бонус, если они смогут рефакторинг источника до половины его размера.
Марк С
4

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

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

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

инка
источник
3

Вы должны изменить восприятие «скучного» проекта. Если это приносит здоровый доход, это не может быть очень трудно сделать.

hplbsh
источник
1
да, работает над брендингом.
Fanatic23
2

Часто эти проекты хороши для ваших программистов, которые посредственны и счастливы быть посредственными. Вы знаете, люди, которые не увлекаются программированием и просто рассматривают его как способ оплаты счетов. Теперь поймите кое-что: я не говорю это, потому что они слабые программисты, и вы хотите сделать их жизнь несчастной. Я говорю это потому, что обычно это те люди, которые просто не ожидают, что их работа станет источником удовлетворения в их жизни. По звукам это звучит как низкое давление, постоянные потоки доходов. Скорее всего, эти работники более чем счастливы выполнить легкую работу под низким давлением.

Конечно, это не значит, что вы можете просто дать им скучные задания и забыть о них. Возможно, вы могли бы дать своим игрокам "А" 80% веселых заданий / 20% скучных заданий, ваши "игроки Б" могли бы быть 50/50, а ваши "игроки С" - 20/80.

Джейсон Бейкер
источник
1

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

philosodad
источник
1

Я должен признать, что я никогда не работал над скучным и неинтересным проектом, поэтому я не уверен, что понимаю ваш вопрос. И я разрабатываю корпоративные системы для жизни. Серьезно, на практике я обнаружил, что программистам надоедает "скучная" работа гораздо меньше, чем я ожидал. Бесполезная работа, такая как заполнение расписаний, которые никто никогда не проверяет, - гораздо большая проблема. Что, как говорится:

Знайте свои предпочтения программистов; некоторые программисты не любят графический интерфейс, некоторые избегают SQL. Старайтесь уважать эти предпочтения, поскольку задача, которая скучна одному программисту, может доставлять удовольствие другому. Если по какой-либо причине невозможно разделить работу таким образом, сделайте ее интересной за счет усиления конкуренции - пусть соревнуются те, кто первым завершит свою часть, или составьте табло, на части кода которого было наименьшее количество ошибок в QA. Microsoft известна своей корпоративной культурой, которая заставляет программистов конкурировать на разных подходах и в конечном итоге выбирать лучший или включать лучшие части каждого подхода в конечный продукт.

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

Domchi
источник
0

Я имел / видел успех с использованием такого рода проекта в качестве пути к более интересным.

Если все ваши новые и средние разработчики начинают работать в «скучных» проектах, задавая вопросы старшим разработчикам (которые большую часть времени участвуют в других проектах), и вы даете понять, что чем лучше вы работаете в области обслуживания, тем больше скорее всего, вы будете вовлечены в новую работу в будущем, а затем при условии, что у вас есть достойная команда, и вы действительно будете периодически менять команду и время от времени привлекать главных разработчиков к новой работе, команды будут объединяться.

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

Билл
источник
2
Проблема с этим подходом состоит в том, что он может привести к высокому начальному обороту. Я понимаю, что иногда вам приходится ждать, чтобы получить то, что вы хотите, но зачем мне работать в компании, которая начнет меня с рутинной работы, когда есть множество других компаний, которые назначат мне более интересные проекты для начала?
Джейсон Бейкер
1
Я думаю, что вы описываете исключение "очень хорошая команда". Вы не можете сделать это с командой, где каждый является старшим разработчиком. Если вы не являетесь старшим разработчиком, то, как правило, вы не собираетесь заниматься крутыми проектами, если вы все равно находитесь в бизнес-секторе. Если вы можете занять передовое положение программного обеспечения как младший разработчик, это хорошо для вас, но во многих местах это не очень вероятно.
Билл