Planifier et établir des priorités
Découvrez comment identifier les objectifs de vos efforts 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
Au lieu d’examiner une liste de contrôle des fonctionnalités ou des fonctionnalités, commencez par identifier les objectifs de vos efforts d’ingénierie de plateforme. Vous pouvez planifier et mettre à jour continuellement les objectifs au fil du temps. Toutefois, être clair sur ce que vous souhaitez gagner de l’investissement dans votre parcours d’ingénierie de plateforme peut aller beaucoup dans l’aide à la création d’un support organisationnel.
En tant que responsable de l’ingénierie de plateforme une fois mis en place, « Je ne fais pas quelque chose pour l’ingénierie de plateforme tant que je n’ai pas quelque chose que je peux gagner de lui. » – Peter, responsable de l’ingénierie de plateforme, Multinationale Tech Company
Au fur et à 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, réduisez les bogues et les problèmes pendant la mise en production.
- Améliorez la sécurité, réduisez le nombre d’incidents de sécurité ou les vulnérabilités courantes détectées (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 valeur de l’entreprise en réduisant la complexité, la surcharge et la promotion du partage de code par le biais de pratiques internes de 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 dirigeants et partenaires internes conduit à é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 ces scénarios 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 référentiel
- Outils d'approvisionnement
- Provisionner une infrastructure commune
- Accorder aux membres de l’équipe l’accès
- Établir des pipelines CI/CD
- Provisionner l’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, services
- Configurer l’ordinateur développeur
- Augmenter le membre de l’équipe sur les applications
- Créer un environnement de bac à sable d’application
- Créer et passer en revue la première demande de tirage
Scénario : Ajouter ou mettre à jour l’infrastructure pour l’application existante
- Comprendre les meilleures pratiques organisationnelles, les options disponibles
- Mettre à jour / ajouter une infrastructure en tant qu’artefacts de code
- Créer un environnement de bac à sable d’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 disponibles, le SDK, les services
- Évaluer s’il répond aux besoins
- Se connecter à l’équipe propriétaire pour toute question
- Adopter pour l’application
Scénario : Répondre à un incident d’opération
- Notification d’un problème
- Évaluer si le code de l’application ou l’infrastructure (ou les deux)
- 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
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) Migration de coordination 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
- Documentation sur les bonnes pratiques de mise à jour
- Créer des modèles, mettre à jour l’automatisation, les stratégies, 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, libérer
De nombreux scénarios s’appliquent à plusieurs rôles. Vous devez donc réfléchir aux métriques pour comprendre la quantité de vos scénarios à améliorer.
Des problèmes aux concepts
Ensuite, cherchez à comprendre 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’enquête. Il s’agit du framework de progression d’hypothèse. 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 les 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.
Faites le cas 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.
Mettez une autre façon, ne créez pas de solutions qui ciblent les étapes ultérieures de votre parcours, sauf si vous avez vraiment besoin de.
Une fois que vous avez identifié votre plateforme viable la plus mince (TVP) (un MVP pour votre plateforme), pilotez-la avec un ensemble d’équipes de développement qui sont prêtes à fournir des commentaires. 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 le succès que vous êtes est une partie importante d’un état d’esprit de produit. Même les petits succès avec des investissements modestes peuvent poser le terrain pour des investissements plus importants pour s’appuyer.
Par exemple, il peut être difficile d’obtenir du financement ou d’acheter pour les efforts de conformité, car ils peuvent être perçus comme une taxe opérationnelle pour les équipes de développement qui fournissent de la valeur commerciale. Un état d’esprit 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 de tirer parti de ce que vous créez. Zéro sur ceux qui vous aident à mesurer si vous, et vos clients d’équipe de développement, atteignent 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 d’activité : jours médians pour terminer la première demande de tirage (intégration), minutes médianes pour les processus de génération et de test (exemple : CI), temps médian de fusion de la demande de tirage.
- Qualité du logiciel : incidents (problèmes) créés par mois par dev(nombre normalisé en nombre de développeurs), temps moyen de correction (MTTR) et temps moyen d’examen et de correction du problème de sécurité.
- Facilité d’utilisation de la plateforme : satisfaction des utilisateurs net (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. Pour commencer, vous devez mesurer certaines lignes de base, 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 :
| Zone | Exemples de métriques |
|---|---|
| Performances de remise de logiciels | DevOps Research and Assessment (DORA) : délai de modification, fréquence de déploiement, taux d’échec des modifications, temps de restauration du service (MTTR) |
| Opérations | DORA (MTTR), temps moyen entre l’échec (MTBF), temps moyen de réception, disponibilité du client final, latence, métriques de débit, coût par équipe, coût par déploiement |
| Métriques d’adoption des fonctionnalités de plateforme | Nombre d’équipes ou de développeurs utilisant un outil ou une fonctionnalité au fil du temps, pourcentage de référentiels à l’aide de la plateforme, modèles les plus populaires, pipelines, etc. |
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. Peu importe, veillez à mesurer la facilité d’utilisation et d’enquête de plateforme que vous avez régulièrement 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 pilotez vos nouvelles fonctionnalités de plateforme ou de plateforme. Cela vous donnera également l’expérience de gestion de votre plateforme en tant que produit. Shy away from replatforming projects to begin since you learn as you go, and large existing applications ont souvent des besoins uniques qui ne sont découverts que pendant l’effort de replateformage lui-même. En raison de cela, le couplage de votre réussite à ces types d’efforts peut entraîner des incompatibilités attendues ou des problèmes de rupture tardive. À partir de quelque chose de plus récent peut vous donner confiance dans votre direction la valeur qu’il fournit. Cela réduit le risque de s’attaquer à ces efforts plus importants. Mettez une autre façon, si vous êtes confiant que les gens peuvent commencer droit et rester droit, alors il devient plus facile de conduire une campagne appropriée avec ce que vous apprenez de l’expérience. Si cette approche n’est pas possible, vous souhaiterez 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 rester avec de nouvelles fonctionnalités lorsqu’ils sont exposés dans quelque chose qu’ils aiment déjà et utilisent. À 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 les 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 éditeurs de logiciels de fonctionnalités 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 en fonction de la maintenance à long terme vous amènera probablement à basculer au fil du temps.