Recherche sur le lieu de travail ouvert

Présentation

GSD guide ma façon de travailler. Au fil des années, j'ai intégré diverses méthodologies dans mes habitudes de travail quotidiennes, notamment la boucle de rétroaction des méthodes lean et l'optimisation itérative du développement agile, comme moyen d'améliorer le GSD. Cela signifie que je dois utiliser mon temps de manière très efficace : lister des objectifs clairs et discrets ; marquer les projets terminés et continuer à faire progresser le projet de manière itérative ; Mais peut-on encore faire du GSD quand on le base sur l’ouverture ? Ou peut-être que l’approche de GSD ne fonctionne tout simplement pas ?

Travailler dans un environnement ouvert et suivre les conseils du cadre de décision ouvert ralentira le démarrage du projet. Mais sur un projet récent, nous avons pris une décision qui était la bonne dès le départ : travailler de manière ouverte et en partenariat avec notre communauté.

C'est la meilleure décision que nous aurions pu prendre.

Examinons les conséquences involontaires de cette expérience et voyons comment nous pouvons intégrer la pensée GSD dans un cadre organisationnel ouvert.

Construire une communauté

En octobre 2014, j'ai repris un nouveau projet : Jim Whitehurst, alors PDG de Red Hat, était sur le point de lancer un nouveau livre "The Open Organization". Je souhaitais construire une communauté basée sur les concepts proposés dans le document. livre. "Super, cela ressemble à un défi, j'y participe!", Pensai-je. Mais bientôt le syndrome de l’imposteur s’est installé et j’ai commencé à penser : « Qu’allons-nous faire pour réussir ?

Permettez-moi de vous donner un spoiler : à la fin du livre, Jim encourage les lecteurs à visiter Opensource.com pour poursuivre la conversation sur l'ouverture et la gestion au 21e siècle. Ainsi, en mai 2015, notre équipe a créé une nouvelle section sur le site Web pour discuter de ces idées. Nous prévoyons de raconter quelques histoires, comme nous le faisons souvent sur Opensource.com, mais cette fois autour des idées et des concepts du livre. Depuis, nous avons publié de nouveaux articles chaque semaine, organisé un club de lecture en ligne sur Twitter et transformé Open Organization en une série de livres.

Nous avons écrit les trois premiers numéros de la série de livres en interne et les avons publiés tous les six mois. Au fur et à mesure que chaque numéro est terminé, nous le publions à la communauté. Ensuite, nous passons au problème suivant et le cycle continue.

Cette façon de travailler nous a permis de connaître un grand succès. Près de 3 000 personnes se sont abonnées au nouveau livre de la série : The Leader's Handbook for Open Organizations. Nous avons travaillé sur le projet selon un cycle de six mois afin que la date de sortie du nouveau livre corresponde au deuxième anniversaire du livre précédent.

Dans ce contexte, la façon dont nous avons réalisé ce livre a été simple et directe : sur le thème du travail ouvert, nous avons rassemblé les meilleures histoires et les avons organisées en articles, en recrutant des auteurs pour combler certaines lacunes de contenu, en utilisant des outils open source pour ajuster les styles de police. , travailler avec les designers pour finaliser la couverture et enfin publier le livre. Cette manière de travailler nous permet d’avancer à toute vitesse selon notre propre timeline (GSD). Au troisième livre, notre flux de travail était presque terminé.

Mais tout a changé lorsque nous avons prévu de commencer le dernier livre de The Open Organization, qui se concentrera sur l'intersection des organisations ouvertes et de la culture informatique. J'ai proposé ce livre en utilisant un cadre de prise de décision ouvert parce que je voulais démontrer qu'une approche ouverte du travail conduit à de meilleurs résultats, même si je savais que cela pourrait complètement changer notre façon de travailler. Le délai était très serré (seulement deux mois et demi), mais nous avons décidé de tenter le coup.

Utiliser un cadre décisionnel ouvert pour terminer un livre Le cadre de prise de décision ouvert décrit les 4 étapes qui composent le processus de prise de décision ouvert. Voici comment nous travaillons à travers chaque phase (et comment l’ouverture nous aide à faire le travail).

1.Concept Nous avons commencé par rédiger une ébauche décrivant notre vision du projet. Nous devons retirer quelque chose et le partager avec des « clients » potentiels (dans ce cas, des parties prenantes et des auteurs potentiels). Nous organisons ensuite des entretiens avec des experts du domaine qui pourront nous donner des avis directs et honnêtes. L’enthousiasme manifesté par ces experts et les conseils qu’ils nous ont prodigués ont validé nos idées tout en fournissant des retours qui nous ont permis d’avancer. Si nous n'obtenons pas ces validations, nous revenons à notre idée originale et décidons par où recommencer.

2. Planification et recherche Après plusieurs entretiens, nous sommes prêts à annoncer le projet sur Opensource.com. En parallèle, nous avons également lancé le projet sur Github, en fournissant une description du projet, un calendrier estimé et en clarifiant nos contraintes. L'annonce a été bien accueillie, certains éléments manquants dans notre catalogue initialement prévu ayant été achevés dans les 72 heures suivant l'annonce du projet. De plus (et plus important encore), les lecteurs ont suggéré des idées pour certains chapitres qui ne faisaient pas partie de nos plans, mais qui, selon eux, compléteraient la version que nous avions initialement envisagée.

Avec le recul, j'estime que dans la première et la deuxième phases du projet, l'ouverture du projet n'a pas affecté notre capacité à mener à bien le projet. En fait, travailler de cette manière présente un grand avantage : découvrir et combler les lacunes du contenu. Nous n'avons pas seulement comblé les lacunes, nous les avons comblées rapidement et avec des idées auxquelles nous n'aurions jamais pensé nous-mêmes. Cela ne nous oblige pas nécessairement à faire plus de travail, cela change simplement notre façon de travailler. Nous nous appuyons sur notre réseau limité, invitons les autres à écrire, puis organisons le contenu que nous recevons, en définissant le contexte et en guidant les gens dans la bonne direction.

3. Conception, développement et tests

Cette phase du projet concerne la gestion de projet, la gestion de certains non-conformistes félins et la gestion des attentes du projet. Nous avons des délais clairs, nous communiquons à l’avance et nous communiquons fréquemment. Nous avons également utilisé une stratégie consistant à dresser une liste des contributeurs et des parties prenantes et à les tenir informés de l'avancement du projet tout au long de sa durée de vie, en particulier des étapes que nous avons tracées sur Github.

Enfin, notre livre a besoin d'un nom. Nous avons recueilli de nombreux retours sur ce que devrait être le titre et, plus important encore, sur ce que le titre ne devrait pas être. Nous recueillons les commentaires via des tickets sur Github et rendons public le fait que notre équipe prendra la décision finale. Alors que nous nous préparions à annoncer les titres finaux, mon collègue Bryan Behrenshausen a fait un excellent travail en partageant le processus qui a conduit à notre décision. Les gens semblaient satisfaits, même s'ils n'étaient pas d'accord avec notre titre final.

La phase « bêta » du livre nécessite beaucoup de relecture. Les membres de la communauté se sont vraiment impliqués en répondant à ce message « demander de l'aide ». Nous avons reçu environ 80 commentaires sur le ticket GitHub faisant état de l'avancement du travail de relecture (sans parler des nombreux commentaires supplémentaires reçus par e-mail et autres canaux de commentaires).

À propos de l'accomplissement de la tâche : à ce stade, nous avons personnellement expérimenté la loi de Linus : "Avec plus d'yeux, toutes les fautes de frappe sont superficielles." Si nous la complétons indépendamment comme les trois premiers livres, alors tout le fardeau de la relecture repose sur nos épaules ( comme c'est le cas pour ces livres) ! Au lieu de cela, les membres de la communauté ont généreusement assumé le fardeau de la relecture pour nous, et notre travail est passé de la relecture nous-mêmes (même si nous en faisions encore beaucoup) à la gestion de toutes les demandes de modification. Il s’agit d’un changement bienvenu pour notre équipe et d’une opportunité pour la communauté de s’impliquer. Nous aurions certainement pu terminer la relecture plus rapidement si nous l'avions fait nous-mêmes, mais avec l'ouverture, nous avons trouvé plus d'erreurs avant la date limite, c'est sûr.

4. Publier

Eh bien, nous avons maintenant la version finale du livre. (Ou juste la première édition ?)

Nous divisons la sortie en deux étapes. Premièrement, conformément au calendrier public de notre projet, nous avons discrètement lancé le livre quelques jours avant la date finale pour permettre aux contributeurs de notre communauté de nous aider à tester le formulaire de téléchargement. La deuxième étape est maintenant l'annonce officielle de la version générale de ce livre. Bien entendu, nous acceptons toujours les commentaires après la sortie, tout comme l'approche open source.

Contenu

Succès débloqués
Suivre un cadre décisionnel ouvert est la clé du succès du Guide pour le changement de culture informatique. En collaborant avec les clients et les parties prenantes, en partageant nos contraintes et en étant transparents sur notre travail, nous avons même dépassé nos propres attentes pour le projet de livre.

Je suis très satisfait de la collaboration, des retours et de l'activité tout au long du projet. Même s’il y a eu une période d’anxiété à l’idée de ne pas faire avancer les choses aussi rapidement que je le souhaiterais, j’ai rapidement réalisé que l’ouverture du processus nous permettait en réalité d’en faire plus. Cela est évident d'après mon aperçu ci-dessus.

Alors peut-être que je devrais repenser ma mentalité GSD et l'étendre à GMD : faites-en plus, faites-en plus et, dans ce cas, obtenez de meilleurs résultats.

(photo du titre : opensource.com)

À propos de l'auteur :

Jason Hibbets - Jason Hibbets est un évangéliste communautaire senior chez Red Hat Enterprise Marketing et un Community Manager chez Opensource.com. Il travaille chez Red Hat depuis 2003 et est le fondateur de l'Open Source Cities Foundation. Les postes précédents incluent celui de spécialiste marketing senior, de chef de projet, de responsable de la base de connaissances Red Hat et d'ingénieur de support.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!