De nombreuses organisations sont transition vers DevOps Le DevOps est une pratique logicielle où les développeurs écrivent et exploitent leur code. Cette transition est souvent motivée par la transformation numérique et la nécessité d'innover plus rapidement tout en étant disponibles 24h/24 et 7j/7. Mais quel est le lien entre le DevOps et la diversité, l'inclusion et le sentiment d'appartenance ?

Je crois que les principes et pratiques fondamentaux du DevOps transcendent les pratiques de développement logiciel et peuvent être appliqués à de nombreuses fonctions et pratiques d'une organisation, notamment la manière de créer et favoriser un environnement diversifié et inclusif Et je le constate chez PagerDuty, où non seulement notre équipe de développement pratique le DevOps, mais où les principes et les pratiques du DevOps imprègnent notre culture (par exemple, l'une de nos valeurs d'entreprise est « Reconnaître et assumer »).

Dans cet article, je parlerai de quatre principes ou pratiques DevOps importants, et de la manière dont ils peuvent être appliqués pour construire une culture de travail diversifiée et inclusive.

1. Investir dans l'automatisation, les processus et l'outillage

Le premier principe consiste à investir dans des outils et des processus qui automatisent le travail. L'automatisation désigne ici tout ce qui réduit les tâches répétitives ou fastidieuses, diminue les frictions et permet aux employés de se concentrer sur les tâches à forte valeur ajoutée qui comptent vraiment.

Dans le monde du DevOps, le pipeline CI/CD illustre parfaitement l'automatisation appliquée au développement logiciel. Ce pipeline permet aux développeurs de compiler et de déployer du code. C'est une condition essentielle au bon fonctionnement du modèle « construire, posséder » : comment responsabiliser un développeur s'il n'a pas accès aux outils nécessaires pour ajouter des fonctionnalités utiles et corriger les erreurs ?

Le même concept peut s'appliquer au recrutement d'une main-d'œuvre diversifiée et à un autre type de filière : la filière de recrutement. Les entreprises comptent de nombreux responsables du recrutement, et tous souhaitent disposer d'une équipe diversifiée. Et comment leur en vouloir ? Chaque responsable souhaite avoir la meilleure équipe possible, et des études ont démontré que… Les équipes diversifiées sont plus performantes. .

PagerDuty encourage ses responsables du recrutement à développer activement leurs réseaux afin d'y inclure des personnes issues de groupes sous-représentés. Nous sommes conscients qu'il faut parfois déployer des efforts supplémentaires pour garantir un vivier de candidats diversifié. C'est pourquoi nous avons investi dans des outils et des processus visant à automatiser la constitution d'un tel vivier.

• Nous soumettons toutes nos descriptions de poste à Textio afin de nous assurer qu'elles ne comportent pas de biais inhérents.
• Nous exigeons de nos recruteurs internes et externes qu'ils nous fournissent un vivier de candidats diversifié. Nous ne collaborerons pas avec les recruteurs externes qui ne s'engagent pas à respecter cette exigence.
• Nous collaborons avec un certain nombre d'organisations comme Code2040 , Académie Hackbright , HITEC, Voie à suivre , et Bridgeschool pour trouver des candidats dans des domaines comme l'ingénierie et le développement de produits, où il est traditionnellement plus difficile de trouver des candidats issus de la diversité sur de nombreux marchés.

L'un des principaux résultats de ces pratiques est que plus de 50 % des participants à notre Programme de stage en ingénierie et développement de produits 2018 s'identifiant comme femmes et/ou personnes de couleur. Ces stagiaires constituent la majorité de nos recrues débutantes.

2. Objectifs et mesures

Le deuxième principe consiste à se fixer des objectifs et à mesurer ses progrès pour les atteindre. Dans le monde du DevOps, les entreprises demandent aux ingénieurs de développer et d'exploiter des logiciels. Cela implique qu'ils soient d'astreinte (généralement une semaine sur six ou sept) et prêts à être débordés à tout moment. De ce fait, il est essentiel de mesurer le temps que l'équipe consacre au développement et à l'exploitation des logiciels. « interrompre » le travail est important. S'il y en a trop, ce genre de travail Les ingénieurs subiront une perte de temps personnel ou de sommeil, une baisse du moral, un taux d'attrition élevé et une capacité d'innovation réduite.

Pour gérer efficacement les interruptions de travail, il est essentiel de définir des objectifs de charge opérationnelle et d'en assurer un suivi rigoureux. Chez PagerDuty, nous partageons la charge d'astreinte de l'équipe à chaque revue de sprint et analysons son évolution. Nous organisons des réunions de passation d'astreinte pour permettre aux équipes d'examiner ces problématiques en détail et d'identifier les investissements nécessaires pour réduire la charge. Enfin, nous développons des produits qui aident nos clients à gérer les interruptions et à avoir une visibilité sur la santé de leurs équipes.

Le même principe s'applique à vos objectifs d'inclusion, de diversité et d'appartenance : ils doivent être facilement mesurables et visibles. Chez PagerDuty, nous fixons des objectifs de diversité et les mesurons dans le cadre de notre processus d'évaluation trimestrielle, au même titre que nous mesurons les ventes ou la livraison des produits.

Par exemple, avant mon arrivée chez PagerDuty, tous les responsables de l'équipe produit étaient des hommes et les femmes étaient peu nombreuses. Nous avons déployé des efforts concertés pour améliorer la diversité de l'équipe, notamment en renforçant la présence des femmes. Chaque année, nous fixions un objectif précis de pourcentage de femmes, nous le mesurions, nous évaluions les progrès chaque trimestre et nous l'atteignions. Ce type de changement prend du temps et nos chiffres ne sont pas encore tout à fait optimaux. Cependant, en tirant parti des programmes mis en place pour alimenter un vivier de candidats diversifiés, nous recrutons selon des ratios qui reflètent mieux la population et nous améliorons constamment notre diversité globale.

3. Apprentissage et amélioration continus

Cela m'amène au troisième principe du DevOps : l'apprentissage et l'amélioration continus. Dans la vie comme en DevOps, vous ferez des erreurs. L'important est votre réaction face à ces erreurs et votre capacité à promouvoir une culture d'apprentissage continu. Mon exemple préféré d'application de ce principe dans le monde du développement logiciel est : autopsies sans reproche , ce qui devrait être fait pour chaque incident majeur.

Quelques éléments clés d'une analyse post-mortem sans recherche de coupable sont essentiels pour garantir que l'organisation tire des leçons de ses expériences et s'améliore :

• Ils devraient être, eh bien, irréprochables. Cela signifie que la cause d'un incident ne devrait jamais être imputée à une personne. Si une action a conduit à un incident, quels contrôles ou garde-fous manquaient pour permettre cette action ? Éviter de blâmer autrui garantit une analyse ouverte et honnête de la situation.
• L'équipe doit considérer les incidents comme des occasions d'apprendre. Les analyses post-mortem permettent 1) d'évaluer votre processus de réponse pour voir si l'équipe aurait pu faire mieux pendant la réponse et 2) d'empêcher qu'un incident similaire ne se reproduise à l'avenir.
• Les enseignements tirés doivent être partagés non seulement au sein de l'équipe, mais aussi à l'échelle de toute l'organisation et, idéalement, avec vos clients. Tout le monde ne le fait pas, mais cela permet à vos clients de constater que vous prenez chaque incident au sérieux et que vous avez mis en place des mesures pour éviter qu'il ne se reproduise. L'erreur est humaine, mais rien ne justifie la répétition des incidents.

L'analyse post-mortem sans recherche de coupable permet de tirer des enseignements en dehors des incidents majeurs. Comme vous le savez, la diversité et l'inclusion sont des sujets complexes. À l'instar du DevOps, il est important d'accepter d'emblée que des erreurs seront commises.

Un exemple d'erreur s'est produit lors d'une réunion générale de PagerDuty . Nous présentions les détails de notre conférence annuelle, le PagerDuty Summit. Cinq conférenciers principaux étaient prévus, dont deux femmes. L'une d'elles était notre PDG, Jennifer Tejada, et la seconde n'avait pas encore confirmé sa présence. Quelqu'un a créé une diapositive en omettant notre PDG (puisque tout le monde dans l'entreprise la connaissait) et la seconde intervenante. Résultat : trois conférenciers principaux, des hommes blancs, sont apparus. Comme vous pouvez l'imaginer, cela a suscité une vive polémique.

Des questions pertinentes ont été posées, telles que : « Comment une entreprise qui accorde autant d’importance à la diversité de ses employés peut-elle ne pas avoir de conférenciers principaux issus de la diversité ? » Parallèlement, l’équipe qui avait travaillé sans relâche pour constituer un panel de conférenciers diversifié (non seulement pour les conférences principales, mais aussi pour garantir la diversité dans tous les ateliers) était contrariée par l’accusation selon laquelle elle ne se concentrait pas suffisamment sur la diversité.

Qu'avons-nous appris ?

Nous avons constaté qu'en mettant l'accent sur la diversité et l'inclusion et en développant un programme dédié, les employés sensibles à ces valeurs ont choisi de rejoindre PagerDuty. Lorsqu'ils ont relevé un problème, ils ont légitimement exigé des améliorations. Nous avons compris que l'image perçue est importante et qu'il faut y prêter attention à tous les niveaux. Nous avons également appris qu'il est erroné de présumer des intentions (par exemple, que les organisateurs ne se soucient pas de la diversité lors de notre conférence ou que tout le monde sait qu'ils s'efforcent de constituer un panel d'intervenants diversifié) et qu'il est essentiel de rester ouvert aux motivations tout en questionnant ce qui semble problématique. Bien entendu, tous ces points ont été abordés et consignés dans le cadre de l'analyse post-mortem.

4. Autonomisation individuelle

Ceci m'amène au dernier principe fondamental du DevOps, et sans doute mon préféré : l'autonomisation individuelle. Les organisations traditionnelles fonctionnent selon un modèle hiérarchique rigide, où les décisions sont prises au sommet et appliquées en cascade. Dans le domaine du développement, par exemple, cela signifierait que les mises en production de code nécessiteraient l'approbation d'un vice-président, rendant le déploiement continu difficile, voire impossible.

Les principes DevOps partent du principe, à juste titre, que les personnes les plus proches du code en sont les mieux informées. En les aidant à travailler efficacement plutôt qu'en les freinant, vous leur permettez d'innover et de résoudre les problèmes plus rapidement. En effet, face à un problème, les personnes qui manipulent le code sont plus à même de prendre des décisions que n'importe quel dirigeant, aussi compétent soit-il. Ce principe se reflète dans les bonnes pratiques de gestion des incidents : les parties prenantes sont tenues informées en temps réel pendant un incident, mais sont dissuadées d'interrompre la résolution de l'incident en cours.

Quel est donc le lien entre l'autonomisation individuelle et la diversité, l'inclusion et le sentiment d'appartenance ? L'entreprise peut mettre en place des programmes, mais une impulsion donnée uniquement par la direction ne suffit pas à impulser le changement. J'ai surtout abordé la question de la diversité jusqu'ici, mais en matière d'inclusion et de sentiment d'appartenance, ce sont les employés qui sont essentiels : seuls eux peuvent dire s'ils se sentent réellement inclus.

Pour favoriser l'inclusion chez PagerDuty, nous avons mis en place plusieurs programmes gérés par les employés, notamment : Groupes de ressources pour les employés (GRE) Les groupes de ressources pour les employés (GRE) organisent des réunions et des événements afin de soutenir les populations sous-représentées au sein de l'entreprise et de la société. PagerDuty parraine ces GRE, mais ils sont gérés par les employés pour les employés.

Nous avons également un groupe « Femmes dans la vente », une autre fonction traditionnellement dominée par les hommes. Ce groupe d'employées a a animé plusieurs panels avec des femmes occupant des postes à tous les niveaux de la vente pour parler de leurs expériences et partager leurs conseils, servant ainsi de formidables modèles pour les femmes en début de carrière dans la vente.

Il y a environ un an et demi, nous avons également mis en place de nouvelles valeurs d'entreprise. Ces initiatives, imposées par la direction, n'ont pas trouvé d'écho auprès des employés. Nous avons donc revu notre copie et organisé plusieurs groupes de discussion avec les employés afin de recueillir leurs avis sur ce qui comptait le plus pour eux. Suite à ces échanges, nous avons instauré de nouvelles valeurs d'entreprise qui correspondent parfaitement à l'esprit de PagerDuty (et qui, je pense, sont très « PagerDuty»). Alex Solomon, notre cofondateur et directeur technique, en parle plus en détail. ici .

Intégrer le DevOps chez ID&B

Il est bien connu dans le secteur que la transition vers le DevOps est un parcours complexe. Elle nécessite d'aligner les processus, les outils, la culture et l'organisation pour une parfaite synergie. L'important est de se rappeler que l'objectif n'est pas d'atteindre son but. Des erreurs seront toujours commises. Nous aurons toujours de nouvelles technologies à développer et de meilleurs processus à mettre en place. La clé du succès réside dans la progression à chaque itération et à chaque tentative, et, en cas d'échec, dans l'apprentissage tiré de ses erreurs.

Promouvoir une culture de diversité, d'inclusion et d'appartenance ne fait pas exception, et s'appuyer sur les principes fondamentaux DevOps ci-dessous sera utile.

• Le changement doit venir à la fois d'en haut et d'en bas.
• Investissez dans l'automatisation et les outils pour simplifier les choses : la plupart des gens souhaitent être inclusifs et construiront une organisation diversifiée si vous leur en donnez les moyens.
• Évaluez en permanence votre performance, sans vous blâmer.
• Enfin, évaluez vos succès et vos échecs en cours de route en gardant à l'esprit que le seul véritable échec est celui dont on ne tire pas de leçons et dont on ne prend pas de mesures pour s'améliorer – il s'agit d'un voyage.