Discussion :

[Michael Guilloux]

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

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 ?

[Jarodd]

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...

[NSKis]

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...

[Kearz]

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.

[Anne Au Nîmes]

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).

[DarkBakura]

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.

[SaiRictus]

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)

[midonet7]

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.

[el_slapper]

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.

[midonet7]

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

[Laurent 1973]

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.

[Gunny]

Mouais... Du bon et du moins bon dans cet article. Je passe sur les pubs énormes et le style clickbait.

1. Technical debt slows down a project more than anything else

C'est vrai, mais c'est plus facile à dire qu'à faire... Et ça dépend beaucoup des situations.

2. Estimates are mostly bullshit

C'est plutôt vrai aussi, en général les estimations tiennent plus du voeu pieux que de la prédiction scientifique. Le problème étant que plus on veut estimer précisément, plus on doit se plonger dans la tâche à faire. Ca prend du temps, et au bout d'un moment on finit par commencer à déjà résoudre le problème... Donner une fourchette est un peu plus réaliste
Et c'est sans compter la règle 90-90 : https://en.wikipedia.org/wiki/Ninety-ninety_rule

3. It can be done right or fast

Oui, si on veut un truc bien fait, il faut y mettre le temps et l'argent.

4. Some developers can actually produce less than 0 code

Pas trop d'accord. D'une part, dans mon expérience je n'ai pas rencontré beaucoup de devs réellement incompétents à ce point. De plus je ne pense pas que ce soit une bonne idée qu'un dev aille voir le boss pour dire que tel autre dev est trop nul. Non seulement ça crée des tensions qui ne sont pas nécessaires mais en plus c'est pour ça que l'on a des code reviews et ce genre de chose...

5. Better equipment is one of the cheapest productivity investments you can make

100% d'adccord par contre. Incroyable le nombre d'endroits où on n'a que du matériel pourri pour travailler, avec des écrans minuscules, des machines asthmatiques, un duo clavier/souris en carton-pâte, un bureau Playschool et une chaise inconfortable. Remplacer tout ça par du matériel de qualité coûte relativement peu et augmente dramatiquement la productivité : machine plus répondante, confort de pouvoir afficher plus d'informations à l'écran, moins de problèmes de santé, moins de stress... J'ai vraiment du mal à comprendre que pour autant d'employeurs la question du matos est totalement élaguée.

6. New technologies are usually not as risky as you think

Euh, oui et non. Rester à la pointe de la technologie, c'est très bien et ça évite que le projet reste encroûté et devienne obsolète, et ça permet de pouvoir évoluer rapidement (beaucoup de nouvelles technos apprtent un gain de productivité). Par contre ça a un coût (d'apprentissage, de refactoring, etc.) et un risque : difficile de voir comment une techno bourgeonnante va évoluer. De plus il faut évaluer si on a vraiment besoin du tout dernier framework javascript à la mode... et de choisir le bon, car on a un choix assez monumental sur les nouvelles technos maintenant. Pas toujours évident de s'y retrouver et faire le bon choix.

7. Business analysts and project managers don’t do shit

De mon expérience, ce n'est pas que les chefs de projet ne servent à rien, c'est que beaucoup d'entre eux sont incompétents et/ou n'ont aucune véritable formation. Chef de projet c'est difficile. Bosser avec un vrai bon chef de projet, ça change la vie : ça permet de se concentrer sur le boulot à faire plutôt que de perdre 50% ou plus de son temps à aller à la pêche aux infos et à faire des aller-retours entre 15 personnes différentes. Je n'ai pas envie de gérer des ressources, de faire des réunions d'une demi-journée, de remplir des fichiers excel, de revoir des specs 20 fois jusqu'à ce qu'elles soient finalement correctes, etc. Je suis un dev, mon boulot c'est de faire du dev ! Un bon chef de projet va se charger de tout ça pour que je puisse me concentrer sur les infos vraiment importantes pour bien faire mon travail et produire plus de code, et de meilleure qualité. Je ne demande pas à n'être qu'un pisseur de code et n'avoir aucun contact avec l'utilisateur, bien sûr, mais à avoir le moins de friction possible pour pouvoir faire mon vrai boulot (ce pour quoi je suis payé et qui est décrit dans mon contrat de travail) correctement. Une organisation agile peut évidemment être une autre solution à ce problème, mais c'est pas toujours évident à mettre en place non plus.

[_skip]

Je vais me faire l'avocat du diable parce que pour être moi-même développeur et chef d'équipe, le râbachage de généralités et de stéréotypes sur le développement chez les bloggers me gonfle un peu

J'ai l'impression de relire encore et encore un énième concentré de lieux communs sur la profession. Le développeur, ce grand incompris qui se retrouve à assumer les décisions de supérieurs bornés et incompétents qui se croient à tort plus malins que lui. Ca tourne toujours autour de la même idée, les chefs c'est mal, la hiérarchie c'est mal, <mais insérer une recommandation agile ici> c'est bien... Généralement quand on voit ce genre de pavé, y'a une petite note en bas de page: "Ah et au fait pour savoir comment faut bosser oubliez pas notre super service de coaching Agile à seulement 250$ la demi journée".

Enfin là le profil du mec c'est autre chose

John Sonmez is the founder of Simple Programmer and a life coach for software developers

Ok c'est un coach et il vend des bouquins... A peine différent. Franchement j'aimerais bien que les gars de son genre, les baratineurs et autre consultants agiles laissent un peu les développeurs tranquilles et aillent casser les pieds au monde dans une autre industrie.
Et puis il y a cette remarque :

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.

Maaaaiis bien sûr, inutiles car forcément des incapables qui se la jouent ... Même si je suis d'accord qu'on peut trouver des cas de chefs de projets ou d'analystes métier complètement nuls et les monter en épingle. Avoir un projet bien dirigé et une bonne analyse des besoins c'est juste au moins aussi important qu'avoir des bons développeurs pour le réaliser. Si on veut faire des généralités on peut aussi ironiser sur le développeur qui écarte toutes les solutions non-code et qui fait passer la technique (code, framework, etc...) au détriment du fonctionnel.

Pour l'avoir vécu, je suis au contraire intimement convaincu que l'accès direct aux développeurs c'est une erreur. Déjà parce que ces derniers ne peuvent pas être tout le temps interrompus par des demandes clients et du support, faut clairement un filtrage en aval et parce que passé le stade de la start up avec 3 clients et 2 développeurs, on sait plus du tout qui fait quoi. Les interlocuteurs se multiplient, se contredisent, plus personne sait ce qui se passe et on perd en visibilité et en productivité. Clairement pour chaque projet, faut une personne qui a la vue d'ensemble, l'historique, qui connaît les contrats et accords passés avec le client sinon on s'en sort plus.
Ca empêche absolument pas le responsable de projet de consulter les développeurs, de prendre renseignements avant d'engager l'équipe. Il peut y avoir des différences de point de vue mais au bout d'un moment si les développeurs veulent absolument tout faire à leur guise parce qu'ils pensent tout mieux savoir et avoir de mauvais dirigeants, ils ont qu'à monter leur propre entreprise et ils comprendront mieux le problème. J'aime pas cette vision du monde victimaire et stéréotypée qui fait penser à la lutte des classes.

Je passe les autres trucs du style, "les estimations c'est de la connerie (bullshit, c'est dans l'article)". C'est clair qu'on préférerait tous avoir des deadlines infinies et ne s'arrêter que quand on a atteint la perfection, seulement les estimations sont nécessaires pour chiffrer les coûts et organiser les ressources et font partie essentielle de la phase de marchandage avec le client. Sans ça point de début, point de fin, c'est moche mais rien ne peut se substituer à cela, tout le monde ne veut pas travailler sur un modèle "pay per use", on doit forcément pouvoir mettre un ordre de grandeur sur ce qu'on investit. Il y a quasiment aucun projet qui peut se faire sans une estimation, ni construction d'immeuble, route, ligne de chemin de fer. Donc c'est pas de la connerie dont on choisit de se passer ou non, c'est un problème.

[Anne Au Nîmes]

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.

C'est exactement ce cas de figure auquel je faisais référence. C'est d'autant plus le cas si chez le client tu as également des techniciens, dont les informations transmises ont été épurées par leur hiérarchie, puis encore épurées par la tienne. A la fin il ne te reste que les grandes lignes, et tu es bien content d'avoir les coordonnées du type qui fera l'intégration chez le client, de leur sys-admin, ou de l'utilisateur final.

Bien entendu, il faut que ce contact direct avec le client soit à l'initiative de l'équipe de développement et non l'inverse, car comme tu le dis, tu seras souvent importuné pour faire la hotline.

[Saverok]

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.

Il y a beaucoup à dire sur cet article mais ce point là en particulier me fait bondir !
Quand on travaille en équipe, savoir se synchroniser est indispensable tant sur les interfaces que sur le temps.

Je dirai même que savoir estimer correctement son RAF est un élément déterminant de la qualité d'un développeur.
Il est indispensable de savoir communiquer ce que l'on fait, surtout dans un métier aussi technique que le notre.
Balancé des phrases du genre "ça sera fait quand ça sera fait" est totalement absurde et désastreux en terme d'image sans parler de la planif (qui fait intervenir potentiellement énormément de monde sans parler, dans certains cas, de campagne marketing, d'envoie de courriers par milliers, de formation de plusieurs centaines d'utilisateurs, etc, etc, etc qui ont besoin d'être synchronisés et planifiés de longues dates).

Comment être crédible si on ne sait pas estimé son temps de réalisation ?
Personnellement, ça me renvoie une image de quelqu'un qui ne maîtrise pas ce qu'il fait.

Je préfère de très loin un développeur moyen mais qui sait me fixer une date de réalisation et la tenir (ou encore anticiper un retard et le remonter à temps) plutôt qu'un cador qui livre ses dev de manière erratique.

[DarkBakura]

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.

C'est justement ce dernier point que je voulais souligner avec mon message, plus que le reste. Le développeur n'est pas censé perdre son temps avec les questions clients. Mais dans la théorie (et j'insiste sur le terme), il n'est pas non plus censé être en interaction avec le client dans l'autre sens. Même s'il a des questions, il est censé les poser à son CP qui se chargera de les relayer s'il n'a pas eu d'éléments pouvant y répondre directement.
Après, cela reste de la théorie donc, et tu as tout à fait raison sur ta vision des choses, c'est évident. Il peut être bien plus avantageux de communiquer en direct avec le client pour certains points à risques, pour limiter les problèmes de déformation de l'information ou de négligeances sur certains aspects. Mais si déjà de base le CP sait poser les bonnes questions, cela permettrait de dispenser le développeur de ce genre de souci. Mais avec des si...

Comment être crédible si on ne sait pas estimé son temps de réalisation ?
Personnellement, ça me renvoie une image de quelqu'un qui ne maîtrise pas ce qu'il fait.

Je trouve souvent tes commentaires pertinents mais là, ta vision me parait très limitée.

Evidemment que dans l'idéal il est bien qu'un développeur sache estimer le temps de développement de tel ou tel projet. Sur le fond, tu as raison. Mais je vais te prendre un exemple tout bête qui nous arrive en ce moment encore dans mon équipe : comment estimer le coût en jour/homme quand tu récoltes un projet développé par une autre personne, et dont tu as à peine eu le temps d'effleurer le code ?

On a eu ce cas là cette année. Et sans documentation, avec le peu de temps que nous avions eu pour nous pencher dans le coeur du code et en comprendre tout le fonctionnement, nous avons dû estimer notre temps de travail sur les différents livrables à venir. Et évidemment, nous avons eu tout faux. Puisqu'en cours de développement ont surgi des bugs qui étaient liés à la structure même de l'architecture pensée et réalisée par une seule personne, qui n'est plus joignable et n'a laissé aucun document ou commentaire pour expliquer ses travaux. Le temps de les corriger, de comprendre comment réaliser les items suivants en respectant l'architecture de base de l'application, ça nous a mis en retard de plusieurs semaines sur le planning prévu, bien que nous ayons fini par le rattraper en partie. Cela fait-il de nous de mauvais développeurs pour autant ?

[grunk]

Comment être crédible si on ne sait pas estimé son temps de réalisation ?

Sommes nous plus crédible quand on annonce un délais de X semaines et qu'au final on livre en X+n semaines parce que comme à chaque fois on ne peut pas prévoir l’imprévisible.
Perso je suis pas capable d'annoncer un délai réaliste avant d'avoir les mains dans le code depuis un petit moment tout simplement parce que avant je n'ai pas une connaissance suffisante du projet, de sa courbe d'évolution, etc ...
C'est encore plus vrai quand on reprend de l'existant et qu'on va de surprise en surprise au fur et à mesure qu'on s'enfonce dans le code.

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

Un simple SSD pour compiler ca change tout. Sur certains projet c'est pas loin de 5min par compilation. Multiplié par les 10 ou 20 compilation que tu fais par jour ...

[astyan42]

Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients

Pour être honnête, je suis pas tout à fait d'accord avec ça quand on parle d'une boite qui a une taille respectable. Une équipe, c'est pas que des developpeurs, on a beosin de l'équipe de produit qui saura nous synthétiser les besoins clients, nous définir les priorités en fonction des clients. Sinon tant qu'on y est, pourquoi le développeur ne serait pas aussi commercial ? Pour en revenir au sujet initial, je pense que c'est un métier à part et que a partir d'une certaine taille ce poste devient indispensable.

[Laurent 1973]

C'est justement ce dernier point que je voulais souligner avec mon message, plus que le reste. Le développeur n'est pas censé perdre son temps avec les questions clients. Mais dans la théorie (et j'insiste sur le terme), il n'est pas non plus censé être en interaction avec le client dans l'autre sens. Même s'il a des questions, il est censé les poser à son CP qui se chargera de les relayer s'il n'a pas eu d'éléments pouvant y répondre directement.
Après, cela reste de la théorie donc, et tu as tout à fait raison sur ta vision des choses, c'est évident. Il peut être bien plus avantageux de communiquer en direct avec le client pour certains points à risques, pour limiter les problèmes de déformation de l'information ou de négligeances sur certains aspects. Mais si déjà de base le CP sait poser les bonnes questions, cela permettrait de dispenser le développeur de ce genre de souci. Mais avec des si...

Je tiens a préciser: je trouve important que les développeurs soient en discussion avec les utilisateurs (ceux qui utilisent le logiciel), je ne parles pas forcement des clients (ceux qui commandent, qui payent). C'est souvent pas les mêmes et de la même façon que l'on trouve un vision faussée entre (certain) CP et les développeurs, on peut retrouvé la même chose de l'autre coté entre le client (le donneur d'ordre) et les utilisateurs métiers.

Petite anecdote pour illustrer: il est important d'aller voir ces utilisateurs.

Je travaillait il y a quelque année, pour un éditeur de logiciel dans le domaine de l'analyse chimique.
Nos clients étaient, entre autre, des raffineries en pétrochimie.

On m'avait expliqué que les utilisateurs utilisaient notre logiciel, dans des labos de chimie, pour valider la qualité des carburants à la sortie de la raffinerie.
Et j'ai eu l'occasion de rendre visite à un de ces labos pour une maintenance et j'ai compris beaucoup mieux .....

En résumé: les opérateurs en pétrochimie étaient constamment debout autour de grandes paillasses de chimie où étaient posées des dizaines d'appareils d'analyses.
5 PC étaient éparpillés entres ses appareils, entre 2 machines, un vieux écran 14'' cathodique palot et à peine la place pour le clavier et la souris.
Le principale boulot de ces utilisateurs étaient de préparer des échantillons de produit à analyser, de les mettre dans l'appareil, de cliquer sur un bouton de notre logiciel et d'attendre le rapport dans l'imprimante.

Le contexte d'utilisation était complètement différent de ce que je m'imaginait dans mon bureau, assis derrière mon écran 19''.
Cette visite m'a beaucoup fait comprendre de chose sur comment faire évoluer l'ergonomie de nos interfaces graphiques utilisateurs, l'importance de la souris, des raccourcis clavier, le nombre de clique/validation pour une action ....

J'ai fait d'autre visite chez d'autres utilisateurs, pour divers raison, et j'ai aussi pu constaté d'autres contraintes: déploiement en production, temps de traitement, importance des rapports, contrainte de sécurité informatique, ...
Mais tout cela, sans l'avoir vu sur le terrain, je ne crois pas qu'un CP aurait pu me le faire comprendre correctement.

Donc, amis développeurs, allez rencontrer vos utilisateurs, allez voir comment ils travaillent.

Et puis, c'est plutôt sympa de voir utiliser notre réalisation en vrai

[smarties]

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.

Même un bac+2 sortant d'IUT suffirait. Il faudrait juste quelques développeurs expérimentés dans l'équipe pour guider le nouveau venu.