Aragnis, c'est toi qui apparemment connaît rien. Dans une entreprise les objectifs ont toujours un but financier donc de rentabilité, tu me dis cependant comment tu fais pour dire au développeur : tu dois me rapporter x milliers (ou millions comme tu veux) par mois ? Même chose pour n'importe quel métier d'ailleurs. Non ça ne marche pas comme ça, les objectifs sont des chiffres pas des aspects financiers par exemple corriger x bugs par mois, faire x développements par mois, traiter x requêtes support par mois etc.
Et sans vouloir te contredire, y en a qui savent très bien pisser du code, d'autres qui en sont incapable mais qui sont capable de diriger par exemple.
Concernant les bugs, je vais te parler de deux entreprises où j'ai bossé (je donne pas de nom).
La première, ils avaient un bug sur la facturation : régulièrement le client ne pouvait avoir sa facture à cause de différences entre la commande et la facture, souvent de l'ordre de 0,01 centimes d'euros (oui oui tu as entendu moins de 1 centime d'euro d'écart). Ca faisait des années qu'ils avaient le problème sans jamais l'avoir corrigé (le produit était un module e-commerce pour Wordpress).
Quand je suis arrivé dans l'entreprise, après avoir fait le dev qui m'a été demandé : un générateur de code-barres (gérant TOUT les code-barres du monde), je me suis penché sur certains des plus gros bugs du produit.
Quand j'ai discuté avec mon collègue de ce problème, sa réponse fût la suivante : "on peut pas corriger ce bug, c'est trop compliqué". Je demande au chef de projet qui me renvoi sur le dit collègue car c'est lui qui s'en occupe.
Je vais voir le patron qui me donne autorisation pour corriger le problème.
Il m'a fallut 5 minutes pour trouver la source du problème : pour chaque produits, dans la base de données ils stockent des arrondis, puis ils font un arrondis en plus sur le panier qu'ils stockent et réutilises ensuite, sans compter les arrondis sur la TVA bref tout était fait avec des arrondis dès le départ.
Résultat, visuellement comme ils faisaient encore un arrondis tout était bon, en pratique non des différences qui pouvaient être importantes en plus suivant le prix des produits du panier, posaient le problème.
En facturation on ne fait JAMAIS d'arrondis. L'arrondis c'est sur le prix final qu'on le réalise. Même si sur une facture tu as toujours que 2 chiffres après la virgule, on arrondis sur le visuel pas lors des calculs (je te laisse aller te renseigner sur comment fonctionne une facture si tu me crois pas).
Pour corriger le problème il m'a fallut 10 minutes seulement + 30 minutes à faire des tests dans tout les sens afin de confirmer la correction du problème. Pas possible cependant de corriger pour les factures existantes, il faut simplement forcer un recalcul du panier (je sais pas si au final ils l'ont fait, car je suis partis peut après avoir fait cette correction, donc je sais pas s'ils ont appliqués ce que j'ai dit), mais pour les nouvelles commandes plus aucun soucis.
Donc en moins d'une heure, ce bug a été corrigé et pourtant j'étais stagiaire (en stage pour 6 semaines seulement), alors que les devs qui étaient là depuis des lustres disaient sans cesse au patron qu'on pouvait pas corriger, que c'était trop compliqué.
On voit donc celui qui est compétent et celui qui en a rien à carré.
Ensuite seconde entreprise : le chef de projet est très bien pour gérer un projet, en revanche quand il s'agît qu'il code il va au plus pressé même s'il sait très bien que ça crée un bug, sa politique : on s'en fiche on va au plus vite comme ça on a finit, et ont corrigera quand le client le demandera.
Alors que la livraison au client ne se fait de toute façon qu'à la fin de la durée prévue et non dès que le boulot est finit (dans mon cette entreprise je parle ^^), donc que tu pisses du code buggé jusqu'à la moelle en 10 minutes ou que tu pisses du code fonctionnel en 2h, si on te donne 3 jours pour faire le boulot, ça revient au même sauf que tu as mal fait ton boulot d'un côté alors que de l'autre tu as fait le travail de façon pro.
Mon collègue qui était là depuis assez longtemps (depuis le début de l'entreprise les 2 sont là en fait), lui pense comme moi : quitte à attendre pour livrer le client, autant faire du bon travail. Donc lui sur ce qu'il doit coder, il se fait chier à coder correctement, résultat relativement peut de bugs et quand il y en a, le code étant propre il corrige sans trop de difficulté ; quand le chef de projet lui va passer plusieurs heures à corriger son code quand il a une couille dans son potage.
Moi j'ai travaillé comme mon collègue, et résultat le client est content du boulot que j'ai fait et pour les retours que j'ai (c'était une mission de 6 mois donc je suis plus dans l'entreprise), assez peut de corrections de bugs à faire dans ce que j'ai fait et pourtant c'était en plus la première fois que je codais en VBA donc en plus sur un langage que je connaissais pas.
Au final dans mes deux expériences, j'ai constaté la chose suivante : des personnes qui en ont rien à foutre et pisses du code pourris et buggé à mort, quand à côté moi (et mon collègue pour la seconde entreprise), on fait bien notre boulot et du coup moins de corrections à faire, donc gain de temps mais aussi d'argent pour l'entreprise et un client qui est content que tout fonctionne.
Alors excuse moi, mais quelqu'un qui pisse correctement son code, c'est des problèmes en moins que devra chercher à résoudre le support, surtout si c'est un problème du code et que les devs doivent retoucher le code pour corriger (ce qui fait patienter le client qui finit un jour par en avoir ras le cul et ça se comprends).
Donc pour revenir au sujet original, si les devs font du bon boulot, moins de boulot pour le support donc aucun intérêt à garder du personnel qui coûte des sous inutilement. Et c'est là où tu comprends rien au fonctionnement qu'une entreprise doit avoir. Toi tu pars du principe qu'on embauche et on licencie jamais ; ben non, une entreprise à besoin de personnel efficace ET utile, si le personnel fait pas son boulot il dégage (logique) ; en revanche s'il fait bien son boulot mais qu'il n'est plus utile logique aussi de le licencier.
Faut pas voir le licenciement toujours comme une mauvaise chose quand une entreprise va bien financièrement. Si se sont des personnes qui apportes rien à l'entreprise parce qu'elles n'ont pas de boulot, on dépense pas de l'argent en les gardant.
C'est comme la seconde entreprise où j'ai bossé, ma mission était de 6 mois et le client à la fin ne savait finalement pas s'il allait nous donner le boulot qui était prévu ou non car il avait perdu une partie de ses budgets, résultat au lieu de me prendre en CDI ou de prolonger le CDD, ben rien n'a été fait ; alors certes j'ai pas été licencié puisque je suis allé au bout de ma missison, mais je n'étais plus utile pour l'entreprise. J'aurais donc été en CDI ça aurait été un licenciement, comme c'était une fin de contrat y a pas eu de renouvellement tout simplement.
Dans la pratique l'entreprise avait un employé et qu'un coup en avait un de moins, sans que se soit ce dernier qui ai choisi de partir ; le résultat étant donc : -1, mais tu vas dire que c'est scandaleux bien entendu. Mais par contre quand se sont les opérateurs télécoms français (SFR et BT en tête) qui licencies à tour de bras sous des prétextes fallacieux (SFR), là on dit rien bien entendu.
|