Le Blog Synbioz : conseils et ressources pour vos projets de développements web

De l'étude de besoins au lancement de votre application web : notre process

Rédigé par Martin Catty | 6 avril 2020

Vous l'avez compris au travers de nos précédents articles : notre approche consiste à extraire la sève de votre projet.

Nous n'allons donc pas vous demander de nous fournir un cahier des charges et une spécification fonctionnelle détaillant le moindre fonctionnement de l'application web que vous souhaitez développer.

Ce que nous souhaitons comprendre, ce sont les fondements de votre projet, sa vision.

et établir la feuille de route de votre application <<

Tout au long du projet, plusieurs étapes vont se succéder, afin qu'ensemble, nous dégagions les fruits d'une collaboration réussie.

Vous prendrez connaissance dans cet article de ces différentes étapes, de quoi elles se composent et pourquoi elles sont importantes. Ces étapes constitueront la trame de notre accompagnement si nous travaillons ensemble.

1 - S'assurer que nous pouvons vous aider

Notre premier contact nous permettra d'apprendre à se connaitre mutuellement, avoir une première vision de votre projet et vous indiquer si nous sommes en mesure de vous accompagner.

Être en mesure de vous accompagner, cela signifie pour nous : vous aider pendant toute la durée du projet, et bien plus. De l'expression de besoin jusqu'à sa mise en conditions opérationnelles.

Mais il faut aussi admettre ses limites. Des contraintes spécifiques (technique, timing de réalisation, intégration d'un outil inconnu) peuvent faire que nous ne serons pas les plus à même de vous aider.

Le cas échéant, nous préférerons vous en informer de suite.

2 - Faire notre métier de conseil

Selon nous, notre valeur ajoutée dans un projet va bien au-delà de son exécution.

Il s'agit de vous aider à identifier rapidement les pièges en s'appuyant sur notre expérience pour identifier les fonctionnalités disposant d'un excellent ratio valeur / difficulté de mise en place.

Nous sommes là également pour vous informer sur les usages et tendances de l'industrie du développement logiciel : les intégrations d'outils qui pourraient vous donner un avantage concurrentiel ou raccourcir les délais de développement, les bonnes pratiques en termes d'ergonomie et d'accessibilité, l'intérêt d'une technologie et tant d'autres.

Cette phase doit nous assurer à l'un et l'autre une chose très importante : nous travaillons ensemble dans une logique de collaboration, pas de subordination.

Bien entendu, il existe une relation contractuelle et le client a le dernier mot à l'heure des choix ; mais nous n'intervenons jamais comme de purs exécutants.

3 - Apprends-moi ton métier, je t'apprendrai le mien

Les meilleurs résultats sont le fruit des meilleures collaborations. Chacun a son territoire de prédilection, qui correspond peu ou prou à son propre métier.

Pour confectionner un bon produit, il s'agit de croiser ces deux métiers. Pour cela, chacun devra s'aventurer en terre inconnue pour apprendre le métier de l'autre.

Il n'existe pas de solution miracle : pour réussir cela, il faut passer du temps ensemble pour comprendre les particularités d'un métier et en capter l'essence.

Il est important que cette démarche soit réciproque et que jamais l'un des deux acteurs ne considère le métier de l'autre comme une boîte noire.

4 - Définir un périmètre acceptable

Cette étape est sans doute l'une des plus complexes, car c'est pendant celle-là que nous sommes amenés à dire non. Pour un client, il est difficile de se voir opposer un refus, et c'est tout à fait normal.

Mais nous le faisons dans l'intérêt du projet, pour éviter de se lancer dans des réalisations trop ambitieuses, trop complexes ou basées sur trop d'incertitudes (ressentis, feeling, biais cognitifs…)

 

If you're not embarrassed by the first version of your product, you've launched too late — Reid Hoffman

 

Plus petit sera le périmètre, et plus rapide pourra être le lancement. L'important est de pouvoir apporter les fonctionnalités clés qui apporteront immédiatement de la valeur ajoutée aux utilisateurs finaux.

Pour cela, nous menons avec nos clients des ateliers de co-création (autrement appelés design sprint).

Le but de ces ateliers est de mener un processus de création de façon purement exploratoire, processus au terme duquel nous aboutissons à des maquettes et des hypothèses d'utilisation de l'application en question.

Il reste à éprouver ces hypothèses auprès des utilisateurs finaux en testant sur un ou plusieurs prototypes.

Cette étape de co-création, qui dure environ cinq jours, offre l'avantage d'être concrète et ludique tout en permettant une bonne prise en main et une bonne compréhension du métier et du besoin.

5 - Développer, recetter, répéter

Vient ensuite la phase de développement. Pour cette phase, nous employons deux modes de fonctionnement distincts : soit nous livrons les développements toutes les X semaines, soit nous ne livrons que quand nous atteignons un ensemble fonctionnel cohérent (c'est à dire que nous ne livrons que quand N fonctionnalités sont prêtes).

Nous utilisons généralement le premier mode pour de l'amélioration continue ou des corrections, tandis que nous utiliserons le second dans le cadre d'un projet / sous projet.

Par projet, nous entendons ici un ensemble homogène de fonctionnalités, qui sont fortement interdépendantes. On peut par exemple considérer la mise en place de l'authentification d'une application comme un sous projet. Si vos utilisateurs peuvent s'authentifier (fonctionnalité 1) mais ne peuvent pas s'inscrire (fonctionnalité 2), ça n'a probablement pas grand intérêt : nous piloterons donc le projet d'un point de vue fonctionnel.

À l'inverse, une fois ce projet livré, vous pouvez vouloir faire en sorte que vos utilisateurs puissent s'authentifier avec Google. Dans ce cas, cela s'apparentera plutôt à de l'amélioration continue.

Au démarrage de chaque itération (temporelle ou fonctionnelle), nous allons devoir définir les ressources que nous souhaitons y affecter. En effet, les compétences ne sont pas nécessairement les mêmes selon les fonctionnalités à implémenter.

Une fois la fonctionnalité en place, il est indispensable de la tester, de la recetter. Pour chacune des fonctionnalités mises en place, nous vous encourageons vivement à mettre en place un cahier de recette.

Le cahier de recette offre plusieurs avantages :

  • Il permet de lister tout ce que doit faire l'application, groupé par domaines fonctionnels, de façon concise

  • En constituant votre cahier de recette au fil de l'eau, la charge de travail est marginale là où elle devient colossale s'il était question de créer le cahier de recette a posteriori.

  • Le format est très simple à appréhender et peut être pris en main par n'importe quelle personne du métier. Cela permet de sceller les processus et les informations clés du métier pendant que les personnes sont présentes. On connait tous des personnes clés dans les entreprises qui sont les seules à connaître tout le métier, entrainant des pertes de connaissances quand elles sont amenées à quitter l'entreprise un jour ou l'autre.

  • Le cahier de recette permet de garder la logique fonctionnelle centralisée en un seul endroit et utilisé par tous. Un document de spécification peut devenir illisible au fur et à mesure de sa modification, et il devient difficile et chronophage d'y retrouver une information précise. Le cahier de recette reste quant à lui simple à lire et même à découper, notamment par domaines fonctionnels.

  • Il permet de faire le pont avec les équipes techniques, en facilitant la mise en place de tests automatisés (notamment end-to-end).

  • Il permet (tant qu'il est fait consciencieusement et qu'il est tenu à jour) aux personnes en charge de l'assurance qualité de dérouler un jeu de tests complet et de s'assurer qu'aucune régression ne survient.

Vous aurez peut-être le sentiment que cette tâche vous fera perdre un peu de temps au début du projet, mais elle vous en fera gagner énormément pour un projet dont la durée de vie est importante (> 1 an).

 

6 - Mise en exploitation

Une fois que l'application est développée et conforme aux attentes, il est temps de procéder à la mise en production.

Évidemment, c'est une phase qui aura été anticipée bien en amont, à la fois pour calibrer les besoins en dimensionnement des infrastructures, mais également la configuration des intégrations avec d'autres solutions, ou encore les garanties souhaitées (SLA, GTI, GTR…).

Un point important ici est de bien délimiter les responsabilités des uns et des autres. Il est généralement plus judicieux que le client n'ait qu'un guichet unique lorsqu'un problème survient, même si les équipes opérationnelles et celles de développement sont différentes.

Cela évite l'effet ping-pong, les premiers pouvant mettre les problèmes sur le compte des équipes de développement, et réciproquement.

Le second point est également crucial : ne partez pas en production sans filet !

Une fois l'application en production, vous devez savoir précisément :

  • qui est en charge de s'assurer qu'elle fonctionne et qui est en charge de réparer ce qui ne fonctionnerait plus
  • quelles sont les garanties souscrites ? Ou de manière simplifiée : sous combien de temps ce qui ne fonctionne plus doit être pris en charge (on parle alors de Garantie de Temps d'Intervention), et réparé (on parle de Garantie de Temps de Rétablissement)
  • quelles sont les sécurités mises en place ?
  • qui dispose des accès à la production ? Comment sont révoqués ces accès ?

Ces aspects sont importants, et requièrent une attention et une expertise à part entière. C'est notamment pour cette raison que nous avons créé une activité devops dédiée à ces sujets au travers de Plunge.

Ainsi, nous disposons d'un monitoring actif et nous mettons à disposition de nos clients (ou des clients de nos clients) une solution de Helpdesk permettant de remonter des dysfonctionnements (par ticket, e-mail, etc).

Ces outils permettent de suivre les incidents du moment où ils surviennent jusqu'à leur résolution et ce, même si plusieurs interlocuteurs (qu'ils soient côté technique ou côté client) doivent intervenir.

7 - Et après ?

Notre guide sur la vision produit vous aidera également à vous projeter après la réalisation du projet. Car la mise en production d'un produit n'est pas une fin : ce n'est qu'un début, et un produit auquel on n'apporte aucune modification ni aucune amélioration est un produit mort.

Dans ce guide, vous verrez également comment définir (en amont) différents indicateurs qui vous aideront à mesurer le succès et la trajectoire de votre projet.

Bien entendu, une fois les différentes phases du projet terminées, nous continuons à vous accompagner dans la durée et en proximité.

N'hésitez pas à nous solliciter si vous avez la moindre question ou une simple demande de conseils : nous sommes là pour ça !