5 erreurs courantes

L'objectif de l'Inception lors d'une migration dans le cloud est de définir le contenu du travail nécessaire ainsi que de planifier les étapes pour y arriver. Les situations où l'Inception a été réalisée en mode « économique » par manque de temps ou d'alignement sur les priorités ont toujours compliqué la suite du projet. Il est essentiel de prendre le temps de libérer les personnes ayant les connaissances au sein de l'organisation. Le niveau de précision et d'estimation du travail est directement proportionnel à l'effort investi dans l'Inception. Lorsque nous réalisons ces activités sans faire intervenir les bons acteurs avec le bon niveau de préparation, nous ajoutons de l'inconnu et donc, un plus grand risque pour la réussite du projet. Le lancement doit être planifié en étroite collaboration avec Guidewire afin de définir les objectifs et les attentes, de sorte que les ateliers soient planifiés de manière à rencontrer ces conditions. 

La migration vers le cloud est un changement technologique structurant qui implique des défis majeurs. Un projet de migration vers le cloud est loin d'être facile, il y aura des surprises et c'est dans ces moments critiques que les acteurs ayant la connaissance et l'expérience des systèmes Guidewire feront la différence. Les exigences relatives aux niveaux de formation dans les équipes de projet sont loin d'être excentriques. Les acteurs certifiés pourront partager leurs connaissances avec leurs collègues et en faire profiter les autres équipes. Ils seront également en mesure d'effectuer des tâches clés dans le projet. Leur répartition au sein des équipes est évidemment un facteur clé à considérer. S'ils sont inclus dans le périmètre du projet, les sujets tels que le numérique et l'analytique ont souvent des particularités qui nécessitent une expertise plus pointue. Avec un cycle de livraison de 3 versions par année, les choses évoluent vite et l'investissement initial peut sembler important financièrement et difficile en termes de temps. Il est donc possible de se faire accompagner par un partenaire stratégique tel que GFT. 

Pour l'équipe DevOps, le passage au cloud représente un changement majeur dans leur quotidien car, en plus de nouveaux outils, les processus sont amenés à changer drastiquement. Le premier changement s'observe principalement dans le partage des responsabilités avec les équipes de Guidewire, notamment au niveau du support de production. La plateforme cloud Guidewire propose plusieurs outils DevOps et elle évolue tous les mois. Les problèmes et les perturbations dans les opérations quotidiennes de CI/CD ralentissent fortement les équipes de développement et affectent leur moral. Ne pas inclure au moins quelques profils DevOps dès la première phase du projet de transition vers le cloud afin de participer à la mise en œuvre du nouveau CI/CD et de tester les outils serait une erreur importante. Le déploiement en production représente une grande victoire, mais si le support en production qui suit n'est pas à la hauteur, le projet peut être perçu comme un échec. L'implication en amont des acteurs qui assureront le support de production sera un « game changer » afin qu'ils se familiarisent avec les procédures pour réduire la charge de la résolution des incidents, notamment en termes de temps de résolution.

Nous appelons "Dry-runs" les pratiques d'exécution des opérations de mise en production. Ils représentent une activité importante dans la phase de stabilisation et de préparation au déploiement. Il y en a généralement 2 à 4 en fonction de la taille du projet et de sa portée. C'est pourquoi il est essentiel d'arriver avec un plan de match déjà bien réfléchi dès la première fois. Il est alors facile d'apporter des ajustements et des améliorations. L'établissement d'un plan complet et précis prend du temps et nécessite souvent de rassembler des informations provenant de sources et d’endroits multiples. Le succès des ‘’Dry-runs’’ influence toujours le niveau de confiance de l'équipe de gestion, qui peut provoquer un inconfort lorsque les résultats sont négatifs. Ce malaise peut entraîner des reports, des retards supplémentaires et des coûts additionnels.

L'une des erreurs les plus fréquentes et les plus coûteuses est de sous-estimer la portée des tests qui seront effectués pendant la stabilisation. Cela va au-delà des applications Guidewire qui seront migrées vers la plateforme en cloud. Il est particulièrement important de prendre en compte tous les points d'intégration avec les systèmes qui communiquent avec Guidewire afin d'éviter les effets collatéraux après la mise en production. La réflexion et la définition de la stratégie de tests doivent débuter lors de la phase de stabilisation et se cristalliser lors de la phase de développement. Il faut prévoir suffisamment de temps pour l'exécution de ces tests intégrés, mais surtout pour examiner et corriger les anomalies potentielles qui pourraient être découvertes. La mise en place d'un processus clair et efficace de priorisation, de résolution et de redéploiement des correctifs doit être partagée et connue de tous. Lorsque la phase de tests commence, il n'y a pas de temps pour la découverte, il faut être efficace dès le début et comme cela se passe à la toute fin du projet, il y a rarement de marge de manœuvre pour les dérapages.