Sinon, c'est de nouveau la nuit. Une petite anecdote fun mais pas trop utile, ça vous dit ? :) Ce soir, je vais vous partager la galère de gestion d'un projet quand on veut aller trop, beaucoup trop loin ... <p> Tout le monde le sait, dans un projet, il faut savoir s'adapter au besoin. On peut le faire en planifiant directement en fonction des besoins (quand vous faites une maison ou un jardin par exemple, pas trop itérable comme projet) ou en réduisant le travail à faire en se concentrant sur l'essentiel et en enrichissant peut à peut en fonction des retours/idées et de la croissance de l'équipe (Qwice). </p><p>Mais que se passe-t-il si un maillon veut trop bien faire par rapport au besoin et/ou au moyens ? Se planter en général. Je l'ai appris chez Tankyou, et a mes dépends sur certains projets en école (oui, j'étais du genre a reprendre un projet from scratch 3 jours avant le rendu parceque j'avais trouver une meilleur implémentation... Et je n'avais pas encore le reflexe Git :O). </p><p>Du coup, chez Tankyou, un jour, nous avons recruté un CTO. C'était une bonne idée. La boîte voulait mettre un coup de fouet sur le produit tech et mieux l'organiser et gérer (on était 3, un front sénior et 2 back junior). Et il leur a proposé une refonte complète du système informatique pour créer une plateforme de services automobile et livraison (le Amazon de l'auto quoi). Une refonte complète du système from scratch. Finit le python monolithe et AWS, bonjour Go en service et GCP. Une très bonne idée en soit qui a été très bien accueillit côté dev. Il y avait beaucoup de chose à revoir dans le projet actuelle et c'était l'occasion de le faire, en plus de pouvoir travailler sur de nouvelles techno (bon, j'étais le seul de l'équipe en place à avoir de l'expérience en go (1 projet d'école ... )). On se met donc a créer l'architecture de services, les méthodes de communications entre eux et le front, les outils de test, des librairies utilitaires pour simplifier le travail et l'accélérer... Puis on se met sur le premier service, un système d'auth (protocole OAuth). Vers la fin du projet, un dev sénior back nous rejoint, expérimenté en Go. Il prend ses marques et nous propose une nouvelle architecture de projet. Et il a fallut un peu de temps pour qu'on l'accepte et fasse les premières propositions avec. Et créer une deuxième version du système d'auth. Mais wait, il était pas finis celui la ? </p><p>Bah si, mais non... On avait pas d'environnement de déploiement et personne de compétent disponible pour le mettre en place. Bon, c'est pas grave. Ca ne fait qu'un mois qu'on a démarrer la refonte, et on a pas encore tous les profils promis. On manque notamment d'un devops pour créer les envs de dépoiement justement. Nous en profitons donc pour refactor le service d'auth avec la nouvelle archi. Une fois, deux fois... Cinq fois... Toujours pas d'environnement de test... Et oui, on a eu un devops entre temps mais il n'a pas été garder et toujours personne pour mettre en place la stack voulu (Kubernetes sur GCP avec de la sécurité de mot de passe via Vault de mémoire et une API Gateway (Kong) au dessus, le tout wrap et automatisé via terraform). On propose d'au moins déployé sur Cloud Run ou sur un container simple une version des services pour permettre au PO de testé le système, histoire d'avancer un peu. Parceque la, ça fait long le serveur d'auth... Mais pas moyen. Il fallait absolument que ce soit parfait dès le début. <br /><br />Bref, le projet a pas vraiment avancé et en un an, on a créer 3 services (auth, audit et début de la gestion des utilisateurs). Au final, la refonte sera abandonné et retour au monolith python. Du temps, des ressources perdues, non pas pour un projet inutile mais par la volonté de trop bien faire du début. On était une team sous staffé (1 dev front et 3 dev back) avec deux projets à gérer en parallèle. <br /><br />J'ai cependant adoré travailler avec les personnes impliqués dans ce projet et c'est plus de la tristesse et de la frustration qui ont été créer suite à cela. Mais j'en ai retenue définitivement une excellente leçons. Tu dois te projeter dans ce qui serait l'idéal, mais n'oublies jamais qu'il faut avant tout avancer dans ton projet. Quand tu es seul à l'attendre, tu t'en fous, c'est ton problème. Mais en entreprise ou si des personnes commence à suivre un projet, ils vont attendre des mises à jours ou des informations. Tu peux justifier de ne rien avoir à montrer pendant un certain temps, mais si ça dure trop, plus personne ne t'attendra. S'obstiner sur la perfection peut créer bien plus de dégats que d'accepter un compromis tant que celui-ci ne met pas en danger le projet (sécurité, robustesse, etc.) Et si j'ai encore du mal à trouver le juste milieux entre trop et pas assez, j'essaye de me fixer des limites.<br /><br />Voilà, un long pavé pour pas grand chose, mais toutes expériences est bonne à prendre, n'est-ce pas :) </p>