Michael Ballé, Céleste Dhellemmes et Woody Rousseauexpliquent pourquoi il est clé de mettre la valeur au cœur des discussions avec le client pour réussir le développement d’une entreprise prospère et robuste dans le domaine de la tech.
56 % de croissance d’une année à l’autre, c’est fantastique – une bénédiction même. Atteindre de tels résultats est enivrant, mais cela vient également avec son lot de tracas : où trouver des développeurs ? Une fois que nous les avons convaincus de nous rejoindre, comment allons-nous trouver des projets sympas pour maintenir leur intérêt – et les garder ? Comment allons-nous créer un environnement convivial en des temps si difficiles ? Dans la frénésie du quotidien, il est aisé de se retrouver embourbé dans les problèmes sans fin de ventes ou d’opérations et de passer en mode réactif.
Avec mon co-fondateur Rodolphe Darves-Bornoz, nous sommes tout à fait conscients que nous avons de la chance de nous trouver sur un marché où la demande surpasse largement l’offre, et d’avoir choisi le marché de la technologie financière (FinTech) pour notre start-up Tech. Il y a plein de boulot et de projets fascinants. Nous sommes très fiers d’avoir aidé BpiFrance, la banque d’investissement française, à promouvoir l’innovation et la finance auprès des entrepreneurs, pour répondre à la pandémie du Covid-19, et à adapter leur offre auprès des entreprises en difficulté dans ces temps de grande nécessité. Mais nous avons réalisé à quel point il était simple de passer en mode « livrer à tout prix » pour satisfaire nos clients et passer à autre chose.
Mesurer notre taux de recommandation (NPS) tout au long de nos projets fait partie intégrante de l’ADN de notre entreprise. Nous avons donc une bonne perception de l’état d’avancement du projet et savons si les clients sont satisfaits de nos équipes. Nous savons quand nous faisons les choses correctement ou pas. Mais le NPS ne nous dit pas si nous faisons les bonnes choses ! Il y a quelques années, nous avons commencé à nous questionner sur la qualité des systèmes que nous fabriquons – la qualité fondamentale, pas seulement « le moins de bugs possibles et livrer à temps ». Nous avions besoin de nous construire une réputation de créateurs de logiciels intelligents afin de créer une entreprise prospère et ainsi devenir incontournables pour l’acquisition de systèmes utiles et élégants. C’est ce qui nous a amenés à explorer le Lean.
L’une d’entre nous, Céleste, a rejoint l’Académie Lean Ingénierie (animée par Michael) et a commencé à se demander comment les concepts du Lean en Ingénierie pourraient s’appliquer à la production de logiciels. En commençant par les outils de QFD (Quality Function Deployment), elle s’est rendu compte que l’architecture des produits pourrait également s’appliquer aux systèmes de logiciels : développeurs et ingénieurs pensent de la même façon quand il s’agit de livrer des fonctionnalités aux clients. Céleste a séparé un produit en 3 parties : les tâches à faire, les systèmes, et les technologies.
- Les tâches à faire définissent les niveaux de performance dont les clients ont besoin, comme la facilité de connexion, la vitesse à laquelle le système répond, et les niveaux de défaillances ;
- Les systèmes sont les pavés de code qui réalisent les tâches demandées à travers l’interface utilisateur ;
- Les technologies consistent à choisir la bonne technologie pour coder le système le plus intelligemment possible. On s’intéresse alors à la sécurité (vulnérabilité au piratage), à la vitesse (le temps de réponse), et la stabilité (les risques de pannes ou de surcharge d’autres systèmes par des interfaces lourdes).
Céleste a représenté sur un diagramme « système » ces 3 aspects de nos produits, en s’essayant dans un premier temps sur des produits existants, sur lesquels nous avions suffisamment de recul pour comprendre nos choix techniques, bons ou mauvais. Elle travaille désormais avec les architectes pour les convaincre de clarifier leurs choix au fur et à mesure qu’ils conçoivent de nouveaux produits ou fonctionnalités pour les clients.
L’observation de ces diagrammes d’architecture nous a donné un regard unique sur notre performance – nous savons mesurer si nos produits finaux sont bons, moyens ou faibles, en nous basant sur les « tâches à faire » une fois qu’ils sont entre les mains de l’utilisateur.
Mais cela nous a aussi amenés à nous poser une question plus profonde sur la valeur du point de vue du client : avons-nous réussi à bien identifier les « tâches à faire » ? Comme nous le savons tous, les distributeurs de logiciels continuent d’ajouter des fonctionnalités à leurs systèmes pour satisfaire tel ou tel soi-disant « besoin client » jusqu’au point où le système est si complexe qu’il en devient inutilisable pour l’utilisateur moyen et requiert une expertise réelle pour naviguer dans les menus et fonctionnalités. Nous savons également que ce qui rend un logiciel plus convivial qu’un autre est souvent compliqué à déterminer : pourquoi préférez-vous utiliser Whatsapp plutôt que Messenger ? Il y a de nombreuses hypothèses – des couleurs plus chaudes, la robustesse (toujours disponible), la confiance (messages cryptés), les temps de réponse, le moteur de recherche, la facilité d’archivage, etc. – mais qui sait exactement ? Les utilisateurs ne peuvent certainement pas nous le dire. Pour eux, choisir l’un par rapport à l’autre est question de pur instinct.
Il est primordial de clarifier les tâches à faire telles que nous les voyons si nous voulons avoir une réflexion vraiment profonde à propos de la valeur : travaillons-nous sur les tâches dont les utilisateurs ont réellement besoin ou envie, mais qu’ils ne nous communiquent pas parce que c’est plus intuitif que raisonné ? Nous ne connaissons pas les réponses à ces questions fondamentales, mais nous imaginons des façons de mieux évaluer le comportement réel des utilisateurs et d’analyser les réclamations pour tenter de comprendre ce qu’ils aiment ou n’aiment pas.
Les bénéfices pour les utilisateurs ne constituent toutefois qu’une partie de l’équation. L’autre aspect est le coût total pour les utilisateurs – leur coût de possession et notre coût de développement. Leur coût de possession apparaît dans les bugs qu’ils nous demandent de résoudre ou les fonctionnalités supplémentaires qu’ils souhaitent que nous développions. Nos coûts de développement apparaissent sous deux formes, la production et la retouche : le coût nécessaire du développement (heures de codage, mais aussi coût d’autres fournisseurs, comme le fournisseur de cloud) plus les coûts exceptionnels de développement (heures de débogage et de re-codage).
Au fil de ses lectures Lean, l’un d’entre nous (Woody) est tombé sur le dantotsu, une approche menant à une amélioration radicale de la qualité, qui a été rendue populaire par le vétéran de Toyota Sada Nomura. De ce bouquin, Woody a pris à cœur la notion de management des points faibles : comment isoler des problèmes qualité récurrents et les résoudre jusqu’à ce qu’ils ne réapparaissent plus.
En tant que fondateur et directeur technique de l’entreprise, Woody a investi dans des systèmes pour détecter les bugs en temps réel (une chose étonnamment difficile à faire dans une entreprise de logiciels), comprendre la nature de ces bugs, et commencer une analyse approfondie avec les développeurs de ceux qui reviennent le plus souvent.
Les obstacles sont de taille, car cela doit se faire dans l'urgence de la livraison de chaque projet, avec une pénurie chronique de personnel due à une concurrence féroce pour recruter des développeurs, et une pression constante de la part des clients qui modifient souvent le déroulement des projets alors que le codage est déjà en route. La vie habituelle dans le développement de logiciels ! Pourtant, les premiers résultats sont prometteurs et nous apprenons rapidement sur les problèmes typiques liés à des technologies spécifiques.
Et nous nous sommes rendu compte lors du gemba walk de nos fondateurs que ce dont nous avions besoin, c’était de faire concorder les deux approches pour développer une vision de la valeur qui soit plus cohérente: vrais bénéfices pour les utilisateurs / coût total du service.
Nous avons déjà des retours positifs sur les deux volets de l’équation :
- Nous discutons de plus en plus avec nos clients de ce qu’est la valeur, là où les discussions traditionnelles avec des fournisseurs d’informatique ont tendance à se concentrer sur les tarifs journaliers et les devis de logiciels. Cela a pour effet de changer la nature de notre relation, en arrêtant de tergiverser sur le prix et le délai et en s’intéressant plutôt au résultat pour le client.
- Les tech leaders ont désormais une compréhension plus pratique de notre stratégie zéro-bug – plutôt qu’un slogan d’entreprise, il s’agit de se concentrer sur des activités claires qu’ils peuvent prendre en charge et discuter.
Il est bien possible que les financiers pur sucre demandent comment cela peut se transformer en croissance et en profitabilité, et jusqu'à présent, nous n’avons d’autre réponse que notre conviction que placer la valeur au cœur de nos discussions avec les clients est la clé pour développer un nouveau type d’entreprise. Une entreprise où la technologie apporte de meilleurs résultats, pas seulement du rendement. C’est ce qui donne du sens à notre travail !
Michael Ballé est un auteur et sensei lean, cofondateur de l’Institut Lean France, Céleste Dhellemmes est Head of Product chez Sipios, du groupe M33 Theodo, Woody Rousseau est CTO de Sipios.
Article paru sur Planet-Lean.com. Traduction par Marc-Antoine Guichard, Nicolas Villemain et François Lopez.
Téléchargez le PDF
Cet article La valeur du logiciel est apparu en premier sur Institut Lean France.
A lire aussi
-
Qu’est-ce qu’une vraie transformation Lean ?
Publié le 19/08/2021
En s’intéressant aux transformations réussies, les auteurs expliquent pourquoi...
-
Être un bon manager aujourd’hui – travailler compétence et confiance
Publié le 03/12/2021
Pourquoi sommes-nous si moroses ? C’est la question que se pose le journal...
-
Combattre les silos par le travail en équipe
Publié le 10/05/2017
Quelle valeur supplémentaire avez-vous proposé à vos clients dernièrement ?...
-
Problèmes épineux et notions de seuil
Publié le 22/06/2021
Un an après le début de la pandémie de COVID, Toyota a annoncé des résultats...
-
L’agenda des formations Lean Inter-Entreprises 2017 (2nd semestre) est en ligne
Publié le 28/12/2016
Le Relais lean Centre opère les formations inter-entreprises de l’Institut....
-
Publié le 26/01/2016
En 50 ans, Toyota est devenu le leader d’un marché déjà fortement saturé. Deux...
-
La théorie de la transformation lean
Publié le 09/05/2022
Dans cet article théorique passionnant, l’auteur nous rappelle comment, dans une...
-
La magie du lean réside dans l’identification des problèmes
Publié le 04/11/2021
S’appuyant sur le livre récemment publié par Nate Furuta, Michael Ballé...
-
Publié le 21/03/2016
Que penser d’un nouveau patron qui veut s’appuyer sur les A3 pour résoudre les...
-
Arrêtons de confondre management visuel et reporting au mur
Publié le 26/11/2018
Le rêve de certains dirigeants, qui voient dans le management visuel une...