Community Version 1.0.0d
Aktualisiert im Februar, 2020
© Red Hat und Mitwirkende | Das Open Decision Framework wurde vom Red Hat People-Team erstellt und ist unter der Creative Commons "Namensnennung-Weitergabe unter gleichen Bedingungen" 4.0 International License (CC BY-SA 4.0) verfügbar. Red Hat und das Red Hat-Logo sind Marken von Red Hat, Inc., die in anderen Ländern eingetragen sind. Geänderte Versionen müssen das gesamte Red Hat-Branding entfernen.
- Diese Fassung des Dokumentes dient der vereinfachten Zusammenarbeit und der Nachvollziehbarkeit von Änderungen.
- Die Seitenzahlen korrespondieren mit den LibreOffice (.odp) und PDF Files in diesem Repository.
- Deutsche Übersetzung von Joachim Schroeder ([email protected]) und Guenter Herold ([email protected])
Seite 2 von 15
Was es ist
- Ein flexibler, offener Ansatz, um Projekte durchzuführen und Business-Entscheidungen zu treffen.
Wann man es einsetzt
In Entscheidungsprozessen und Projekten, die beispielsweise
- die Unternehmenskultur und Zusammenarbeit beeinflussen
- Mitarbeiter ausserhalb des unmittelbaren Projektes oder der jeweiligen Abteilung betreffen
Wie man es anwendet
- Integrieren Sie Schritte aus dem Open Decision Framework in Ihren Projektplan oder Entscheidungsprozess
Seite 3 von 15
| Transparent | Einbeziehend | Kundenzentriert |
| Erklären Sie zu Beginn, wer die Entscheidung trifft, welche Probleme Sie lösen möchten, welche Anforderungen und Einschränkungen bestehen und welchem Prozess Sie folgen werden. | Bitten Sie andere um Feedback und arbeiten Sie während des gesamten Entscheidungsprozesses zusammen. Suchen Sie nach unterschiedlichen Perspektiven, einschließlich potenzieller Kritiker. | Stellen Sie sich Menschen als Kunden mit konkurrierenden Bedürfnissen und Prioritäten vor. Wenn eine Entscheidung einigen Kunden hilft, andere jedoch enttäuscht, gehen Sie während der Umsetzung des Entscheidungsprozesses aktiv mit diesen Erwartungen und Beziehungen um. |
Seite 4 von 15
Offener Austausch
Unabhängig davon, ob Sie Software entwickeln oder versuchen ein Geschäftsproblem zu lösen, beginnt der offene Austausch, wenn Sie Ihren "Quellcode" mit anderen teilen. Ein freier Ideenaustausch ist entscheidend für die Schaffung eines Umfelds, in dem die Menschen lernen und auf Basis vorhandener Informationen neue Ideen umsetzen können.
Beteiligung
Wenn wir für Zusammenarbeit offen sind, werden wir kreativer und produktiver. Wir können Probleme lösen, die niemand alleine lösen kann. Und wenn wir offene Standards implementieren können, ermöglichen wir anderen, an unserer Vision teilzuhaben und mitzugestalten.
Veröffentlichen Sie rasch und oft
Schnelle Prototypen können zu schnellem Scheitern führen, und dies führt schneller zu besseren Lösungen. Wenn Sie experimentieren können, können Sie Probleme aus neuen Perspektiven betrachten und Antworten an neuen Orten suchen. Sie können lernen, indem Sie viele Möglichkeiten ausprobieren.
Meritokratie
In einer Meritokratie können gute Ideen von überall herkommen und die besten Ideen gewinnen. Jeder hat Zugriff auf die gleichen Informationen. Erfolgreiches Arbeiten bestimmt, welche Projekte entstehen und Unterstützung und Einsatz von der Community erhalten.
Community
Gemeinschaften bilden sich um einen gemeinsamen Zweck herum. Die Individuen einer Gemeinschaft bringen unterschiedliche Ideen und Sichtweisen ein und teilen ihre Arbeit. Zusammen kann eine Gemeinschaft weit über die Fähigkeiten jedes einzelnen Mitglieds hinauswachsen. Die Gemeinschaft vervielfacht somit den Einsatz und verteilt gleichzeitig die Arbeit effektiv auf alle Mitglieder. Gemeinsam können wir mehr erreichen.
Adaptiert von: https://opensource.com/open-source-way
Seite 5 von 15
| Prinzipien | → | Methoden | → | Resultate |
|
• Offener Austausch • Beteiligung • Rasche und häufige Veröffentlichung • Meritokratie • Community |
→ |
• Transparenz gegenüber internen und externen Interessensgruppen • Einbeziehung der Kunden • Feedback einholen und schrittweise Änderungen umsetzen • Ideenfindung mit Kunden • Vertrauen und Respekt durch Zusammenarbeit aufbauen |
→ |
• Kunden buy-in • Stärkere und schnellere Akzeptanz • Die besten Ideen gewinnen • Weniger Fehler, Probleme und unvorhergesehene Rückschläge • Höheres Engagement der Mitarbeiter • Entscheidungen, die an Strategie und Kultur ausgerichtet sind |
Seite 6 von 15
Aber wenn Sie offene Entscheidungen treffen, dann...
- verstehen Mitarbeiter, warum die Entscheidung getroffen wurde und wie sie zur Strategie, Zielen und Mission der Firma passt
- werden geschäftliche Anforderungen, Recherche- und Bewertungskriterien sichtbar
- war der Entscheidungsprozess inklusiv und transparent
- erkennen auch jene, die nicht Entscheidungsträger waren, wie sie in diesem Prozess beitragen konnten
- ist es offensichtlich, dass die Entscheidungsträger die Werte und die Kultur meiner Firma verstehen auch wenn ich selbst der Entscheidung nicht zustimmen kann
- wurde ich nicht überrascht, selbst wenn ich möglicherweise enttäuscht bin
- wurde meine Stimme gehört und geschätzt
page 7 of 15
| Schritte zu mehr Offenheit | Zu stellende Fragen | Typische Flame-War Trigger |
|
Gehe transparent vor • Veröffentliche die Problembeschreibung und mögliche Lösungsansätze • Benenne alle Aspekte des Projektes und Entscheidungen, die nicht offengelegt werden können • Veröffentliche deinen Ideenfindungsprozess Baue auf Meinungsvielfalt und eine inklusive Umgebung |
• Was sind potenzielle Auswirkungen auf die Organisation? Auf die Kultur? • Wen müssen wir in die Planung einbinden? • Wessen Problem versuchen wir zu lösen? • Wen oder wessen Unterstützung brauchen wir? • Wer könnte sonst noch betroffen sein? • Wer hat schonmal ein ähnliches Problem gelöst? • Wer wird wahrscheinlich nicht einverstanden sein, widersprechen, ablehnen oder aussteigen? Wer könnte noch interessiert sein? |
Es gibt eine Reihe von Problemen, die häufig Gegensätze generieren und für Aufregung innerhalb Red Hats sorgen, wie: • Entscheidungen, Richtlinien oder Änderungen, die Mitarbeiter betreffen, wie z.B. Auszeichnungen oder Wohlfühlprogramme • Änderungen am Arbeitsplatz von Mitarbeitern • Einführung von proprietären Technologien • Nutzung von proprietären Formaten • Datenschutz und -Verbreitung Falls einer dieser Punkte auf Ihr Projekt oder Entscheidung zutrifft, sollten Sie zusätzliche Schritte unternehmen, um Ihren Prozess offen, inklusiv und transparent zu machen. |
| Grundsätzliche Überlegungen | ||
|
• Vertraulichkeit, Schutz der Privatsphäre und regulatorische Anforderungen • Potenzial für Kontroversen • Einfluss auf Red Hats Kultur und zukünftige Entscheidungen • Rollen + Verantwortlichkeiten (OPT Modell: https://github.com/red-hat-people-team/opt-model/) • Ort zur Veröffentlichung |
page 8 of 15
| Schritte zu mehr Offenheit | Zu stellende Fragen | |
| Binde Kunden und Mitwirkende ein • Sammle Input von internen Kunden und solchen, deren Hilfe Du benötigst (Umfragen, Interviews, Fokusgruppen etc.) • Mache es leicht, teilzunehmen und zu steuern. Frage, welche Tools zur Zusammenarbeit die Kunden bevorzugen. Erstelle einen Plan zur Konsolidierung und Veröffentlichung von Feedback • Bleibe offen für neue Informationen und Perspektiven • Berücksichtige persönliche Feedback- und Kommunikations-Optionen zusätzlich zu den formalen Kanälen Setze von vornherein die Erwartungshaltung |
Erkläre das Offensichtliche • Veröffentliche den Geltungsbereich des Projektes oder der Entscheidung und erwähne dies regelmäßig • Veröffentliche Entscheidungskriterien und ihre relative Wichtigkeit • Veröffentliche deine Recherche inklusive schwieriger Abwägungen und Geschäftsanforderungen • So weit möglich, veröffentliche alle relevanten rechtlichen Bedenken, sowie Bedenken zur Meldepflicht und Vertraulichkeit Plane die Veränderung |
• Wie werden wir die Entscheidung treffen? • Welche internen Kunden, Interessensgruppen und Mitwirkende wollen wir involvieren? • Wie wollen wir diese einbinden und wie mit ihnen kommunizieren? • Was sind die Optionen aus dem Open Source Umfeld? • Wie könnte sich die Wahl einer pröprietären Technologie oder Formates auf die Wahlfreiheit in der Zukunft auswirken? • Wie passt dies zur Firmenstrategie und Mission? • Wo könnte dies mit Red Hats Werten und Kultur in Konflikt stehen? |
| Grundlegende Überlegungen | ||
|
• Auswirkung – wer, wie oft, und unerwartet • Wo und wie wird zusammengearbeitet • Rollen + Verantwortlichkeiten (OPT Modell: https://github.com/red-hat-people-team/opt-model/) |
||
Seite 9 von 15
| Schritte zu mehr Offenheit | Zu stellende Fragen | |
| Baue deine Community • Frage die Abteilungen, wer aus ihrem Team Feedback geben kann • Mache Kunden und Interessensgruppen mit der Entscheidung vertraut, speziell mit denen, die sich am heftigsten über die Auswirkungen beschweren könnten • Untersuche Optionen und Anpassungen für Kunden mit negativen Auswirkungen Unterstütze offenen Austausch |
Sorge dafür, dass Bedenken ohne Gefahr geäussert werden können • Lade das Projektteam und Mitwirkende ein, Risiken und Bedenken, die du übersehen hast, zu äussern. • Frage: Was könnte den Erfolg des Projektes verhindern? Welche Bedenken wird das Team haben? Was fehlt noch? • Veröffentliche Risiken und Hürden, die im Prozessverlauf auftauchen Führe eine Scheiter-Analyse durch Aktiviere deine Botschafter |
• Können wir einen Piloten einrichten oder frühzeitig starten, um Input zu sammeln? • Wie werden wir testen? • Welche internen Kunden können beim Testen helfen? • Macht eine cross-funktionale Gruppe Sinn? • Können wir eine Community mit Leidenschaft um das Projekt oder die Entscheidung bilden? • Haben wir die Leute, welche die Arbeiten durchführen werden auch eingebunden? • Von wem brauchen wir grundsätzlich oder gar mehr Buy-In oder Unterstützung? |
| Grundlegende Überlegungen | ||
|
• Repräsentation verschiedener Kundentypen • Unerwartete Einflüsse und Anwendungsfälle • Unausgesprochene Risiken und Bedenken |
||
Seite 10 von 15
| Schritte zu mehr Offenheit | Zu stellende Fragen | |
| Behalte das Ende im Auge • Zeige Abgestimmtheit mit Red Hats Strategie, Mission, Kultur und Werten • Hebe hervor, welche Schritte du unternommen hast, um die Entscheidung offen zu treffen • Unterstreiche die Anwendung des Open Decision Frameworks • Sprich mit den Kollegen darüber, wo man detaillierte Informationen hierzu finden kann • Zeige auf, wie das eingebrachte Feedback die Entscheidung oder das Projekt verändert bzw. umgestaltet hat • Erkläre, wie man auch nach begonnener Umsetzung weiterhin Feedback und Verbesserungsvorschläge einbringen kann • Akzeptiere, wenn du mit dem Ergebnis nicht vollständig übereinstimmst, oder dir bewusst ist, dass andere nicht restlos überzeugt sein werden • Kommuniziere offen den Zeitplan oder die Kriterien, die erfüllt sein müssen, um die Entscheidung zu überdenken • Bleibe mit denen in Kontakt, die der Entscheidung ablehnend gegenüberstehen |
Setze standardmäßig auf Offenheit • Verdeutliche unablässig die relevanten Geschäftsanforderungen und -beschränkungen • Sprich über relevante Rechts-, Berichterstattungs- und Vertraulichkeitsprobleme • Kommuniziere Erfolgskriterien und veröffentliche relevante Metriken Leiste einen "upstream" Beitrag |
• Wie monitoren wir Mailing-Listen und andere Feedbackkanäle nach Inkrafttreten der Entscheidung? • Wenn wir in einer frühen Projektphase begonnen haben, oder auch unsere Entscheidung von vielen zukünftigen Parametern beeinflusst wird, werden wir weiterhin schrittweise Verbesserungen basierend auf Feedback vornehmen? • Wie groß ist unsere Bereitschaft, aufgrund von Feedback unsere Entscheidung zu überarbeiten?? • Was ist ein angemessenes Zeitfenster für zusätzliche Eingaben und Verfeinerungen?? • Haben wir etwas Wichtiges übersehen? Wie gehen wir damit um? • Muss die Entscheidung überprüft werden? • Hat die offene Entscheidungsfindung (open decision) zu den gewünschten Ergebnissen geführt? • Wie können wir unsere gewonnenen Erkenntnisse teilen und offene Entscheidungen bei Red Hat fördern? |
Seite 12 von 15
- Red Hat Multiplier – quick reference sheets on collaboration, transparency, trust, meritocracy, connection
- The Open Source Way handbook – guide to creating and nurturing communities of contributors
- The Open Organization (book + online community)
- Prioritizing by impact, see grid in Máirín Duffy's "5 UX Tips for Developers"
- Opensource.com – A Red Hat supported publication focused on how open source principles can be applied to business, education, government, and more
- The Advice Process (Daniel Tenner)
Seite 14 von 15
-
Basierend auf Prinzipien, die von Open Source Communities praktiziert werden
- Forschung der Fuqua School of Business der Duke University und Diana Martin (2009 – 2010); zusätzliche Community-Ressourcen
-
Entwickelt von der Personalabteilung mit Beiträgen der funktionsübergreifenden Fokusgruppe
- Ergebnisse aus den Bemühungen des Project Management Office der Personalabteilung zur Schaffung einer "open project management methodology" (2012 – 2013)
- Google Calendar-Memolistenkonversationen dienten als Katalysator, um Entwürfe mit allen Mitarbeitern zu teilen und zur Teilnahme einzuladen (2014)
- Getestet von IT und Engineering in der Google Calendar Bridge-Arbeitsgruppe (2014 – 2015)
-
Aktualisiert und gepflegt von Rebecca Fernandez ([email protected])
Seite 15 von 15
Eine Sammlung bewährter Praktiken, zur:
- besseren Abstimmung zwischen Geschäftsentscheidungen und unserer Unternehmensstrategie, Zielen, Kultur, Werten und unserer Mission
- Verdeutlichung, wie "gut" in der Entscheidungsfindung und Kommunikation aussieht
- konsistenten Anleitung von Teams und Führungskräften zu den kulturellen Erwartungen von Red Hat im Einklang von Transparenz und Vertraulichkeit
- Verbesserung des Engagements der Mitarbeiter und des Signal-Rausch-Verhältnisses auf memo-list bzw. der Kommunikation insgesamt