Dienstag, Mai 27, 2008

Tipps zur Teamarbeit

Ein (Projekt-)Team ist ein Gruppe von Menschen, an die eine Herausforderung oder eine Aufgabe herangetragen wird und von der man die zielgerichtete Bewältigung der Herausforderung erwartet. Oft geschieht das unter Randbedingung wie begrenzten Geldmitteln und Zeitbeschränkungen. Die Teammitglieder sind außerdem gegenseitig voneinander abhängig, um die Herausforderung bewältigen zu können.

Arbeitsteilung und Spezialisierung sind die Wunderwaffen der Teamarbeit. Ein gutes Team bewältigt eine Herausforderung schneller als ein schlechtes Team. Ein gutes Team teilt die Arbeit besser auf und bildet bessere Experten aus als ein schlechtes Team. Ein gutes Team schafft schneller oder mehr. Nachfolgend ein paar Tipps, die Ihnen helfen sollen, gute und effektive Teamarbeit zu leisten.

Definieren Sie eine Teamleitung. Machen Sie eine Person zu Ihrer Teamleitung und übertragen Sie ihr die Verantwortung zur Koordination des Teams. Im Zweifel hat die Teamleitung das Recht Entscheidungen zu treffen, damit eine Handlungsunfähigkeit mangels Entscheidung aufgelöst werden kann. Die Teamleitung trägt die Verantwortung für das Team und damit auch für das Ergebnis.

Nutzen Sie Ihre Stärken -- oder machen Sie sich stark. Teilen Sie sich die Arbeit gemäß den Spezialisierungen im Team auf und/oder nutzen Sie die Arbeitsteilung, um einzelne Personen zu Experten werden zu lassen. Klären Sie, wer welche Kompetenzen und Interessen mitbringt. Nutzen Sie die Stärken und Talente eines jeden Teammitglieds. Oder bauen Sie Stärken auf.

Keine Aufgabe, die nicht zielführend ist. Fragen Sie sich bei jeder Aufgabe, warum diese Aufgabe sein muss. Eine Aufgabe ist dann überflüssig, wenn auch ohne sie ein Erfolg denkbar ist.

Keine Aufgabe ohne ein klar definiertes Ergebnis. Das Ergebnis ist dann klar definiert, wenn entscheidbar ist, wann die Aufgabe beendet ist. Beispiel: "Ich schau mir mal JavaScript an" ist kein definiertes Ergebnis, "Ich stelle eine Übersicht der Kontrollstrukturen von JavaScript zusammen" hingegen schon.

Keine Aufgabe ohne Klarstellung, für wen das Ergebnis ist. Betrachten Sie Ihre Aufgabe und das Ergebnis als Dienstleistung, als Service für den Empfänger des Ergebnisses. Betrachten Sie den Empfänger als Kunden – und machen Sie ihn glücklich! Denken Sie daran, dass Ihr Kunde von dem Ergebnis profitieren und nicht mehr Zeit als nötig zum Verarbeiten des Ergebnisses investieren möchte. Dennoch sind Quellen, Begründungen etc. anzugeben, denn die Plausibilität ihrer Ergebnisse muss im Zweifelsfall nachvollziehbar sein.

Keine Aufgabe, die länger als zwei Wochen benötigt. Die Zeitspanne von maximal zwei Wochen ist für viele Menschen ein guter Maßstab. "Kleine" Aufgaben sind psychologisch wichtig. Es zwingt außerdem dazu, eine Herausforderung in überschaubare Aufgabe runterzubrechen und erlaubt der Teamleitung ein besseres Nachhalten über den Stand der Dinge.

Keine Aufgabe ohne einen(!) Aufgaben-Verantwortlichen. Wer treibt eine Aufgabe voran, wer kümmert sich darum, dass sie in Angriff genommen wird, wer hält den Arbeitsforschritt nach, wer meldet rechtzeitig Probleme, wer erklärt eine Aufgabe für erledigt? Der Verantwortliche bzw. die Verantwortliche erntet Ruhm wie auch Tadel. Bei kleinen Aufgaben fallen die Rollen zusammen: dann ist eine Person sowohl Aufgaben-Verantwortliche als auch Ausführende. Bei größeren Aufgaben mag man sich die Arbeit teilen, die Verantwortung jedoch nicht. Denn: Verantwortung ist nicht teilbar!

Lernen Sie, auf das Ende einer Aufgabe hinzuarbeiten -- alles andere ist uninteressant. Nehmen wir an, Sie haben die Aufgabe, die Kontrollstrukturen von JavaScript in einer Übersicht zusammenzustellen. Diese Aufgabe ist schnell erledigt, Sie bedarf vielleicht gerade einer halben Stunde, selbst wenn Sie als Informatik-Student noch nie mit JavaScript Kontakt hatten. Natürlich ist es verführerisch, im Web Links zu JavaScript zu verfolgen und vieles Interessantes über die Sprache in Erfahrung zu bringen; ergebnisorientiert ist das nicht.

Definieren Sie Zeiten zur thematischen Orientierung und zum zielorientierten Kompetenzaufbau. Wir sind Menschen, wir können nicht andauernd in Ergebnissen arbeiten und denken. Wir benötigen Zeiten, um uns zu orientieren oder um Kompetenzen aufzubauen, ohne uns dem Druck und dem Stress von Zielen und Ergebnissen unterwerfen zu müssen. Diese Zeiten sind notwendig um (a) überhaupt Ergebnisse und Ziele definieren zu können (Orientierung) und um (b) in die Lage versetzt zu werden, sich Ergebnisse erarbeiten zu können (Kompetenzaufbau). Aber begrenzen Sie diese Zeiten und vereinbaren Sie sich auf ein Thema. Und: Das Thema muss zielführend sein. Beachten Sie, dass sich Kompetenzen in der Regel anhand konkreter Aufgaben aufbauen lassen. Themenarbeit endet mit einem kurzen Tätigkeits- und Erkenntnisbericht an das Team, schließlich ist auch der Lern- oder Orientierungsprozess für das Team von Interesse.

Keine Person im Team ohne aktuelle Aufgabe oder Themenzeit. Sobald eine Person gar nichts tut und etwa einer anderen Person bei der Arbeit zuschaut (gerne maskiert unter "Wir arbeiten zusammen."), läuft irgendetwas schief mit der Teamarbeit. Es kann an mangelnder Koordination bzw. Kommunikation des Teams liegen. Möglicherweise sind aber auch einfach zu viele Personen in einem Team, mehr, als die Aufgabe hergibt.

Arbeiten Sie allein. Sobald mehr als eine Person das Gleiche tut, findet keine Arbeitsteilung mehr statt. Teamarbeit schließt gemeinsames Arbeiten zur gleichen Zeit in einer gemeinsamen Umgebung nicht aus, aber sie verfehlt ihr Ziel, wenn zwei oder mehr Personen grundlos das Gleiche tun. (Auch hier ist die Maskierung "Wir arbeiten zusammen." nicht selten.) Es ist eine der größten Herausforderungen, die Teamarbeit mit sich bringt: alleine arbeiten zu können. Es sind typische Verhaltensmuster von Unsicherheit und Flucht vor der Herausforderung, die Menschen dazu bewegen, mit jemand anderem an der gleichen Aufgabe zusammen arbeiten zu wollen. Auch wenn es paradox zu sein scheint: Teamfähigkeit heißt, weite Strecken über autonom arbeiten zu können. Anders ist Teamarbeit z.B. über das Web in Form von remote collaboration gar nicht möglich.

Definieren Sie regelmäßige, kurze Treffen zur Koordination. Die Arbeiten müssen regelmäßig unter allen Teammitgliedern abgestimmt werden, wobei Anwesenheit (physisch oder virtuell) mehr als sinnvoll ist. Solche Treffen sind kurz zu halten, da diese Zeiten keine Produktivzeiten sind.

Schaffen Sie Möglichkeiten zur Kommunikation. Menschen in einem Team müssen kommunizieren, um eine Identität als Gruppe entwickeln zu können -- und das gilt es gezielt zu kultivieren. Zum Beispiel durch Kommunikationsecken (die berühmte Ecke oder Küche mit der Kaffeemaschine), gemeinsame Arbeitsräume, gemeinsame Mittagessen, Mailing-Listen, Diskussionsforen, Chat-Rooms etc.

Schaffen Sie sich Zeitblöcke zur ungestörten, konzentrierten Arbeit. Ob Sie an einer Aufgabe arbeiten oder mit einem Themenblock beschäftigt sind, Sie brauchen Zeitblöcke von 1 1/2 bis 4 Stunden, um produktive Arbeit leisten zu können. In dieser Zeit sollten sie ungestört sein und auch für Ihre Teammitglieder nicht zur Verfügung stehen.

Zusammenfassung

Teamarbeit ist Arbeitsteilung -- was wörtlich zu nehmen ist: Sie teilen sich die Arbeit. In aller Regel wird mit der Arbeitsteilung eine Spezialisierung einhergehen. Sie arbeiten meist ergebnisorientiert, gelegentlich themenbezogen. Eine Aufgabe ist zeitlich klar begrenzt und hat ein definiertes Ergebnis. Es gibt einen Aufgaben-Verantwortlichen und eine Person bzw. Personengruppe, für die das Resultat der Aufgabe von Nutzen ist. Die Aufbereitung des Resultats sollte an der Zielgruppe ausgerichtet sein. Themenarbeit ist ebenfalls zeitlich klar begrenzt, zielorientiert und endet mit einem Bericht ans Team.

Übrigens sollte ein Team nicht aus zu vielen Personen bestehen. Jenseits von elf, zwölf Personen bilden sich automatisch Untergruppen heraus, die ein Team in wenig gut steuerbare Einheiten zerfallen lassen.

Mittwoch, Mai 21, 2008

Informatik als angewandte Philosophie

Was war zuerst: Die Henne oder das Ei? Oder setzen wir noch früher an: Was bitte ist ein Ei, was genau ein Huhn? Informatiker setzen sich auf ihre eigene Art und Weise mit solchen Fragen auseinander -- eigentlich sogar tagtäglich. Zwar sprechen sie selten von Hühnern oder Eiern, aber sie haben Antworten zu bieten.

Wollen Sie auch erfahren, was Informatiker so gedankenverloren in den Kaffee schauen lässt und warum Milchtüten eine echte Herausforderung sind?

Dann möchte ich Sie herzlich einladen zu meinem Vortrag "Informatik als Angewandte Philosophie: Gedanken über Bits und Bytes" am Dienstag, 3. Juni 2008, um 17:30 Uhr bis 19 Uhr. Der Vortrag findet statt im Rahmen der Ringvorlesung "Mensch-Umwelt-Zukunft" an der Hochschule Heilbronn (Max-Planck-Str. 39) im Raum E010.

Ich freue mich auf Ihren Besuch. Und wenn Sie Wünsche, Anregungen, Gedanken haben, zu denen Sie gerne etwas hören möchten, dann lassen Sie es mich wissen.

Montag, Mai 12, 2008

Forth gedacht: JavaScript 2

Forth ist eine der Programmiersprachen aus der Frühzeit der Informatik. Die Sprache entstand Anfang der 70er Jahre und wurde von Charles H. Moore erschaffen -- und sie hat bis heute überlebt. Sie ist stack-basiert, äußerst einfach aufgebaut, sie kann mühelos ohne Betriebssystem auskommen und ist beliebig erweiterbar. Die Programme sind schnell und äußerst kompakt, weshalb Forth gerade im Bereich der eingebetteten Systeme noch immer gerne genutzt wird. Und man kann mit Forth Programme interaktiv entwickeln; ein Vorteil, den man von interaktiven, dynamisch-typisierten Sprachen kennt. Was das spannende ist: Forth ist ein entscheidender Baustein im neuesten JavaScript 2 (ECMAScript 4) für den Mozilla-Browser Firefox 4.0.

In der zukünftigen Generation des Firefox-Browsers 4.0 (ich spreche nicht von Firefox 3.0, der bald fertig gestellt sein wird) wollen die Mozilla-Entwickler das dann aktuelle JavaScript 2.0 auf einer Virtuellen Maschine (VM) mit JIT-Kompilierung (just in time compilation) ausführen lassen. Im November 2006 erhielt die Mozilla-Organisation die dafür notwendige Technologie von Adobe Systems. Adobe spendete das etwa 135.000 Zeilen Code umfassende Tamarin an Mozilla. Tamarin ist der Name der VM, die Adobe seit Flash 9 für die Ausführung von ActionScript einsetzt. Derzeit läuft ein Projekt namens ActionMonkey bei Mozilla, das die aktuelle JavaScript-Implementierung für Firefox (SpiderMonkey) und das Tamarin-Projekt zusammenbringt.

Der ByteCode von Tamarin wird in Files mit der Endung .abc abgelegt; sie sind das Analogon zu .class-Files für die Java VM. Der abc-ByteCode wird in Forth als Zwischensprache (Intermediate Language, IL) übersetzt. Für Forth gibt es dann einen C-Interpreter. Wer hier generell einen Einstieg finden möchte, dem sei der Blog "Hacking with Caffein" von Mason Chang empfohlen, insbesondere der Beitrag "Getting started with Tamarin and Forth" (27. März 2008). Man darf gespannt sein, wie sich das ActionMonkey-Projekt machen wird und ob sich Forth als IL in der Virtuellen Maschine halten wird!

Wer sich für ein modernes "Forth" interessiert, der sei auf Factor verwiesen. Siehe dazu auch "Factor: In der Kürze liegt die Würze".