Personne ne demandera au développeur d'écrire du code sans accès à un ordinateur, mais de nombreuses entreprises pensent qu'il doit en quelque sorte travailler sans avoir la capacité d'utiliser pleinement ses capacités mentales. Et c'est à peu près aussi irréaliste.
Et donc passons en revue une liste de douze choses qui empêchent les développeurs d'entrer dans un état de flux et de fournir une productivité maximale. Je vais essayer de passer des choses les plus importantes aux moins importantes. Suggérez vos options et commentaires!
Si quelqu'un doute qu'il vaut la peine de dépenser de l'argent et des efforts à ce sujet, il suffit de se rappeler combien les programmeurs sont payés. Même une augmentation de 10% de la productivité, c'est beaucoup d'argent!
1) Réunions et autres distractions
À mon avis, distraire le développeur est le moyen le plus sûr de tuer sa productivité dans l'œuf. Il ne peut pas simplement prendre et continuer de l'endroit où il a été interrompu. Il doit d'abord s'impliquer à nouveau dans le processus, puis parcourir toute la chaîne de pensées jusqu'au bon moment - cela seul peut prendre une demi-heure ou plus. Et plus ces ruptures se produisent, plus l'irritation s'accumule, plus la qualité du travail diminue, plus les bugs apparaissent souvent et cette liste peut être poursuivie.
«Plus je suis distrait lorsque j'essaie de commencer une tâche, plus le temps s'écoule entre les tentatives. Si j'ai été tiré toute la matinée, il n'y a rien d'étonnant à ce que la journée se révèle improductive »- Développeur anonyme avec Reddit
Et la réunion? Leur seule différence par rapport aux autres distractions est qu'elles sont planifiées à l'avance. Et cela ne fait qu'aggraver la situation. Il est difficile pour un programmeur d'avancer dans la résolution d'un problème s'il s'attend à une interruption de travail à l'avance. Par conséquent, si dans une heure ou deux, il doit se rendre à la réunion de planification, il ne sera probablement pas en mesure de faire quoi que ce soit d'important pour aucun de ses projets - après tout, la plupart des tâches d'ingénierie prennent plus de temps.
Comme l'a dit Paul Graham: "Une réunion peut tuer une demi-journée: le temps est divisé en deux périodes, pour lesquelles vous ne pouvez rien faire de sérieux."
Comment éviter cet état de fait? Tout y est peint depuis longtemps, donc il n'y a pas d'excuses. Vous avez juste besoin de mettre les raboteuses au tout début de la journée ou, disons, juste avant le dîner, afin de ne pas avoir à distraire les gens du travail sans besoin.
2) piqûre
De toutes les variétés de gestionnaires, ceux qui interviennent pour une raison quelconque, peut-être le pire impact sur la productivité des employés. Bien sûr, cela est également affecté par le fait que ce type particulier est particulièrement enclin à organiser un tas de réunions et à demander l'attention des développeurs pour des raisons imprévues. Mais ce n'est pas le seul point. De telles actions témoignent d'un manque de confiance et, de ce fait, les gens ont le sentiment d'être considérés comme incapables de quoi que ce soit et remettent en cause leurs compétences professionnelles. Même si le programmeur a toujours une certaine motivation à travailler malgré des interruptions sans fin, une telle attitude la découragera complètement. Les conséquences ne se limitent pas à une baisse de performance. Les managers intrusifs forcent en particulier souvent les employés à quitter l'entreprise, ou du moins l'équipe.
3) Pas clair
Le manque de clarté peut être illustré par de nombreux exemples différents. Par exemple, un rapport de bogue dans l’esprit "Ça ne marche pas ici, corrigez-le!" ne donne évidemment pas aux développeurs toutes les informations nécessaires au travail. Soit dit en passant, dans ce cas particulier, l'introduction d'un modèle pour les rapports de bogues peut aider.
Ou un autre cas: des exigences vagues pour une partie du produit. Avec de tels développeurs d'introduction, commencez simplement à faire ce qu'ils imaginent eux-mêmes, puis un gestionnaire fournit une description plus détaillée du comportement attendu de l'utilisateur, et ils doivent tous recommencer à zéro.
Les priorités indistinctement définies appartiennent à la même catégorie. Les programmeurs passent beaucoup de temps à se creuser la tête sur ce qu'ils devraient commencer, bien que l'éviter soit très simple. Eh bien, si jamais ils doivent rapporter au directeur pourquoi ils sont engagés dans cela et non cela (malgré le fait que personne n'ait stipulé la commande), vous pouvez être sûr que cela les rendra formidables.
4) Gestionnaires des mouettes
Avez-vous déjà entendu parler de cela? Il y a des managers qui ne participent pas du tout au workflow ... sauf pour les moments où ils décident soudain de plonger sur quelqu'un et de se tromper. "Ce n'est pas bon, et ça aussi, mais ça ne regarde pas du tout", et s'envola. Je dois admettre que j'aime la comparaison, mais le phénomène qui la sous-tend est beaucoup plus courant que nous le souhaiterions. Ce comportement affecte très mal les développeurs: beaucoup doivent ensuite travailler sur une humeur de travail pendant des heures, et quelqu'un abandonne le flux pendant des jours entiers.
5) Vol de lauriers
Vous est-il déjà arrivé qu'un des managers ou autres programmeurs se soit attribué ce que vous avez lutté pendant plusieurs semaines? Les développeurs mettent leur professionnalisme avant tout. Voler les mérites d'autrui, c'est comme refuser à une personne la compétence de gonfler la sienne. Je mets ce point suffisamment haut parce que je crois que de telles choses conduisent à une situation très tendue, qui peut pendant longtemps «baisser» les performances de toute l'équipe.
6) Ameublement: bruit, mouvement, conception de l'espace de travail ...
Cela peut sembler étrange aux personnes d'autres professions, mais pour les programmeurs, l'environnement décide beaucoup au cours du travail. Dites que le bruit blanc - le bourdonnement du climatiseur, le bruit des voitures et des camions de la rue - les aide à mieux se concentrer. C'est pourquoi beaucoup d'entre nous travaillent avec des écouteurs! Au fait, j'ai récemment découvert RainyMood - une bonne chose!
Cependant, si le bureau est conçu de manière à ce qu'il y ait toujours un certain mouvement autour de la personne, cela aura l'effet inverse. Et si, en outre, les moniteurs sont installés de telle manière que les gestionnaires voient constamment ce qui est à l'écran, cela crée un stress inutile et des raisons inutiles pour distraire les développeurs des affaires.
7) Décalage des limites du projet
En gestion de projet, ce terme est utilisé pour les situations où les volumes de projets augmentent de façon incontrôlable. Cela se produit généralement lorsque, initialement, ils n'étaient pas strictement définis et documentés ou n'étaient pas surveillés au cours du processus.
En raison du déplacement des frontières, les requêtes relativement simples se transforment en monstres confus qui mangent beaucoup de temps! Et dans la plupart des cas, cela commence lorsque le produit est déjà en développement.
Prenons par exemple une fonction simple:
- Première version (avant mise en œuvre): la fonction est définie comme "Afficher la carte de localisation"
- La deuxième version (lorsque la première itération est presque terminée): la description devient "Afficher la carte de localisation 3D"
- Troisième version (lorsque la deuxième itération est presque terminée): la description devient "Afficher une carte de localisation 3D sur laquelle l'utilisateur pourrait se déplacer"
8) Processus de détermination des caractéristiques du produit
Cela peut sembler incompréhensible à première vue, mais en fait, tout est simple. Si les responsables du produit priorisent sans tester leurs hypothèses (par le biais de commentaires ou de toute autre manière) sur l'intérêt du public pour certaines opportunités, et que les développeurs voient que ces opportunités ne sont tout simplement pas utilisées, alors ils auront le sentiment que leur travail n'a pas de sens et la motivation va s'effondrer. Nous voulons tous sentir que nous laissons une trace dans le monde, et c'est particulièrement important pour les développeurs!
9) Ignorer la dette technique
Le devoir technique est une décision consciente de permettre un certain étirement dans le choix des solutions et la rédaction du code afin de déployer le produit plus rapidement. Un certain montant de dette technique survient inévitablement dans tout projet et peut aider à respecter les délais sur de courtes distances. Cependant, à long terme, cela augmente la complexité du système et ralentit ainsi les développeurs. Les gens loin de la programmation sous-estiment souvent l'impact de ces processus sur la productivité et nécessitent d'aller de l'avant sans arrêt - dans cette situation, des problèmes commencent à se poser. Si le refactoring reste toujours en dehors de la liste des priorités, non seulement la productivité des employés, mais aussi la qualité du produit en souffriront.
10) Une variété d'outils et d'équipements
Les développeurs utilisent quotidiennement de nombreux outils pour écrire, pousser et fusionner du code. Plus ils parviennent à automatiser les processus, mieux c'est. Il va sans dire que les outils anciens auront un impact direct sur les performances. Il décide également en grande partie sur quoi le travail est effectué - sur un ordinateur portable ou également sur un écran supplémentaire. Si nous comparons les prix du fer avec les salaires des programmeurs, même une augmentation de 5% de la productivité paiera certainement tous les coûts! Il suffit de fournir à l'équipe le matériel et les outils qu'elle préfère utiliser (pour le matériel, la solution doit être individuelle, pour les outils - collectifs).
11) Documentation pratique
Dans le processus d'enseignement de la programmation, nous avons tous appris que vous devez commencer à ajouter des commentaires au code dès que possible et aussi souvent que possible. L'idée était qu'il serait préférable qu'il y ait trop de commentaires que pas assez. Malheureusement, beaucoup de gens ont mal compris cela et ont décidé que chaque ligne devait être expliquée. C'est pourquoi nous avons des exemples comme celui-ci, de l'
article de Jeff Atwood «Code sans commentaire»:
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}Comprenez-vous ce que fait ce code en général? Donc je n'ai rien compris. Le problème est que beaucoup est dit ici sur la façon dont tout fonctionne, mais pas un mot sur la raison pour laquelle cela est nécessaire. Si nous supposons qu'un bogue s'est produit dans le programme et que vous avez trouvé un tel fragment de code sous le capot, cela ne vous aurait pas aidé à comprendre la situation.
12) Délais extrêmement serrés
Le dernier point est lié à la tendance des gestionnaires à demander aux développeurs d'estimer approximativement le temps dont ils auront besoin, puis à les presser pour sous-estimer cette estimation, puis à assimiler comme par magie la date finale avec la date limite! Dans le même temps, les managers pensent même que puisque les développeurs «fixent eux-mêmes les délais», cela signifie qu'ils se sont inscrits pour la date limite correspondante et doivent être considérés comme une option finalement approuvée qui peut être transférée à la haute direction.
Les développeurs estiment qu'un tel délai est une folie totale et qu'il est impossible de le respecter; Il y a de la discorde dans l'équipe et personne ne peut se concentrer.
Mais ne s'agit-il que de développeurs?
Si vous regardez tous ces 12 points, vous remarquerez qu'ils sont, pour la plupart, pertinents pour toutes les personnes impliquées dans les projets. C'est juste que dans le cas des programmeurs, ils sont particulièrement critiques, car leur travail nécessite une immersion profonde dans le processus.
Si vous remarquez que certains des points mentionnés sont typiques pour votre entreprise, il serait bon de parcourir cette liste avec l'équipe de développeurs, de construire un dialogue avec eux, de découvrir où les problèmes surviennent et comment les résoudre au mieux. Quoi qu'ils disent, il est extrêmement important de prendre ces commentaires et commentaires au sérieux. Au cours des trente dernières années, beaucoup de choses ont changé en termes de technologie, mais le principe de base du travail d'équipe reste le même: lors de la discussion sur la performance, il est nécessaire de prendre en compte le facteur humain. Améliorez vos processus de travail, votre environnement, vos habitudes d'équipe et donnez-leur la possibilité de vous dire comment atteindre une productivité maximale.