IT-Projekt-Management: Die Grundlagen

Hach… Projekt-Management… Der rote Faden in der Entwicklung, an dem man sich festhalten kann, wenn man total verirrt ist.

Was heißt denn hier eigentlich Projekt-Management? Als “fachfremder” Entwickler habe ich schon früh erkannt, dass man nicht einfach so drauf los programmieren kann. Manchmal schon, aber man lernt schnell, dass man Dinge lieber vorher planen sollte (so wie diesen Beitrag *zwinker*), sofern es Sinn macht.

Wie man sein IT-Projekt managed (und damit meine ich in diesem Fall Software-Entwicklung), hängt sehr stark von den eigenen Präferenzen und dem Team ab. Sicher, es gibt viele Standards und Methoden, aber jetzt soll es erstmal um die Grundlagen gehen: Warum brauche ich das eigentlich?

Warum brauche ich das eigentlich?

Stelle dir vor, du willst dein Auto reparieren. Das ist eine totale Schrottkarre, weil es die günstig im Realprospekt gab. An jeder Stelle ist eine Macke und der Wagen springt nicht mal an. Macht es dann Sinn, sich um den Lack zu kümmern?

Klüger wäre es, eine Liste mit Dingen zu machen, die man erledigen muss und diese dann zu sortieren. So kann man den Wagen dann wenigstens nutzen, um zum nächsten Real zu fahren und einen Felsenreiniger und chinesische Würzpaste zu besorgen!

Genau das macht Projekt-Management im Kern aus: Einen Plan vor Augen haben, oder wenigstens die Richtung zu kennen, in die man sich bewegen möchte.

Wie fange ich damit an?

Projekt-Management ist keine Frage der Software oder der Methode, sondern der Disziplin. Je mehr man sich Zeit gibt, die Dinge zu notieren, umso einfacher hat man es später.

Dabei ist es egal, ob man Redmine, Jira, ein Whiteboard oder einen Haufen gelber Zettel nutzt – hauptsache, man gewöhnt sich eine Routine an, findet seinen eigenen Stil und überlegt sich dann, wie man diese Methodik durch Software verbessern kann.

Also: Wenn man anfängt, reicht ein weißes Blatt Papier. Darauf notiert man jede Kleinigkeit, die man erledigen möchte. Nach der ersten Zeile hat man allerdings einen Schreibkrampf, weil “man schreibt doch nur in der Grundschule mit der Hand”. Also überlegt man sich, diese Liste in eine Text-Datei zu packen. Oder man macht ein Trello-Board:

Solche Boards sind einfache Listen – in diesem Fall bestehend aus “Todo” und “Done” – wobei man letztere gar nicht brauchen würde, es aber ein schönes haptisches Gefühl ist, wenn man etwas erledigt hat.

Fang also damit an, dich zu disziplinieren und jede Kleinigkeit und Anmerkung zu notieren, du wirst es später brauchen.

Methoden des Projekt-Managements

Hui, jetzt lehne ich mich aus dem Fenster. Aber hier geht es hauptsächlich um die eigene Erfahrung und wie man seine Projekt-Management-Skills auf die richtige Spur bringt.

Welche Methoden man anwendet, hängt stark davon ab, wie groß dein Team ist. Machst du es selber, musst du dich nur vor dem Spiegel rechtfertigen. Gibt es aber mehr Leute im Team, fällt es auf, wenn man keine Ahnung vom Projekt hat. Was braucht man also?

• Für eine Person: Da reicht eigentlich eine Textdatei.
• Bis zu vier Personen: Einfache Boardverwaltung, d.h. ein Ticketsystem mit “Workflow”
• Darüber hinaus: Scrum, Kanban, etc. inkl. zugehöriger Software

Hier geht es allerdings eher um die ersten beiden, so wie sie bei einem kleinen Start-Up zu finden sind. Zeit ist dann immer knapp und derjenige, der alle Küken im Nest hält, muss selbst einiges an Output liefern und hat wenig Zeit, sich mit Projekt-Management zu beschäftigen.

Ein Workflow aus Erfahrung

Hat man nur ein kleines Team, reicht eine Software aus, mit der man Tickets verwalten kann. Gute Open-Source-Lösungen sind z.B.:

• Redmine
• OpenProject

Im Prinzip ist es ein Glaubenskrieg – mag man eher PHP, ist das letztere die bessere Wahl. Von der Redmine-Homepage sollte man sich nicht irritieren lassen – das Design ist schrecklich, aber es funktioniert.

Bei allen diesen Systemen lassen sich Tickets erstellen. Das sind Posts mit übergeordneten oder abgekapselten Aufgaben, die man erledigen kann. Im Fall von unterricht.cloud ist das z.B:

• Passwort-Reset-Funktion
• Icon bei Button “Meeting erstellen”
• Chat über Mercure verbinden

Alles Dinge, die kleinen bis großen Aufwand bedeuten. Sinn macht es natürlich, Untertickets zu erstellen, um die großen Aufgaben in kleine Happen zu unterteilen.

Jedes dieser Tickets hat einen Status, der angibt… naja, welchen Status es gerade hat. Ein Ticket kann z.B. “offen”, “geschlossen” oder “problematisch” sein. Ein Workflow ist dann eine Abfolge von verschiedenen Status.

Beispiel aus der Praxis – diese Status kann man gut als Startpunkt nutzen:

• Neu: Das Ticket wurde von jemandem erstellt zur weiteren Bearbeitung.
• Zugewiesen: Das Ticket wurde einem Entwickler zur Bearbeitung zugewiesen.
• In Bearbeitung: Der Entwickler arbeitet am Problem.
• QA: Technik: Ein anderer Entwickler kann die Lösung überprüfen.
• QA: Funktion: Ein Nicht-Entwickler testet die Funktion.
• Problem vorhanden: Der Entwickler muss nacharbeiten.
• Geschlossen: Ticket erledigt!

Ein Ticket durchläuft diesen “Life-Cycle” so oft, bis es geschlossen wird. Je nach Team und Arbeitsweise gibt es unendlich viele Möglichkeiten, das System anzupassen!

Aber Achtung: Man kann sich im Optimieren von Workflows so verlieren, dass gar keine Tasks mehr erledigt werden. Ist das Team sehr viel größer, ist man sowieso den ganzen Tag damit beschäftigt.

Die großen Vorteile

Jedes Ticket hat natürlich eine Kommentarfunktion. Je öfter und ausgiebiger man diese nutzt, desto weniger Probleme hat man später, wenn man einen Fehler sucht oder den Schuldigen finden möchte, um diesen zu mit Elektrostößen zu bestrafen.

Fazit

Projekt-Management bedeutet Disziplin. Je mehr man davon hat, desto kleiner ist die Gefahr sich zu verzetteln. Dabei ist erstmal gar nicht entscheidend, welche Software oder Methode man anwendet – wichtig ist, überhaupt erst einmal anzufangen und sich an den Workflow zu gewöhnen. Es lohnt sich!

PS: Wenn man Post-Its benutzt, darf man sich natürlich verzetteln.