L’essentiel de notre travail consiste à construire des logiciels qui appartiennent à un client. UMOYA Zone est différent. C’est une coentreprise, et être copropriétaire d’un produit nous a appris des choses que le travail pour des clients n’enseigne pas.
Presque tout ce que construit nVisionIT appartient à quelqu’un d’autre. Un client décrit un résultat, nous concevons et livrons le système, et il en devient propriétaire. C’est notre métier, et cela le restera.
UMOYA Zone fait exception. C’est une application de développement personnel et de performance, conçue en coentreprise avec ses fondateurs, qui ont passé des années à mettre au point une méthode de coaching pour aider les gens à se fixer des objectifs et à tenir les habitudes qui les y conduisent. Nous avons apporté l’ingénierie, et nous avons notre part dans ce que le produit deviendra.
Les fondateurs avaient une méthode et des années de pratique directe avec des personnes. Ce qui leur manquait, c’était un moyen de la mettre dans la poche de chacun et de la faire fonctionner durablement sur deux plateformes mobiles. Nous savions construire le logiciel et le faire tourner, et nous n’aurions jamais inventé une méthode de coaching.
La copropriété place les deux parties derrière le même résultat. Quand les fondateurs demandent une fonctionnalité, nous n’établissons pas de devis. Nous décidons ensemble si elle mérite sa place dans le produit, et certaines demandes s’arrêtent là.
La première vraie décision produit portait sur les données. Les gens utilisent l’application pour noter la façon dont ils se voient, y compris les mauvaises semaines. Nous avons décidé très tôt que ces saisies resteraient sur le téléphone de l’utilisateur et n’atteindraient jamais nos serveurs. Cela a fermé la porte à certaines fonctionnalités qui dépendent de la collecte centralisée des données de tous, et cela a fait du produit un espace où l’on peut être honnête. Un prochain article décrit ce que cela a impliqué pour l’ingénierie.
Un projet client se termine par la recette et la passation. Un produit ne se termine pas. Chaque nouvelle version d’iOS et d’Android doit être testée avec l’application, les boutiques d’applications posent leurs propres questions, et quelqu’un doit décider à quoi servira la prochaine version.
Dans le travail pour des clients, cet effort continu relève généralement du budget de quelqu’un d’autre. Ici, il relève du nôtre, et cela a changé la façon dont nous conseillons nos clients dès la conception. Quand un client demande une seconde plateforme, une dépendance supplémentaire ou une fonctionnalité que peu de gens utiliseront, nous chiffrons désormais les années de maintenance qu’elle entraîne en plus du développement.
On utilise un logiciel d’entreprise parce que son travail l’exige, et l’on s’accommode d’un écran maladroit. On ouvre une application de bien-être sur son temps libre, et si la première minute est confuse, beaucoup ne reviennent jamais. Cela a orienté le produit vers un démarrage court, une première action unique et claire, et des fonctionnalités qui ne restent que si elles sont utilisées.
UMOYA Zone s’adresse aux particuliers, ainsi qu’aux organisations qui veulent proposer à leurs équipes un programme structuré : entreprises, académies sportives, écoles et structures de santé. Ce que fait l’application est décrit sur la page UMOYA Zone.
Fait partie de la série Retours de nos projets. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Des normes appliquées de la même façon sur chaque mission, c’est ce qui permet à une petite équipe de développement de garder son rythme au-delà du premier mois. Voici ce que cela donne en pratique.
Les données non structurées sont la moitié la plus difficile du retrait d’une ancienne plateforme. Quand les documents sont au cœur du travail quotidien, l’objectif est une migration que les utilisateurs ne remarquent jamais, et le risque se loge ailleurs que dans le code.
Quand un investisseur regarde sous le capot d’une plateforme en croissance, les questions portent sur les identifiants, les données et la réalité des corrections. Ce que nous avons appris en menant une due diligence technique de la première revue jusqu’à la remédiation vérifiée.
