Joel on Software - Getting Things Done When You're Only a Grunt
Deutsche Übersetzung

Das Original:
http://www.joelonsoftware.com/articles/fog0000000332.html
Joel Spolsky, 25. Dezember 2001
©2000-2009 Joel Spolsky
Diese Übersetzung:
http://www.bitloeffel.de/DOC/joelonsoftware/GettingThingsDone_de.html
Hans-Werner.Heinzen @ Bitloeffel.de , August 2009

Wie man als kleines Licht Großes bewirken kann

An dieser Stelle sollte es eigentlich um Softwaremanagement gehen; doch manchmal fehlt es einem an Macht, Veränderungen mit Befehl von oben durchsetzen zu können. Klar, dass man als kleiner Rechenknecht am unteren Ende der Hackordnung Zeitpläne oder das Benutzen einer Fehlerdatenbank nicht einfach anordnen kann. Wahrscheinlich hast du, wenn du Manager bist, bereits festgestellt, dass das Führen von Programmieren eher wie das Hüten einer Horde junger Hunde ist, nur weniger spaßig. "Sitz!" oder "Platz!" bewirken da nicht viel.

Es kann ziemlich frustrieren: das Arbeiten für eine Firma, die beim Joel-Test schlecht abschneidet. Egal wie gut du auch kodierst, deine Kollegen schreiben dermaßen schlechten Kode, dass du dich schämst, mit dem Projekt in Verbindung gebracht zu werden. Oder das Management trifft dumme Entscheidungen, so dass du dein Talent gezwungenermaßen mit einem Rentenalterplanspiel für Kinder vergeudest ... in der AS/400-Version!

Du könntest natürlich kündigen. Aber wahrscheinlich gibt es einen guten Grund, der dich dort festhält: die Aktien sind in den Keller gerutscht, es gibt keinen besseren Job in Hinterposemuckel, oder der Boss hält deine Liebste als Geisel. Egal, jedenfalls kann einem das Leben in einem schlechten Team den Blutdruck ziemlich hochtreiben. Aber ich hab' hier ein paar Strategien, um ein Team von unten her zu verbessern, und die will ich gerne weitergeben.

Strategie 1: Tu's einfach

Schon eine Person kann eine Menge zum Verbessern des Projekts beitragen. Gibt's keinen täglichen Bau- und Paketierungsprozess? Schreib' einen! Richte auf deiner Maschine einen nächtlichen Job ein und verschick' die Ergebnisse als E-Mail. Besteht der Prozess aus zu vielen Arbeitsschritten? Schreib' das Makefile neu! Niemand testet die Benutzbarkeit? Mach deine eigenen Flurtests mit den Leuten von der Poststelle auf einem Blatt Papier oder mit einem VB-Prototypen.

Strategie 2: Nutze die Kraft des Virus-Marketings

Viele der Joel-Test-Strategien können von einer Einzelperson in ein unkooperativen Team eingeführt werden. Wenn das geschickt gemacht wird, wird sich einiges davon im Team weiterverbreiten.

Zum Beispiel kann keiner im Team davon überzeugt werden, eine Fehlerdatenbank zu verwenden? Lass' dir keine grauen Haare wachsen; benutz' deine eigene. Trag' die Fehler ein, die du in deinem eigenen Kode findest. Wenn dir ein Fehler auffällt, den jemand anderes ganz dringend bearbeiten sollte, ordne ihr den Fehler zu, indem du deine Fehlerdatenbank benutzt. Wenn du eine gute Fehlerverfolgungs-Software benutzt, wird die eine Elektropost verschicken. Und so kannst du immer wieder E-Mails schicken, bis der Fehler behoben ist. Letztendlich wird man den Wert der Fehlerdatenbank erkennen und das System auch benutzen, was ja die Absicht war. Wenn die QS-Leute sich weigern, Fehler dort einzutragen, weigere du dich, Fehlermeldungen auf anderen Kanälen wahrzunehmen. Wer zum dreitausendsten Mal gehört hat: "Ich würde das ja gerne in Ordnung bringen ... aber ich vergesse es bestimmt wieder. Könntest du das nicht vielleicht in der Datenbank eintragen?", der wird schließlich das System benutzen.

Niemand im Team will eine Quellenverwaltung benutzen? Bau dein eigenes CVS-Archiv; wenn nötig, auf der eigenen Festplatte. Auch ohne Unterstützung kannst du dort völlig unabhängig auch den Kode der anderen einbuchen. Wenn es dann ein Problem gibt, das die Quellenverwaltung lösen kann (irgendjemand hat aus Versehen rm * ~ anstatt rm *~) eingetippt), wird man bei dir um Hilfe nachfragen. Schließlich wird man auch realisieren, dass man sogar selbst ausbuchen kann.

Strategie 3: Schaffe einen Exzellenzkern

Im Team macht keiner Zeitpläne, oder schreibt Konzepte? Mach' es selbst. Niemand wird meckern, wenn du dir ein oder zwei Tage Zeit nimmst, ein Minimalkonzept, plus Zeitplan, für deine Arbeit zu schreiben.

Versuch', gute Leute für das Team zu gewinnen. Beteilige dich an Mitarbeitersuche und Bewerbungsgesprächen. Wirb für gute Kandidaten.

Finde heraus, wer willens und fähig ist, dazuzulernen, und zieh' sie auf deine Seite. Selbst in einem miesen Team gibt es intelligente Leute, denen zum Schreiben von gutem Kode nur die Erfahrung fehlt. Hilf ihnen. Bring sie dazu, sich weiterzubilden. Schau dir ihren Kode an. Aber schreib' ihnen keine besserwisserischen E-Mails, was sie schon wieder falsch gemacht hätten. Melde besser, völlig unschuldig, den Fehler, von dem du weißt, das er Ergebnis des falschen Kodes ist. Lass' sie selbst die Ursache finden; so ist der Lerneffekt größer.

Strategie 4: Mach' Dummköpfe unschädlich

Selbst im besten Team gibt es ein oder zwei Dummköpfe. Das frustrierende daran ist, dass ihr schlechter Kode deinen guten korrumpiert, und dass gute Programmierer zeitaufwendig hinter schlechten hinterherräumen müssen.

Als kleiner Rechenknecht kann dein Ziel nur Schadensbegrenzung sein. Es wird der Moment kommen, an dem einer dieser Genies zwei Wochen braucht, um einen dermaßen grottenschlechten Kode zu schreiben, dass er nie funktionieren wird. Du wirst versucht sein, das Ding in 15 Minuten neu, und richtig, zu schreiben. Widerstehe der Versuchung! Das ist die Gelegenheit, diesen Irren für Monate unschädlich zu machen. Hör' einfach nicht auf damit, einen Fehler nach dem anderen zu melden. Er wird sich monatelang damit herumschlagen. Solange, bis du keine Fehler mehr finden kannst. Und während dieser Monate kann er woanders keinen Schaden anrichten.

Strategie 5: Halte dich von Störquellen fern

Alle angenehmen Arbeitsplätze gleichen sich: eigene Büros, ruhige Umgebung, beste Werkzeuge, wenig Unterbrechungen und noch weniger lange Sitzungen. Alle unangenehme Arbeitsplätze sind unangenehm auf ihre ganz besondere Art.

Die schlechte Nachricht ist, dass es fast unmöglich ist, an den Räumlichkeiten etwas zu ändern, egal in welcher Firma. Nicht einmal der Vostand kann das. Deshalb haben so wenige Entwickler eigene Büros. Den Firmen schadet das mindestens auf zweierlei Art. Erstens ist es schwerer, Topleute zu bekommen, die angenehme Arbeitsbedingungen vorziehen (solange alles andere vergleichbar ist). Zweitens vermindert sich die Produktivität der Entwickler dramatisch mit der Anzahl der Störungen; sie werden die "produktiven Zone" schwer erreichen und kaum für längere Zeit aufrechterhalten können.

Such' nach Möglichkeiten, dem zu entfliehen. Nimm deinen Klapprechner mit in die Kantine - die meiste Zeit des Tages gibt's da viele leere Tische (und keiner findet dich). Reservier' dir einen Besprechungsraum für den ganzen Tag und kodiere dort. Mach' durch die Menge deiner Check-ins klar, wieviel du geschafft kriegst, wenn du einen Raum für dich alleine hast. Wenn der nächste Termin drückt und dein Chef dich fragt, was du brauchst, um die Arbeit "bis gestern" zu erledigen, dann weißt du, was du sagen musst. Man wird dir ein Büro besorgen. Und ziemlich bald wird man darüber nachdenken, wie man wohl diese Produktivität das ganze Jahr über bekommen könnte.

Fang' spät an, hör' spät auf. Die Stunden, nachdem der Rest der Firma schon gegangen ist, können die produktivsten sein. Oder umgekehrt, wenn dein Team normalerweise spät anfängt, kommst du schon um 9. In den zwei Stunden, bevor dich die anderen belästigen können, kriegst du mehr erledigt, als am Rest des Tages.

Lass' Outlook (oder was auch immer) nicht im Hintergrund laufen; wenn du meinst, es sei nötig, schau' halt einmal pro Stunde nach der Post.

Strategie 6: Werde wertvoll für die Firma

Keine dieser Strategien greift, solange du nicht selbst ein hervorragender Mitarbeiter bist. Wenn du nicht viel und guten Kode schreibst, wird man es dir übelnehmen, dass du Zeit mit Fehlerdatenbanken vertrödelst, während du doch Kode produzieren sollst. Nichts ist schädlicher für deine Karriere, als der Ruf, aus Verliebtheit in Verfahrensweisen nichts zustande zu bringen.

Als ich einst Anfänger in einer neuen Firma war, bemerkte ich, dass man dort nur um die 2 auf der Skala des Joel-Tests arbeitete, und und ich war entschlossen, das zu ändern. Ich wusste aber auch, dass ich zuallererst einen guten Eindruck machen musste. So verwandte ich die ersten sieben Stunden des Arbeitstages - so wie's von mir erwartet wurde - auf das Kodieren. Eine Flut von Check-ins lässt dein Ansehen im Teams rasch steigen. Aber die letzte Stunde vor dem Heimweg reservierte ich dafür, Arbeitsabläufe zu verbessern. Ich räumte Hindernisse für das Entwanzen aus dem Weg, schrieb ein Skript für einen täglichen Bau- und Paketierungsprozess und installierte eine Fehlerdatenbank, ich kümmerte mich um all den lästigen Kleinkram, der das Entwickeln so zäh machen kann, schrieb jeweils Konzepte für die Arbeit des Tages, schrieb eine Schritt-für-Schritt-Anleitung zum Einrichten eines Entwicklerarbeitsplatzes und dokumentierte in allen Einzelheiten eine bisher nicht dokumentierte interne Sprache. Langsam, nach und nach, wurde der Prozess besser. Niemand außer mir (und meinem Team, als ich dann eines leiten durfte) scherte sich um Zeitpläne oder Konzepte. Wir aber liefen auf Level 10 der Joel-Test-Skala.

Es ist möglich, etwas zu verbessern, auch wenn du nicht das Sagen hast, doch du musst sein wie Cäsars Ehefrau: über jeden Verdacht erhaben. Sonst machst du dir Feinde.

Weitere Vorschläge?