Entreprises non natives du cloud : comment l’expérience des développeurs peut faciliter la transformation numérique

Il existe un nombre important et croissant de développeurs de logiciels dans le monde. Malgré ce que nous entendons dans les médias, tous ne sont pas dans la Silicon Valley, ou ne travaillent pas dans des startups, ou même dans de grandes entreprises technologiques. En fait, beaucoup – peut-être la plupart – travaillent dans des entreprises des secteurs « traditionnels » – banques régionales, chaînes de distribution, compagnies d’assurance maladie, etc. Stimulées par la nécessité d’interagir avec les clients finaux grâce à une excellente expérience logicielle, ces entreprises changent pensez aux logiciels. Ils veulent le placer au cœur de leur entreprise, rivaliser pour attirer les clients en fonction de son efficacité et ne pas se laisser distancer par leurs pairs.
Le centre de la conversation est souvent le cloud, déterminer comment «y arriver», quel cloud choisir et comment gérer la sécurité. Les entreprises non natives du cloud signalent des difficultés à extraire de la valeur de leurs investissements dans le cloud. Ils citent le manque généralisé de compétences comme un obstacle au succès : selon une étude récente Enquête McKinsey95 % des personnes interrogées déclarent que le manque de talents et de capacités cloud les freine dans leurs transformations.
Pour réussir la transformation numérique, les organisations doivent aller au-delà de la mentalité « passer au cloud », car le simple fait de déplacer des applications vers le cloud ne fait que confondre les problèmes qu’elles ont déjà. Au lieu de cela, il doit y avoir une stratégie plus intentionnelle. Adopter le « all-in » sur le cloud signifie également que vous devrez adopter de nouvelles façons de travailler en équipe et briser les silos du passé. Résoudre l’expérience des développeurs est un moyen puissant et pratique de briser l’ancienne façon de penser qui sépare les équipes d’infrastructure et DevOps des secteurs d’activité.
Minimiser le travail des développeurs
Une sondage ont constaté que les développeurs ne consacrent que 32 % de leur temps de travail au codage. Lorsque les développeurs ne peuvent pas travailler sur le développement de logiciels, cela coûte de l’argent à l’entreprise. Le « labeur », le terme couramment utilisé pour décrire le travail pénible auquel les développeurs doivent faire face, diminue la productivité. Éliminez le labeur et vous augmentez la productivité.
Cela demande aux équipes qui construisent la plate-forme et les pipelines de voir le développeur comme leur client d’une manière qui va au-delà du discours d’entreprise du passé. Ils doivent être motivés pour remettre en question les hypothèses sur ce qui peut et ne peut pas être automatisé, et être jugés sur la base de mesures telles que le temps nécessaire pour qu’un développeur soit « prêt » jusqu’au moment où la modification est en production, ou le temps qu’il faut à un développeur pour être embarqué sur la plateforme. La culture doit constamment se demander « pourquoi cette chose est-elle difficile pour le développeur ».
Investissez dans l’automatisation
Lorsque votre équipe automatise ses processus, votre chaîne d’approvisionnement logicielle devient rationalisée. Vos développeurs peuvent ensuite placer le logiciel dans une boucle de production de livraison continue – un tapis roulant virtuel qui régit le processus. En effet, votre code entre dans un environnement de type production sans que les développeurs aient à effectuer les tâches de configuration de l’inventaire qui nuisent à la productivité. Cela va au-delà des seules améliorations technologiques : elles doivent inclure les parties prenantes des équipes juridiques, par exemple, qui pourraient par défaut rester fermes sur l’exigence que certains contrôles soient manuels. Bien qu’il puisse y avoir des lois qui imposent une approbation manuelle, d’après mon expérience, si une équipe réfléchit vraiment, non seulement beaucoup plus d’automatisation est possible, mais en fait c’est une meilleure solution pour l’acteur commercial que le processus manuel précédent.
N’inventez que ce qui vous différencie
Les développeurs de plates-formes d’entreprises non natives du cloud ont pris l’habitude de tout faire par eux-mêmes. Leur mentalité d’amorçage est admirable, mais construire un outil qui est déjà disponible ailleurs est une idée terrible. Ne construisez pas une plate-forme pour Kubernetes, par exemple. Ils existent déjà. Construisez uniquement les éléments qui différencient votre entreprise. Pour le reste, économisez du temps et des ressources et examinez les solutions existantes. Les géants de la Silicon Valley doivent construire de nouvelles infrastructures car ils ont une échelle sans précédent ; si vous ne le faites pas – et vous ne le faites probablement pas – alors utilisez leurs inventions plutôt que de créer les vôtres.
Croisez vos équipes
Pour forcer le changement culturel, les équipes Infrastructure et DevOps font peut-être de leur mieux pour servir le développeur, mais marcher un kilomètre à la place de quelqu’un d’autre n’est pas facile, même avec la meilleure des intentions. Envisagez une pollinisation croisée des équipes, en faisant tourner quelques individus de temps en temps, comme état permanent. De cette façon, ceux qui créent l’expérience de développement devront en faire l’expérience eux-mêmes, ce qui tend à faire exploser tout sentiment de fierté dans sa création. Dans le sens inverse, le développeur d’applications peut expliquer les problèmes au sein de l’équipe DevOps de manière beaucoup plus efficace que lors d’une série de réunions. Par-dessus tout, la tactique contribue à la culture globale de collaboration d’une manière plus efficace que ce que j’ai vu résulter de toute insistance de la direction sur le fait que « nous sommes une seule équipe ».
Les développeurs adorent
De plus, les développeurs d’applications ont soif de comprendre ce qu’ils essaient d’accomplir et de résoudre les problèmes à la lumière de cela. Un développeur heureux est celui qui travaille directement avec des gens d’affaires qui définissent les objectifs, utilisent la créativité pour les résoudre et expérimentent les résultats. Un développeur mécontent est celui qui construit quelque chose de dicté sans comprendre pourquoi, et ne sait jamais si cela a fonctionné. C’est l’un des secrets de la rétention, et même de l’attraction des développeurs, qui est généralement négligé.
Oubliez le perfectionnisme et connectez-vous avec l’utilisateur final
Les entreprises non natives du cloud essaient de se connecter à l’utilisateur final. Notre mentalité passée était de ne pas publier une application tant qu’elle n’était pas parfaite. Cependant, le développement est continu dans les entreprises natives du cloud : elles commencent avec un produit minimal viable et le perfectionnent au fur et à mesure. Bien que ce processus semble imprudent, il permet à l’équipe de développement de voir quelles fonctionnalités les utilisateurs aiment et n’aiment pas. Ensuite, ils peuvent aller encore plus loin et entrer en contact avec l’utilisateur final par le biais d’enquêtes et de recherches. Fini les hésitations et le perfectionnisme. Je n’ai jamais travaillé avec une équipe qui, rétrospectivement, aurait souhaité qu’elle sorte plus tard, quand les choses seraient plus prêtes.
Obtenir le bénéfice pour l’entreprise
En supposant que cela soit en marche, il y a encore plus de changement culturel à conduire. L’intérêt d’une expérience de développeur excellente et en constante amélioration est que les développeurs – en fait les équipes de produits – soient en mesure de produire et de modifier en permanence des logiciels pour soutenir l’entreprise. Nous devons impliquer les parties prenantes de l’entreprise dans le processus continu de développement de logiciels, ce qui signifie définir des critères de réussite client pour chaque étape majeure du logiciel, créer des hypothèses sur la manière d’y parvenir, travailler en permanence avec les développeurs sur des définitions d’exigences qui correspondent à ces critères, les mesurer par rapport aux retours clients, et boucler la boucle avec des hypothèses affinées et nouvelles.
Ce sont quelques-uns des ingrédients qui, selon moi, sont les plus importants pour aider les organisations à progresser dans leurs transformations numériques, mais souvent négligés car ils appellent un changement de comportement et une réflexion audacieuse. L’expérience développeur doit être une priorité, ce qui nécessite de nouvelles façons de penser et d’interagir entre les développeurs et les équipes d’infrastructure. Une fois qu’il s’améliore, le développeur doit être connecté aux équipes commerciales pour en récolter les bénéfices. Ajoutez-les aux améliorations technologiques de l’ère du cloud et les entreprises non natives du cloud peuvent vraiment faire le saut.
Pour en savoir plus, rendez-nous visite ici.
Source link