Recherche

Décider ce que
l'on construit.

Avant d'écrire la moindre ligne de code, nous faisons passer un problème par cinq portes. Au bout, soit nous le construisons, soit nous l'abandonnons. Et il nous faut quelques semaines pour y arriver.

DOSSIER DE DOMAINE THÈSE CONSEIL DES PARTIES DÉFINITION GO / NO-GO GO · COMMERCIALISER NO-GO · RETOUR À LA FILE
5
portes entre une question et une construction
7
domaines passés par ces portes à ce jour
3
produits en service aujourd'hui
0
produit construit sans Go
Les portes

Cinq portes.
Chacune finit par un écrit.

Rien ne passe à la porte suivante tant que la précédente n'est pas mise par écrit. Les exemples ci-dessous suivent un même domaine : le logiciel scolaire.

01

Choisir le domaine

Nous choisissons un secteur où la région a un vrai besoin et où nous avons les ingénieurs pour y répondre. Le domaine reçoit un court dossier : ce que nous savons, ce que nous ignorons, et les questions qui méritent une réponse. Nous ne prenons que les domaines que nous pouvons mener jusqu'à un produit fini.

On en sort avec · un dossier de domaine
Exemple
Dossier de domaineDans la file
Écoles privées, Égypte
  1. Avec combien d'outils distincts une école fonctionne-t-elle ?
  2. Qui saisit deux fois les mêmes informations sur un élève, et à quelle fréquence ?
  3. Que peut réellement voir un parent aujourd'hui ?
Étape suivante : entretiens sur le terrain
02

Nommer le problème

Nous allons sur le terrain. Nous interrogeons ceux qui font le travail, regardons de près les outils qu'ils utilisent aujourd'hui, et notons où les choses cassent. Cette porte se ferme quand nous pouvons énoncer le problème central en une phrase dont on pourrait prouver qu'elle est fausse.

On en sort avec · une thèse d'une page
Exemple
Thèse du problèmeUne page
Le problème, en une phrase

Une école garde le même élève dans cinq systèmes qui ne partagent pas leurs données. Personne ne voit donc l'enfant dans son ensemble.

Nous avons tort si la plupart des écoles fonctionnent déjà avec un seul système connecté.
03

Réunir tout le monde

Nous nous asseyons avec tous ceux dont le problème relève : le régulateur, le propriétaire, ceux qui s'en serviraient chaque jour, et celui qui paie. Ils nous disent ce qu'une solution doit faire pour qu'ils l'adoptent.

On en sort avec · une forme de solution acceptée par tous
LE CONSEIL une table, un problème RégulateurPropriétaires d'écolesDirecteursEnseignantsParents Openner
04

Écrire la spécification

Nous écrivons ce que nous construirions avant d'en construire la moindre partie : l'architecture, les données, qui peut voir quoi, et ce que cela coûte à faire tourner chaque mois. Si ceux qui étaient autour de la table ne s'en serviraient pas, nous continuons à y travailler.

On en sort avec · une spécification et un dossier économique
Exemple
Spécificationv1.0
Socle
Un seul dossier élève, 24 modules connectés
Accès
Les rôles décident qui voit quoi. Chaque modification est tracée.
Langue
Arabe et anglais, de droite à gauche
Qui paie
L'école, par élève et par mois
05

Décider

Nous tranchons et nous le mettons par écrit. Un Go passe à la commercialisation. Un No-Go est archivé avec tout ce que nous avons appris, et le domaine retourne dans la file pour être réexaminé plus tard.

On en sort avec · un mémo de décision signé
Exemple
Mémo de décisionArchivé
Domaine
Éducation
Décision
Go
Suite
Construire, puis piloter dans des écoles du Caire
Resp. de la rechercheAssocié gérant
Go
Apportez votre problème

Faites passer votre problème par les portes.

Des ministères, des entreprises et des universités nous confient les mêmes cinq portes pour un problème qui leur est propre. Vous obtenez une décision écrite en quelques semaines. Nous ne construisons que si la réponse est Go.

GouvernementsEntreprisesUniversitésOrganismes à but non lucratif
Engager la conversation
La porte cinq, de près

Quatre questions.
Il faut quatre oui.

À la dernière porte, chaque domaine passe les mêmes quatre questions. Basculez-les et regardez la décision changer.