Open-Workplace-Forschung

Einführung

GSD leitet meine Arbeitsweise. Im Laufe der Jahre habe ich verschiedene Methoden in meine täglichen Arbeitsgewohnheiten integriert, darunter die Feedbackschleife von Lean-Methoden und die iterative Optimierung der agilen Entwicklung, um die GSD zu verbessern. Das bedeutet, dass ich meine Zeit sehr effizient nutzen muss: klare, diskrete Ziele auflisten; abgeschlossene Projekte markieren und den Projektfortschritt iterativ weiter vorantreiben; Aber können wir GSD trotzdem erreichen, wenn wir es auf Offenheit gründen? Oder funktioniert der Ansatz von GSD einfach nicht?

Wenn Sie in einer offenen Umgebung arbeiten und die Anleitungen im Open Decision Framework befolgen, wird der Projektstart langsamer. Aber bei einem aktuellen Projekt haben wir von Anfang an die richtige Entscheidung getroffen: offen und partnerschaftlich mit unserer Community zusammenzuarbeiten.

Das ist die beste Entscheidung, die wir treffen konnten.

Schauen wir uns die unbeabsichtigten Konsequenzen dieser Erfahrung an und sehen wir, wie wir das GSD-Denken in einen offenen Organisationsrahmen integrieren können.

Bauen Sie eine Community auf

Im Oktober 2014 übernahm ich ein neues Projekt: Jim Whitehurst, der damalige CEO von Red Hat, war dabei, ein neues Buch „The Open Organization“ herauszubringen. Ich wollte eine Community aufbauen, die auf den darin vorgeschlagenen Konzepten basiert Buch. „Toll, das klingt nach einer Herausforderung, ich bin dabei!“ dachte ich. Aber bald setzte das Hochstapler-Syndrom ein und ich begann zu denken: „Was zum Teufel sollen wir tun, um erfolgreich zu sein?“

Lassen Sie mich Ihnen einen Spoiler geben: Am Ende des Buches ermutigt Jim die Leser, Opensource.com zu besuchen, um das Gespräch über Offenheit und Management im 21. Jahrhundert fortzusetzen. Deshalb hat unser Team im Mai 2015 einen neuen Bereich auf der Website erstellt, um diese Ideen zu diskutieren. Wir planen, einige Geschichten zu erzählen, wie wir es oft auf Opensource.com tun, aber dieses Mal geht es um Ideen und Konzepte aus dem Buch. Seitdem haben wir jede Woche neue Artikel veröffentlicht, einen Online-Buchclub auf Twitter veranstaltet und Open Organization in eine Buchreihe verwandelt.

Wir haben die ersten drei Ausgaben der Buchreihe selbst geschrieben und alle sechs Monate veröffentlicht. Sobald jede Ausgabe abgeschlossen ist, veröffentlichen wir sie für die Community. Dann gehen wir zur nächsten Ausgabe über und der Zyklus geht weiter.

Diese Arbeitsweise hat uns große Erfolge beschert. Fast 3.000 Menschen haben das neue Buch der Reihe abonniert: The Leader's Handbook for Open Organizations. Wir haben in einem sechsmonatigen Zyklus an dem Projekt gearbeitet, sodass das Erscheinungsdatum des neuen Buches am zweiten Jahrestag des vorherigen Buches liegen würde.

In diesem Zusammenhang war die Art und Weise, wie wir dieses Buch fertiggestellt haben, einfach und unkompliziert: Zum Thema Open Work haben wir die besten Geschichten gesammelt und sie in Artikeln organisiert, Autoren rekrutiert, um einige Inhaltslücken zu schließen, und Open-Source-Tools verwendet, um Schriftstile anzupassen , arbeiten Sie mit Designern zusammen, um das Cover fertigzustellen und schließlich das Buch zu veröffentlichen. Diese Arbeitsweise ermöglicht es uns, gemäß unserer eigenen Zeitleiste (GSD) mit voller Geschwindigkeit voranzukommen. Mit dem dritten Buch war unser Arbeitsablauf größtenteils abgeschlossen.

Aber das änderte sich alles, als wir planten, mit dem letzten Buch von „The Open Organization“ zu beginnen, das sich auf die Schnittstelle zwischen offenen Organisationen und IT-Kultur konzentrieren wird. Ich habe dieses Buch unter Verwendung eines offenen Entscheidungsrahmens vorgeschlagen, weil ich zeigen wollte, dass ein offener Arbeitsansatz zu besseren Ergebnissen führt, auch wenn ich wusste, dass er unsere Arbeitsweise völlig verändern könnte. Der Zeitrahmen war sehr eng (nur zweieinhalb Monate), aber wir beschlossen, es zu versuchen.

Verwenden Sie einen offenen Entscheidungsrahmen, um ein Buch fertigzustellen Das Open Decision Making Framework beschreibt die vier Phasen, aus denen sich der offene Entscheidungsprozess zusammensetzt. Hier erfahren Sie, wie wir jede Phase durchlaufen (und wie Offenheit dabei hilft, die Arbeit zu erledigen).

1. Konzept Wir begannen damit, einen Entwurf zu schreiben, in dem wir unsere Vision für das Projekt darlegten. Wir müssen etwas herausnehmen und es mit potenziellen „Kunden“ (in diesem Fall potenziellen Stakeholdern und Autoren) teilen. Anschließend führten wir Gespräche mit Experten auf diesem Gebiet, die uns direkte und ehrliche Meinungen mitteilen konnten. Der Enthusiasmus dieser Experten und die Beratung, die sie uns gaben, bestätigten unsere Ideen und lieferten gleichzeitig Feedback, das uns voranbrachte. Wenn wir diese Bestätigungen nicht erhalten, greifen wir auf unsere ursprüngliche Idee zurück und entscheiden, wo wir noch einmal anfangen sollen.

2. Planung und Recherche Nach mehreren Interviews sind wir bereit, das Projekt auf Opensource.com anzukündigen. Gleichzeitig haben wir das Projekt auch auf Github gestartet, eine Projektbeschreibung, einen geschätzten Zeitplan und eine Klärung unserer Einschränkungen bereitgestellt. Die Ankündigung wurde gut angenommen und einige Artikel, die in unserem ursprünglich geplanten Katalog fehlten, wurden innerhalb von 72 Stunden nach Bekanntgabe des Projekts fertiggestellt. Darüber hinaus (und was noch wichtiger ist) haben die Leser Ideen für einige Kapitel vorgeschlagen, die nicht Teil unserer Pläne waren, von denen sie jedoch glaubten, dass sie die Version, die wir uns ursprünglich vorgestellt hatten, ergänzen würden.

Rückblickend habe ich das Gefühl, dass die Öffnung des Projekts in der ersten und zweiten Phase des Projekts keinen Einfluss auf unsere Fähigkeit hatte, das Projekt abzuschließen. Tatsächlich hat diese Arbeitsweise einen großen Vorteil: das Entdecken und Schließen von Inhaltslücken. Wir haben die Lücken nicht nur geschlossen, sondern schnell und mit Ideen, an die wir selbst nie gedacht hätten. Dies erfordert nicht zwangsläufig mehr Arbeit, sondern verändert nur die Art und Weise, wie wir arbeiten. Wir greifen auf unser begrenztes Netzwerk zurück, laden andere zum Schreiben ein und organisieren dann die Inhalte, die wir erhalten, indem wir den Kontext festlegen und die Menschen in die richtige Richtung leiten.

3. Design, Entwicklung und Tests

In dieser Phase des Projekts dreht sich alles um Projektmanagement, den Umgang mit einigen katzenartigen Außenseitern und den Umgang mit den Erwartungen des Projekts. Wir haben klare Fristen, wir kommunizieren im Voraus und wir kommunizieren häufig. Wir verfolgten auch die Strategie, eine Liste der Mitwirkenden und Stakeholder zu erstellen und sie über den Fortschritt des Projekts während seiner gesamten Laufzeit auf dem Laufenden zu halten, insbesondere über die Meilensteine, die wir auf Github festgelegt haben.

Endlich braucht unser Buch einen Namen. Wir haben viel Feedback darüber gesammelt, wie der Titel lauten sollte und, was noch wichtiger ist, wie der Titel nicht lauten sollte. Wir sammeln Feedback über Tickets auf Github und machen öffentlich, dass unser Team die endgültige Entscheidung treffen wird. Während wir uns darauf vorbereiteten, die endgültigen Titel bekannt zu geben, hat mein Kollege Bryan Behrenshausen großartige Arbeit geleistet und uns über den Prozess informiert, der zu unserer Entscheidung geführt hat. Die Leute schienen sich darüber zu freuen – auch wenn sie mit unserem endgültigen Titel nicht einverstanden waren.

Die „Beta“-Phase des Buches erfordert viel Korrekturlesen. Community-Mitglieder haben sich wirklich an der Beantwortung dieses „Bitte um Hilfe“-Beitrags beteiligt. Wir haben etwa 80 Kommentare zum GitHub-Ticket erhalten, die über den Fortschritt der Korrekturlesearbeiten berichten (ganz zu schweigen von den vielen zusätzlichen Rückmeldungen, die wir per E-Mail und über andere Feedback-Kanäle erhalten haben).

Über das Erledigen der Aufgabe: In diesem Stadium haben wir das Gesetz von Linus persönlich erlebt: „Mit mehr Augen sind alle Tippfehler oberflächlich.“ Wenn wir es wie die ersten drei Bücher unabhängig erledigen, liegt die gesamte Last des Korrekturlesens auf unseren Schultern ( wie es bei diesen Büchern der Fall ist)! Stattdessen übernahmen Community-Mitglieder großzügig die Last des Korrekturlesens für uns, und unsere Aufgabe verlagerte sich vom Korrekturlesen selbst (obwohl wir immer noch viel davon machten) zur Verwaltung aller Änderungswünsche. Dies ist eine willkommene Abwechslung für unser Team und eine Gelegenheit für die Community, sich zu engagieren. Wir hätten das Korrekturlesen auf jeden Fall schneller abschließen können, wenn wir es selbst gemacht hätten, aber mit der Offenlegung haben wir vor Ablauf der Frist mehr Fehler gefunden, das ist sicher.

4. Veröffentlichen

Nun, wir haben jetzt die endgültige Version des Buches herausgebracht. (Oder nur die Erstausgabe?)

Wir unterteilen die Veröffentlichung in zwei Phasen. Gemäß unserem öffentlichen Projektzeitplan haben wir das Buch zunächst einige Tage vor dem endgültigen Datum stillschweigend veröffentlicht, um unseren Community-Mitwirkenden die Möglichkeit zu geben, uns beim Testen des Download-Formulars zu helfen. Die zweite Stufe ist nun die offizielle Ankündigung der allgemeinen Version dieses Buches. Natürlich nehmen wir auch nach der Veröffentlichung Rückmeldungen entgegen, ebenso wie der Open-Source-Ansatz.

Inhalt

Erfolge freigeschaltet
Die Einhaltung eines offenen Entscheidungsrahmens ist der Schlüssel zum Erfolg des Guide to IT Culture Change. Durch die Zusammenarbeit mit Kunden und Stakeholdern, das Teilen unserer Einschränkungen und die Transparenz unserer Arbeit haben wir sogar unsere eigenen Erwartungen an das Buchprojekt übertroffen.

Ich bin mit der Zusammenarbeit, dem Feedback und der Aktivität während des gesamten Projekts sehr zufrieden. Während ich eine Zeit lang Angst hatte, Dinge nicht so schnell zu erledigen, wie ich wollte, wurde mir schnell klar, dass wir durch die Öffnung des Prozesses tatsächlich mehr erledigen konnten. Das geht aus meiner obigen Übersicht hervor.

Vielleicht sollte ich also meine GSD-Mentalität überdenken und sie auf GMD ausweiten: Mehr erledigen, mehr erledigen und in diesem Fall bessere Ergebnisse erzielen.

(Titelbild: opensource.com)

Über den Autor:

Jason Hibbets – Jason Hibbets ist Senior Community Evangelist im Red Hat Enterprise Marketing und Community Manager bei Opensource.com. Er ist seit 2003 bei Red Hat und Gründer der Open Source Cities Foundation. Zu seinen früheren Positionen zählen Senior Marketing Specialist, Projektmanager, Red Hat Knowledge Base Maintainer und Support Engineer.

Das obige ist der detaillierte Inhalt vonOpen-Workplace-Forschung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!