Retours de terrain et repères pour décider de la suite de votre produit.
Dette technique
Une facture à la mauvaise adresse, trois cents remboursements évitables, un rapport faux de 1 200 euros. Cinq cas pour distinguer les défauts du code, des outils et de l’organisation.
Lire l’articleDette technique
Un rapport demande une heure chaque vendredi. L’automatiser paraît facile, jusqu’à ce qu’un doublon explique le travail manuel. Un cas pour distinguer objection utile et attente sans décision.
Dette technique
Une commande pour Lyon, une facture pour Paris et un seul champ d’adresse. Démonstration des erreurs qu’un second champ ne suffit pas à corriger.
Dette technique
Trois heures pour corriger et tester, puis six jours avant la mise en production. Un cas chiffré pour suivre le coût de l’attente jusque dans le travail du support.
Dette technique
120 commandes payées, 120 factures créées, 118 envois acceptés. Deux factures suffisent à montrer ce qu’un contrôle de disponibilité ne vérifie pas.
Dette technique
Un script encore présent, un domaine expiré encore autorisé et des permissions à examiner. Ce que ces constats établissent, et les vérifications nécessaires avant de parler de compromission.
Dette technique
Des centaines d’exceptions dans Slack, une équipe divisée entre incidents et fonctionnalités, puis un arrêt négocié du développement. Ce que nous avons changé pendant le Drynuary et ce qui est resté après.