Un projet de développement d'application bien préparé se caractérise par une bonne vision de l'ensemble et un bon niveau de détail dans l'exécution.
Pour nourrir ces deux besoins, qui semblent aux deux extrêmes l'un de l'autre, les interlocuteurs peuvent et doivent être différents. Ce qui veut dire qu'il est essentiel d'identifier les bonnes personnes selon les besoins du projet et de ne solliciter leur présence que lorsqu'elle est nécessaire.
Il n'y a rien de pire que d'avoir dans une réunion des gens qui n'ont rien à y faire.
Notre conseil :
Prendre le temps de construire la vision projet.
C'est un mot que je bannirais volontiers tant il a été galvaudé. Être agile ne veut pas dire commencer rapidement à développer le projet en enchaînant les sprints.
Il signifie qu'il faut définir quelle est la valeur du projet pour s'assurer de la livrer de manière continue grâce à une collaboration renforcée entre les parties prenantes.
C'est la définition de la valeur et de la vision du projet qui intervient le plus en amont. Un projet est bien différent d'une idée, et il a besoin d'être travaillé avant qu'une phase de développement applicatif puisse être amorcée.
Pour cela, il est nécessaire d'investir en amont du projet, notamment au travers d'ateliers de co-création. Cet investissement de quelques jours permettra de lever les risques et de s'assurer de la pertinence du projet. Cette phase est également essentielle dans la mobilisation des parties prenantes du projet qui assureront ensuite la phase de conduite du changement.
Notre conseil :
Investir du temps et du budget en amont du projet pour le préparer et explorer les hypothèses.
Les ressources disponibles sur Internet sont telles que la difficulté n'est pas de trouver une réponse à un besoin, mais de choisir.
Et souvent, pour s'éviter de choisir ou d'avoir à maintenir des outils que l'on n'a pas développés soi-même, on préfère ré-inventer la roue. C'est un vrai écueil culturel dans les équipes techniques, et il faut lutter contre.
L'essence de votre projet doit être clairement identifiée et c'est là-dessus que doivent être fléchés les budgets. Combien de départements IT sont réticents à l'idée de passer par une solution SaaS qui leur coûtera quelques dizaines d'euros par mois et préfèrent a contrario ré-investir des dizaines de jours/hommes pour développer un outil sans doute inférieur ? Le fameux CAPEX vs OPEX.
À l'inverse, on choisit à la légère des bibliothèques open source, simplement parce qu'on n'a pas à passer à la caisse, sans prendre le temps de vérifier si elles sont correctement maintenues, si le code est compréhensible et qu'on pourra y contribuer, si elles sont elles-mêmes à jour en terme de dépendances, si le nombre de tickets ouverts est raisonnable avec des tickets qui ne sont pas restés ouverts depuis 5 ans, etc.
Notre conseil :
Utiliser son budget à la création de la valeur du produit et utiliser des outils, plugins ou services tiers pour le reste.
Que l'équipe en charge du projet soit interne ou externe, l'écoute et la franchise doivent être la norme dans une relation équilibrée.
Presser une équipe pour tenir une deadline peut arriver, mais ça ne doit pas être la norme. Si la communication est à sens unique, parce que l'une des deux parties ne peut se voir opposer un non, le projet ira tôt ou tard dans le mur.
Vous aurez rapidement face à vous des gens qui vous diront oui en se mettant dans des situations impossibles pour essayer de livrer (au détriment de la qualité et donc du futur du projet).
Les équipes techniques ne doivent pas être traitées uniquement comme des exécutants, mais elles doivent aussi de leur côté comprendre que l'enjeu-même du projet n'est pas technique.
Notre conseil :
Traiter les personnes en charge de la réalisation comme des parties prenantes et non des exécutants.
Les projets ont de nombreux points communs avec les relations amoureuses. Au début, la relation est passionnée, tout est à construire et on n'en voit que les côtés positifs.
Mais si l'on n'entretient pas cette relation, elle s'use. Pour les projets de développement, c'est assez similaire : passée l'euphorie de la feuille blanche, il faut soit accepter, soit remédier aux défauts du projet.
C'est normal et ce n'est pas une fatalité. Si on veut continuer à construire des étages à la maison, il faut sans cesse en consolider les bases et aussi parfois accepter de supprimer ou réaffecter des pièces (vous noterez que j'ai changé d'analogie pour m'éviter quelques foudres 🙂).
Concrètement, vous entendrez souvent les équipes techniques parler de « dette technique ». Il faut se le représenter sous forme d'usure. On pense à tort que parce qu'un logiciel est immatériel, il ne s'use pas. C'est faux. Comme une voiture, s'il n'est pas entretenu régulièrement, le coût des réparations à un moment donné va devenir tel qu'on préférera considérer l'achat d'un véhicule neuf.
Toutefois, le remplacement d'un logiciel est une affaire bien plus complexe que celle d'une voiture, pour la simple raison que les spécifications des voitures sont globalement les mêmes d'une voiture à l'autre. Tous les constructeurs y adhèrent et vous livrent un véhicule avec 4 roues, un moteur et un volant.
Dans le cadre du logiciel, une refonte impliquera de connaître précisément la cible à atteindre, et pour se faire, avoir une très bonne connaissance du besoin métier. Étant donné que des tas de développeurs différents peuvent intervenir sur le projet, la seule source de vérité se trouve dans le code.
Cela implique le plus souvent de devoir faire de la rétro-ingénierie de l'existant pour développer le nouvel outil, ce qui fait généralement exploser les coûts.
Pour ne pas en arriver là, il faut prendre le temps de traiter l'usure au fil du temps, ne pas hésiter à retirer des parties de code si elles ne sont plus utiles. L'argument du « au cas où » ne tient pas, votre outil de gestion de l'historique du code est là pour ça.
Enfin, maintenir ses dépendances au fil du temps, c'est aussi s'éviter des migrations fastidieuses lorsque vient le temps d'une montée de version majeure.
Sans ça, la maison se transformera vite en château de cartes.
Notre conseil :
Accorder du temps pour garder les fondations du projet solide (dette technique, mise à niveau des outils, documentation, best practices).
