28. November 2013 - Pascal Szewczyk

Schlechtes Projekt-Setup? Dann lieber ohne mich.

Ich wurde gefragt, ob ich kurzfristig Zeit habe, in einem Webdesign-Projekt mit einzuspringen. Hatte ich. Es war Freitag, Montag sollte es schon losgehen. Ein Online-Shop.

Am Montag, früher Nachmittag, erfuhr ich, dass der Shop nächste Woche Mittwoch live gehen sollte. Knapper Zeitplan.

Ich bekam also einen Haufen Dateien 122 Stück. Photoshop, Videos, Feinkonzept, PDF… ein undurchschaubarer Haufen. 1,3 Gigabyte feinster unstrukturierter Datenmüll.

Super grinsendes Stockfoto mit Daumen nach oben!

Meine erste Frage:

"Wie strukturiert ihr bisher eure Arbeit?"

Große Fragezeichen. Keine zielführende Antwort. Gibt es ein Versionierungssystem? Git? Von mir aus auch SVN? Ich hab auch schon mit Mercurial gearbeitet. Irgendwas? Wieder große Fragezeichen. Der einzige bisherige Entwickler arbeitete per FTP auf seinem vServer bei Hosteurope ohne Versionierung.

Darüber hinaus wurde zur Bug-Aufzeichnung Excel eingesetzt. Damit wurden Excel-Listen hin- und hergeschoben.

Der typische Prozess, der eintrifft, wenn sich keiner Gedanken über den Prozess macht und der sich zunehmend verschärft, je mehr der Release-Termin näher rückt.

Mir würde ein FTP-Zugang zur Verfügung gestellt, da könnte ich ja dann mit rein arbeiten.

Mit dem Blick von außen gibt es nur eine einzige Antwort.

"Das kannste schon so machen, aber dann ist es halt kacke."

Ohne mich. Ich bin nicht dabei.

Das Ticketsystem

Ich möchte ein Ticketsystem, welches die Aufgaben zum einen priorisiert, wo man Show-Stopper fixed und Bugs für eine bessere Geschmeidigkeit hinten dran stellt. Keiner beschwert sich über fehlende optimierte Retina-Icons, wenn der Checkout-Prozess im Grunde noch nicht vorhanden ist.

Damit erübrigen sich auch so Zeitfresser in Telefonschalten: "Wie sieht es denn aus, was ist denn noch offen?" Mit der sich Projektmanager gerne eine Berechtigung für ihr Dasein erkaufen.

Fragen über den aktuellen Stand lassen sich damit sehr prima transparent anzeigen. Tickets gibt es zunächst nur zwei. Offene und geschlossene. Offene Tickets sind noch nicht bearbeitet und geschlossene verschwinden aus dem Fokus. Wenn der Fertigungstag näher rückt und im System noch 1000 offene Tickets sind, kann das Projektmanagement gegensteuern. Zum Beispiel mit der Identifizierung von Show-Stoppern oder den Release-Termin verschieben, sollten sich nicht alle Show-Stopper rechtzeitig beheben lassen. Darüber hinaus kann man die Sache noch granularer einstellen. Für Despoten unter den Projektmanagern könnte man noch zu bearbeitende Tickets auf "In Progress" stellen. Außerdem könnte man noch nach Feature und Bug unterteilen und eine Priorisierung einstellen.

Derer gibt es drei mit denen ich bisher gearbeitet habe. Redmine, Jira und Basecamp.

Redmine ist ein webbasiertes Projektmanagement-Tool. Es ist OpenSource und basiert auf Ruby. Es ist kostenlos und damit in der IT-Branche sehr beliebt. Es integriert ein Wiki und viele weitere Sachen. Man kann prima Zeiten auf den Tickets erfassen. Außerdem kann man Dateien hochladen, was unter anderem auch in Telefonschalten gut funktioniert, weil man einen zentralen Ablageplatz für Dateien hat und nicht jeder auf seinem Rechner lokal erst suchen muss, wo er diese abgelegt hat. So kommen auch nicht mehr diese Ausreden zustande, dass man eine E-Mail nicht bekommen hat.

"Oh, nee ich glaube das hast du mir nicht geschickt!"

Redmine kann man übrigens auf einem Uberspace Host installieren. Die Erklärung dafür gibt es hier

Zudem gibt es noch Jira, welches im Enterprise Umfeld häufig eingesetzt wird. Ich habe bisher zweimal mit Jira gearbeitet. Das war auch immer sehr in Ordnung. Kostet ab 10$ im Monat.

Und dann gibt es noch BaseCamp, welches ich noch nie eingesetzt habe. Es deckt aber auch alles ab, für ein vernünftiges Projektmanagement-Setup gebraucht wird. Steht ja auch oben drüber. Es wird über ein Abo-Modell vertrieben. Ab $20 geht es los.

Und für den Einstieg eignet sich oft auch Trello. Ein kostenloses webbasiertes Tool zur Erstellung von Listen mit vielen Personen. Ohne vordefinierten Workflow fängt die Sache aber schnell an nicht mehr zu funktionieren bzw. der Umgang damit wird sehr hemdsärmelig. Aber besser als Excel-Listen ist es allemal.

Das Problem an Excel-Listen ist, dass diese nicht mitwachsen. Es gibt eindeutige Probleme z.B. "Die Schriftgröße von 13px auf 16px" machen. Das kann man schnell abarbeiten und sogar nachmessen, ob das Ticket erledigt wurde. Es gibt aber auch Tickets, die sind nicht eindeutig. "Bitte das neue Layout für die Seite XY verwenden". Welches neue Layout? Und schon verlasse ich mein Excel-Tool und mache einen Medienwechsel. Höchstwahrscheinlich per E-Mail. Es geht zweimal hin und her, vielleicht muss neben dem Projektmanager noch ein Designer hinzugezogen werden, der mir "das neue Layout" erstmal definiert. In der Zwischenzeit habe ich einen Teil der Fehler in der Excel-Liste korrigiert und irgendwann auch das neue Layout eingearbeitet. Währenddessen gab es aber für das Excel-Dokument eine Schleife, wo der Konzepter des Projekts auch noch Bugs eingetragen hat. Wir haben also schon zwei Excel-Listen im Umlauf… das hält nie irgendeiner nach. Excel-Listen für Bug- und Feature-Reports greifen nie. Niemand synchronisiert Excel-Listen, wenn er noch "Das neue Layout" einbauen muss. Excel ist ein optimiertes Tool, zum Berechnen von Aufgaben mit vielen Faktoren. Oder Einkaufszettel.

Versionierung

Ich möchte ein Versionierungssystem, bei dem ich und andere in den große Codetopf reinschreiben können. Ich möchte Code mergen und wenn dabei was kaputt gegangen ist, möchte ich wieder zurückspringen zur letzten lauffähigen Variante.

Würde ich meinen Code auf dem FTP-Server live bearbeiten. Dabei würde ich andere Sachen von weiteren Entwicklern überschreiben. Die würden sich ärgern. Ich würde mich ärgern. Ein optimierterer Arbeitsprozess wäre so maximal pessimiert, dass eine solche Arbeitsweise ökonomisch überhaupt nicht sinnvoll. Es ist absurd, so zu arbeiten.

Wenn ich den Prozess nicht als eigenes zu optimierendes Projekt betrachte, führt es dazu, dass ich immer nur eine schlecht gelaunte Projektmanagement-Person in meinem Rücken habe. Die ohne Rücksicht auf Verluste ihren Druck zu meinem macht. Ohne Beachtung, ob mich das bei meiner Arbeit unterstützt oder nicht. Tut es nicht.

Am besten kann ich arbeiten, wenn ich weiß, was als nächstes und übernächstes für mich zu tun ist. Was als nächstes zu tun ist, muss ich nicht selber entscheiden. Das ist ja der Job vom Projekt-Managament. Ich möchte mich auf meine nächstwichtigste Aufgabe fokussieren und nicht nebenbei Word- und Excel-Listen durch die Gegend schieben und den Überblick zu behalten. Das kann ich nicht, ich muss nämlich programmieren und programmieren ist immer das Lösen von komplexen Problemen. Und nicht das routinierte Excel-Listen synchronisieren.

An idealen Tagen, habe ich 6 Stunden zum programmieren und 2 Stunden für Gedönse. Telefonieren, organisieren, Kaffee trinken, wichtige Artikel im Web lesen… Du weißt schon… Manchmal kann ich auch 12 Stunden programmieren, aber im Durchschnitt sind 6 Stunden sicher realistisch.

Ich habe mir das vorliegende Setup also eine Stunde angehört und versucht, dagegen zu steuern. Was mir schnell auch nur mäßig sinnvoll erschien. Der Release-Termin wurde als nicht verschiebbar und in Stein gemeißelt kommuniziert und für die Optimierung des Prozesses blieb gerade einfach keine Zeit.

Also musste ich das Projekt absagen. Nicht zur Freude der Projektmanagerin, die hatte ja jetzt gedacht mit doppelt so vielen Entwicklern ist man auch doppelt so schnell. Aber auf dieses Setup konnte ich mich nicht einlassen.

Vielleicht hilft der vorliegende Artikel ja, den ein oder anderen anzuregen, mal über sein Prozess-Management nachzudenken.

comments powered by Disqus