Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
528 lines (427 sloc) 21.1 KB

Cadre de Décicion Ouverte

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 : 10 Apr 2017

© 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.

Notes

  • 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.

Contenu

Vue d'ensemble

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.

Qu'est-ce qu'une décision ouverte ?

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.

Les décisions ouvertes sont issues des principes open source

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

Comment les principes open source conduisent à de meilleures décisions

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

On ne peut pas plaire à tout le monde.

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.

Cadre de Décision Ouverte

Phase ou activité: Conceptualiser, Définir, Imaginer

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
• Solliciter les usagers internes et les parties prenantes très tôt, en particulier ceux qui pourraient ne pas être d'accord.

• Chercher des perspectives variées et sous-représentées (emplacement géographique, ethnie, département, niveau hiérarchique, genre, âge, etc. )

• Promouvoir la collaboration et fournir des canaux de réponse

• Prendre en compte les risques, les limites et les impacts culturels potentiels, en particulier pour les problèmes qui sont des controverses historiques

• 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 ?

Phase ou activité: Planifier, Rechercher

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
• Être spécifique à propos des types de feedback que vous recherchez et à propos de qui prend les décisions.

• Publier le processus de décision et la planification du projet plan avec des rôles, des dates et des contraintes

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

• Developper et rassembler le feedback sur la communication, la gestion du changement et les plans d'adoption

• Imaginez comment des personnes énervées pourraient répondre ( via une memo-liste ou un autre canal)

• 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/)

Phase ou activité: Concevoir, Developper, Tester

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
• Évaluer, valider et incorporer le feedback

• Mettre en valeur les changements effectués suite au feedback

• Si une suggestion n'est pas possible, expliquer pourquoi

• Publier la progression du projet dans un endroit public

• Fournir des infos régulières aux sponsors, aux usagers et aux parties prenantes

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
• Imaginez que c'est le jour de l'annonce et que des personnes sont surprises ou énervées. Qu'est-ce qui a déclenché cela ?

• Identifier les changements que vous feriez ou les points que vous pourriez clarifier et faites-les de manière pro-active.

Activer vos ambassadeurs
• Équiper la communauté pour qu'elle vous aide à clarifier les désinformations et les incompréhensions.

• 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

Phase ou activité: Launcer, Deployer, Clôturer

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
• Archiver et Publier les méthodes, les leçons apprises, les communiqués et les critères de décision, pour que d'autres puissent étudier les anciennes décisions, comprendre pourquoi une décision a été prise et voir comment les leaders ont répondu à des problèmes similaires par le passé.

• Proposer votre aide à d'autres personnes pour prendre des décisions ou choisir un outil de collaboration

• 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 ?

Ressources

page 13 of 15

Annexes

Histoire: D'où vient le Cadre de Décision Ouverte

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 (rfernand@redhat.com)

Pourquoi ce cadre existe

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