Comment nous construisons un logiciel, de la première idée au lancement

La plupart des projets logiciels n'échouent pas à cause de la technologie. Ils échouent parce que personne ne s'est mis d'accord sur le problème, le périmètre ou le sens de « terminé ». Notre méthode est construite pour éviter précisément cela. Voici comment un projet type avance, de la première idée au jour du lancement.

Partir du besoin, pas de l'outil

La première conversation ne porte pas sur les frameworks. Nous demandons ce qui ralentit l'entreprise, qui en souffre et ce qui changerait si le problème était résolu. Une bonne réponse est précise. « Notre équipe ressaisit chaque réservation dans trois tableurs » est utile. « Nous avons besoin d'une application » ne l'est pas.

• Qui va l'utiliser, et à quelle fréquence ?
• Que font ces personnes aujourd'hui à la place ?
• Que faut-il pour que ce projet soit considéré comme réussi ?
• Qu'est-ce qui peut attendre une prochaine version ?

Écouter ceux qui vivront avec la solution

Des exigences écrites en salle de réunion sont des suppositions. Les personnes les plus proches du travail savent où le temps se perd vraiment. Nous leur parlons, nous observons comment le travail se fait aujourd'hui et nous notons ce que nous entendons avec des mots simples que chacun peut vérifier.

Étudier les options et fixer le périmètre

Avant d'écrire du code, nous choisissons une approche : l'architecture, les technologies et le contenu de la première version. Nous préférons une petite première version qui résout le problème central à une grande qui prétend tout résoudre. Une feuille de route courte indique ce qui vient maintenant, ce qui vient ensuite et ce qui est volontairement laissé de côté.

Construire par cycles courts

Nous travaillons par itérations courtes et montrons quelque chose de concret à la fin de chacune. Pas des diapositives, mais une partie fonctionnelle du produit. La voir tôt est le moyen le moins coûteux de découvrir qu'un écran prête à confusion ou qu'une règle a été mal comprise. Une modification en semaine deux coûte très peu. La même modification au sixième mois peut coûter très cher.

Tester avant que quoi que ce soit n'atteigne les utilisateurs

Les tests font partie de la construction, pas d'une étape ajoutée à la fin. Nous vérifions que les fonctionnalités marchent, que les anciennes n'ont pas cassé quand les nouvelles sont arrivées, que le produit est assez rapide sur des téléphones et des connexions ordinaires et que les données sensibles sont traitées avec soin. Ensuite, les personnes qui ont demandé le produit confirment qu'il correspond à ce qui a été convenu.

Lancer avec de la supervision, puis continuer à améliorer

La mise en ligne n'est qu'un début. Nous déployons avec de la supervision dès le premier jour pour que les problèmes apparaissent sur un tableau de bord avant d'apparaître dans un message agacé. Après le lancement, l'usage réel nous dit quoi améliorer. Beaucoup de produits demandent quelques ajustements dans les premières semaines, puis un plan d'améliorations régulier.

Ce que vous pouvez attendre de nous

• Un périmètre écrit et clair avant le début du développement
• Des démonstrations régulières de logiciel fonctionnel
• Une communication honnête quand quelque chose change
• Une documentation et une vraie passation
• Un accompagnement après le lancement

Si vous avez une idée ou un processus à améliorer, la meilleure première étape est une conversation. Parlez-nous-en via la page contact et nous vous aiderons à décider quoi construire en premier.