Wenn es brennt oder bei einem schweren Unfall rufen wir die
„Rettungskräfte“: Profis wie Feuerwehrleute, Sanitäter, Notärzte und
Polizisten, die für solche Situationen ausgebildet sind und wissen, was zu tun
ist. Wenn es in Ihrem Software-Projekt soweit gekommen ist, dass Sie externe,
professionelle Retter in Anspruch nehmen müssen: mein Beileid. Dann ist es eher
fünf nach als fünf vor Zwölf.
Retten sollte also früher beginnen, zum Beispiel:
Im Angebot sind das geplante, iterative Vorgehen und die
dafür notwendigen, zeitnahen und arbeitsintensiven Abnahmen durch den Kunden
nicht dargestellt. Wer ist dafür zuständig? Ihr Vertriebler? Der
Geschäftsführer? Weiß er, dass Sie glauben, dass er zuständig sei? Weiß er, was
Sie benötigen?
Die Design-Agentur hat Ihr Kunde ausgewählt, die
„Pixelschubser“ liefern ja auch nur zu – das aber mal wieder zu spät. Klar, im Vertragswerk
ist schön abgegrenzt, wer für was zuständig ist. Also kümmern Sie sich nicht
drum, richtig? Und der Kunde muss schließlich selbst seine Dienstleister
steuern! Kann er das? In wie weit ist Ihr Erfolg abhängig davon, dass am Ende
wirklich etwas bei dem Projekt herauskommt?
Sie sind Entwickler und kommen spontan als Unterstützung in
das hippe Web-Projekt: man braucht nämlich mal eben einen Java-Profi, der die Daten
von der Web-Anwendung in das Buchungssystem in SAP bringen kann, und mit Java
ist der SAP-Zugriff ja technisch eher einfach. Alle sind gut drauf – nur Sie
haben so etwas schon mal gemacht: mit viel mehr Aufwand als den zehn geplanten
Tagen, weil die Fachlichkeit nicht geklärt war. Eskalieren Sie – und sind der
Spielverderber?
Sie wundern sich, dass in Ihrem neuen Projekt der
Projektleiter die Aufgaben kleinteilig vorgibt, bis hin zur Struktur der Entity
Beans der Persistenzschicht. Sie haben das ungute Bauchgefühl, dass die
Schnittstellen zwischen den Komponenten nur durch den Projektleiter geprüft
wurden. Die Entwickler untereinander reden auch nicht miteinander, man arbeitet
vor sich hin. Ob das gut geht?
Die Rettung des Projektes sind: Sie selbst! Fühlen Sie sich in professioneller Verantwortung
zuständig – unabhängig von der Rolle im Projekt. Vermeiden Sie aber,
sich zu sehr in fremde Verantwortungsbereiche einzumischen und prüfen Sie sich
selbst, ob Sie gerade den „Projektkümmerer“ darstellen.
Reden ist immer nützlich in Krisensituationen, einerseits.
Andererseits sagt man: melden macht frei.
Was hilft also?
- Reden Sie mit den
Verantwortlichen, oder mit denen, die Sie dafür halten.
- Erkennen und benennen Sie
Ihre Annahmen explizit: „Ich vermute, dass Sie für die Vertragsgestaltung
zuständig sind, ist das korrekt?“. Versetzen Sie sich mal gedanklich in die Lage des vermeintlich Verantwortlichen - was kann er, was braucht er?
- Bei Gleichgestellten wie
z.B. anderen Projektleitern oder Entwicklern ist es hilfreich, Interesse
und eigene Kompetenz zu demonstrieren. Gedankenaustausch und
unverbindliche Gespräche nehmen viele Menschen eher an als gute
Ratschläge.
- Überlegen Sie sich
Lösungsvorschläge, vor allem Manager lieben es, aus Alternativen
auszuwählen: das verringert ihre Arbeitslast. Wenn Sie dafür nicht
genügend Hintergrundwissen haben, schlagen Sie Experten vor, die an
der Lösungsfindung mitwirken
können.
- Zeigen Sie Konsequenzen
auf, möglichst mit ganz konkreten Auswirkungen oder Beispielen aus
Projekten: „Die SAP-Integration hat damals das zwanzigfache gekostet, weil
wir die fachlichen Prozesse auch noch klären mussten“.
- Manchmal hilft so gar
nichts und man will nicht immer als „Meckerfritze“ darstehen. Dann geht
nur noch: vermerken. Schriftlich – heute normalerweise als e-Mail – mit
einer Zusammenfassung, etwa nach einem Gespräch zu dem Thema. Das rettet
nicht das Projekt, hilft aber den professionellen Rettern, wenn’s denn
gekracht hat.
Auch als Entwickler unter einem mitunter nicht
interessierten Projektleiter hat man Möglichkeiten: so kann man sich aus den
agilen Methoden einfache Maßnahmen abschauen:
- Stand Up Meetings: maximal
15 Minuten, nur das Team, jeder erzählt, was er getan hat, was er tun wird
und was ihn behindert. Hilft bei Informationsflut und schwacher
Projektorganisation.
- Gegenseitige Code-Reviews:
aufwändig, zugegeben, aber effektiv. Alle Beteiligten müssen dann aber
auch lernen wollen!
- Kundenfeedback: auf
Termine mit dem Kunden drängen – Feedback einsammeln.
- Ziele klären: Ziele kann
man nur erreichen, wenn sie glasklar sind. Dazu gehört auch, die Ziele zu
verstehen, sie zu hinterfragen und Risiken zu benennen.
- Überschaubare Schritte:
Der Projektleiter will Sie erst in vier Wochen wiedersehen? Setzen Sie
sich im Team Wochenziele!
Eigenverantwortung kann viel bewirken - suchen und nutzen Sie die Ansatzpunkte!
Keine Kommentare:
Kommentar veröffentlichen
Kommentare? Erwünscht!
Aus rechtlichen Gründen werden Kommentare moderiert...
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.