Planifier et hiérarchiser

Découvrez comment identifier les objectifs de vos efforts d’ingénierie de plateforme basés sur le modèle de capacité d’ingénierie de plateforme, parcourir les scénarios courants et rechercher des moyens de mesurer la réussite. Mesurez le succès en définissant vos objectifs en fonction des objectifs métier.

Identifier les objectifs et les scénarios clés

Pour commencer, commencez par évaluer où votre organisation est aujourd’hui en utilisant le modèle de capacité d’ingénierie de plateforme. Utilisez le modèle pour tracer l’emplacement où votre organisation dispose de six fonctionnalités d’ingénierie de plateforme principales : investissement, adoption, gouvernance, approvisionnement et gestion, interfaces et mesures et commentaires. Toutes les organisations sont plus avancées dans certaines fonctionnalités que dans d’autres. Une fois que vous savez où se trouve votre organisation aujourd’hui, vous pouvez choisir les fonctionnalités que vous souhaitez développer. Pour en savoir plus, consultez Évaluer vos pratiques actuelles et définir des objectifs futurs.

Vous pouvez planifier et mettre à jour continuellement vos objectifs d’ingénierie de plateforme au fil du temps. Être clair sur ce que vous souhaitez tirer parti de l’investissement dans votre parcours d’ingénierie de plateforme peut contribuer grandement à la création d'un support organisationnel.

En tant que responsable de l'ingénierie de plateforme l'a dit un jour, « Je ne fais rien pour l'ingénierie de plateforme tant que je n'ai pas quelque chose à en tirer. » – Peter, responsable de l'ingénierie de plateforme, société technologique multinationale

À mesure que vous réfléchissez à vos objectifs, étendez-les aux objectifs métier liés à votre effort d’ingénierie de plateforme, plutôt qu’aux spécificités d’une équipe de développement particulière. Les objectifs d’ingénierie de plateforme de haut niveau courants sont les suivants :

• Augmentez la qualité de l’application et réduisez les bogues et les problèmes pendant la mise en production.
• Améliorez la sécurité et réduisez le nombre d’incidents de sécurité ou détectez des vulnérabilités et des expositions courantes (CVE), une fois en production.
• Réduisez les risques grâce à une meilleure conformité dans des domaines tels que les licences, l’accessibilité, la confidentialité ou la réglementation gouvernementale.
• Accélérez la réalisation de la valeur métier en réduisant la complexité, la surcharge, et en promouvant le partage de code par le biais de pratiques d'inner source.
• Réduisez les coûts de développement ou d’exploitation, réduisez la duplication et améliorez l’automatisation.

La sélection de votre objectif principal est essentielle, car votre objectif détermine la façon dont vous pensez à votre hiérarchisation.

Mieux encore, l’accord sur les objectifs et les résultats clés (OKR) avec vos partenaires dirigeants et internes permet d’établir des objectifs mesurables pour la phase actuelle de vos investissements. (D’autres approches de planification ont des concepts similaires si votre organisation utilise autre chose.) Les meilleurs OKR sont ceux que vous pouvez définir en fonction d’une mesure concrète, car il supprime la subjectivité.

Scénarios et travaux à effectuer

Après avoir identifié vos objectifs, choisissez les scénarios clés pour générer votre backlog et votre feuille de route. Par exemple, consultez les scénarios suivants et les travaux associés à effectuer.

Scénario : Commencer à créer une nouvelle application

• Comprendre et appliquer les meilleures pratiques et stratégies organisationnelles
• Créer un nouveau dépôt
• Outils d’approvisionnement
• Provisionner une infrastructure commune
• Accorder aux membres de l’équipe l’accès
• Établir des pipelines CI/CD
• Provisionner une infrastructure de développement
• Déploiement initial pour tester les « canaux »

Scénario : Ajouter ou supprimer un nouveau membre à une équipe existante

• Mettre à jour l’accès aux outils et services
• Configurer une machine de développement
• Monter en puissance le membre de l’équipe sur les applications
• Créer un environnement sandbox pour application
• Créer d'abord et passer en revue la pull request

Scénario : Ajouter ou mettre à jour l’infrastructure pour l’application existante

• Comprendre les meilleures pratiques organisationnelles, les options disponibles
• Mettre à jour ou ajouter une infrastructure en tant qu’artefacts de code
• Créer un environnement de bac à sable pour application
• Vérifier les mises à jour
• Déployer des modifications dans d’autres environnements

Scénario : Ajouter ou mettre à jour un outil pour l’équipe existante

• Comprendre les meilleures pratiques organisationnelles, les options disponibles
• Demander l’utilisation d’un nouvel outil
• Mettre à jour l’accès des membres de l’équipe aux outils
• (Le cas échéant) Intégrer un outil dans des clients ou des pipelines CI/CD

Scénario : Rechercher ou réutiliser l’API, le Kit de développement logiciel (SDK) ou le service existant

• Découvrir les API, sdk ou services disponibles
• Évaluer s’il répond aux besoins
• Contacter l'équipe responsable pour toute question
• Adopter la technologie pour l'application

Scénario : Répondre à un incident d’opération

• Notification d’un problème
• Évaluer si le code de l'application est en cause ou l'infrastructure (ou les deux)
• Créer un environnement de bac à sable qui met en miroir l'environnement de production (si différent)
• Apporter des modifications, tester, libérer hors bande

Scénario : Corriger rapidement l’incident de sécurité

• Notification d’un problème
• Évaluer l’ampleur des problèmes (quels systèmes)
• Comprendre si les clients sont directement affectés
• Créer un environnement de bac à sable qui met en miroir la production (le cas échéant)
• Apporter des modifications, tester, libérer hors bande
• Communiquer avec toute personne concernée

Scénario : Déprécier l’outil

• Comprendre l’utilisation des outils
• Informer les utilisateurs de la dépréciation
• (Facultatif) Coordonner la migration des utilisateurs vers un nouvel outil

Scénario : Déploiement du nouveau modèle d’application d’architecture

• Architecture proposée par le pilote
• Ajuster en fonction des résultats pilotes
• Mise à jour de la documentation sur les bonnes pratiques
• Créer des modèles, mettre à jour l’automatisation, les stratégies et la gouvernance

Auditer la conformité des applications (RGPD, accessibilité, normes d’infrastructure)

• Comprendre les règles de conformité actuelles
• Vérifier que l’application répond aux règles
• Établir l’échéance des correctifs pour les écarts
• Apporter des modifications, tester, déployer

De nombreux scénarios s’appliquent à plusieurs rôles. Réfléchissez aux métriques pour mesurer l’amélioration.

Des problèmes aux concepts

Ensuite, comprenez les problèmes les plus importants auxquels vos développeurs et d’autres rôles sont confrontés aux scénarios et aux travaux que vous avez identifiés. Il peut être tentant de commencer à examiner de nouveaux produits pour combler les lacunes perçues, mais si ces produits ne résolvent pas un point de douleur majeur, ils sont peu susceptibles d’être adoptés ou appréciés.

Il existe plusieurs approches qui peuvent vous aider à effectuer ce type d’investigation, comme l’infrastructure de progression d’hypothèses. Même si vous n’utilisez pas de processus formalisé comme le Framework de progression d’hypothèses, vous devez interviewer les développeurs sur un travail à effectuer pour étendre la discussion, puis identifier leurs plus gros problèmes dans l’accomplissement de leur travail. Une fois que vous avez un bon sens de ce que sont ces problèmes, passez à la recherche de plans pour les résoudre. Cela permet de vous assurer que vous créez des fonctionnalités que les développeurs souhaitent utiliser.

Pour pouvoir répéter rapidement ce processus, identifiez quelqu’un qui peut représenter la voix du client directement sur votre équipe de plateforme de développement interne. Ce rôle est généralement appelé gestionnaire de produits (même s’il a un titre de travail différent) et à mesure que ses connaissances augmentent, ils sont en mesure de prédire avec précision les résultats pour des décisions plus petites et de déterminer quand vous avez besoin d’effectuer plus d’entrevues. Cela permet de maintenir votre agilité tout en vous assurant que vous vous concentrez sur la fourniture de valeur à vos clients internes.

Présentez un argument pour vos investissements initiaux

Une fois que vous avez un ensemble de problèmes et de concepts validés, vous êtes en bonne position pour décider où investir. Toutefois, envisagez l’investissement initial et la maintenance à long terme requises lors de l’évaluation des solutions. La solution d’effort la plus basse qui peut résoudre le problème a tendance à être la bonne pour commencer, mais souvent, c’est le travail de maintenance qui décide finalement si votre investissement est réussi.

Autrement dit, ne créez pas de solutions qui ciblent les étapes ultérieures de votre parcours, sauf si vous en avez vraiment besoin.

Après avoir identifié votre plateforme minimisée et viable (PMV) ( similaire à un produit minimum viable adapté pour votre plateforme), pilotez-la avec un ensemble d’équipes de développement disposées à donner des retours. Si votre solution pilote résout les problèmes auxquels ces équipes sont confrontées, vous ne devriez pas avoir de difficultés à trouver quelqu’un intéressé à s’engager.

Vous devez capturer certaines métriques clés lorsque vous pilotez une nouvelle fonctionnalité ou des modifications afin de déterminer si le concept a réussi avant de le déployer.

Mesurer la réussite et prouver la valeur

Mesurer votre succès est une partie importante d’un état d’esprit produit. Même les petits succès avec des investissements modestes peuvent jeter les bases pour que des investissements plus importants puissent construire dessus.

Par exemple, il peut être difficile d'obtenir des fonds ou l’adhésion pour les initiatives de conformité, car elles peuvent être perçues comme une taxe opérationnelle par les équipes de développement qui fournissent de la valeur commerciale. Une mentalité de produit peut changer cette perception. Avec une mentalité de produit, vous essayez de vous assurer que les clients de votre plateforme de développement interne sont heureux et que les objectifs métier des parties prenantes sont atteints. Les métriques vous permettent d’utiliser des faits pour prouver que vous fournissez de la valeur métier. La définition des OKR peut vous aider, en particulier si vous avez des métriques que vous pouvez utiliser pour aider à supprimer le biais subjectif. Même si vous ne mesurez rien d’applicable aujourd’hui, vous pouvez définir un OKR d’apprentissage pour définir une ligne de base que vous affinerez ensuite une fois cette ligne de base connue.

Voici des exemples de métriques connues que vous pouvez mesurer pour déterminer si les équipes avec lesquelles vous travaillez sont en train d’obtenir de la valeur sur ce que vous créez. Concentrez-vous sur ceux qui vous aident à mesurer si vous, et les clients de votre équipe de développement, atteignez vos objectifs. Par exemple, voici un ensemble de métriques qui vous aident à évaluer si votre plateforme contribue à une organisation d’ingénierie efficace :

• Vitesse / temps jusqu'à la valeur commerciale : jours médians pour terminer la première requête de tirage (intégration initiale), minutes médianes pour les processus de construction et de test (exemple : CI), temps médian de fusion de la requête de tirage.
• Qualité du logiciel : incidents (problèmes) créés par mois par développement (comptez normalisés au nombre de développeurs), temps moyen de récupération (MTTR) et temps moyen pour examiner et corriger le problème de sécurité.
• Facilité d’utilisation de la plateforme : satisfaction nette des utilisateurs (NSAT)
• Écosystème prospère : Score moyen pour chacune des questions interrogées suivantes : « Je suis autorisé à faire mon meilleur travail », « la plupart des jours que je suis stimulé par le travail que je fais », « le travail que je fais est significatif pour moi ».

Vous pouvez ensuite décomposer ces métriques par organisation, équipe ou projet. Vous devez mesurer certaines lignes de base pour commencer, mais vous pouvez ensuite observer ces métriques changer lorsque vous améliorez votre plateforme.

D’autres métriques que vous ou vos sponsors souhaiterez peut-être mesurer sont les suivantes :

La collecte des métriques nécessite du temps et des efforts afin qu’il soit important de se concentrer sur les métriques critiques pour les objectifs principaux que vous avez identifiés, en particulier ceux qui alimentent vos OKR. Les produits basés sur OpenTelemetry comme Application Insights peuvent vous aider.

Veillez à mesurer la facilité d’utilisation de la plateforme et à vous assurer régulièrement que vous disposez d'un écosystème prospère. Ces métriques sont souvent manquées pour les systèmes internes et constituent un indicateur de premier plan pour déterminer si vous atteignez vos objectifs métier plus larges, car la participation engagée est essentielle au succès. Il vous aide également à savoir s’il est temps d’effectuer d’autres développements clients pour comprendre où aller ensuite.

Autres conseils

Quelle que soit la façon dont vous commencez, gardez à l’esprit que vous devez planifier le changement, commencer par de nouvelles applications pour les pilotes, vous concentrer sur l’amélioration des expériences utilisateur existantes, adopter le principe du privilège minimum, planifier l’expérimentation contrôlée et réduire la personnalisation.

Modification planifiée

Votre plateforme d’application cible évoluera au fil du temps et vous ne pourrez peut-être pas migrer tous vos investissements existants en même temps. Réfléchissez à la façon dont vous pouvez prendre en charge plusieurs variantes au fil du temps et planifier le changement.

Valider des idées avec des applications plus récentes

Commencez par les nouvelles applications d’une taille raisonnable lorsque vous testez vos nouvelles capacités de plateforme. Cela vous offre également une expérience de gestion de votre plateforme en tant que produit. Évitez de vous lancer dans des projets de migration de plateforme dès le début, car vous apprenez en cours de route et les grandes applications existantes ont souvent des besoins uniques qui ne sont découverts que pendant le processus de migration de plateforme lui-même. En raison de cela, le couplage de votre succès à ces types d’efforts peut entraîner des décalages d'attentes ou des problèmes survenant tardivement. Commencer avec quelque chose de plus récent peut vous donner confiance dans votre orientation et la valeur qu'il offre. Cela réduit le risque de s’attaquer à ces efforts plus importants. Autrement dit, si vous êtes confiant que les gens peuvent bien commencer et rester sur la bonne voie, alors il devient plus facile de mener une campagne de mise sur la bonne voie avec ce que vous avez appris de l'expérience. Si cette approche n’est pas possible, vous souhaitez effectuer une analyse minutieuse, définir des attentes et effectuer des étapes incrémentielles au lieu d’essayer de modifier tout en même temps.

Concentrez-vous sur les centres de gravité existants pour les expériences utilisateur avant de les créer

Les développeurs sont plus susceptibles d'adopter et de s'en tenir à de nouvelles fonctionnalités lorsqu'elles sont intégrées à ce qu'ils apprécient et utilisent déjà. À mesure que vous évaluez les concepts permettant de fournir de nouvelles fonctionnalités, veillez à examiner les options qui étendent les centres de gravité existants. Par exemple, les éditeurs/IDEs (Visual Studio, VS Code), les suites DevOps (GitHub, Azure DevOps), les CLIs existants ou un portail interne existant peuvent être plus efficaces qu’un tout nouveau portail ou d’autres expériences utilisateur. Pour en savoir plus, consultez Expériences utilisateur.

Supposons le principe du privilège minimum

Supposons que les développeurs disposent d’un accès limité aux systèmes en aval pour des éléments tels que l’infrastructure d’approvisionnement. Vous aurez besoin d’un moyen contrôlé d’activer cet accès pour les expériences en libre-service.

Planifier l’expérimentation contrôlée

Expérimentez avant de déployer des changements majeurs ou risqués. Tout ne doit pas être entièrement automatisé pour démarrer. Un workflow manuel déclenché automatiquement peut être un excellent moyen de piloter des idées.

Réduire la personnalisation de la plateforme d’application

Évitez de créer des fonctionnalités personnalisées de plateforme d’applications qui pourraient être éclipsées par les fonctionnalités que les fournisseurs de logiciels publient au fil du temps. Par exemple, l’hébergement d’exécution, les maillages de service, les systèmes d’identité, et ainsi de suite. Si vous trouvez un besoin urgent dans une zone que vous pensez être semblable à ceci, planifier plusieurs options d’implémentation car la maintenance à long terme vous amènera probablement à changer au fil du temps.

Contenu connexe

• Appliquer des systèmes d’ingénierie logicielle