Des évidences de développeurs pas si évidentes

Maintenant que j’ai 20 ans de carrière derrière moi, je peux me permettre de dire quelles ont été les causes de mes expériences positives et celles négatives. Pour nous développeur, il s’agit surement d’évidences, mais selon la structure où l’on travaille ce n’est pas toujours le cas. Voyons ensemble ce qui fonctionne, de ce qui ne fonctionne pas.

Prenez le temps de faire un cahier des charges.

Un email, ou une réunion « à la va-vite » ne constitue pas un cahier des charges. L’objectif du cahier des charges est de refléter l’ensemble des règles de gestion, des cas d’utilisation, des contraintes, et des conséquences de l’application. Il prend du temps, et ne pas en faire, c’est se tirer une balle dans le pied ! Le jour ou votre développeur vous quitte, comment expliquer le fonctionnement de votre application au nouveau ? Comment se souvenir de tout ? Le code aussi bien commenté qu’il soit ne remplace pas un cahier des charges. Le développeur ne va pas s’amuser à ouvrir tous les fichiers pour tout lire (il y en a tellement). De plus, ça vous évitera les conflits de type : je l’ai dit / non tu l’as pas dit, et les erreurs d’interprétations comme ci-dessous.

Le développeur n’est pas un responsable produit.

Vous donnez un nouveau projet à votre développeur. Celui-ci va emmagasiner une partie des connaissances qu’il y aura dans le cahier des charges. Il se les approprie, les recrache en règles de gestion sous forme de code. L’application fonctionne. C’est parfait, tout le monde est content, et le temps passe…
Vous revenez vers votre dév quelques mois plus tard en lui demandant une nouvelle fonctionnalité. Une fois développée, vous ne comprenez pas pourquoi cette fonction n’a pas été rattachée à une autre similaire sur une autre page. C’est une évidence !

Et bien, non ! Une fois qu’on livre une application, on la sort de sa tête, puis on passe à un nouveau projet. Des nouvelles règles viennent nous encombrer l’esprit. Celles d’antan peuvent ou pas demeurer un moment, mais comme nous n’utilisons pas l’application quotidiennement, il nous est impossible de retenir tout son périmètre fonctionnel. Il est donc normal que si vous n’indiquez pas tous les points de détails à respecter dans cette nouvelle fonction, il y aura des oublis. Pour mieux faire, imaginez qu’il s’agit d’une nouvelle personne, et vous comprendrez que vous devez être exhaustif.

Multiplier les développeurs ne va pas forcément réduire votre temps total.

On ne fait pas 1 bébé en 1 mois même avec 9 femmes. Parfois cette règle s’applique aussi aux projets informatiques. Oui, en ajoutant des ressources au projet, vous gagnerez du temps, mais certaines tâches primordiales ne peuvent être réparties. Et sans ces tâches, vous ne pouvez avancer sur d’autres tâches. On appelle cela : le chemin critique. Une bonne gestion de projet vous indiquera les étapes clés que vous devez respecter, et vous permettra de savoir à quel moment vous pouvez doubler vos efforts. Parfois, il faut accepter d’être un peu patient…

Un chef de projet n’est pas inutile.

Avoir une personne qui fait le lien entre le client (les fonctions attendues de l’application) et les développeurs n’est pas superflue. C’est lui qui connaîtra le mieux le cahier des charges, et le résultat attendu. Il saura faire les tests nécessaires (recette) pour s’assurer que l’application répond aux exigences du client. Il saura retranscrire le langage du client en règles de code pour les dévs. Oui, ça coûte un peu, mais c’est comme lorsque vous construisez une maison. Le chef de projet / architecte s’assure que votre main d’oeuvre fait les choses comme il faut.

Délocalisation et prendre le moins cher : la fausse bonne idée.

Pour une société, il est toujours tentant de faire un appel d’offres et de prendre le projet le moins coûteux. Mais qu’en est-il dans la réalité ? Pensez-vous que des malgaches ou des tunisiens ont reçus la même formation que des européens ? Pensez-vous qu’un stagiaire possède les mêmes connaissances qu’un développeur expérimenté ? Pensez-vous que le niveau d’exigence entre 2 développeurs est forcément la même ?
La réponse est à chaque fois la même : NON.

Lorsque vous embauchez un maçon pour construire votre maison, celui-ci peut faire les choses correctement, ou alors, il peut aussi utiliser du matériel de moins bonne qualité, moins isolant (pour augmenter son bénéfice). Il peut également enfouir tous ses déchets dans votre jardin, plutôt que d’aller en déchetterie. Et oui, tout ça, ça ne se voit pas forcément. Au final, vous aurez visuellement le même bâtiment, mais avec un rendement énergétique bien différent.
Voici un exemple qui en dit long. Les développeurs en sortant de l’école n’ont bien souvent reçus aucune formation en SEO. Du coup, le site qu’ils vont générer sera bien conformes aux maquettes graphiques, mais absolument pas pensé pour le référencement. Si vous aviez pris quelqu’un d’un peu plus expérimenté, vous auriez pu supposer qu’il avait déjà eu connaissance de ces problèmes, et qu’il aurait su comment vous obtenir une bonne indexation dans Google. (Hélas, selon les agences Web, on se rend compte que ce n’est pas forcément le cas; même si cela évolue, et que les bonnes pratiques se répandent).

De plus, suivant les cultures du pays, vos interlocuteurs n’oseront pas vous dire qu’ils n’ont pas compris, et vous risquez de vous retrouver avec un projet qui ne répond pas à votre demande.

De mon expérience, voilà ce que je retiens :
– des coulées de boue chez les malgaches qui ont éradiqués tous les serveurs, et il a donc fallu reprendre le projet en interne depuis zéro,
– des tunisiens qui disent oui-oui à tout et qui livrent quelque chose qui n’a pas été réfléchit/compris,
– des projets délocalisés qui reviennent avec à la clé des commentaires en roumain pour seule documentation,
– des projets menés par des stagiaires successifs mélangeant différentes technologies (php,python,java) sans aucun suivi/lien au sein de la même application.

Refaire tout depuis zéro sur une évolution technologique n’est pas qu’une perte de temps.

Un passage de PHP 5 à PHP 7, un changement de framework, ou un changement de technologie n’est pas anodin, et il faut souvent le justifier. Généralement, on nous dit que cela prend du temps et que comme le résultat sera identique, ça ne sert à rien. Détrompez-vous. L’utilisation d’un nouveau framework peut vous protéger de failles de sécurité, accélérer vos performances, ajouter des fonctionnalités qui faciliteront la maintenance. Non seulement, vos développeurs seront heureux de se mettre à la page, mais votre application répondra aux normes actuelles. Si l’on voulait reprendre la métaphore de la maison, cela reviendrait à dire que vous n’entretenez pas votre toiture. En l’occurrence, on parle aussi parfois d’un effondrement des fondations si des mises à jour ne sont pas réalisées. Ecoutez votre développeur. Tout refaire n’est pas forcément intéressant pour lui; c’est qu’il y voit : un vrai risque ou une vraie plus-value.

Un développeur n’est pas un administrateur système.

Un administrateur système va vérifier que les contraintes de sécurité sont respectées. Il va mettre en production votre application en lui définissant des rôles / permissions bien spécifiques. Un dév, lui bien souvent n’a que la connaissance du code et pas du système. Il va faire en sorte que l’application fonctionne, mais derrière, à la moindre faille, les dégâts ne seront pas les mêmes (accès aux ressources du serveur, à des bases de données autres, à des applications tierces…).
Si vous le laissez jouer le rôle d’administrateur, il fera ça aussi bien qu’il le peut, mais c’est à vos risques et périls. Ne lui en veuillez pas si il y a des problèmes car ce n’est pas son métier !

Si vous aussi, vous avez rencontré des pratiques identiques, n’hésitez pas à en parler dans les commentaires…