fbpx

Les 10 phrases qui énervent un développeur

Chez Atchik Services, nos activités impliquent plusieurs domaines de compétences. Et quel que soit le nôtre, nous avons tous affaire à d’éternels clichés ou phrases répétées en boucle ; il nous arrive de rencontrer des situations vécues comme énervantes, voire exaspérantes. C’est de cette somme d’expériences qu’est née cette série d’articles contenant les 10 phrases qui énervent un corps de métier.

Les 10 phrases qui énervent un développeur
CBS – NCIS

 

1. Ça marche pas !

Cette phrase est ma préférée. Je ne compte plus le nombre de fois où je l’ai entendue.
Plus vous donnez des informations à votre équipe technique et plus elle pourra reproduire puis résoudre le problème rencontré.

 

2. Mais non, t’as pas besoin de specs pour coder.

Cette phrase peut être également formulée de cette manière : Tu veux pas commencer à coder en attendant que je fasse les specs (spécifications qui n’arriveront jamais bien entendu) ?

3. Tu penses que ça va prendre combien de temps pour faire ça ? Trois jours ? C’est trop, je vais mettre un jour sur le devis !

Cette phrase peut également être formulée de cette manière : T’es sûre pour les six heures sur cette tâche ? Je trouve que ça fait trop, t’es sûre que t’as pas exagéré ?
Le chiffrage est un exercice compliqué car il faut essayer de penser à tous les cas, penser aux éventuels problèmes qui pourraient survenir et tout cela sans sur-évaluer la tâche, la fonctionnalité ou bien le projet. Si vous voulez faire un geste au client, c’est votre droit mais essayez de ne pas remettre en cause le chiffrage de vos équipes techniques :-).

4. C’est facile, cela ne te prendra que 2 minutes !

Sans connaître la complexité de l’environnement, de la plateforme, du langage ou bien du framework, c’est peut être plus facile à dire qu’à faire.

 

5. Tu peux me déplacer l’image un peu plus à gauche ? Deux minutes plus tard : un peu plus à droite. Quatre minutes plus tard : un peu plus en haut. Cinq minutes plus tard : tout compte fait, elle était bien où tu l’avais mise.

Cette phrase est valable également pour les graphistes.

6. On met le site en ligne vendredi à 17h.

you shall not release friday afternoon

S’il y a une règle d’or que les développeurs veulent respecter c’est celle là : JAMAIS de mise en production un vendredi ! Vous connaissez la loi de Murphy ? Alors dites-vous qu’elle a l’habitude de survenir principalement dans deux situations : lors d’une démonstration et lors d’une mise en ligne un vendredi.

7. Le site est terminé, on doit le mettre en ligne demain mais il rame grave et il faudrait modifier ça, ça, ça et ça.

il permet un gain de temps et une meilleure communication dans l’équipe.

8. J’ai un problème avec mon ordinateur, tu peux venir voir ?

Fonctionne aussi avec les téléphones, tablettes, imprimantes, claviers, souris, écrans, e-mails…
Ah oui j’oubliais, si Facebook ou Twitter ne fonctionnent plus temporairement, ce n’est pas la faute du développeur et, à moins qu’il ait le numéro de téléphone de Mark, le problème prendra un peu de temps à être résolu et les sites refonctionneront bien tôt ou tard ^^.

9. Ah ouais t’as trouvé le bug ? Tu mets en ligne le correctif tout de suite alors.

Cette phrase peut également être reformulée comme ceci : Ah ouais t’as trouvé le bug ? J’informe le client que c’est corrigé alors !
Entre le moment ou l’on peut reproduire un bug, trouver un correctif, packager le projet, le déployer sur la pré-production, le tester puis déployer enfin ce fameux correctif en production, il se passe généralement un peu plus de 30 secondes ;-).

Le temps peut paraître long mais toutes ces procédures sont mises en place afin de garantir une bonne stabilité de la plateforme et d’éviter, par exemple, les régressions.

10. Tu peux me chiffrer le temps que cela te prendrait pour développer cette appli/ce site ?

Cette question est très « casse-gueule » car, bien évidemment, le client ne voudra pas le même site ou la même application à l’identique ; il faudra donc prendre le temps de poser les bonnes questions et de marger car il y aura des modifications à réaliser dans tous les cas.

Bonus :

– Je veux un Google mieux que Google !
– Quoi tu pars déjà ?
– Si on est agile on doit pouvoir se passer de process.

Pour conclure :

Malgré toutes ces phrases entendues, chez Atchik Services les développeurs ne sont pas énervés. Cet article constitue une occasion de mettre en avant le fait que l’équipe de développement n’a jamais entendu autant de « merci » de la part des modérateurs, superviseurs, community managers…
Cela fait partie de notre travail de concevoir des outils leur permettant d’effectuer correctement leur travail, de leur faire gagner un temps précieux et d’essayer d’améliorer un petit peu leur quotidien ; et lorsque l’on entend un simple « merci », nous avons gagné notre journée ! 🙂

Aurélie


Licence Creative Commons
Cet article est mis à disposition selon les termes de la Licence Creative Commons Attribution - Pas de Modification 3.0 France.


Partagez cet article :

8 thoughts on “Les 10 phrases qui énervent un développeur

  1. A quand les dix phrases les + énervantes des développeurs ? J’ai quelques idées…

    – Ouais ça marche mais en local
    – C’est fait depuis longtemps mais pas mis en prod
    – Il a quelle version de Chrome le client chez qui ça plante ?
    – C’est chelou ça
    – ….

    1. Bonjour Tchoupi,
      Oui, il y a du potentiel pour faire un Top 10, voire même un Top 20 des phrases les plus énervantes dites par un développeur.

      Je rajouterais à votre liste cette phrase que vous avez du déjà entendre :
      – ça marche pour moi !

      Sinon pour votre 3ème phrase « Il a quelle version de Chrome le client chez qui ça plante ? », ça peut vous paraître inutile et exaspérant mais selon le système d’exploitation, le navigateur et la version du navigateur, un site ou une application web peut se mettre à ne pas fonctionner comme convenu. C’est pour cela que plus on donne des informations et plus vite le problème pourra être reproduit et résolu :-).

    1. Bonne remarque Xavier mais, malheureusement, toutes les entreprises/les devs ne connaissent pas l’intégration continue et n’ont pas mis en place des outils comme Jenkins ou Continuum.

      J’ai parlé des mises en ligne le vendredi soir à 17h mais j’aurais pu également parler de celles la nuit ou en week-end, qui se produisent également parce qu’il n’y a pas le choix ou parce qu’il s’agit d’une demande d’un client tout simplement.

      Bref, dans tous les cas, une mise en ligne doit être bien préparée, ne doit pas se faire dans la hâte, et si possible lorsque toute l’équipe est là :-).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *