Stratégie pour développer plusieurs produits numériques
La base de connaissances présentée essaie de mettre en avant des concepts sans vous forcer la main concernant leur adoption.
Une fois que vous avez des idées bien à vous sur le langage (ou les) à utiliser, quel hébergeur… Il peut être intéressant de mutualiser et répliquer vos choix sur vos futurs projets :
- Il n'y a plus à remettre en question 90% des bases techniques à chaque fois, vu que ces bases n'ont quasi pas évolué dans la communauté depuis des années (framework, router, base de données… majoritairement rien de nouveau sous le soleil ☀️) ;
- Si chaque équipe avance en autonomie, vous garantissez ne pas vous retrouver avec des produits exotiques que personne n'a envie de reprendre ;
- Vous vous facilitez le recrutement ! Chaque personne recrutée sera autant compétente sur le projet A que sur le projet B. Les personnes ont une certaine transversalité ;
- Les équipes peuvent se comprendre entre elles, et donc s'entre-aider ;
- Vous facilitez le travail des métiers transverses qui vont venir chapeauter la sécurité, l'opérationnel…
Bien entendu il faut rester lucide. Pour une organisation très importante (donc avec un historique conséquent), il y aura forcément de l'hétérogénéité dû à l'organigramme et aux évolutions technologiques au fil du temps.
… Par contre, pour une plus petite organisation, ayant des projets lancés sur une fenêtre de 3-4 ans, la mutualisation est tout à fait envisageable pour éviter de surcomplexifier la structure interne.
Si la stack "passe-partout" que vous aviez adoptée semble ne pas convenir à la majorité des projets, il peut être judicieux de la remettre en cause plutôt que forcer d'autres projets à la subir. Voir si les gens en sont satisfaits ou non est un bon indicateur 🚦.