Le macareux (puffin en anglais) est un profil qui, à la tête d'une équipe de développeurs, dispose d'une infinité de fonctions logicielles avec peu ou pas d'impact sur l'entreprise, les clients ou les autres employés.
A PUFFIN — (Planifie des initiatives d'usine de fonctionnalités sans fin), en espagnol équivaudrait à des plans sans fin d'initiatives de fonctionnalités.
Ce terme de profils suppose un coût et aucun bénéfice, en plus d'une grande frustration des équipes qui n'ont aucune visibilité dans l'organisation.
Le terme Feature Factory est né lorsqu'un de mes amis développeur de logiciels s'est plaint qu'il était "juste assis dans l'usine, en train de créer des fonctionnalités et de les expédier à d'autres développeurs".
Comment savoir si vous travaillez dans une usine de fonctions ? Il existe des symptômes clairs qui permettent d'identifier ces structures.
- Sans métrique. Les équipes n'ont pas à mesurer l'impact de leur travail. Ou, si la mesure est effectuée, elle est effectuée de manière isolée par l'équipe de gestion des produits et partagée de manière sélective. On ne sait pas si le travail effectué a fonctionné correctement.
- Mélange rapide d'équipes et de projets (également connu sous le nom d'équipe Tetris). Au lieu de missions ou d'initiatives sensées et compréhensibles, les équipes traitent des attributions de rôles et des projets sans savoir pourquoi ni qui devrait être responsable de quoi. Multitâche dans toutes les opérations et surutilisation des ressources.
- Théâtre de succès autour de "l'expédition" avec peu de discussion sur l'impact. On peut dire beaucoup sur une organisation par les questions qu'elle fête.
- Échecs peu fréquents (reconnus) et travaux abandonnés. Sans éliminer ou améliorer de manière significative les fonctions précédentes. La principale mesure du succès est les fonctionnalités fournies, pas les résultats fournis. Le travail est rarement rejeté à la lumière des données et de l'apprentissage. L'équipement n'a pas la mesure nécessaire pour admettre les défaillances de production.
- Aucun lien avec les métriques commerciales. Les conversations sur les résultats des clients ou de l'entreprise n'existent pas ou sont peu fréquentes. L'équipe n'est pas en mesure d'établir un lien entre le travail et les paramètres clés de l'entreprise et de la satisfaction des clients. Impossible de se connecter au travail avec lou une entreprise importante.
- Pas d'analyse d'impact. Les chefs de produit n'examinent pas périodiquement la qualité des décisions relatives aux produits et ne comparent donc pas les avantages attendus avec les avantages réels obtenus. Les développeurs ont des "exigences approuvées", mais les chefs de produit n'ont pas d'objectifs du travail. Seules la vitesse et la production sont prises en compte comme indicateur clé de performance
- Obsession de la priorisation. Des écarts apparaissent entre la rigueur de la priorisation (décider sur quoi travailler) et la rigueur de la validation (décider si, en fait, c'était la bonne chose sur laquelle travailler). La rigueur de la hiérarchisation est uniquement conçue pour tempérer les agendas internes afin que les gens « se sentent en sécurité ». Beaucoup de travail est consacré à la détermination des idées sur lesquelles travailler, laissant peu de place aux ajustements et aux improvisations basés sur les résultats. Les feuilles de route, les plans, affichent une liste de fonctionnalités, et non des domaines d'intervention et/ou des livrables.
- aucun ajustement. Une fois le travail "fait" (selon les principes des responsables de développement), l'équipe passe immédiatement au "projet" suivant, ne laissant pas le temps d'itérer avec des données qualitatives et quantitatives qui débouchent sur des plans d'amélioration et de qualité.
- Culture de transfert du livrable. L'équipe n'est pas directement impliquée dans la recherche, l'exploration des problèmes/défis à relever ou l'expérimentation et la validation ultérieure. Une fois le travail terminé, le développeur a peu de contact avec le support, la satisfaction client et les résultats commerciaux.
- Grands ensembles de forfaits. Sans le mandat d'expérimenter, les fonctionnalités sont fournies dans de grands packages de fonctionnalités, plutôt que dans des versions incrémentielles. Si la méthodologie est appliquée agile, il se peut que, travaillant toujours par sprints, rien de nouveau n'atteigne les clients à la fin de chaque livraison.
- Recherche de revenus à l'avance. Des fonctions sont mises en œuvre pour conclure de nouvelles transactions ponctuelles. Bien que cette approche ne soit pas intrinsèquement erronée, les justifications économiques sont souvent faibles (au mieux) et ne tiennent pas compte de l'augmentation non linéaire de la complexité du produit (avantages à court terme qui s'accumulent plus tard). ). Encore une fois, l'idée que les caractéristiques sont l'unité de mesure de la valeur est renforcée. Les décisions concernant les produits manquent d'une vision et d'une stratégie économiques solides.
- projets "stars". La livraison constante de nouvelles fonctionnalités éclipse d'autres types d'initiatives nécessaires. Les travaux de réingénierie, de réduction des coûts et de création de valeur ont une faible visibilité. Se concentrer sur ces fonctionnalités vedettes détourne les tâches concernant l'impact des nouvelles fonctionnalités sur la convivialité, la maintenabilité, l'évolutivité, etc.
