1265460857|%d.%m.%Y
Nicht wenige verbringen den halben Berufsalltag damit, mittels E-Mail zu organisieren, was zu tun ist. Das, was eigentlich zu tun ist, bleibt dabei auf der Strecke und muss nach Feierabend getan werden. Die freie Zeit wird dadurch immer knapper, und manchmal endet alles in einem Burnout-Syndrom. Der Rat, einfach zu arbeiten und nur noch einmal täglich E-Mails zu checken, geht leider an der Realität vorbei, denn die Arbeit könnte dann schnell vergeblich sein, und das Arbeitsverhältnis dahin. Gibt es also andere Lösungen?
Die Probleme vom Medium E-Mail sind bekannt. Es erschafft einen mehr oder weniger chaotischen Peer-to-peer-Verkehr in einem Umfeld, an dem meist mehrere Benutzer beteiligt sind.
Verteilter Informationsfluss
Typischer E-Mail-Workflow: manche sind besser informiert als andere, und keiner bekommt alles mit
Verschärfend kommt hinzu, dass dieser Verkehr asynchron abläuft, über Stunden oder Tage hinweg. Und immer nur sind einzelne Mails sichtbar, nie das „große Ganze“. Auch Arbeitsdokumente werden massenweise auf diesem Weg übertragen, als Attachment hier, als weitergeleitetes Attachment dort. Betrachtet man das so von außen, kommt sich vor wie in Platons Höhlengleichnis und hat das starke Bedürfnis, den armen Betroffenen endlich das Sonnenlicht zu zeigen.
Doch das ist meist gar nicht nötig. Die Betroffenen wissen selbst um die Mängel. Sie freuen sich deshalb immer darauf, wenn mal wieder ein Meeting stattfindet. Eine Veranstaltung, an der alle Beteiligten gleichzeitig teilnehmen, und in deren Verlauf binnen zwei oder drei Stunden meist mehr geklärt werden kann als in zwei oder drei Arbeitswochen E-Mail-Pflege. Beim anschließenden gemeinsamen Mittagessen wird dann meist noch abfällig über die Mailings hergezogen, und wie überlegen doch die echte Kommunikation der elektronischen sei.
Darin liegt allerdings ein Denkfehler. Denn das Problem ist nicht das Elektronische an der Kommunikation. Das Problem ist die asynchrone, chaotische Peer-to-peer-Charakteristik der E-Mail-Kommunikation. Dabei ist eigentlich alles ganz einfach. Obiges Schaubild schreit geradezu nach Zentralisierung.
Zentralisierter Informationsfluss
Nenen wir ihn den Ideal-Workflow: jeder nimmt teil, und alle bekommen alles mit
Der Ideal-Workflow benötigt also, wie leicht ersichtlich ist, eine brauchbare Client-Server-Lösung, einen zentralen Informationspool, auf den alle Beteiligten zugreifen können, und zu dem alle Beteiligten beitragen können. Also letztlich das Gleiche, was bei einem Meeting geschieht. Jeder kann alles hören, was gesagt wird, und jeder kann selber etwas sagen. Das Ergebnis-Protokoll erhalten alle Beteiligten, und alle haben damit eine gemeinsame Basis.
Nun ist der oben dargestellte Ideal-Workflow stark vereinfachend und idealisierend. Zum einen findet das Beitragen und Abrufen von Information an einem zentralen Informationspool anders als ein Meeting nicht synchron statt, sondern eher wie E-Mail-Verkehr asynchron. Zum anderen könnte das Volumen der gesamten verfügbaren Information einzelne Benutzer überfordern. Es könnte infolge des Information-Overkill sogar zu energieraubendem Kompetenzgerangel kommen, da nun jeder das große Ganze sieht (oder zu überblicken vermeint).
Ganz unproblematisch ist der propagierte Ideal-Workflow also nicht. Für einige, meist kleinere Teams und Projekte mag er ausreichend sein. In Bezug auf komplexere Projekte und Involvierungsgrade von Beteiligten kommen weiterführende Überlegungen dagegen früher oder später auf eine gemischte Lösung.
Verteilter zentralisierter Informationsfluss
Idealer Workflow mit Realitätssinn: ein Teil für alle, andere Teile für bestimmte Beteiligte, aber immer zentral
In diesem Konzept gibt es wie im Ideal-Workflow einen zentralen Informationspool. Dieser ist jedoch kleiner und enthält nur Informationen, die wirklich von allen Beteiligten benötigt werden. Außerdem enthält er Links zu weiteren Informationspools mit spezielleren Informationen. Diese Spezial-Informationspools sind nur für jeweils Beteiligte von Interesse. Wichtiges Merkmal: auch die „Satelliten-Pools“ sind aus Sicht der daran Beteiligten zentrale Informationspools, zu denen alle Beteiligten beitragen können, und deren Inhalte alle Beteiligten abrufen können. Ergebnisse aus den Satelliten-Pools können wiederum in den zentralen Informationspool einfließen.
Und die Software-Lösung dafür?
Wie E-Mail funktioniert und was man dafür braucht, weiß jeder. Doch wenn man Entscheider in Unternehmen bis hierhin lesen lassen und fragen würde, mit welchen Software-Lösungen man einen verteilten zentralen Informationsfluss realisieren kann, werden die meisten mit den Schultern zucken und außerdem an ihr schmales Budget denken.
Der reine Informationsfluss lässt sich mit Hilfe von Wikis realisieren. Ein zentrales Wiki für alle Beteiligten, und Satelliten-Wikis, die über das zentrale Wiki erreichbar sind, für bestimmte Beteiligte und Teilbereiche. Der Wiki-Einsatz als E-Mail-Alternative wird ja auch durchaus häufig propagiert, wie etwa hier und dort. Es gibt auch längst Wikis, die sehr intuitiv zu bedienen sind, inklusive Wysiwyg-Bearbeitung und der Möglichkeit, Inhalte aller Art einzubinden.
Allerdings haben reine Wikis auch Nachteile. Sie erfordern von den Beteiligten nicht nur eine gewisse Einarbeitungszeit, sondern auch eine andere Art, Inhalte beizutragen. Das Gefühl zu kommunizieren geht in Wikis leicht verloren. Und das könnte sich letztlich demotivierend auswirken. Geeigneter sind deshalb möglicherweise Lösungen, die das einfache, direkte Beitragen von zentralen Inhalten um Elemente direkter Kommunikation erweitern. In genau diese Richtung zielt Google Wave. Allerdings wird sich erst noch herausstellen müssen, ob dieses Gesamtkunstwerk aus Instant Messenging, Wiki und Einbindung intelligenter Gadgets wirklich alltagstauglich ist. Soll es für konkrete Projektarbeit eingesetzt werden, erfordert Wave anders als E-Mail und ähnlich wie Wikis konzeptionelle Überlegungen. Welche Waves sollen für welchen Zweck eingerichtet werden? Welche Beteiligten sollen in welche Wave involviert werden? Eines ist jedenfalls sicher: wird Wave ohne Plan und Disziplin genutzt, ist es am Ende noch wesentlich unübersichtlicher als E-Mail.
Eine einfachere, aber auch intuitivere Lösung könnte Etherpad sein. Leider wurde die Etherpad-Hosting-Plattform von Google gekauft und wird wohl einfach in Wave einfließen. Allerdings versprechen die Anbieter, Etherpad künftig als OpenSource-Variante weiterzuentwickeln. Etherpad ist nicht so mit Funktionen überladen wie Wave, kombiniert aber das gemeinsame Erarbeiten eines Dokuments mit Chat-Funktionalität in einer schlichten Oberfläche. Funktionen wie das Anhängen relevanter Dateien oder das Einbinden intelligenter Gadgets fehlen allerdings.
Daneben gibt es diverse Tools, die kollaboratives Schreiben ermöglichen, im weiter gefassten Sinne also client-server-basiertes, gemeinsames Arbeiten an Dokumenten in Echtzeit. Diese Software-Gattung geht schon einen Schritt weiter. Unsere bisherigen Überlegungen drehten sich nämlich nur um Mittel, die den Informationsfluss unter Projektbeteiligten besser fördern als E-Mail. Es ging nicht darum, diese Mittel zum direkten gemeinsamen Arbeiten am Endprodukt zu nutzen. Wenn das Endprodukt einer gemeinsamen Arbeit jedoch aus Bits und Bytes besteht, egal ob Konstruktionsplan, Software, Storyboard oder Manuskript, dann kann das direkte gemeinsame Bearbeiten der Dokumente erwägenswert sein. Für viele Beteiligte ist diese Art zu arbeiten allerdings sehr ungewohnt, und wenn sich bei Beteiligten das Gefühl einstellt, sich ständig beobachtet zu fühlen, dann ist der Einsatz solcher Tools sogar kontraproduktiv.
Noch sehr unterbelichtet sind die Möglichkeiten, die Google Sites bietet. Es handelt sich um ein sehr intuitiv bedienbares Wiki, das eine Reihe von Funktionen mitbringt, die in klassischen Wikis fehlen. So etwa die Möglichkeit, beliebige Dateien an Wiki-Seiten als Attachment anzuhängen, oder die Möglichkeit, beliebige Seiten mit Kommentarfunktionalität auszustatten, um so über Inhalte zu diskutieren. Eine Seite in Google Sites kann eine normale Seite mit Text, Grafik usw. sein. Daneben sind aber auch weitere Seitentypen möglich, beispielsweise für Listen, für die Ablage von Dateien oder für blog-artige, chronologisch sortierte Mitteilungen. Die Möglichkeit Gagdets von Google und anderen Anbietern zu integrieren, erlaubt das direkte Einbinden von Kalenderinhalten, Aufgabenplanern und anderen Tools ins Wiki. Mit etwas Phantasie lässt sich eine Google Site so als ein Informations- und Kommunikationsort modellieren, der für viele Anwender möglicherweise geeigneter ist als Google Wave.
Größere Unternehmen lassen sich allerdings (noch) ungern von fremd-gehosteten Lösungen überzeugen. Klassische Software-Anbieter wie Microsoft oder IBM werden bevorzugt. Der Artikel Collaboration-Software im Vergleich aus der Computerwoche vom Juni 2009 beleuchtet einige der in Frage kommenden Software-Lösungen, wie etwa den Microsoft Office SharePoint Server 2007 oder Lotus Quickr.
Es ist jedenfalls an der Zeit, in Unternehmen und Organisationen Alternativen zur E-Mail ernsthaft zu implementieren. Sonst läuft diese (also die Zeit) am Ende immer mehr davon, und der Burnout trifft am Ende nicht nur Einzelpersonen, sondern das Unternehmen oder die Organisation als Ganzes.
Warum wird hier nicht die gute alte Mailingliste genannt? Sie hat nicht den Nachteil von Mails an einzelne Personen und hat gegenüber dem Wiki den unschlagbaren Vorteil, daß ein Wiki aktiv besucht werden muß, während eine Mailingliste beim normalen Mailabruf mitkommt. Das funktioniert meiner Erfahrung nach bei Wikis überhaupt nicht. Die, die drauf schauen sollen, tun es einfach nicht. Läßt man bei Mailinglisten Attachments zu, was im Intranet kein Problem sein sollte, ist auch die Verteilung von Dokumenten gar kein Problem. Klar, es gibt auch Dinge, die damit nicht gut gehen, wie kollaboratives Schreiben. Aber für viele Dinge sind Mailinglisten doch optimal.
Google Wave ist absolut keine Alternative, weil es m. E. noch pre-alpha ist und nicht wirklich gut funktioniert, zumindest nicht mit allen Browsern.
Hallo Alex,
Der Einwand ist berechtigt. Aber an so was Archaisches habe ich tatsächlich die ganze Zeit über nicht gedacht, als ich an dem Artikel schrieb :-)
Was meine persönliche Erfahrungen mit Mailinglisten betrifft, geht es mir so, dass ich nur mit solchen auf die Dauer leben kann, die ein sehr moderates Posting-Aufkommen haben (maximal ein, zwei Mails am Tag). Wenn dagegen in einer Mailingliste richtig die Post abgeht, finde ich das reichlich chaotisch. Der Vorteil eines zentralen, modellierten Informationsorts besteht meines Erachtens darin, dass Informationen dort von den Beitragenden selbst eingeordnet werden müssen. Das gilt auch für reine Diskussionsbeiträge.
Es gibt eine großartige, traditionsreiche Mailinglisten-Kultur. Noch heute entstehen viele wichtige Standards im Internet wesentlich durch Ergebnisse aus Mailinglistendiskussionen. Bestes Beispiel: das W3C (der Verweis auf deren Mailinglisten-Archiv ist ein richtiger Trüffelhopser ;-)
Allerdings scheint mir dahinter mittlerweile eher so eine Art Abschreck-Effekt zu stecken. Die wollen offensichtlich unter sich bleiben. Andersrum ausgedrückt: wer weiß, welche Einflüsse auf die ganz konkrete, alltägliche Entwicklung der W3C-Standards einwirken würden, wenn es dafür eine zeitgemäße Plattform gäbe …
viele Grüße
Stefan Münz
Ein Wiki habe ich seit Jahren im Unternehmen installiert, inzwischen pro Projekt eines. Wie du schriebst, eignet sich das Wiki weniger für Diskussionen, es ist jedoch dank der Suchen-Funktion eine gute Wissensdatenbank.
Was mir fehlt, ist eine Möglichkeit, ohne Umwege Informationen als veraltet zu kennzeichnen, die bei Suchen ignoriert werden, außer man teilt der Suche mit: Ich suche veraltetes (da dies manchmal benötigt wird, ist Löschen keine Option). Auch fand ich keines mit der Möglichkeit, eine Seite von der Suche auszuschließen, was sinnvoll ist für reine "Linkseiten".
(->FB) letztendlich geht doch nichts über das persönliche tägliche meeting:)
http://de.wikipedia.org/wiki/Scrum#Daily_Scrum
… auch wenn ich es selbst bisher noch nicht zur Praxis machen konnte.. rein konzeptionell bin ich von den team-work-flow-technischen Lösungsansätzen die *scrum* aufzeichnet recht überzeugt::: das Team wird eben zur Teamarbeit während einem sprint lokal zusammengetrommelt.
und ein passendes Werkzeug zur Projektorganisation gibt es ja obendrein gratis dazu:::
http://de.wikipedia.org/wiki/Agilo_for_Scrum
Hallo Manu,
puh, soo viele (für mich) neue Ausdrücke aus den Tiefen der japanischen Produktionswirtschaftsphilosophie … also "lean production" und "kaizen" kannte ich ja schon, aber "scrum", "agile" und das ganzes Drumherum sind mir neu :-)
Irgendwie sind das aber alles so Sachen, die typischerweise in japanischen Autokonzernen ausgebrütet werden, in Campus-artigen Burgen, wo Tag und Nacht tausende hochspezialisierter Ingenieure in ihren Blaumännern rumlaufen und ihre komplette Lebensenergie dem Wohl des Konzerns widmen. Wenn ich über solche Themen schreibe, habe ich immer eher Konstellationen im Hinterkopf, wie sie mir selber eher vertraut sind. Lose Teams, die teilweise aus fest angestellten Mitarbeitern und teilweise aus freiberuflichen oder von externen Agenturen bereitgestellten Outsourcing-Partnern bestehen, viele Kilometer weit verteilt, weitgehend auf Online-Zusammenarbeit angewiesen. Eher so die geisteswissenschaftliche Ecke. Gerade deshalb ist dein Hinweis aber sehr wichtig: wenn man nämlich über solche Themen sinniert, sollte man immer auch die sehr unterschiedlichen Kulturen der Zusammenarbeit berücksichtigen, die es so gibt auf der Welt. Und was für die eine Kultur passt, muss nicht auch für eine andere passen.
viele Grüße
Stefan Münz
Mit den richtigen Werkzeugen als Zusatz kann man bestimmt auch ausgewachsene Versionierungssysteme zu diesem Zweck benutzen. Wahrscheinlich eignen sich dazu die verteilten selbigen (z.B. Mercurial, Git und Bazaar) eher als die zentralen (z.B. CVS und SVN). Ob das allerdings schon einer erfolgreich umgesetzt hat, weiß ich nicht zu berichten. Als Idee ist es mMn zumindest interessant.
!.. dazu muss ich anmerken, dass die sog. "agilen" Entwicklungsmethoden genau aus der anderen Ecke kommen:
"Scrum" zB. funktioniert gerade in kleinen bis mittleren, dh. übersichtlichen Teams sehr gut.
…eher etwas weiter entfernt vom Blaumann im japanischen Grosskonzern, obwohl viele Konzerne aktuell sehr interessiert an der Einbeziehung agiler Methoden sind, weil sie statistisch äusserst erfolgreich sind, gegenüber dem konventionell geführten Requirements Engineering.
Agile ist in letzter Zeit tatsächlich zu so etwas wie einem Hype stilisiert worden…
Bin erst neulich durch diverse Heise Artikel darauf aufmerksam geworden:
Hier ein Link: ! lesenswert:::
http://www.heise.de/developer/artikel/Requirements-Engineering-in-Zeiten-der-Agilitaet-804971.html
…hier findet man auch ohne primäres Interesse an "Agile" einige gute Ideen zu Projektorganisation, Teamwork und Management…
Posting-Vorschau:
Vorschau schließen