Fast delivery : pourquoi est-il urgent de livrer ?

Dans un monde où l’imprévu devient le quotidien, la vitesse d’exécution est une clé incontournable. Elle permet d’arriver plus rapidement sur les véritables lockers d’un projet digital. Le challenge est d’apporter la pédagogie nécessaire pour faire les arbitrages et trouver le mode de travail permettant d’avoir cette vélocité.

Pourquoi est-il urgent de livrer ?

Le « fast delivery » se réfère à la livraison rapide de produits ou de services à des clients. C’est un terme souvent utilisé dans le contexte du commerce électronique, de la restauration, de la logistique et d’autres industries où la rapidité de livraison est un facteur clé pour satisfaire les clients. Que vos produits et services digitaux s’adressent au B2B ou au B2C, vos utilisateurs ont des habitudes de consommation relevant de l’instantanéité. Entre le moment où ils émettent un besoin et où celui-ci est confirmé, il est crucial de montrer une réaction à leurs envies et d’activer un processus qui permettra de répondre rapidement à ce besoin, au risque de les voir partir chez vos concurrents !

Ainsi, faire du fast delivery, c’est être en capacité d’aller au rythme des changements du marché en :

• testant rapidement de nouvelles opportunités de business,
• fidélisant votre clientèle en prenant en compte ses feedbacks et enrichissant son produit très rapidement.

Comment impliquer ses sponsors ?

Le fast delivery permet de répondre rapidement à un besoin utilisateur. C’est donc tout naturellement qu’on fera la conception en suivant les méthodes de product design. Les retours d’expérience nous apprennent que lorsque ces phases de product design sont menées trop loin des sponsors (ceux qui détiennent la vision business et le budget), les projets ont une fâcheuse tendance à déraper à cause des biais suivants :

• réinterprétation de la vision d’origine (on ne parle pas d’un pivot mais d’une erreur d’appréciation de la vision cible),
• difficulté à faire des priorisations drastiques et des choix,
• gaspillage de temps et d’énergie à chiffrer des fonctionnalités de niveau de priorité inférieur au MVP (Minimum Viable Product) pour “avoir une idée d’ensemble”,
• refus d’accepter la simplification de certaines fonctionnalités afin de rentrer dans le délai et le budget,
• dépriorisation des tâches techniques ou du processus de qualité pour permettre de livrer plus de fonctionnel,
• lenteur administrative notamment pour faire rentrer dans le projet des prestataires ou solutions d’éditeur permettant d’accélérer le développement du produit.

Tenir le sponsor éloigné peut déséquilibrer sensiblement la balance qui permet de construire un produit user centric, dans le budget et le délai attendus.

Bien souvent, ces travers sont levés en impliquant les sponsors dans les ateliers stratégiques et des revues de projet courtes et fréquentes. En effet, le responsable du projet et les sponsors ont un niveau d’information similaire sur le projet, et les responsabilités et décisions sont partagées, peu déformées et donc beaucoup plus pragmatiques. Le sponsor est invité à rentrer beaucoup plus dans les contraintes de fabrication, ce qui lui permet de mieux accepter les choix et faire des arbitrages qu’il comprend.

Quelles compétences et organisation pour son équipe ?

Pour délivrer rapidement de la valeur, la technique ne doit pas être un problème. A l’instar d’un musicien qui joue en orchestre, chaque partie prenante de l’équipe doit maîtriser son sujet : être capable de lire la partition à vue, relever les erreurs de conception, être force de proposition et savoir improviser lorsque la partition est incomplète. Il n’est pas exclu (et c’est même encouragé) de constituer une équipe avec quelques juniors, mais plus le projet sera rapide, plus les gestes devront être sûrs et les choix avisés. Cela implique beaucoup de séniorité dans l’équipe.

Pourquoi il faut accepter de s’endetter techniquement (dette qu’il faudra rembourser dès le lancement)

Il est préférable de travailler sur l’amélioration technique de fonctionnalités utilisées plutôt que de faire une sur-ingénieurie sur un produit dont on ne sait pas s’il rencontrera un usage. Cela revient à accepter de créer de la dette technique.

Concevoir un produit absolument parfait dès le début sur le plan technique, c’est :

• accepter le risque d’un refactoring sans fin de l’architecture sans qu’aucune fonctionnalité ne soit développée car l’amélioration d’une stack technique est sans fin ;
• accepter de potentiellement travailler sur les mauvaises priorités (ce n’est que dans les dernières semaines que l’on aura fait la conception et l’implémentation détaillées) ;
• renoncer à une approche “fail first” qui permet d’éprouver très rapidement un grand nombre de sujets et voir où sont les véritables lockers techniques.

Rien n’est possible sans avoir une véritable plateforme technologique agile

Dans les cycles de production sur plusieurs mois / années, on peut observer la méthodologie suivante :

• Dresser la liste des besoins
• Identifier les progiciels “solutions sur étagère” répondant aux besoins
• Tordre les besoins pour rentrer dans l’outil
• Sur le long terme : tordre l’outil dont l’usage ne répondait pas si bien au besoin
   

A l’air du “tout, tout de suite” et du “sans couture”, ces 4 différentes étapes peuvent se retrouver compactées dans un laps de temps inférieur à 4 mois. Dès lors, il est indispensable de penser à l’architecture composable.

En conclusion, délivrer rapidement de la valeur passe essentiellement par :

• impliquer les sponsors pour accélérer les décisions et insuffler à l’équipe la vision du produit,
• disposer d’une architecture composable permettant de s’adapter rapidement à l’évolution du produit,
• travailler avec une équipe expérimentée capable de challenger le périmètre et proposer les bons arbitrages,
• accepter de créer une dette technique qu’on pourra résorber par la suite.