Programmation : 7 choses que votre patron est censé savoir à propos du développement de logiciel
Selon un blogueur

Le , par Michael Guilloux, Chroniqueur Actualités
Si le programmeur est au centre du développement de logiciel, le projet peut toutefois faire intervenir d’autres métiers qui doivent collaborer pour sa réussite. Malheureusement, de tous les acteurs qui interviennent dans le projet, excepté le développeur lui-même, personne ne connaît vraiment les réalités du terrain. Chaque décision prise à quelque niveau que ce soit et chaque acteur intervenant dans le projet peuvent avoir un impact majeur sur la qualité du produit final. Pour éviter ce problème, un bloggeur du nom de John Sonmez a dressé une liste de sept réalités que tout superviseur de développeur est censé savoir à propos du développement de logiciel. Le premier point concerne la dette technique.

La dette technique est le premier facteur de ralentissement du projet

Dans un projet, un développeur peut être poussé à coder de manière non optimale (non-respect de la conception logicielle, non-respect des règles de codage, etc.) pour aller plus vite, à la demande de son patron ou pour respecter un planning trop serré. Cela induit des coûts supplémentaires dans le futur (un peu comme des intérêts). En voulant aller vite, les développeurs contractent en effet une dette technique qu’ils doivent rembourser tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents. Au final, la contrainte d'aller vite n'a réussi qu'à ralentir le projet.

Soit on fait de la qualité, soit on va vite ; on ne peut pas poursuivre les deux objectifs à la fois

Cette deuxième réalité a un point commun avec la première. Sonmez estime que le développeur n’a pas le choix lorsqu’on lui demande d’accomplir dans un bref délai une certaine tâche. Lorsqu’il est sous pression, le développeur utilise certains raccourcis et le résultat est un travail bâclé, un grand désordre parfois. Il laisse en plus une dette technique pour tous ceux qui devront poursuivre le projet. Pour éviter ce problème, le bloggeur suggère de montrer au patron que « vous pouvez le faire soit bien, soit rapidement », avec par exemple des statistiques ou études officielles à l’appui.

Un meilleur équipement est l'investissement le moins cher à la productivité

Le matériel est l’un des meilleurs investissements pour le programmeur, même si cela lui permet de gagner seulement une demi-heure de travail par jour. Malheureusement, beaucoup de patrons négligent encore cela selon Sonmez. Pour ne pas que sa productivité soit remise en cause, le bloggeur estime que le développeur doit insister sur la nécessité d’avoir du matériel performant, ou si possible chercher un autre emploi où son manager sera plus avisé à ce sujet.

Les nouvelles technologies ne sont en général pas aussi risquées que certains le pensent

De nombreuses entreprises restent attachées à leurs vieilles technologies estimant qu’il est risqué d’adopter les plus récentes, mais elles n’ont pas toujours raison. Dans le cas d’un framework ou d’une bibliothèque par exemple, une ancienne version peut introduire certaines vulnérabilités. Passer aux nouvelles technologies peut donc être le choix le plus judicieux.

« Certains développeurs peuvent réellement produire moins que 0 code »

Dans une équipe, les compétences varient d’un développeur à l’autre, mais les membres de l’équipe doivent se compléter et faire en sorte que chaque ligne de code écrite par chacun d’entre eux puisse permettre de résoudre un problème, pas d’en créer un autre de plus. Certains développeurs peuvent être d’une incompétence qui saute aux yeux. Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron, sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.

Les estimations sont inutiles

Une chose que Sonmez croit et qu’il estime que même les meilleurs managers pourraient ne pas savoir, c’est que les estimations qui se projettent au-delà de deux heures dans le futur sont sans valeur. Il explique cela par le fait que presque chaque projet représente un territoire pratiquement inexploré, et que l'imprévu peut se produire à tout moment. Si les superviseurs veulent toutefois faire des estimations, les développeurs devraient soit tenter de les convaincre que cela n’est pas utile, soit insister sur un découpage très fin des tâches de sorte que les estimations ne couvrent que de courtes périodes.

Les analystes d’affaires et les chefs de projet ont-ils encore leur place dans un projet de développement de logiciel ?

Là où le bloggeur s’est montré radical, c’est au sujet de la place qu’occupent les analystes d’affaires et les chefs de projet dans le développement de logiciel. Sonmez reconnaît avant tout qu’il y a absolument des analystes et chefs de projet efficaces, mais il estime que dans la plupart des cas, ils ne sont pas vraiment utiles. Il voit plutôt ces métiers dans un contexte où « tout le monde faisait du développement en cascade et les développeurs ne parlaient pas aux clients directement » et en plus où on avait « besoin de quelqu'un pour créer un énorme diagramme de Gantt », explique le bloggeur.

Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients. Il estime qu'il serait plus avantageux pour le client comme pour le développeur, s'il n'y avait aucun intermédiaire entre les deux parties. Il considère le métier d’analyste comme un métier boiteux qui fait une moitié du travail du développeur, mais qui ne peut pas faire l’autre moitié. En ce qui concerne les chefs de projet, Sonmez pense que les patrons devraient savoir que ceux-ci n’ont pas leur place dans un monde Agile, parce qu’au final, ils finissent par se mettre sur le chemin de tout le monde en voulant se montrer importants.

Source : Simple Programmer

Et vous ?

Que pensez-vous de 7 réalités que les patrons devraient savoir selon le bloggeur ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Jarodd Jarodd - Membre expérimenté https://www.developpez.com
le 13/08/2015 à 9:00
C'est plein de bon sens. Mais c'est utile de répéter ce qui paraît évident car quand on a la tête dans le guidon, on oublie l'essentiel.
J'envoie de suite ce billet à mon chef de projet qui fait l'inverse de tous ces conseils

Pour éviter ce problème, le bloggeur suggère de montrer au patron que « vous pouvez le faire soit bien, soit rapidement », avec par exemple des statistiques ou études officielles à l’appui.
Ca aurait été sympa de sa part de nous donner des statistiques ou des études officielles. Ce blogueur nous rappelle l'évident et nous laisse chercher ce qui est difficile à trouver...
Avatar de NSKis NSKis - En attente de confirmation mail https://www.developpez.com
le 13/08/2015 à 9:10
Le patron sait une seule chose et cela lui suffit amplement:

Tu peux disposer de développeurs en Roumanie, Pologne, Ukraine et Macédoine (pour parler du continent européen) pour un salaire minimalesque et je ne parle pas des nombreuses sociétés européennes qui ont délocalisé leur développement info en Inde ou au Vietnam (en comparaison le smicard passe pour un roi du pétrole!!!)

Les autres points, il s'en balance...
Avatar de Kearz Kearz - Membre expert https://www.developpez.com
le 13/08/2015 à 9:46
Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron, sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.
C'est surement pas au collègue de juger ça. Potentiellement un audit, un N+1 (CP technique, lead dev) mais surement pas un collègue.

Le patron sait une seule chose et cela lui suffit amplement:

Tu peux disposer de développeurs en Roumanie, Pologne, [...]
S'il le savait vraiment et savait vraiment mettre au point ce genre d'offshore, on serait tous au chômage ou presque.
C'est comme la fabrication en chine, beaucoup d'entreprise on fait marche arrière avec les sur-coûts (transport, etc) et délais. C'est pareil, faire du offshore, même en informatique, il y a de coût caché.

S'il voulait vraiment réduire les coûts par le changement de la main d'oeuvre, ils commenceraient par offrir plus de poste de développeur au bac+3.
Avatar de Anne Au Nîmes Anne Au Nîmes - Futur Membre du Club https://www.developpez.com
le 13/08/2015 à 9:53
Soit on fait de la qualité, soit on va vite ; on ne peut pas poursuivre les deux objectifs à la fois
C'est malheureusement partout pareil, pas que dans le monde de la programmation. Et comme partout, pleins de patrons ne l'ont pas assimilé, surtout ceux qui ne connaissent pas le produit qu'ils vendent et qui sont juste des gestionnaires ou des vendeurs.

Tu peux disposer de développeurs en Roumanie, Pologne, Ukraine et Macédoine (pour parler du continent européen) pour un salaire minimalesque et je ne parle pas des nombreuses sociétés européennes qui ont délocalisé leur développement info en Inde ou au Vietnam (en comparaison le smicard passe pour un roi du pétrole!!!)
Hors Europe, il y a quelques années, c'était Madagascar, également pour d'autres activités commme le SEO. Aujourd'hui, les Tunisiens "arrivent en force".
Moi j'aime bien dire à ces patrons "Vous voulez du pas cher? Aucun problème, vous en aurez pour votre argent!".

Blague à part, cela a aussi un effet pervers : tirer les prix vers le bas, ce qui implique des grosses incompréhensions quand des boîtes qui refusent de s'aligner sortent des prix que ces patrons jugent pharaoniques. Tu as beau leur vendre l'expérience, les méthodes AGILE, les tests, la doc, le suivi... Ils s'en foutent, ils veulent juste "un truc qui marche".

Les estimations sont inutiles [...] les meilleurs managers pourraient ne pas savoir, c’est que les estimations qui se projettent au-delà de deux heures dans le futur sont sans valeur [...] les développeurs devraient soit tenter de les convaincre que cela n’est pas utile, soit insister sur un découpage très fin des tâches de sorte que les estimations ne couvrent que de courtes périodes.
Amen

Les analystes d’affaires et les chefs de projet ont-ils encore leur place dans un projet de développement de logiciel ?
[...] Sonmez pense que les patrons devraient savoir que ceux-ci n’ont pas leur place dans un monde Agile, parce qu’au final, ils finissent par se mettre sur le chemin de tout le monde en voulant se montrer importants.
Situation vécue récemment. C'est à la limite du supportable parfois. Autant le CP est utile pour centraliser les demandes du client, autant en réunion ou en démo, il veut trop "se montrer", coupe la parole, alors que souvent il ne connait pas mieux la demande du client que toi (car entre le temps où il te la transmise et le moment où tu l'a concrétisée tu as contacté le client pour avoir plus d'infos), sans parler souvent du volet technique, où les CP sont souvent à la rue (bien que j'en ai vu qui étaient meilleurs que les membres de leur équipe).
Avatar de DarkBakura DarkBakura - Membre actif https://www.developpez.com
le 13/08/2015 à 9:54
Dans une équipe, les compétences varient d’un développeur à l’autre, mais les membres de l’équipe doivent se compléter et faire en sorte que chaque ligne de code écrite par chacun d’entre eux puisse permettre de résoudre un problème, pas d’en créer un autre de plus. Certains développeurs peuvent être d’une incompétence qui saute aux yeux. Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron, sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.
Bien sûr, oui. Encourageons la "délation", surtout si il y a de la diffamation dans le lot. Si X n'aime pas son collègue Y, qu'est-ce qui l'empêcherait, en raisonnant ainsi, d'aller voir le boss pour lui dire "Y est mauvais, il fout la merde dans le code" ? Même si prouver l'inverse n'est pas si compliqué, bonjour l'ambiance et la collaboration au sein de l'équipe et du management après ça.

Bref, tout ça pour dire que ce genre de conseil est assez idiot, et en dehors de la réalité. Un mauvais développeur n'a pas à être balancé par ses collègues. C'est son supérieur qui s'en rendra compte par lui-même.

Pour le reste, c'est assez logique, sans doute évident pour beaucoup d'ailleurs. Mais j'aime particulièrement le point sur les estimations, qui est malheureusement aussi juste qu'ignoré par la grande majorité des managers (du moins, pour ce que j'ai pu voir évidemment, je ne prétends pas que c'est une vérité absolue).

Par contre :
Situation vécue récemment. C'est à la limite du supportable parfois. Autant le CP est utile pour centraliser les demandes du client, autant en réunion ou en démo, il veut trop "se montrer", coupe la parole, alors que souvent il ne connait pas mieux la demande du client que toi (car entre le temps où il te la transmise et le moment où tu l'a concrétisée tu as contacté le client pour avoir plus d'infos)
Je te comprends parfaitement si tu as dû supporter un chef de projet qui voulait se faire saucer au détriment du bon déroulement de vos réunions, mais il est par contre anormal que ce soit à toi (puisque je suppose que tu es développeur) ou à tes collègues de contacter le client. Comme tu l'as justement souligné, c'est le rôle du chef de projet que de centraliser les questions de son équipe pour les soumettre au client, dont il retournera les réponses. En théorie (même si je suis conscient que dans la pratique il peut y avoir des exceptions), le développeur n'a pas à contacter le client, et doit justement laisser le soin au chef de projet de faire passer ses questions quel que soit le moment du projet. S'il ne le fait pas, alors ce n'est pas "vraiment" un chef de projet, d'où les autres problèmes que tu as dû rencontrer.
Avatar de SaiRictus SaiRictus - Membre du Club https://www.developpez.com
le 13/08/2015 à 10:15
C'est marrant ...

J'aurai clairement pu écrire cet article tellement tout ce qui y est dit est vrai !
Dette technique, défauts de conceptions, demandes "pour l'avant veille", ...

J'étais le "techos à la grande gueule" parce que j'étais toujours celui qui disait "non ... pour bien faire les choses et qu'elles soient pérennes il faut un certain temps", ce qui m'a valu "quelques désagréments" (pour rester poli).

Je me souviens notamment d'une modification qu'il fallait faire "de toute urgence" afin d'historiser les actions faites par un utilisateur dans un processus. En fait l'idée était d'enregistrer des dates pour chaque étape du processus et j'essayais d'expliquer au chef produit que c'est une modification qui, pour être bien faite, demandait du temps (ajout d'une table d'étape, ajout d'une table d'historisation) et que même si la solution simple (ajouter autant de champs date -dans la table des processus- qu'il y a d'étapes) serait plus rapide à mettre en place, elle ne serait pas viable sur le long terme (si on décide de rajouter une étape à un processus.

Mais je pourrais citer d'autres exemples.

Le matériel est l’un des meilleurs investissements pour le programmeur, même si cela lui permet de gagner seulement une demi-heure de travail par jour. Malheureusement, beaucoup de patrons négligent encore cela selon Sonmez. Pour ne pas que sa productivité soit remise en cause, le bloggeur estime que le développeur doit insister sur la nécessité d’avoir du matériel performant, ou si possible chercher un autre emploi où son manager sera plus avisé à ce sujet.
où quand ton boss refuse d'acheter une licence ReSharper alors qu'on développe avec Visual Studio et qu'on est plus de 20 développeurs (c'est pas comme ci on est une société d'édition de logiciels)
Avatar de midonet7 midonet7 - Nouveau membre du Club https://www.developpez.com
le 13/08/2015 à 10:31
Certains développeurs peuvent être d’une incompétence qui saute aux yeux.
Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron,
sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.
C'est vrai qu'on trouve dans chaque équipe au sien des entreprises ce genre de développeurs mais les patrons
ne sont pas assez stipudes de ne pas remarquer ces personnes, je pense que tant que le projet
marche bien et que les bons développeurs travail avec 150% pour corriger les erreurs des autres les patrons seront
toujours satisfaits.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 13/08/2015 à 10:38
Je ne suis pas totalement convaincu par le "toujours la nouvelle techno". à l'interieur d'une techno, essayer de passer à la dernière version est généralement un bon cas(mais on a connu une exception ici, avec un fournisseur qui lors d'une version, a mis à la benne la fonctionnalité qui rendait son truc tellement utile pour nous. 8 ans plus tard, il l'a remis, mais on a sauté quelques versions). Par contre, sur le choix de la techno proprement dite, c'est plus compliqué. Du vieux qui suffit(suivant ce que l'on fait, hein), ça peut être un choix stratégique futé. A condition d'avoir la dernière version de ce vieux.

Je me souviens d'avoir développé, en 2009, un outillage de lecture-écriture de XML pour COBOL, alors que dans la version la plus récente(qui avait déjà quelques années), ça existait déjà en natif. Là, on était clairement dans du déni de réalité. Le conseil est souvent juste. Mais pas toujours.

Pour le reste, je suis 100% d'accord. Enfin, un bon chef, c'est utile, mais on en trouve pas tant que ça.
Avatar de midonet7 midonet7 - Nouveau membre du Club https://www.developpez.com
le 13/08/2015 à 10:39
Citation Envoyé par Anne Au Nîmes Voir le message

Situation vécue récemment. C'est à la limite du supportable parfois. Autant le CP est utile pour centraliser les demandes du client, autant en réunion ou en démo, il veut trop "se montrer", coupe la parole, alors que souvent il ne connait pas mieux la demande du client que toi (car entre le temps où il te la transmise et le moment où tu l'a concrétisée tu as contacté le client pour avoir plus d'infos), sans parler souvent du volet technique, où les CP sont souvent à la rue (bien que j'en ai vu qui étaient meilleurs que les membres de leur équipe).
Le mieu c'est que le CP soit un ancien développeur afin de bien jouer le rôle d'intermédiaire entre le client et ses développeurs
Avatar de Laurent 1973 Laurent 1973 - Membre chevronné https://www.developpez.com
le 13/08/2015 à 11:17
Citation Envoyé par DarkBakura Voir le message
Comme tu l'as justement souligné, c'est le rôle du chef de projet que de centraliser les questions de son équipe pour les soumettre au client, dont il retournera les réponses. En théorie (même si je suis conscient que dans la pratique il peut y avoir des exceptions), le développeur n'a pas à contacter le client, et doit justement laisser le soin au chef de projet de faire passer ses questions quel que soit le moment du projet. S'il ne le fait pas, alors ce n'est pas "vraiment" un chef de projet, d'où les autres problèmes que tu as dû rencontrer.
Je suis pas tout a fait d'accord avec toi.

Pourquoi avoir un intermédiaire entre le développeur et l'utilisateur quand on a une question pointu?
Si au contraire ces 2 personnes se parlent (voir même se rencontre sur le lieu d'utilisation) les différents détails ou flou de spécification peuvent être levé bien plus rapidement.

D'avoir un CP ou un responsable quelconque qui face ce travail va forcement filtrer, épurer, simplifier l'information nécessaire (le plus souvent de façon involontaire, un CP est aussi un humain).
Rien ne remplacera le contact direct.

Par contre, là où je te rejoins, les développeurs ne doivent pas être dérangé par le client qui va vouloir tel ou tel correctif/amélioration pour hier ou utiliser le développeur comme hotline de support.
Contacter le responsable de la rubrique Accueil