Nous vivons dans un monde où les outils numériques sont à portée de mains. Une recherche, un achat, un besoin ? Tout peut se faire rapidement grâce à notre ordinateur ou via notre smartphone, et ces possibilités sont d’ailleurs en constante évolution.
Cela n’est possible qu’avec une force accrue des entreprises pour faciliter l’accès à un bien ou un service. Les besoins de création et de modification de fonctionnalités se multiplient donc depuis des années.
Mais au fait, une fonctionnalité ou une évolution, qu’est-ce que c’est concrètement ?
Il s’agit de tout changement dans un applicatif existant. Par exemple, si on parle de petite évolution, on peut penser à l’ajout d’un système de comparaison de produits sur un site e-commerce, ou à la mise à jour du taux de TVA sur la page « panier client » si celui-ci a changé ou encore pouvoir charger un document dans un formulaire de contact, etc. Si on imagine un plus grand projet, ce serait la transition entre l’ancienne et la nouvelle version de Facebook.
Comme on peut le constater, ces projets peuvent être transparent pour les utilisateurs. Mais finalement, comment ça marche ? Simplement avec trois lignes de code ? Non !!
Cet article tentera de montrer les étapes d’un projet en partant du développement et en montrant les étapes qui arrivent avant et après.
Les développements sont terminés. Le plus important est fait, non ? Lorsqu’un dev est terminé, on est loin d’en avoir fini avec ce sujet ! Oui c’est une étape essentielle, mais il ne s’agit que d’une brique dans la mise en place d’un projet. Il en va de même pour l’équipe de DEV qui fera elle aussi partie d’une « équipe projet » de plus grande envergure. Globalement, on peut dire que la partie développement se trouve au milieu d’un projet. Arrêtons-nous sur les étapes que l’on retrouve le plus généralement avant la partie DEV.
Les étapes avant
En effet, avant d’en arriver à développer une fonctionnalité ou un correctif, beaucoup d’étapes ont été franchies :
- L’émergence du besoin
Tout démarre lorsque l’on se rend compte d’une amélioration notable à faire. Il faudra alors détailler cette amélioration et l’ajouter à un liste de fonctionnalités en attente en prenant le temps de rédiger une note rapide sur le travail à réaliser, ou mieux, la spécification détaillée de l’évolution. Il est primordial de tenir a jour un document de spécifications clair sur la partie fonctionnelle (point de vue utilisateurs) d’un projet. En effet, ce document va détailler la philosophie générale et l’usage qui doit être fait pour répondre à un besoin final. En gros, s’il faut mettre à jour la version d’un site, il faudra détailler point par point ce qui doit changer, comment ça doit changer, le comportement attendu, comparer les deux versions, etc. En fonction de cela, un plan de tests sera alors indispensable pour s’assurer que la fonctionnalité remplit correctement sa fonction.
- La composition des sprints
Un sprint, c’est une phase de déploiement d’un produit. Cela sert à organiser en décomposant la mise en production d’un développement souvent complexe. L’idée générale est de commencer par mettre en production une petite fonctionnalité dans un premier sprint, puis de la faire évoluer au travers de différents autres sprints jusqu’à atteindre l’objectif final. On va piocher dans la liste de fonctionnalités globale en attente (backlog) et prioriser celles que l’on souhaite voir en production pour le prochain sprint. Cela va favoriser la tenue d’une organisation claire pour l’ensemble des équipes. La méthode Agile prévoit des sprints réguliers, tous les quinze jours en moyenne. En règle générale le produit final est déjà livré en production et fonctionnel. Il ne s’agira donc que de l’update de celui-ci.
Il faudra bien sûr veiller à ce que les spécifications de chaque évolution / sprint soit claire et compréhensible. (On ne le répètera jamais assez dans notre métier : la documentation est primordiale !) Ces sprints auront vocation à être quantifiés en termes de charge et de coût de développement afin de pouvoir s’inscrire dans une mise en production. Selon la charge de travail et la complexité, les projets seront distribués selon un calendrier et chaque créneau de MEP sera identifié. À cette étape, les développements peuvent commencer et suivre leur parcours jusqu’au prochain projet !
- Cas particulier : Les lots
Parfois, on commence à avoir plusieurs évolutions de même nature, ou touchant à une même fonctionnalité dans l’objectif de proposer une évolution par étapes. Ces étapes se traduiront en parties indépendantes appelées « lots ». L’identification et la charge de travail est donc plus clairement identifiée et ordonnée spécifiquement pour un lot. Sur cette fonctionnalité précise, cela aura pour but d’organiser la « mise en production », c’est-à-dire l’ouverture du service aux utilisateurs.
Les étapes après
Voyons à présent les étapes que l’on retrouve après la partie développements.
- Tester le développement
La phase de test arrivera après les développements et viendra vérifier que la fonctionnalité remplit bien son objectif de base. Dans un premier temps, le développeur testera uniquement son développement. Une équipe QA viendra éventuellement challenger la fonctionnalité dans sa globalité afin de vérifier que tout est conforme. Les spécifications qui auront été rédigées en début de projet seront d’une précieuse aide pour cette partie ; nous en avons parlé plus haut.
Lorsque tout semble OK par rapport à ce qui a été demandé, la fonctionnalité sera alors livrée dans un environnement distinct de la production afin d’effectuer une dernière vérification. (Voir article suivant : Découverte de la QA)
- Tester l’ensemble de la fonctionnalité
Lorsque les équipes techniques auront livré le travail dans un environnement dédié, le métier jettera un œil supplémentaire. C’est ici une phase de tests la plus étendue possible, et plus globale que la phase précédente. En effet, cette nouvelle fonctionnalité viendra s’insérer dans le projet de manière globale en parallèle des autres fonctionnalités prévues. Cette phase vise donc à vérifier que le projet est conforme dans sa globalité et viable au regard des utilisateurs finaux, quel que soit leur parcours au sein de l’applicatif.
Une fois encore, à cette étape, le cahier de recette sera très utile. En effet, le métier viendra s’assurer que le produit est conforme aux attentes. Si certains points ne le sont pas, une correction sera nécessaire de la part de l’équipe technique.
- La mise en production
La mise en production sera constituée des sprints précédemment définis, en tenant compte des projets en cours. On évitera de faire passer dans la même MEP des évolutions qui vont toucher à un même bloc technique ou fonctionnel afin de limiter les risques. Il ne restera plus qu’à confirmer la date de mise en production. Cette MEP devra être minutieusement préparée en tenant informé / faisant participer les acteurs concernés. C’est une étape délicate qui mobilise parfois plusieurs intervenants. Chacun aura un rôle précis à jouer à un moment donné afin que l’enchainement des actions se fasse étape par étape, en validant chacune d’elles. Il faudra donc veiller à ce que tous les acteurs soient informés de la MEP et disponibles s’ils doivent intervenir. Souvent, tout se passe bien. Mais il arrive qu’il y ait des couacs !! Dans ce cas, soit on peut trouver une solution rapide, soit on laisse la version précédente et on décale la mise en production.
Mais d’ailleurs, qui sont-ils, ces intervenants ?
Les acteurs autour d’un projet
De manière générale, nous allons retrouver les équipes suivantes:
- Produit : Cette équipe est garante de la bonne tenue du produit ainsi que de ses évolutions et réclamations clients (parfois au travers d’une équipe support). C’est un point de contact privilégié car il est au centre des autres équipes.
- Avant-vente : Ils sont chargés d’appréhender, de présenter un produit aux futurs clients. C’est souvent cette équipe qui reçoit les questions et idées d’améliorations des futurs utilisateurs.
- Commerciaux : En charge de la contractualisation, ils échangent parfois avec l’équipe produit pour façonner le produit final de façon plus personnalisée pour un client.
- Maîtrise d’ouvrage : C’est l’entité pour laquelle est réalisé le besoin, c’est-à-dire l’organisation qui souhaite voir une évolution au sein du service qu’il propose.
- Le métier : Nom un peu global qui définit l’équipe interne à l’organisation qui sera directement impactée par l’évolution apportée. Par exemple, l’équipe commerciale sera identifiée comme le « métier » pour une évolution sur une page tarifaire.
- Maîtrise d’œuvre : Il s’agit de l’équipe technique en charge des développements. Un point de contact dédié à ce projet sera en charge de coordonner et chiffrer les travaux. Avec le chef de projet MOA, ce sera l’autre point de contact incontournable.
Ces équipes vont intervenir à différentes phases du projet en fonction de l’organisation de celui-ci et de la méthode utilisée. Pour plus de détails, je vous propose cet article qui donne plus d’informations sur le sujet.
Bon voilà, c’est terminé là !
FAUX !
La conduite du changement
En effet, quelque soit sa complexité et son envergure, tout projet ne sera réussi que s’il remplit sa fonction comme espéré par les utilisateurs finaux. S’ils n’adhèrent pas à l’évolution, ce sera un échec.
Pour éviter cela, plusieurs solutions sont à la disposition du chef de projet :
• Analyser et lister les pratiques de l’utilisateur final et comprendre avec précision le besoin. Cela nécessite un énorme travail d’analyse souvent lourd et peu qualitatif. • Organiser le besoin dans une spécification claire et précise pour l’équipe technique afin que le rendu soit le plus proche possible de ce qui est attendu. • Impliquer quelqu’un de l’équipe métier dès le démarrage du projet afin qu’il puisse s’approprier l’évolution en avance de phase. Il deviendra alors un relai privilégié auprès du reste de l’équipe et saura apporter son expertise tout au long de la mise en place. D’autres méthodes sont utilisées également, comme par exemple l’A/B testing. Il s’agira de mettre en production deux versions différentes d’un même produit pendant un temps donné. À la fin, on ne laissera que la version qui sera la plus appropriée aux utilisateurs.
Quoi qu’il en soit, il faut garder à l’esprit qu’il y a autant de contextes et d’organisations que d’entreprise, car elles sont toutes différentes !
