Motiver les développeurs dans un projet perçu comme ennuyeux?

En tant que manager, je ne peux pas toujours finir par générer un travail de pointe. Certains projets fonctionnent en mode maintenance et génèrent un cash-flow libre sain pour l'entreprise.

En tant que développeur, que faudrait-il pour que vous restiez dans ce projet? J'ai pensé à renommer le travail, mais je pourrais faire avec beaucoup d'aide ici.

EDIT: Merci à tous pour les suggestions. Jusqu'à présent, voici ce que nous avons:

1. Rotation du travail selon l'intérêt du développeur
2. Environnement de travail flexible
3. Prévoyez du temps pour travailler sur des projets pour animaux de compagnie
4. Socials et fun
5. Image de marque du projet
6. Utilisez-le comme un tremplin pour d'autres projets

Pour les projets en mode maintenance, pensez à la suite. Qu'est-ce qui finira par les rendre peu attrayants pour vos clients? Pour éviter l'obsolescence, ont-ils besoin de nouvelles fonctionnalités, de meilleures performances ou d'être simplifiés? Si vous recommencez, certains projets peuvent-ils être fusionnés? Doivent-ils être construits avec différents outils, langages ou processus? Y a-t-il des améliorations ou des orientations que personne n'a envisagées? Demandez à vos développeurs de répondre à certaines de ces questions. Construisez des prototypes. Essayez un nouveau langage ou cadre. Donnez à un projet une nouvelle interface mobile.

Il est plus facile d'expérimenter des alternatives lorsqu'il n'y a pas de date limite imminente. Utilisez les temps ternes pour déjouer vos concurrents.

Vous devez leur offrir quelque chose pour occuper leur temps. Les projets en mode maintenance ne nécessitent souvent pas 40 heures par semaine de la part de chaque développeur. Si c'est le cas, il y a probablement quelque chose qui ne va pas avec le logiciel, mais d'après la façon dont vous avez posé la question, je suppose que vous cherchez des idées pour occuper vos développeurs alors qu'il n'y a pas grand-chose à faire. Je ne sais pas quel est votre budget financier, mais je pense que certaines incitations comme les envoyer à une conférence sur les logiciels pourraient être utiles. Une autre suggestion pourrait inclure explicitement leur permettant d'explorer leurs propres intérêts, disons 15 heures par semaine. Quelqu'un pourrait être intéressé à explorer, par exemple, des algorithmes de tri ou la conception de bases de données. Ce n'est peut-être pas directement lié à votre entreprise, mais je ne peux pas imaginer que vous ne bénéficieriez pas de leurs connaissances accrues à la fin. Ne les forcez pas à travailler sans rien faire. Leur permettre d'occuper leur temps avec autre chose s'il n'y a pas beaucoup de travail à faire. Je pense qu'il est juste de demander un résumé de ce qu'ils font pour s'assurer qu'ils ne naviguent pas simplement sur le Web au hasard, mais les laissent explorer un peu.

Amusez-vous à travailler sur le projet.

En fait, les projets intéressants sont assez rares. Et des études montrent que le bonheur des employés dépend fortement du social et du plaisir. Ils mentionnent massivement leurs collègues lorsqu'on leur demande pourquoi ils ne quitteraient pas leur emploi actuel.

C'est pourquoi vous devriez toujours être heureux lorsque vous entendez rire dans votre immeuble au lieu de crier.

Pour moi, le meilleur facteur de motivation dans cette situation est des objectifs très clairs, en particulier sous la forme d'une bonne spécification. Ou, plutôt que mieux, c'est l'une des rares choses qu'il vous reste à offrir. Le raisonnement là-bas est que si le travail lui-même n'est pas intéressant, savoir que je vais retravailler un tas de ces trucs ennuyeux est un énorme démotivateur supplémentaire. Cela peut dépendre du fait que le programmeur reconnaît clairement la valeur d'une spécification.

Une autre chose est de faire comprendre que si ennuyeux que cela puisse être, les projets générateurs de revenus sont pour le bien de tous - pas de revenus, pas d'emploi, etc. Le travail doit être fait, sinon vous n'aurez pas assez d'argent pour les garder à bord. Soulignez-le explicitement, parfois les gens ne s'en rendent pas compte.

Ensuite, divisez la charge. Essayez de trouver des moyens de garder des limites fixes de travail ennuyeux et ennuyeux (selon le type de travail, divisez les jours de la semaine, divisez les tâches, etc.) afin que personne n'ait le sentiment d'être coincé avec tout le désordre pendant que d'autres le font des choses amusantes.

Ensuite, essayez de l'égaler avec des choses amusantes. Et parlez aux développeurs, ils pourraient avoir de bonnes idées.

Il faut changer la perception du projet "terne". Si cela génère un revenu sain, cela ne peut pas être très difficile à faire.

Souvent, ces projets sont bons pour vos programmeurs qui sont médiocres et heureux d'être médiocres. Vous savez, les gens qui ne sont pas passionnés par la programmation et qui la considèrent simplement comme un moyen de payer les factures. Maintenant, comprenez quelque chose: je ne dis pas cela parce que ce sont des programmeurs plus faibles et que vous voulez rendre leur vie misérable. Je dis cela parce que ce sont généralement les types de personnes qui ne s'attendent pas à ce que leur travail soit une source d'épanouissement dans leur vie. À en juger par ces sons, ceux-ci ressemblent à des flux de revenus stables et à basse pression. Plus que probablement, ces travailleurs sont plus qu'heureux de prendre un travail facile et à basse pression.

Bien sûr, cela ne signifie pas que vous pouvez simplement leur confier des tâches ennuyeuses et les oublier. Peut-être pourriez-vous donner à vos "joueurs A" 80% de tâches amusantes / 20% de tâches ennuyeuses, vos "joueurs B" pourraient être 50/50 et vos "joueurs C" pourraient être 20/80.

Laissez vos développeurs gagner du temps rémunéré en travaillant sur leur propre animal de compagnie / open-source / projets intéressants en effectuant un travail de grognement. Offrez-leur un soutien pour ces types de projets, surtout si le travail porte sur un projet ou un programme interne. C'est une stratégie que Google utilise, je pense?

Je dois admettre que je n'ai jamais travaillé sur un projet ennuyeux et sans intérêt, donc je ne suis pas sûr de comprendre votre question. Et je développe des systèmes d'entreprise pour vivre. :) Sérieusement, dans la pratique, j'ai trouvé que les programmeurs sont gênés par un travail "ennuyeux" beaucoup moins que ce à quoi je m'attendais. Un travail inutile, comme remplir des feuilles de temps que personne ne vérifie, est un problème beaucoup plus important. Cela étant dit:

Connaissez vos préférences de programmeurs; certains programmeurs n'aiment pas l'interface graphique, certains s'éloignent de SQL. Essayez de respecter ces préférences, car une tâche ennuyeuse pour un programmeur peut être amusante pour un autre. S'il n'est pas possible de diviser le travail de cette manière pour une raison quelconque, rendez-le intéressant en augmentant la concurrence - laissez-les rivaliser qui sera le premier à terminer sa partie, ou créez un tableau de bord sur la partie du code qui a le moins de quantité des bogues dans le contrôle qualité. Microsoft est connu pour sa culture d'entreprise qui fait que les programmeurs se font concurrence sur différentes approches et choisissent finalement la meilleure ou incorporent les meilleures parties de chaque approche dans le produit final.

Posséder une partie du produit et en avoir le contrôle augmente également considérablement son engagement. En revanche, il n'y a rien de plus ennuyeux que d'avoir quelqu'un pour gérer votre travail. De plus, s'il y a une tâche récurrente que tout le monde déteste, expliquer la situation dans son ensemble - que c'est quelque chose qui doit être fait et pourquoi et faire tourner la personne qui le fait chaque semaine est généralement plus que suffisant.

J'ai eu / vu du succès à utiliser ce type de projet comme chemin vers les plus intéressants.

Si vos nouveaux développeurs et ceux de niveau intermédiaire commencent tous dans des projets "ennuyeux" en posant des questions aux développeurs seniors (qui sont sur les autres projets la plupart du temps) et vous indiquez clairement que mieux vous faites dans le domaine de la maintenance, plus vous êtes susceptible d'obtenir une implication future dans le nouveau travail, puis en supposant que vous avez une équipe décente et en fait suivre le changement d'équipe occasionnel et en attirant occasionnellement les principaux développeurs sur le nouveau travail, les équipes s'aligneront.

Si vous avez une mauvaise équipe, ou une très bonne équipe, cette approche peut ne pas fonctionner pour vous.