Quelle part des fonctionnalités livrées est encore utilisée 90 jours après leur sortie, et qu'est-il advenu de celles inutilisées et de leurs indicateurs ?

Question ouverte

Les outils de feature flags ont commencé à formaliser la durée de vie d'un indicateur : la documentation d'Unleash attribue à chaque type d'indicateur une durée de vie attendue et indique que tous les indicateurs sont automatiquement marqués comme potentiellement obsolètes une fois cette durée dépassée, en guise d'invitation au nettoyage. Cela traite l'indicateur. Cela ne dit rien de la fonctionnalité qui se trouve derrière, et le wiki ne dispose d'aucune donnée sur la moitié la plus inconfortable de la question : parmi les fonctionnalités qu'une équipe livre en un an, combien sont encore utilisées une fois que l'annonce de lancement s'est estompée ?

La question est délibérément étroite. Prendre chaque fonctionnalité publiée pendant une période définie qui disposait d'un signal d'usage (un événement, un paramètre, une vue de page), et observer ce même signal 90 jours après la sortie. Quelle part des fonctionnalités avait un usage supérieur à un seuil que l'équipe considère significatif, quelle part avait un usage résiduel, et quelle part n'en avait pratiquement aucun ? Quelles caractéristiques séparaient les groupes : fonctionnalités demandées par de nombreux utilisateurs par rapport à celles demandées par un seul gros client, fonctionnalités repérables dans le flux principal par rapport à celles cachées derrière une page de paramètres, fonctionnalités qui remplaçaient un comportement existant par rapport à celles qui en ajoutaient un ? Puis le devenir : pour les fonctionnalités sans usage significatif, l'équipe les a-t-elle supprimées, masquées, laissées en l'état, ou a-t-elle investi dans leur promotion, et comment cette décision a-t-elle été prise ? Et le volet ingénierie : les indicateurs des fonctionnalités inutilisées ont-ils été supprimés, laissés activés, ou laissés désactivés avec le code toujours en place, et le marqueur d'obsolescence de l'outil de feature flags a-t-il joué un rôle ?

La réponse compte parce que les feuilles de route sont planifiées comme si chaque fonctionnalité livrée était conservée, alors que le coût d'une fonctionnalité inutilisée (son code, son indicateur, ses tests, sa documentation, ses questions de support) perdure jusqu'à ce que quelqu'un en décide autrement.

Ce qu'une réponse utile contient

Le type de produit, le nombre d'utilisateurs, et le nombre de fonctionnalités publiées durant la période, avec une définition de « fonctionnalité » (une unité qu'un utilisateur pourrait nommer, pas un commit). Le signal d'usage par fonctionnalité et le seuil utilisé pour « significatif », avec le raisonnement. La part dans chaque tranche d'usage à 90 jours, et, si disponible, à un moment ultérieur, puisque certaines fonctionnalités croissent lentement. Les caractéristiques relevées par fonctionnalité et leur lien avec l'usage. La décision prise pour chaque fonctionnalité à faible usage et par qui elle a été prise. L'état de l'indicateur et du code six mois plus tard. Si l'analyse a changé la façon dont l'équipe planifie, par exemple en écrivant une attente d'usage avant de construire. L'année d'une seule équipe constitue une réponse utile si les définitions sont énoncées.