La team
Pour ce printemps, notre équipe s'est agrandie avec l’arrivée de David, Xavier et Sylvain.
Question vie de l’agence, en période de confinement, toute l’équipe se rassemble régulièrement sur Slack pour échanger, travailler, mais aussi pour partager des apéros… à distance ;)
Distances obligent, nous nous sommes réunis chacun chez soi pour la photo d’équipe.
Les projets
Après une période de test avec quelques clients privilégiés, le site e-commerce B2B myprint pour GPV FRANCE est en ligne. Pour celles et ceux qui n’auraient pas suivi, il s’agit d’un service de commande en ligne de produits d’emballage et d’envoi postal à destination des pros. Ceux-ci peuvent passer des demandes de devis en suivant un workflow standard des métiers de l’impression : obtenir un BAT pour une commande et valider ce BAT pour lancer la production. L’impression est au choix : Offset ou numérique, sur une ou deux faces, avec des couleurs quadrichromie, pantone ou monochromatiques. Voir notre fiche référence.
Nous avons également finalisé un autre site e-commerce B2B à destination des professionnels de l’onglerie : OA Nail System. Un site disponible en France et bientôt aux États-Unis et en Suisse.
Comment ça marche chez Blackbird ?
Pour continuer sur notre lancée de notre dernier article de saison, voici un petit aperçu de notre atelier. Aujourd’hui, nous vous parlons de notre méthode d’analyse et de réponse à un besoin exprimé.
D’une manière générale, un projet débute avec l’arrivée d’un cahier des charges, et si ce n’est pas le cas (cela arrive parfois), nous demandons que ce précédent soit réalisé. En effet, il est très compliqué de fournir une réponse détaillée sans connaître les besoins, les enjeux et plus généralement l’activité de notre prospect.
Une fois réceptionné, le cahier des charges est scrupuleusement lu et annoté. Vient ensuite une première réunion de questions / réponses avec le commanditaire. Cette séance est essentielle pour dévoiler les non-dits du cahier des charges. Il y a dans cette réunion deux objectifs : mettre en lumière les fonctionnalités implicites et comprendre le pourquoi de certaines demandes.
Avec le cahier des charges et les réponses fournies lors de la réunion de Q&A, nous démarrons l’établissement du backlog. Ce backlog est composé d’Epics et de stories. Les Epics sont les branches des fonctions principales du site (par exemple : liste des produits, recherche, compte clients, workflow de la commande, synchronisations, etc.). Elles sont détaillées avec les stories (tâches techniques, spécifications ou User Stories). L’objectif est de définir le projet en ayant une vue utilisateur. Et bien sûr nous considérons tous les utilisateurs du projet : le simple visiteur, le client et les administrateurs (sav, service marketing, responsable vente, logistique, etc.). Chaque fonctionnalité est ainsi recensée dans un grand Google Sheet.
Les fonctions sont également hiérarchisée par release, ce qui nous permet de définir le MVP et toutes les versions ultérieures. Le MVP étant tout ce qui est nécessaire et vital pour pouvoir ouvrir le site e-commerce, les releases suivantes étant, par ordre de priorité, les évolutions souhaitées. Ces évolutions pourront être incluses ou non dans le budget initial du projet.
Avec ce jeu de versionning, nous permettons ainsi un arbitrage qui sera réalisé avec le commanditaire, selon ses besoins, le temps alloué à la production du projet et le budget. Les fonctions qui seraient éventuellement écartées pendant l’arbitrage pourront toujours revenir dans le projet dans de futures phases.
Ce document est ensuite transmis aux développeurs et intégrateurs pour qu’ils puissent en faire l’évaluation des efforts nécessaires, exprimée fonction par fonction en Story Point (pour cela, nous restons simple, un Story Point égal une heure… une convention qui nous permet de comparer les projets et d’obtenir un effort juste, établi selon des mesures rationnelles).
Une fois l’estimation réalisée, le backlog est consolidé et devient d’un côté une enveloppe budgétaire, de l’autre une capacité de production calculée sur le nombre de développeurs alloués au projet et de leur focus que l’on pourra accorder.
Lorsque le projet est validé, le backlog est importé dans notre outil de gestion de production (Jira), ce qui nous permet de le planifier et de contrôler la justesse des estimations.
Pour conclure, ce backlog est chez nous un outil essentiel pour la définition du périmètre et pour assurer le suivi de l’avancement du projet. C’est notre fil d’Ariane pour nous permettre de parcourir le labyrinthe complexe du code et sortir un beau projet, rentable, efficace et évolutif.
Nous vous souhaitons à tous de bien prendre soin de vous, restez connectés et chez-vous :)
La team !
