Être développeur, c'est bien plus que développer

Vous côtoyez des développeurs dans le cadre de votre travail ? Alors, il y a de fortes chances que vous n’ayez aucune connaissance de ce qu’ils font au quotidien. Beaucoup pensent que développer est un métier facile. Après tout, il suffit d’écrire du code puis de le mettre en production en évitant les bugs.

Si vous êtes dans cette situation, ce n’est pas grave. Vous n’êtes pas le seul. Être incompris est le fardeau des métiers techniques. Et en même temps, c’est normal. Ces métiers nécessitent des compétences qui ne s’acquièrent qu’avec une formation spécifique.

C’est pourquoi, nous allons découvrir ensemble les tâches qui occupent le quotidien des développeurs. Celles dont ils doivent s’acquitter pour réussir les projets qui leur sont demandés. Vous comprendrez pourquoi il est difficile d’estimer le temps d’un projet. Et donc, pourquoi les délais sont souvent plus longs que prévus.

J’ai divisé l’ensemble des ces tâches en six catégories distinctes.

Les pré-requis du développement

Ces tâches sont un fil rouge qui suit les développeurs tout au long de leur carrière. Bien sûr, elles peuvent être ignorées. Mais cela serait au détriment de la réputation (satisfaction, bad buzz) et des finances (amendes) de l’entreprise.

• Ne pas créer de failles de sécurité : chaque développement induit un risque de sécurité en augmentant la surface d’exposition. Le développeur doit veiller à ce que les données confidentielles des utilisateurs ne soient pas exploitables par n’importe qui. Par ailleurs, des attaquants ne doivent pas pouvoir infiltrer les réseaux et les machines de l’entreprise.
• Respect les contraintes imposées par la RGPD : personne n’aime ça. Mais c’est une obligation légale qui va dans le sens de l’utilisateur. Le développeur doit respecter les règles en vigueur, à chaque nouvelle fonctionnalité.
• Maintenir un bon niveau de performances applicatives : il est très facile de dégrader une application. Une petite fonctionnalité peut avoir de gros impacts. Les choix techniques diffèrent en fonction du nombre d’utilisateurs et de fonctionnalités du projet. C’est pourquoi, les développeurs doivent y penser en permanence. Ils devront faire évoluer les technologies plusieurs fois durant la vie de l’entreprise.
• Maintenir un bon niveau de disponibilité applicative : il est très facile de rendre indisponible une application. Les développeurs doivent travailler à la sécurité du projet et ses performances. Ils doivent aussi mettre en place des mécanismes pour garantir l’accès à l’application. Certaines entreprises ont des objectifs forts à ce sujet. Votre prestataire de paiements ne doit pas être indisponible, ne serait-ce que quelques heures.
• Maintenir un code lisible : écrire du code, c’est raconter une histoire. Il y a une infinité de façons de l’écrire, toutes différentes. Sauf qu’ici, le livre se rédige à plusieurs. Cela veut dire que ce qu’un développeur écrit, doit être compris par les autres. Et ce, même si le développeur en question a quitté l’entreprise depuis des années. Si plus personne ne comprends comment a été conçu votre projet, alors ce dernier ne pourra plus évoluer.
• [Mettre à jour les données en temps réel] : plus optionnel que les autres, ce pré-requis s’applique à certaines entreprises ou certaines fonctionnalités précises. Mettre à jour des données en temps réel pour les utilisateurs n’est pas toujours simple. Si c’est un besoin fort, c’est une contrainte supplémentaire à intégrer au développement.

Le processus de développement

Ici, aucune obligation de réaliser l’ensemble de ces tâches. Selon l’entreprise, ses pratiques et sa culture, certaines pourraient même ne pas exister. Dans certains cas, les tâches peuvent être assignées à des personnes différentes. Selon le niveau d’expertise et d’expérience, toutes n’auront pas le même rôle. En pratique, les développeurs se retrouvent souvent à en faire la majeure partie.

• Collaborer avec l’équipe produit : lorsque l’entreprise dispose d’une culture produit forte, les développeurs consacrent du temps à penser les fonctionnalités avec les designers. Ils les aident à valider les faisabilités techniques, modifiant les maquettes le cas échéant.
• Concevoir techniquement les développements : on ne monte pas un meuble sans regarder la notice. Pour un développeur, c’est la même chose. Il ne devrait pas développer sans savoir ce qu’il doit faire au préalable. À la seule différence, qu’il est lui-même en charge de rédiger la notice.
• Prendre connaissances des tâches attendues : dans certains cas, ce n’est pas le développeur en charge du développement qui a rédigé les spécifications techniques. La première étape de son travail sera donc de comprendre ce qui est attendu, donc ce qu’il doit faire.
• Estimer le temps de travail nécessaire : toutes les entreprises et tous les projets ne requièrent pas d’estimation. Cependant, cela reste une pratique très fréquente. L’équipe qui prépare son travail à venir est souvent en charge de l’estimer temporellement. Cela permet de donner de la visibilité au reste de l’entreprise.
• Développer les fonctionnalités : c’est le coeur du métier de développeur. C’est là qu’il transforme des idées et des concepts, en lignes de code tangibles qui leur donneront vie.
• Tester son travail : certaines entreprises ont des équipes dédiées d’Assurance Qualité pour gérer cette étape. Pour les autres, il est attendu que le développeur procède à une batterie de tests. Il doit s’assurer que son travail fonctionne correctement, sans (trop) de bugs. On trouve des tests manuels à réaliser, mais aussi des tests automatiques à rédiger (tests unitaires, tests fonctionnels, tests end to end, monkey testing…)
• Corriger son code : les bonnes pratiques attendent des développeurs qu’ils relisent et approuvent le code écrit par leurs collègues. Cela implique que souvent, le code n’est pas approuvé dès la première lecture. L’auteur d’une fonctionnalité devra donc ré-écrire certaines parties de son code pour valider l’étape de relecture.
• Corriger les conflits : lorsque de nombreux développeurs travaillent sur une base de code partagée, plusieurs d’entre eux modifient souvent la même fonctionnalité au même moment. Cela résulte en des conflits que les développeurs devront résoudre.
• Mettre en production sa fonctionnalité : la finalité d’un développement est sa mise en ligne. Cette étape peut être très simple en fonction du processus de déploiement ainsi que de la nature de la fonctionnalité. Un changement de wording en déploiement continu sera simple et rapide. Une migration de base de données en déploiement manuel le sera beaucoup moins.
• Rédiger la documentation : pour simplifier le travail des autres développeurs, il est recommandé de documenter le code qui a été écrit. Cela les aidera à utiliser ou faire évoluer la fonctionnalité.

Le Service Après-Vente

Le travail ne se termine pas lorsqu’une fonctionnalité est mise en production. Il débute seulement. Dès lors que quelque chose existe en production, il faut le maintenir, le corriger et le faire évoluer.

• Assurer le support technique : une fois les fonctionnalités mises en production, ces dernières doivent fonctionner correctement. Elles ne doivent pas avoir de bugs ou en créer dans d’autres fonctionnalités. Les développeurs doivent consacrer du temps à la surveillance automatisée des projets, que l’on appelle le monitoring. Ils doivent aussi participer au support technique humain des utilisateurs.
• Annuler les mises en production : lorsqu’un bug est détecté, une mesure de précaution consiste en un retour en arrière de l’application. Au moins, le temps de corriger le problème. Selon les outils à disposition du développeur, cette étape peut prendre du temps.
• Corriger les bugs : ils font partie intégrante du quotidien. Il est impossible de développer un projet sans en créer. Il faut par contre les résoudre. Corriger un bug, c’est d’abord le comprendre. Le développeur doit se mettre dans les mêmes conditions d’apparition pour le reproduire. Une fois cette tâche réussie, il pourra identifier ce qui ne marche pas et développer un correctif.

Les imprévus du quotidien

Nous aimerions que tout se déroule toujours comme nous le souhaitons. Mais c’est rarement le cas. Les journées sont rythmées par de nombreux imprévus qui tombent toujours au moment le moins opportun.

• Gérer les incidents techniques : un datacenter qui prends feu, un prestataire qui tombe, une attaque de hackers… De nombreux éléments peuvent mettre à mal vos applications. Et ce, sans que votre équipe n’en soit responsable. Nous pouvons anticiper au mieux et travailler à la résilience, mais le risque 0 n’existera jamais. Par contre, les développeurs seront toujours mobilisés pour trouver des solutions dans le feu de l’action.
• Répondre aux questions du métier : même avec la meilleure documentation, il y aura toujours quelqu’un pour solliciter un développeur et lui demander de lui expliquer le fonctionnement d’une fonctionnalité.
• Développer des fonctionnalités au dernier-moment : un code promotionnel unique à créer pour signer un deal, une demande importante du CEO à faire de toute urgence, rembourser automatiquement 1000 clients pour faire gagner du temps au service comptable… De nombreuses demandes arrivent sur le bureau des développeurs sans passer par le processus de priorisation classique.

Aider les autres développeurs

Ils ont beau être seuls devant leur ordinateur, développer est un travail collectif. Certains des meilleurs développeurs ne consacrent d’ailleurs aucun temps à développer. Pourtant, s’ils n’étaient pas là, la productivité de toute l’équipe en souffrirait.

• Approuver les conceptions techniques : pour garantir la cohérence d’un système dans son ensemble, il est important que tous les développeurs respectent les mêmes façons de faire. Il est recommandé que chaque conception technique réalisée par un développeur, soit relue et validée par un autre.
• Approuver les développements réalisés : nous l’avons vu, il y a souvent un processus de Code Review en place. Cela garantit une uniformisation des développements, en réduisant le risque de bugs grâce à un regard extérieur. Chaque développeur doit donc relire le travail des autres.
• Accompagner les autres développeurs : de temps en temps, les développeurs n’arrivent pas à résoudre seuls, les problèmes auxquels ils font face. Ils ont besoin d’homologues, pour les écouter et les aider
• Former les autres développeurs : une équipe est aussi forte que son élément le plus faible. C’est pourquoi, il est important de faire progresser tout le monde. Les développeurs expérimentés doivent transmettre leur savoir aux autres. Pour cela, de nombreux formats existent tels que des ateliers collectifs ou individuels.

Se former soi-même

L’informatique est un univers en perpétuelle évolution. Un développeur qui ne se forme pas est un développeur qui sera vite obsolète. Une carrière professionnelle dure en moyenne 40 ans. Les développeurs doivent rester à jour durant toute cette période.

• Faire de la veille technique : il est important que les développeurs soient au courant des nouveautés techniques et des évolutions des bonnes pratiques. C’est ce qui permettra à votre projet d’évoluer et de continuer à rester compétitif. Pour réussir cela, ils doivent investir du temps dans l’auto-formation.
• Développer des Proof Of Concept : lorsqu’une technologie semble avoir du potentiel pour votre entreprise, il est important de laisser certaines personnes le vérifier. Cela permet de ne pas s’engager tête baissée dans une évolution qui ne serait pas viable.

Le développement n’est finalement qu’une petite partie de l’activité des développeurs. Toutes les autres tâches sont soi à son service, soit des obstacles à son bon déroulement.

C’est souvent cela qui est vecteur d’incompréhension entre le métier et la technique. Lorsque nous souhaitons le développement d’une fonctionnalité, nous ne nous rendons pas compte du nombre de tâches annexes à celle-ci. Les développeurs aussi font souvent cette erreur. Quand ils estiment le temps nécessaire à un projet, ils n’intègrent en général que le processus de développement en lui-même.

Et c’est d’ailleurs sur le développement que l’on aimerait qu’ils se concentrent. C’est cette tâche qui est directement génératrice de valeur pour le projet ou l’entreprise.

Pour maximiser le temps consacré à générer de la valeur, il est important de trouver comment réduire le temps consacré aux tâches annexes. Si vous souhaitez savoir comment faire, rendez-vous dans mon article suivant : pourquoi réduire la charge mentale des développeurs à travers la Developer Experience ?