Version Communautaire 1.0.4.fr_FR
Dernière mise à jour de la version originale : 10 Apr. 2017
Traduction à partir de la version 1.0.4
Dernière mise à jour de la traduction : 29 janvier 2018
© 2014-2017 Red Hat et contributeurs | Le Cadre de Décision Ouverte ("Open Decision Framework" en anglais) a été créé par l'équipe Red Hat People et est disponible sous licence Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). Red Hat et le logo Shadowman sont des marques déposées de Red Hat, Inc. et enregistrées dans d'autres pays. La marque Red Hat doit être retirée de toute version modifiée.
- Cette version markdown des diapositives est publiée pour faciliter la collaboration et le suivi des changements.
- La numérotation des pages correspond aux fichiers LibreOffice (.odp) et PDF dans le dépôt.
page 2 sur 15
Qu'est-ce c'est ?
- Une approche flexible et ouverte pour prendre des décisions en entreprise et mener des projets.
Quand l'utiliser ?
Pour des décisions et des projets qui :
- impactent notre culture ou
- affectent des collaborateurs au-delà de votre équipe immédiate
Comment l'utiliser ?
- Intégrer par étapes le Cadre de Décision Ouverte dans votre projet ou dans votre processus de prise de décision.
page 3 sur 15
| Transparente | Inclusive | Centrée sur l'usager |
| Expliquer qui prend la décision, quels problèmes vous essayez de régler, les pré-requis et les contraintes en jeu et le processus que vous allez suivre. | Solliciter le retour d'autres personnes et collaborer tout au long du processus de décision. Rechercher des points de vue variés, notamment ceux des détracteurs potentiels. | Considérer les personnes comme des usagers ayant des besoins contradictoires et des priorités. Quand une décision aide certains usagers mais en déçoit d'autres, gérer les relations et les attentes tout en avançant sur le projet. |
page 4 sur 15
Échanges ouverts
Que vous developpiez un logiciel ou que vous essayiez de résoudre un problème dans l'entreprise, l'échange ouvert commence en partageant le "code source" avec d'autres personnes. Un échange libre des idées est essentiel pour créer un environnement où chacun a les moyens d'apprendre et d'utiliser l'information existante pour imaginer de nouvelles idées.
Participation
Quand nous sommes libres de collaborer, nous créons. Nous pouvons résoudre des problèmes qu'un individu ne pourrait pas résoudre tout seul. Et quand nous pouvons implémenter des standards ouverts, nous permettons aux autres de participer dans le futur.
Publier tôt + souvent
Le prototypage rapide peut mener à des échecs rapides, et cela conduit à de meilleures solutions. Quand on est libre d'expérimenter, on peut regarder les problèmes de manières différentes et chercher des réponses dans des endroits différents. On peut apprendre en faisant.
Méritocracie
Dans une méritocracie, les bonnes idées peuvent venir de n'importe où et la meilleure idée gagne. Tout le monde a accès à la même information. C'est la qualité du travail qui détermine quels projets prennent de l'ampleur et attire le support et les efforts de la communauté.
Communauté
Les communautés sont formées autour d'un objectif commun. Elles rassemblent des idées diverses et partagent le travail. Une fois réunie, une communauté globale peut créer au delà des capacités de n'importe quel individu. Elle multiplie les efforts et répartit le travail. Ensemble nous pouvons faire plus.
Adapté de : https://opensource.com/open-source-way
page 5 sur 15
| Principes | → | Pratique | → | Résultats |
|
• Échanges ouverts • Participation • Publier tôt + souvent • Méritocracie • Communauté |
→ → → |
• Transparence avec les usagers internes et les autres parties prenantes • Implication des usagers • Récolter du feedback et s'adapter de manière itérative • Imaginer avec les usagers • Construire de la confiance et du respect via la collaboration |
→ → → |
• Adhésion des usagers • Adoption plus rapide et plus forte • Les meilleures idées gagnent • Moins de bugs, de problèmes et d'impacts imprévus • Plus grand engagement des collaborateurs • Décisions alignées sur la stratégie et la culture |
Mais quand on prend une décision ouverte, les gens se disent...
page 6 sur 15
- Je comprend pourquoi la décision a été prise et comment elle s'aligne avec la stratégie, les buts et la mission de Red Hat.
- Les pré-requis de l'entreprise, les critères de recherche et d'évaluation étaient visibles.
- Le processus de décision était inclusif et transparent.
- Même si je n'ai pas pris la décision, je peux contribuer au processus.
- Je ne suis peut-être pas d'accord avec la décision mais il est évident que les personnes qui l'ont prise comprennent les valeurs et la culture de Red Hat.
- Je suis peut-être déçu mais je ne suis pas surpris.
- Ma voix a été entendue et valorisée.
page 7 sur 15
| Étapes pour devenir ouvert | Questions à poser | Déclencheurs de flamewar |
|
Diriger avec transparence • Publier un énoncé du problème et des approches possibles • Identifer les aspects du projet ou de la décision qui ne peuvent pas être ouvert • Publier votre processus de conception Bâtir une diversité de points de vue + un environnement inclusif |
• Quel est l'impact potentiel sur l'organisation ? Sur la culture ? • Que faut-il inclure dans le planning ? • Qui est concerné par le problème que nous essayons de régler? • À qui devons-nous ou voulons-nous demander de l'aide ? • Qui d'autres pourrait être impacté ? • Qui a résolu un problème similaire ? • Qui va probablement être en désaccord, s'opposer, rejeter ou de se désengager ? Qui d'autre devons-nous prendre en compte? |
Il y a une poignée de problèmes qui provoquent en général de la controverse ou de
l'énervement chez Red Hat, notamment : • Les décisions, les politiques ou changements qui impactent les collaborateurs , par exemple les rémunérations et le programme de bien-être. • Les changements dans l'environnement de travail des collaborateurs • L'implémentation d'une technologie propriétaire • L'utilisation de formats propriétaires • Le partage de données et la vie privée Si votre projet touche à l'un de ces thèmes, ajoutez des étapes supplémentaires pour garantir que votre processus est ouvert, inclusif et transparent. |
| Points clés | ||
|
• Confidentialité, vie privée, et contraintes légales • Controverses potentielles • Impact sur la culture Red Hat et les futures décisions • Rôles + responsabilités (modèle OPT : https://github.com/red-hat-people-team/opt-model/) • Où publier ? |
page 8 sur 15
| Étapes pour devenir ouverts | Questions à poser | |
| Solliciter usagers + collaborateurs • Rassembler des retours auprès d'usagers internes et de personnes qui vont vous aider (questionnaires, entretiens, groupes témoins, etc.) • Faciliter la participation + la gestion de projet. Demander aux usagers quels outils de collaboration ils préfèrent utiliser. Prévoir la consolidation et la publication du feedback. • Rester ouvert à de nouvelles informations et perspectives • Envisager le feedback et la communication pair-à-pair, en plus des canaux formels. Définir les attentes dès le départ |
Expliquer les évidences • Publier le périmètre du projet ou de la décision et itérer régulièrement • Publier les facteurs de décisions et leur importance relative • Publier vos recherches, notamment les compromis difficiles, les pré-requis de l'entreprise • Dans le mesure du possible, publier tous les éléments légaux, les rapports et les enjeux de confidentialité Planifier la transition |
• Comment allons-nous prendre les décisions? • Quels usagers internes, parties prenantes et collaborateurs allons-nous impliquer ? • Comment allons-nous les solliciter et communiquer avec eux ? • Quelles sont les options open source ? • Comment le choix d'une technologie ou d'un format propriétaire va limiter nos choix dans le futur ? • Comment cela s'aligne avec la stratégie et la mission de la société ? • Où est-ce que cela peut coincer avec les valeurs et la culture de Red Hat ? |
| Points Clés | ||
|
• Impact – qui, quelle fréquence et les imprévus • Où et comment collaborer • Roles + responsibilités (modèle OPT : https://github.com/red-hat-people-team/opt-model/) |
||
page 9 sur 15
| Étapes pour devenir ouvert | Questions à poser | |
| Bâtir votre communauté • Demander aux départements qui parmi leurs équipes peut fournir du feedback • Discuter de la décision avec les usagers et les parties prenantes, en particulier ceux qui parlent le plus des impacts. • Rechercher des options ou des aménagements pour les usagers qui seront impactés négativement. Promouvoir des échanges ouverts |
Rassurer les personnes qui expriment des doutes • Inviter l'équipe du projet et les collaborateurs à remonter des risques ou des doutes que vous avez sous-estimés. • Question: Qu'est-ce qui pourrait empêcher la réussite du projet ? Quels seront les doutes de l'équipe ? Que sommes-nous en train d'oublier ? • Publier au fur et à mesure les risques et les limitations découvertes Imaginer l'échec Activer vos ambassadeurs |
• Est-il possible de faire un prototype ou publier très tôt
afin de récolter des réactions ? • Comment allons-nous tester ? • Quel usagers internes peuvent nous aider à tester ? • Est-ce qu'un groupe de travail transversal a du sens ? • Peut-on batir une communauté de passionnés autour de ce projet ou cette décision ? • Avons-nous impliqué les personnes qui vont devoir faire le travail ? • Auprès de qui devons nous chercher plus d'adhésion ou de soutien. |
| Points clés | ||
|
• Représentation de différents types d'usagers • Impacts et cas d'utilisation imprévus • Risques et doutes non exprimés |
||
page 10 sur 15
| Étapes pour devenir ouvert | Questions à poser | |
| Commencer par envisager la fin • Démontrer la cohérence avec la stratégie, la mission, la culture et les valeurs de Red Hat • Souligner les étapes que vous avez suivie pour prendre votre décision de manière ouverte • Mettre en avant l'utilisation de ce cadre de décision ouverte • Dire aux collaborateurs où trouver des informations détaillées • Montrer comment le feedback a modelé la décision ou le projet • Expliquer comment fournir du feedback après le lancement • Signaler quand vous n'êtes pas complètement satisfait de la décision ou que vous savez que d'autres ne le seront pas. • Partager votre feuille de route et vos critères pour revenir sur la décision • Rester en contact avec les personnes qui rejettent la décision |
Ouvert par défaut • Réaffirmer les contraintes et les pré-requis pertinents • Partager les problèmes légaux, les rapports, et les questions de confidentialité • Communiquer les critères de succès et publier les métriques pertinentes Contribuer en amont |
• Comment allons-nous suivre les listes de discussions et les autres canaux de
feedback après le lancement ? • Si nous avons fait des version préliminaires, allons-nous continuer à faire des améliorations incrémentales basées sur le feedback ? • A quel point souhaitons nous faire des révisions sur la base du feedback ? • Quelle est la fenêtre temporelle raisonable pour l'affinage et les retours utilisateurs ? • Avons-nous sous-estimé un point important ? Comment le prendre en compte ? • Est-ce que la décision doit être réévaluée ? • Est-ce que cette décision ouverte nous a mené au résultat désiré ? • Comment pouvons-nous partager les leçons apprises et encourager la prise de décision ouverte chez Red Hat ? |
page 13 of 15
- Red Hat Multiplier – Pense-bête sur la collaboration, la transparence, la confiance, la méritocracie et la connexion
- The Open Source Way handbook – guide pour créer et entretenir une communauté de contributeurs
- The Open Organization (livre + communauté en ligne)
- Prioritizing by impact, voir le tableau de Máirín Duffy : "5 UX Tips for Developers"
- Opensource.com – Une publication soutenue par Red Hat sur la manière dont les principes open source peuvent être appliqués notamment aux entreprises, à l'éducation, aux gouvernements
- The Advice Process (Daniel Tenner)
page 14 sur 15
-
Basé sur des principes pratiqués par des communautés open source
- Recherches par la Fuqua School of Business à l'université de Duke et Diana Martin (2009 – 2010); ressources communautaires supplémentaires
-
Developpé par l'équipe Red Hat People avec des contributions de groupes témoins inter-fonctionnels
- Issu de l'effort "Project Management Office" pour créer un méthodologie de gestion de projet ouvert. (2012 – 2013)
- Une conversation via une liste mémo d'un calendrier Google utilisée comme catalysateur pour partager des brouillons avec tous les collaborateurs et inviter à la participation (2014)
- Testé par les équipes IT et Engineering, dans le groupe de travail basé sur Google Calendar (2014 – 2015)
-
Mis à jour et maintenu par Rebecca Fernandez ([email protected])
page 15 sur 15
Un ensemble de pratiques éprouvées qui :
- Produit des décisions d'entreprise cohérentes avec la stratégie, les buts, la culture, les valeurs et la mission de notre société
- Démontre “A quoi ressemble les bonnes pratiques" en terme de prise de décision et de communication
- Offre aux équipes et aux leaders un guide cohérent des attentes culturelles de Red Hat, équilibrant la transparence et la confidentialité
- Améliore l'implication des collaborateurs, le ratio signal-bruit sur les memo-listes