Vous avez un projet de développement d’application ou de modernisation d’une application existante, ou encore d’un produit logiciel ou d’un module.
Que ce soit pour des raisons d’obsolescence technologique, pour tirer parti de nouvelles technologies, pour mieux répondre aux besoins métier et aux attentes des utilisateurs avec une expérience utilisateur dans l’air du temps ou encore pour exploiter les avantages du Cloud, se pose la question de la manière de mener le projet.
Faut-il mobiliser des renforts chez un prestataire ? Ou encore sous-traiter totalement la réalisation ? Faut-il mener cela en mode agile selon les tendances du moment ?
L’article ci-dessous présente les différents modes d’intervention de SoftFluent et propose une analyse de l’adéquation de ces modes à des contextes projets différents.
SoftFluent réalise ses projets selon 3 modes d’engagement :
- Un modèle à la carte sur les ressources
- Un modèle au forfait basé sur le résultat
- Un modèle agile avec la possibilité d’une démarche budgétaire forfaitisée
Il est important de comprendre que ces modèles portent chacun des avantages et inconvénients qui leur sont propres.
Rappel sur le triangle des contraintes
Dans le métier du logiciel et dans différents métiers conduits en mode projet, il est souvent fait référence au triangle des contraintes (délai-périmètre-coût) :
L’expérience en développement permet de savoir que si l’on cherche à tout réaliser en même temps, à savoir atteindre un périmètre maximal, dans un délai relativement court et pour un coût raisonnable, l’arbitrage implicite se fera au détriment de la qualité, que cela soit choisi ou non. C’est pourquoi on le place ici au centre, sans que cela soit toujours visible de l’extérieur. C’est encore plus vrai quand cela se fait au travers de la pression d’un client sur un fournisseur ou dans des logiques d’appel d’offres. Le moins-disant est au final presque toujours choisi et les fournisseurs expérimentés le savent lorsqu’ils répondent. Les moins bons fournisseurs se contentent de cette non-qualité, les plus compétents savent ensuite comment redresser le tir à coup d’avenants en se glissant dans les failles inévitables de tout cahier des charges.
Une approche moins politique, mais empreinte de sagesse, veut qu’on choisisse de privilégier explicitement deux paramètres sans chercher à optimiser les trois sommets du triangle, mais en s’assurant de conserver un projet de qualité.
Chez SoftFluent, nous pensons que nos 3 modèles de réponse ont leur place en fonction de la nature du projet, car les paramètres du triangle n’auront pas la même importance.
Modèle « A la carte »
Dans le modèle à la carte, c’est le client qui garde la maitrise des ressources engagées et du budget, avec une souplesse totale sur les ressources. Il sollicite les ressources de SoftFluent selon ses besoins et peut les combiner avec ses propres équipes. Nous proposons notamment aux éditeurs de logiciels un modèle de « Squad hybride » qui permet de diffuser des compétences au sein de l’équipe de l’éditeur client. Le focus devra être mis sur les compétences et leur complémentarité avec l’équipe ou sur un besoin très spécifique de renfort de production.
La gestion du budget et le pilotage sont totalement du ressort du client à l’aide de prévisions de temps. Les commandes sont possibles au fil de l’eau, mais la mise à disposition de ressources nécessite généralement une anticipation de 3 semaines à un mois, et SoftFluent laisse la possibilité de fin d’une ressource avec un mois de préavis.
Avantages
Contreparties
- Focalisation sur les compétences « ad hoc »
- Energie concentrée sur l’action et non le processus
- Souplesse totale
- Diffusion de compétences chez le client en mode « squad hybride »
- Budget et pilotage à gérer par le client
- Compréhension nécessaire du métier du développement du côté du client
Avantages
- Focalisation sur les compétences « ad hoc »
- Energie concentrée sur l’action et non le processus
- Souplesse totale
- Diffusion de compétences chez le client en mode « squad hybride »
Contreparties
- Budget et pilotage à gérer par le client
- Compréhension nécessaire du métier du développement du côté du client
Dans le triangle des contraintes, nous recommandons ce modèle lorsque le « time to market » joue un rôle majeur et qu’il faut produire beaucoup de périmètre fonctionnel dans un délai court. En effet, dans ce modèle, le paramètre budgétaire devient alors une variable d’ajustement et on est prêt à justifier le coût d’une transformation rapide.
Modèle « Forfait »
Dans le modèle forfait, le client sait décrire exactement son besoin fonctionnel et les éléments dont il a besoin pour son métier. Cela suppose une capacité à formaliser un cahier des charges précis et relativement figé pour permettre de bien séparer le travail des concepteurs et le travail des développeurs. Le cas échéant, ce travail peut être délégué à des spécialistes en assistance à maitrise d’ouvrage comme la filiale Abeee Consulting de SoftFluent.
Une fois les livrables attendus parfaitement décrits, et validés conjointement par le donneur d’ordre et le prestataire, l’équipe de développement peut réaliser le logiciel selon un budget défini en suivant les éléments explicités et les cahiers de recette qui devront être établis pour vérifier la conformité du logiciel aux spécifications. Le client doit d’ailleurs procéder à la recette lors de la livraison finale, ou par lots si le projet a été découpé.
Les découvertes « en cours de projet », qu’il s’agisse de précisions nécessaires, de besoins additionnels ou de changements devront être intégrés dans une prochaine version ou donner lieu à avenant.
Avantages
Contreparties
- Périmètre garanti par contrat
- Budget garanti par contrat
- Répartition des rôles explicite
- Capacité à formaliser un cahier des charges clair et ferme
- Recours à l’avenant indispensable en cas d’évolution de périmètre
- Travail important de gestion du processus et de suivi contractuel
- Intérêts antinomiques par construction
Avantages
- Périmètre garanti par contrat
- Budget garanti par contrat
- Répartition des rôles explicite
Contreparties
- Capacité à formaliser un cahier des charges clair et ferme
- Recours à l’avenant indispensable en cas d’évolution de périmètre
- Travail important de gestion du processus et de suivi contractuel
- Intérêts antinomiques par construction
Dans le triangle des contraintes, nous recommandons ce modèle lorsqu’il faut optimiser le coût de réalisation d’une application relativement bordée, dont on imagine la maintenance au fil de l’eau relativement faible. Cela signifie qu’il s’agit d’une application limitée ou ciblée, à périmètre peu évolutif. Cela se fait au prix du délai car il y a une lourdeur à mettre en place un mécanisme contractuel qui va opposer, par construction, les intérêts du donneur d’ordre et du prestataire.
Modèle « Agile »
Dans le modèle agile, il est privilégié une construction au fil de l’eau de la solution à développer, dans un modèle de collaboration étroite entre un « product owner », responsable de penser la solution à réaliser, et les équipes de développement qui produisent le logiciel par itérations.
Ce modèle agile évite le risque d’effet tunnel de la méthode précédente, effet qui peut se révéler désastreux si la capacité à bien décrire et figer un cahier des charges est insuffisante chez le client, ou si la solution mérite une mise au point qui s’ajuste au fil du temps.
De notre expérience, il est souvent préférable de procéder ainsi pour de grandes applications « cœur de métier », car celles-ci évoluent en permanence, et il est illusoire de vouloir les figer le temps d’une reconception et d’un redéveloppement, qui va s’étaler sur des mois voire des années.
Le cœur du pilotage se situe autour de la constitution d’un ‘backlog’ qu’on priorise ensuite au fil des itérations. Il convient de prévoir un processus de macro-planification « au-dessus » de la méthode agile afin de se donner un minimum de visibilité et pouvoir communiquer aux parties prenantes sur une roadmap à long terme.
Avantages
Contreparties
- Budget garanti par itération
- Délais garantis pour une version
- Répartition des rôles explicite
- Capacité à arbitrer le périmètre (PO)
- Effort nécessaire pour retraduire en macro-planification budgétaire
Avantages
- Budget garanti par itération
- Délais garantis pour une version
- Répartition des rôles explicite
Contreparties
- Capacité à arbitrer le périmètre (PO)
- Effort nécessaire pour retraduire en macro-planification budgétaire
Dans le triangle des contraintes nous recommandons ce modèle lorsqu’il faut s’assurer d’avancer régulièrement en pilotant par le budget. Cela permet d’arbitrer l’évolution du métier en hiérarchisant en fonction du besoin fonctionnel porteur de valeur tout en assurant une évolution technologique régulière pour ne pas accumuler de dette technologique. Le périmètre sera la variable d’ajustement, sachant que pour un logiciel cœur de métier qui doit faire l’objet de maintenance permanente, celui-ci sera enrichi dans le temps. L’important est alors d’avoir la bonne organisation pour maintenir un dialogue constructif avec les utilisateurs afin de les satisfaire.
Conclusion
Nous résumons par ce diagramme de Venn le choix de la bonne méthode en fonction des deux principaux paramètres importants pour votre projet :
Le triangle des contraintes et la méthode à privilégier
suivant les deux contraintes majeures,
en sacrifiant un peu plus le 3e paramètre.
Quelle que soit la méthode choisie, SoftFluent dispose de l’expertise technique nécessaire pour proposer une stratégie de migration progressive de votre application.
Sur de nombreux projets, nous alimentons un modèle modernisé pour les nouveaux modules, tout en conservant une compatibilité des anciens modules ‘Legacy’ le temps nécessaire et organisons l’évolution et la réduction de la dette technique.
