Comment livrer en deux semaines quand il n'y a pas d'autre option

La plupart des projets ont une piste de décollage. Des semaines de cadrage, de collecte des besoins, de revues de design, d'approbations des parties prenantes. La machine de livraison qui tourne à son rythme normal.

Et puis parfois, la machine se brise. Un événement externe fait s'effondrer l'échéancier. Le besoin d'affaires est immédiat et l'option d'avancer lentement n'existe pas. Il faut livrer — maintenant — et régler le reste plus tard.

En mars 2020, c'était ma réalité.

La situation

Le Muttart Conservatory de la Ville d'Edmonton avait une boutique de plantes florissante. Les citoyens entraient, choisissaient leurs plantes, payaient à la caisse, repartaient chez eux. Puis la COVID-19 a frappé et l'établissement a fermé ses portes au public du jour au lendemain. Plus de ventes en personne. Aucune période de transition. La source de revenus — et le service aux citoyens qui en dépendaient — s'est tout simplement arrêtée.

Une tentative de solution était déjà en place. Quelqu'un avait essayé d'adapter le CRM existant de la Ville pour gérer les commandes en ligne. C'est entré en service. Ça ne fonctionnait pas. Aucun inventaire en temps réel, aucune gestion automatisée des commandes, du personnel qui faisait du rapprochement manuel jour et nuit juste pour tenir le rythme. L'exploitation coûtait plus cher que ce qu'elle générait.

J'avais deux semaines pour corriger le tir.

Décision un : ne pas construire, intégrer

La décision la plus importante que j'ai prise dans la première heure, c'est celle-ci : je ne vais rien construire à partir de zéro.

Quand le temps est la contrainte, le développement sur mesure est presque toujours la mauvaise réponse. Le sur-mesure exige de la collecte de besoins, des décisions d'architecture, du temps de développement, des tests, une infrastructure de déploiement et du débogage en production. Tout cela prend des semaines au minimum. Nous n'avions pas des semaines.

Ce qu'il nous fallait, c'était une plateforme qui réglait déjà le problème — du commerce électronique avec inventaire en temps réel — et que je pouvais configurer et mettre en ligne en quelques jours. Shopify était la réponse. Ce n'était pas un compromis. C'était le bon outil pour la tâche, choisi sous la contrainte du temps.

C'est la décision que la plupart des gens ratent en situation de crise. La pression de faire quelque chose se traduit souvent par la pression de construire quelque chose. Résistez-y. La question n'est pas « qu'est-ce qu'on peut construire ? » La question est « qu'est-ce qui existe déjà et qui règle ça ? »

Décision deux : découper sans pitié

Deux semaines, ce n'est pas assez pour construire tout ce que chacun pourrait souhaiter. C'est assez pour construire la chose qui règle le problème central.

J'ai défini le résultat minimal viable : les citoyens peuvent acheter des plantes en ligne, l'inventaire est suivi en temps réel pour qu'on ne vende jamais en rupture de stock, et il y a une option de cueillette à l'auto pour les gens habitués de se déplacer en personne.

Tout le reste — analytique avancée, programmes de fidélité, design sur mesure, multiples modes de paiement, optimisation en français — est allé dans un carnet de tâches. Pas pour toujours. Juste pas maintenant.

Découper sans pitié est inconfortable, parce que ça oblige à dire non à des gens qui ont des besoins légitimes. Mais c'est la seule façon de livrer sur une échéance qui ne peut pas bouger.

Décision trois : communiquer avant d'être prêt

Au jour trois, avant que quoi que ce soit ne soit construit, j'ai informé les parties prenantes de ce que nous allions livrer exactement, de ce que nous ne livrerions explicitement pas dans cette phase, et pourquoi. Je leur ai montré le plan Shopify. J'ai expliqué le processus de cueillette à l'auto sur un tableau blanc.

Il y a eu des questions. Il y a eu des demandes d'ajouts. J'ai documenté chaque demande et je les ai reportées à la phase deux. Puis je suis retourné construire.

C'est important parce qu'en situation de crise, l'absence de communication crée de l'anxiété, et l'anxiété crée de l'interférence. Les parties prenantes qui ignorent ce qui se passe se mettent à poser des questions aux pires moments, à convoquer des réunions, à réclamer des suivis. Les informer tôt — même quand on n'a pas toutes les réponses — vous achète l'espace pour exécuter.

Décision quatre : tester avec de vrais utilisateurs, pas avec soi-même

Au jour dix, le système de base fonctionnait. Avant la mise en ligne, j'ai demandé à trois membres du personnel — des gens qui allaient réellement s'en servir — de parcourir le flux d'achat et de cueillette comme s'ils étaient des citoyens.

Ils ont trouvé des choses auxquelles je n'avais pas pensé. Pas des bogues au sens traditionnel, mais des trous dans l'expérience. Des instructions de cueillette pas claires. Un courriel de confirmation qui ne disait pas aux citoyens quoi apporter pour récupérer leur commande. Un format de description de produit qui se prêtait mal au magasinage en ligne.

J'ai tout corrigé en deux jours. Pas parce que j'avais du temps à perdre, mais parce que lancer avec ces trous aurait créé un fardeau de soutien qui aurait consommé plus de temps que de les corriger avant le lancement.

Ce que nous avons lancé

Au jour quatorze, la boutique en ligne du Muttart est entrée en service sur Shopify. Inventaire en temps réel. Confirmation de commande automatisée. Réservation de cueillette à l'auto avec des instructions claires. Option de livraison à domicile.

Le temps supplémentaire a cessé. Les citoyens pouvaient magasiner. La source de revenus a repris. Le personnel est passé de journées à rapprocher des feuilles de calcul à des journées à traiter des commandes.

À quoi ressemble ce cadre dans n'importe quelle crise

1. Ne construisez pas — trouvez ce qui existe déjà. Le développement sur mesure est un dernier recours sous pression du temps, pas un premier réflexe.
2. Définissez le résultat minimal viable, pas le résultat idéal. Livrez la chose qui règle le problème central. Tout le reste, c'est la phase deux.
3. Communiquez avant d'être prêt. Informez les parties prenantes tôt. Reportez tous les ajouts dans un carnet documenté. Protégez votre temps d'exécution.
4. Testez avec de vrais utilisateurs avant le lancement. Pas de l'assurance qualité. De vraies personnes qui vont réellement utiliser la chose.
5. Lancez, puis itérez. Un système en service qui est correct à 80 % vaut plus qu'un système parfait livré dans trois mois.

La contrainte des deux semaines n'a pas produit un moins bon résultat. À certains égards, elle en a produit un meilleur — parce qu'il n'y avait pas de temps pour les débats de comité, pas de place pour la dérive des exigences, et aucune occasion de trop réfléchir à des décisions qu'il fallait prendre puis dépasser.

La pression, bien gérée, clarifie les choses.