Le 20 mai dernier, nous avons participé à la journée BizSpark sur le Lean Startup, l’occasion pour nous de présenter 2 sessions sur le sujet.
Plus de 200 participants, des rencontres, des échanges constructifs sur le sujet.
Les slides de nos sessions sont ici et ici, et il y a un bon compte-rendu de la journée chez PIA ici.
Pour revenir à nos sessions, voici les messages que l’on souhaite faire passer.
Quelle place le développeur occupe-t-il dans la création de valeurs ?
Le développeur a le rôle fondamental d’orchestrer l’information entre l’utilisateur et la machine.
- Il doit analyser la situation, comprendre les besoins et les manques.
- Il doit concevoir les données, les traitements, les échanges, l’expérience utilisateur, l’ergonomie.
- Il doit penser à la sécurité, les performances, la montée en charge.
Doit-il pour autant écrire du code pour faire tout cela ? Le code est fragile, source de bugs, de rigidité, difficile à faire évoluer.
Notre vision est que le développeur doit être plus proche de la création de valeurs qu’il ne l’est aujourd’***. C’est le sens de l’histoire, de ne plus passer son temps à s’occuper des détails techniques:
- Il y a 20 ans, il était nécessaire d’écrire du code pour gérer finement la place des octets sur le disque.
- Il y a 10 ans, le développeur devait faire attention à gérer correctement la mémoire, et à bien désallouer toutes les ressources qu’il avait allouées précédemment.
- Aujourd’***, on ne s’occupe plus de savoir où sont les machines physiques, ni le lieu de stockage.
Et on prétend même qu’on n’a plus besoin d’écrire la moindre ligne de code spécifique pour afficher/transporter/stocker des données métiers.
Et pour être efficace dans ces taches, on a besoin d’outils.
- De même que l’on a besoin d’un compilateur pour traduire le code écrit en ce que comprend la machine.
- De même que l’on a besoin d’un Garbage Collector, pour gérer la mémoire comme il faut sans que l’on ne s’occupe de rien.
- De même que l’on a besoin d’une base de données, pour stocker les données sur le disque.
- On a besoin d’outils pour piloter la machine dans l’affichage, le transport, la communication, et nous sommes un de ceux-là.
Certains développeurs nous reprochent d’éliminer une partie de leur travail; oui, nous éliminons la partie stupide, répétitive, sans valeur, que la machine peut très bien faire toute seule. A condition toutefois de lui décrire ce qu’elle doit faire; c’est là où le développeur a sa valeur ajoutée. Avec sa capacité d’analyse, il peut décrire correctement à la machine ce qu’elle doit faire pour rendre le service à l’utilisateur.
Mais ce n’est pas un travail d’écriture de code, c’est un travail de description:
- c’est beaucoup plus facile à faire, cela demande moins d’efforts et moins de connaissances techniques.
- c’est beaucoup plus rapide à faire, cela demande beaucoup moins de temps.
- on fait moins d’erreurs, le résultat est beaucoup plus solide.
- et surtout, on peut modifier, effacer, recommencer, comme on le souhaite, sans remettre en cause l’existant, sans remettre en cause des journées de travail.
Et si la machine sait le faire, sans qu’un être humain ait besoin d’écrire du code, c’est que ce travail de codage n’a pas de valeur pour le produit, c’est du gâchis de temps, d’argent, d’énergie.
Un MVP en 3 jours, c’est possible !
Avec PIA, nous souhaitons montrer qu’un MVP est faisable avec un investissement minimum, dans l’esprit du Lean Startup.
Pour cela, il est préférable d’avoir une méthode et des outils.
Pour la méthode, PIA sait très bien le faire, et l’a très bien expliqué et montré:
- Donner du sens au produit, fédérer autour de l’usage.
- Cibler les utilisateurs, définir les profils, les attentes de l’innovation.
- Définir le contenu, l’architecture de l’information.
- Réaliser un prototype papier.
A partir du prototype papier, on est en mesure d’implémenter très rapidement. C’est là que notre outil entre en jeu:
- Décrire un premier modèle simple avec les données de l’application; le vocabulaire est le même que celui employé par le fonctionnel.
- Décrire les écrans; ce travail est facile, parce que le prototype papier nous dit exactement ce que l’on doit faire.
- Décrire le chargement; j’écris volontairement décrire et pas écrire, car il s’agit bien d’un travail descriptif, plus que du codage technique. Je ne sais pas où sont mes données, dans une base, dans un fichier, dans Azure Storage.
Enfin, déployer cette première version dans Azure, 3 clics de souris, 1 minute de travail.
En quelques heures, on a un premier jet qui fonctionne, que l’utilisateur peut utiliser et critiquer.
Et puisque la question a été posée, l’exemple montré sur scène représente 1/2 journée de travail pour le 1er jet, et 2h pour le 2ème; j’ai fait sur scène les modifications de développement, et il y a un travail d’intégration du design visuel, à réaliser avec une feuille de styles CSS.
En conclusion, pour revenir à l’esprit du Lean Startup, je dirais qu’on a essayé de montrer que le développeur peut et doit se rapprocher de l’utilisateur, éviter de se perdre dans des considérations techniques, qu’il faut pour cela des outils, et que l’approche est la suivante:
- L’utilisateur est au coeur du processus.
- On travaille en cycle court, très court, quelques heures suffisent pour réaliser des choses visibles et utilisables.
- L’application est toujours en état de marche, cela réduit les risques.
- Il est possible de changer les plans, le pivot est facile.
Nous aurons l’occasion d’y revenir avec des exemples concrets de réalisations.