Joel on Software

Joel on Software   Joel über Software

 

Andere auf Deutsch verfügbare "Joel on Software"-Artikel

Andere auf Englisch verfügbare "Joel on Software"-Artikel

Email an den Verfasser (nur auf Englisch)

 

Wie man als kleine Nummer Großes bewirken kann


Von Joel Spolsky
Aus dem Englischen von Hartmut Ludwig
Redigiert von John L. Webber
25. Dezember 2001

Auf dieser Website sollte es um Software-Managment gehen. Aber manchmal ist man gar nicht in der Position, Änderungen in der Firma einfach anordnen zu können. Klar - wenn man nur ein kleiner Programmierknecht am untersten Ende der Hackordnung ist, kann man den Leuten nicht einfach befehlen, dass sie ab sofort Ablaufpläne oder Bug-Datenbanken erstellen sollen. Und selbst wenn Sie Manager sein sollten, haben Sie womöglich schon festgestellt, dass die Leitung von Entwicklern mit der Beaufsichtigung eines Katzenrudels zu tun hat, nur dass es nicht so viel Spaß macht. Nur dadurch dass man sagt "Energie!" setzt sich das Schiff noch nicht in Bewegung.

Es kann frustrierend sein, in einer Organisation zu arbeiten, die im  Joel Test schlecht abschneidet. Egal wie gut Ihr Code ist, Ihre Kollegen schreiben so schlechten Code, dass es Ihnen peinlich sein muss, mit dem Projekt in Verbindung gebracht zu werden. Oder das Management fällt schlechte Entscheidungen im Bezug darauf, was zu entwickeln ist und Sie sind gezwungen, Ihr Talent damit zu verschwenden, die AS/400-Version eines Spieles zur Rentenplanung für Kinder zu debuggen.

Sie könnten natürlich auch einfach kündigen, nehme ich an. Aber wir gehen einmal davon aus, dass es einen guten Grund dafür gibt, dass sie hier gelandet sind. Sie warten auf die Übertragung der Aktienoptionen, Sie finden keinen besseren Job in Ihrem Kuhdorf, oder Ihr Boss hat einen Ihrer Lieben als Geisel genommen. Auf jeden Fall - das Leben in einem schlechten Team kann sehr anstrengend sein. Aber es gibt Strategien das Team von Grund auf zu verbessern und einige davon möchte ich Ihnen vorstellen.

Strategie 1 Tun Sie es einfach!

Um ein Projekt voran zu bringen kann vieles schon dadurch geleistet werden, dass nur eine Person es tut. Sie haben keinen Server für ein tägliches Build? Schaffen Sie sich einen. Ziehen Sie Ihre eigene Maschine hoch, auf der nachts ein Job läuft, der das Build erzeugt und Mails über das Ergebnis verschickt. Sind zu viele Schritte notwendig, um ein Build zu erzeugen? Schreiben Sie sich ein Make-Script. Niemand testet die Usability? Machen Sie selbst spontane Tests mit den Leuten von der Poststelle, einem Stück Papier oder einem kleinen Prototypen in Visual Basic.

Strategie 2 Nutzen Sie die Möglichkeiten des Viren-Marketing

Viele Der Strategien aus dem Joel Test können von einer einzelnen Person ohne Unterstützung durch das Team umgesetzt werden. Manche davon werden sich wenn sie gut funktionierten automatisch auch beim Rest des Teams verbreiten.

Nehmen wir zum Beispiel einmal an, dass niemand im Team davon überzeugt werden kann eine gemeinsame Bug-Datenbank  zu verwenden. Lassen Sie sich dadurch nicht stören. Führen Sie einfach für sich Ihre eigene. Wenn Sie einen Bug finden, den jemand anders fixen sollte, weisen Sie den Bug in Ihrer Datenbank dieser Person zu. Wenn Sie eine gute Bugtracking-Software haben, wird die eine Mail an ihn verschicken. Auf diese Weise können Sie immer weiter Mails an die Entwickler schicken, wenn die ihre Fehler nicht beheben. Eventuell erkennen die dann den Wert eines Bugtracking-Systems und fangen selbst an das System so zu benutzen, wie es gedacht ist. Wenn das Qualitätssicherungs-Team sich weigert, Fehler in das Bugtracking-System einzutragen, weigern Sie sich einfach, Fehlermeldungen zu bearbeiten, die auf andere Weise an Sie herangetragen wurden. Und wenn Sie dann zum dreitausendsten mal zu den Leuten sagen "Hört mal, ich würde den Fehler ja liebend gern beheben, aber ich vergesse es bestimmt wieder. Könnt Ihr ihn nicht in mein System eingeben?" dann fangen die auch an, die Datenbank zu benutzen.

Niemand in Ihrem Team möchte mit einer Versionsverwaltung arbeiten? Dann erstellen Sie ein eigenes CVS-Repository, wenn nötig auf Ihrer eigenen Festplatte. Auch ohne Unterstützung können Sie Ihren Code unabhängig von den anderen ein- und auschecken. Dann, wenn die einmal Probleme haben, die Ihre Versionsverwaltungssystem lösen kann (weil jemand aus Versehen rm * ~ anstatt rm *~ eingegeben hat), kommen Sie hilfesuchend zu Ihnen. Vielleicht realisieren die Leute dann, dass sie sich auch ihre eigenen Versionen auschecken können.

Strategie 3 Schaffen Sie sich den Raum für Qualität

Das Team definiert keine Zeitpläne oder Spezifikationen? Dann schreiben Sie Ihre eigenen. Niemand wird sich darüber beschweren, wenn Sie sich ein bis zwei Tage damit beschäftigen, eine minimale Spezifikation und einen Zeitplan für das kommende Projekt zu schreiben.

Holen Sie bessere Leute ins Team. Versuchen Sie sich bei Ausschreibungen und Bewerbungsgesprächen zu beteiligen und kümmern Sie sich darum, dass gute Bewerber ins Team kommen.

Finden Sie die Leute, die willens und fähig sind, sich weiter zu entwickeln und ziehen Sie sie auf Ihre Seite. Auch in schlechten Teams werden Sie wahrscheinlich ein paar kluge Köpfe finden, die einfach noch nicht die Erfahrung haben um tollen Code zu schreiben. Helfen Sie Ihnen weiter. Versetzen Sie sie in die Lage, sich weiterzubilden. Schauen Sie sich an, welchen Code sie einchecken. Wenn sie etwas Dummes machen, schicken Sie ihnen nicht eine überhebliche Mail, in der Sie erklären, was sie alles falsch gemacht haben. Das macht sie nur ärgerlich und treibt sie in die Defensive. Stattdessen melden Sie einfach ganz unschuldig den Bug, von dem Sie wissen, dass er kommen wird. Lassen Sie sie herausfinden, was die Ursache ist. Wenn sie den Fehler selbst herausfinden, werden sie die Lektion wesentlich besser behalten.

Strategie 4 Schalten Sie die Deppen aus

Selbst in den besten Teams gibt es ein oder zwei Deppen. Das frustrierende dabei, schlechte Programmierer im Team zu haben ist, wenn deren schlechter Code Ihren guten Code kaputtmacht, oder wenn gute Programmierer ihre Zeit damit verschwenden müssen, hinter den schlechten Programmierern aufzuräumen.

Als Programmierknecht, ist Ihr Ziel die Schadensbegrenzung, auch "Kapselung" genannt. Irgendwann wird eines dieser Genies nach zwei Wochen arbeit ein Stück Code verzapft haben, das so unglaublich schlecht ist, dass es niemals funktionieren kann. Man ist dann versucht, die Viertelstunde dranzuhängen, die es einen kosten würde das Ganze von Grund auf neu zu schreiben. Widerstehen Sie der Versuchung. Sie haben die perfekte Gelegenheit, solche Schwachköpfe für mehrere Monate kalt zu stellen. Melden Sie einfach fortwährend die Bugs, die sie in deren Code gefunden haben. Die haben dann keine andere Wahl, als für Monate einen nach dem anderen niederzukämpfen, bis Sie keine weiteren Bugs mehr finden. In diesen Monaten können sie jedenfalls nirgendwo anders einen Schaden anrichten.

Strategie 5  Halten Sie sich von Ablenkungen fern

Alle guten Arbeitsumfelder sind ähnlich (Einzelbüros, ruhige Arbeitsbedingungen, exzellente Tools, wenig Unterbrechungen und noch weniger große Meetings). Alle schlechten Arbeitsumfelder sind hingegen auf ihre ganz spezielle Art ungeeignet.

Die schlechte Nachricht ist: Für fast jede Firma ist es so gut wie unmöglich, an diesen Arbeitsbedingungen etwas zu ändern. Langfristige Mietverträge können dazu führen, dass selbst dem Hauptgeschäftsführer die Hände gebunden sind. Deswegen kriegen so wenig Softwareentwickler eigene Büros. Dies schadet den Firmen auf zumindest zwei Arten. Erstens: es wird schwieriger, erstklassige Programmierer anzuwerben, denn die würden es in jedem Fall vorziehen, bei einer anderen Firma zu arbeiten, die ihnen eine nettere Umgebung bieten kann (wenn alles andere gleich ist). Zweitens: Die Vielzahl der Unterbrechungen kann die Produktivität der Entwickler dramatisch reduzieren, weil es ihnen dadurch einfach unmöglich gemacht wird, in die "Zone" zu kommen und dort auch einige Zeit zu verweilen.

Suchen Sie nach Möglichkeiten, aus einer solchen Umgebung herauszukommen. Nehmen Sie einen Laptop mit in die Cafeteria, wo es viele Tische gibt, die die meiste Zeit des Tages leer sind (und niemand wird Sie hier finden). Buchen Sie einen Besprechungsraum für den ganzen Tag und schreiben Sie dort ihren Code und belegen Sie anhand der Anzahl Ihrer Checkins wie viel mehr Arbeit Sie erledigen können, wenn sie alleine in einem Raum sind. Wenn es das nächste Mal eng wird und der Manager Sie fragt, was Sie brauchen, um etwas in einem Tag hinzukriegen, dann wissen Sie, was Sie zu sagen haben. Man wird dann für einen Tag ein eigenes Büro für Sie finden. Und sehr schnell wird man sich fragen, was man tun kann, um diese hohe Produktivität ein ganzes Jahr über aufrecht zu erhalten.

Kommen Sie spät auf die Arbeit und bleiben Sie lange. Diese Stunden nachdem der Rest der Firma nach Hause gegangen ist können die produktivsten sein. Oder wenn Sie in einem Team von Entwicklern sind, die üblicherweise spät kommen, dann fangen Sie um 9 Uhr früh an. In den zwei Stunden, bevor die anderen Leute kommen und Sie stören, werden Sie mehr Arbeit erledigt bekommen als im ganzen Rest des Tages.

Lassen Sie nicht ihren Mail- oder Instant Messaging-Client laufen. Wenn Sie wollen, können Sie ja jede Stunde einmal ihre Mail checken, aber lassen Sie ihn nicht laufen.

Strategie 6 Machen Sie sich unverzichtbar

Keine dieser Strategien funktioniert, wenn Sie nicht wirklich einen ausgezeichneten Beitrag leisten. Wenn Sie nicht stets guten Code schreiben und zwar viel davon, dann wird man es Ihnen übel nehmen, dass Sie andauernd an Ihrer Bug-Datenbank basteln, obwohl Sie eigentlich Code schreiben sollten. Es gibt nichts tödlicheres für Ihre Karriere, als den Ruf zu haben so sehr mit den Prozessen beschäftigt zu sein, dass man die eigentliche Aufgabe nicht erledigt bekommt.

Einmal, als ich einen neuen Job als kleiner Programmier-Knecht in einer neuen Firma angenommen habe, musste ich feststellen, dass die Firma im Joel Test so irgendwo im Bereich von 2 Punkten rangierte, und ich nahm mir vor, das zu ändern. Aber ich wusste auch, dass es zunächst einmal entscheidend war, einen guten Eindruck zu hinterlassen. Also habe ich die ersten sieben Stunden eines jeden Arbeitstages damit verbracht, einfach nur Code zu schreiben, so wie es von mir erwartet wurde. Es gibt nichts, was einen vor dem Rest des Entwicklungsteams besser dastehen lässt, als ein Schwarm von Checkins. Aber jeden Nachmittag, bevor ich heim ging, habe ich eine Stunde nur dafür reserviert, den Prozess zu optimieren. Ich nutzte diese Zeit, um alles zu beseitigen, was es erschwerte, unser Produkt zu debuggen. Ich setzte einen Daily-Build-Server und eine Bug-Datenbank auf. Ich beseitigte alle seit längerer Zeit bestehenden Störungen, die uns beim Entwickeln behinderten. Ich schrieb Spezifikationen für die Arbeit, die ich den Tag über machen würde und. Ich verfasste ein Dokument, das Schritt für Schritt den Aufbau eines Entwicklerarbeitsplatzes von Grund auf beschrieb. Ich dokumentierte sorgfältig eine interne Sprache, die bislang undokumentiert war. Langsam wurde der Prozess besser und besser. Niemand außer mir (und dem Team, mit dessen Leitung ich betraut wurde) hat jemals Spezifikationen oder Zeitpläne gemacht und dennoch erreichten wir ungefähr eine 10 beim Joel Test.

Sie können also für Verbesserung sorgen, auch wenn Sie keine Leitungsfunktion innehaben, aber Sie müssen schon Cäsars Frau sein: über jeden Zweifel erhaben. Sonsten schaffen Sie sich Feinde auf dem Weg.



Titel der Originalausgabe: Getting Things Done When You're Only A Grunt  

Joel Spolsky ist der Gründer von Fog Creek Software, einer kleinen Software Firma in New York City. Nachdem er auf der Yale University graduierte arbeitete er als Programmierer und Manager bei Microsoft, Viacom und Juno.


Der Inhalt dieser Seiten stellt die persönliche Ansicht des Autors dar.
Copyright ©1999-2005  Joel Spolsky. Die Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky