Ne pas corriger un bug : l'arbitrage clé de la dette technique
On a choisi de ne pas corriger un bug connu depuis 6 mois. Un CTO hands-on détaille la grille d'arbitrage utilisée pour prioriser un backlog de bugs.
Lire l'article →7 articles sur ce sujet
On a choisi de ne pas corriger un bug connu depuis 6 mois. Un CTO hands-on détaille la grille d'arbitrage utilisée pour prioriser un backlog de bugs.
Lire l'article →Une roadmap bien priorisée peut rester déconnectée du terrain. Comment une question simple posée à l'équipe a révélé qu'on construisait des features que personne n'utilisait - et ce qu'on a mis en place pour y remédier.
Lire l'article →Un retour utilisateur qui fait sens ne devrait jamais finir dans un backlog. Retour sur deux features livrées en une nuit sur Takema, et sur ce que ça demande techniquement.
Lire l'article →Un backlog qui déborde et une équipe occupée ne veulent pas dire qu'on avance. Un CTO hands-on explique pourquoi l'activité masque un problème de priorisation et comment le résoudre.
Lire l'article →Un ticket Jira bien rédigé crée une fausse impression d'alignement entre product et tech. Après 20 ans en équipes produit, voici pourquoi la spécification ne remplace jamais le brief en conversation.
Lire l'article →Livrer une feature en 24h sur une marketplace existante, c'est possible. À condition de résister à l'envie d'en faire trop. Retour sur une approche MVP que j'applique chez mes clients.
Lire l'article →Brief, maquettes Figma, validation... et un an plus tard, enfin la prod. Pourquoi ce processus est une erreur coûteuse, et comment livrer un MVP en 6 semaines.
Lire l'article →
CTO hands-on : j'architecture, je code, je structure l'équipe technique. Je transforme des objectifs business en solutions robustes et durables pour les startups et PME.
En savoir plus →