Projektmanagement in der Softwareentwicklung

Ein Softwareprojekt hat zwei Merkmale, die es schwer steuerbar machen: Die Arbeit ist unsichtbar (niemand sieht ein Modul vorankommen, bis es gezeigt wird) und der Umfang bewegt sich (was der Kunde zu Beginn im Kopf hat, ist nicht das, was er beim Anblick der ersten Version will). Gut steuern heißt dreierlei: ein Phasenplan, den Team und Kunde verstehen, ein Arbeitsboard, das den Status jedes Teils sichtbar macht, und eine Kontrolle von Stunden und Änderungen, die nicht vom Gedächtnis abhängt.

Die Phasen eines Softwareprojekts

PjMan bringt eine Projektvorlage „Softwareentwicklung“ mit sechs Phasen mit:

1. Discovery: das Problem, die Nutzer und den Umfang verstehen, bevor etwas gebaut wird.
2. Design: entscheiden, wie die Lösung aussehen soll, von der Architektur bis zur Nutzererfahrung.
3. Entwicklung: das Produkt bauen, meist in Inkrementen.
4. Tests: prüfen, dass es funktioniert und das Vereinbarte leistet.
5. Deployment: in die Produktion bringen.
6. Support: warten, korrigieren und Service leisten, sobald es genutzt wird.

Beim Anlegen des Projekts wählen Sie die Vorlage, und ihre Phasen werden ins Projekt kopiert, mit ihrem Code (F001, F002 …). Es sind unabhängige Kopien: Sie können sie umbenennen, umordnen, weitere ergänzen (zum Beispiel eine Phase je Release oder Modul) oder nicht benötigte löschen, und jede Phase nimmt Unterphasen bis zu drei Ebenen auf. Ändern Sie die Vorlage später, bleiben bereits angelegte Projekte unberührt. (Projekt anlegen, Stammdaten und Kataloge)

Arbeiten Sie in Iterationen, ist die Vorlage nur ein Ausgangspunkt: Sie können eine Phase je Iteration anlegen und Ihre eigene Abfolge in einer eigenen Vorlage wiederholen.

Was oft schiefgeht

• Der Umfang wächst, ohne dass jemand es entscheidet. Jedes „Könnten wir noch … ergänzen?“ wirkt klein; zusammen verzögern sie die Lieferung.
• Schätzungen sind optimistisch. Und Abweichungen zeigen sich am Ende, wenn kein Spielraum mehr bleibt.
• Fehler vermischen sich mit Verbesserungen. Ein blockierender Fehler und eine Idee für später landen in derselben Liste.
• Arbeit bleibt unbemerkt hängen. Eine Aufgabe, die drei Wochen „in Bearbeitung“ ist, ist ein Signal, das in einer flachen Liste niemand sieht.
• Entscheidungen gehen in Chats verloren. Was vereinbart wurde und warum, versinkt.
• Der Support frisst das Team auf, das das Nächste bauen sollte.

So hilft PjMan

• Ein Kanban-Board der Aufgaben. Jede Spalte ist ein Status, jede Karte eine Aufgabe, mit Priorität, Phase, Fälligkeit, Fortschritt, Stunden und Zuständigen. Eine Karte zu ziehen ändert ihren Status, mit Rückgängig-Option, und Sie können nach Phase, Person, Priorität oder Labels filtern. (Kanban-Boards, Kanban und Gantt)
• Labels je Projekt. Markieren Sie Aufgaben und Probleme mit dem, was Sie brauchen (ein Modul, ein Release, „Kundenprüfung“), und filtern Sie danach in den Boards und in den Abfragen. (Labels)
• Stunden je Phase und Abweichung. Jede Aufgabe trägt geschätzte Stunden, das Team erfasst seine, und jede Phase zeigt erfasst gegen geschätzt; der Projektkopf gibt die Gesamtabweichung an. Der Fortschritt wird nach Stunden gewichtet. (Ratgeber zur Zeiterfassung)
• Probleme getrennt von Aufgaben. Fehler werden als Probleme erfasst, mit Schweregrad und Priorität als getrennten Achsen, Zuständigen, Stunden und konfigurierbaren Status; sie haben ein eigenes Kanban-Board. (Probleme)
• Änderungsanträge. Jede Bitte außerhalb des Umfangs wird mit geschätztem Aufwand und Entscheidung erfasst, statt stillschweigend aufgefangen zu werden. (Änderungsanträge)
• Kommentare mit Erwähnungen. Jede Aufgabe, Phase und jedes Problem hat einen eigenen Verlauf, in dem @ innerhalb der Anwendung benachrichtigt, wer diese Detailansicht sehen kann. Kommentare sind ein Verlauf: Sie werden weder bearbeitet noch gelöscht. (Kommentare und Erwähnungen)
• Plan und Arbeit. Das Gantt-Diagramm der Phasen (nur lesend) und das Kanban-Board, auf denselben Daten.
• Assistent. Aufgaben anlegen, Stunden erfassen oder Status ändern per Sprache oder Text, mit Bestätigungskarte, und eine Analyse des Projektstatus. Er antwortet mit dem kostenlosen Modell oder mit Ihrem eigenen Schlüssel.
• Jede Rolle sieht das Ihre. Der PM steuert das Projekt, die Leitung sieht das Portfolio lesend, und jeder Entwickler sieht seine Aufgaben.

Ein Ausgangspunkt, keine Gussform

Ein Team mit Sprints, eines mit Lieferung in Releases und eines, das ein Produkt betreut, organisieren ihre Arbeit nicht gleich. Passen Sie die Phasen an Ihre Art zu liefern an, legen Sie eine eigene Vorlage an, wenn Sie dasselbe Schema wiederholen, und denken Sie ans Wesentliche: wenige Phasen, schätzbare Aufgaben und ein Board, das aktuell gehalten wird. Der Ratgeber Projekt in Phasen und Unterphasen gliedern gibt praktische Kriterien dafür.

Probieren Sie es aus

Erstellen Sie Ihr Konto, legen Sie ein Projekt mit der Vorlage „Softwareentwicklung“ an und bringen Sie Ihre ersten Aufgaben aufs Board. Oder entdecken Sie die Demo mit Beispielprojekten.