Umgang mit Spezifikationsänderungen

In Softwareprojekten kommt es immer wieder zu Änderungen von Anforderungen. Dies sind zum Teil kleine Anpassungen und Erweiterungen, manchmal aber auch grössere Umstellungen. Dies erlebe ich einerseits direkt in eigenen Projekten und sehe es andererseits auch ständig bei den Projekten der Kollegen. Dabei sind sowohl meine als auch die allgemeinen Reaktionen oftmals gleich. Und auch Sie haben sicher schon solche oder ähnlich lautende Aussagen gehört nachdem es Änderungen der Spezifikationen gegeben hat:

  • „Jetzt muss ich schon wieder den kompletten Quellcode der letzten zwei Wochen verwerfen und alles neu machen.“
  • „Der Projektleiter ist unfähig. Warum fällt ihm erst jetzt auf das wir dies anders lösen sollen.“
  • „Mit den ständigen Anforderungsänderungen gefährdet der Projektleiter das Projekt.“

 
Diese Reaktionen sind völlig verständlich. Wer verwirft schon gern seine bisherige Arbeit oder ändert mit Freude ständig den Kurs? Sicher niemand! Sie haben diese Situationen sicherlich auch schon erlebt. Aber haben Sie sich schon jemals die Zeit genommen und sich gefragt warum der Projektleiter ständig mit Änderungen zu Ihnen kommt? Oder nehmen Sie diese einfach als gegeben hin. Sind die Änderungen nötig oder ist der Projektleiter nicht kompetent genug sein Projekt zu steuern?

 
Sicher, es gibt Projektleiter die zu wenig vorrausschauend Planen oder die ihr Vorgehen nach der aktuellen Windrichtung ausrichten, aber dies sind hoffentlich die Ausnahmen. In den meisten Fällen sind Änderungen einfach nötig. Ein Projekt findet immer über einen Zeitraum statt. Die Projektanforderungen und damit die Softwarespezifikationen entstehen mit den Bedingungen die zu einem bestimmten Zeitpunkt herrschen. Im Laufe des Projektes ändern sich aber die Umweltbedingungen. Technologien werden durch bessere ersetzt, Konkurrenten kommen auf den Markt, neue Märkte und Kunden werden erschlossen und auch das Projektteam selbst unterliegt Änderungen wie zum Beispiel Personalwechseln.

 
Solche Ereignisse haben auf das Projektziel selbst keinen grossen Einfluss. Ist dies doch der Fall ist es wahrscheinlicher das das Projekt gestoppt und ein neues Projekt mit einem neuen Ziel gestartet werden muss. Das Projektziel bleibt also meist konstant aber der Weg zum Ziel kann sehr stark von diesen Umweltbedingungen beeinflusst werden. Je länger die Laufzeit eines Projektes ist, desto häufiger werden solche Anpassungen an geänderte Umweltbedingungen nötig sein. Aber selbst bei kurzen Zeitspannen sind Eingriffe unvermeidbar.

 
Ein guter Projektleiter erkennt, das sich Umweltbedingen geändert haben und reagiert entsprechend. Um das Projektziel effektiv und effizient erreichen zu können muss der Projektleiter als Steuermann reagieren. Er muss das Ruder übernehmen und sein Schiff nach dem Wind richten. Die oben angesprochene ständige Ausrichtung des Vorgehens anhand der Windrichtung ist somit nicht zwangsweise etwas Negatives sondern kann zum Erreichen der Projektziele sogar zwingend nötig sein.

 
Als Softwareentwickler sollten Sie sich dessen bewusst sein und Änderungen eher positiv gegenüber stehen. Darüber hinaus sollten Sie sogar skeptisch werden wenn sie im Projekt über einen längeren Zeitraum hinweg mit festen Spezifikationen arbeiten. Das ist für Sie zwar augenscheinlich ein angenehmes Arbeiten, aber die Umweltbedingungen ändern sich ständig. Je länger Sie also ohne Anpassungen und Veränderungen an einer Sache arbeiten, umso wahrscheinlicher ist es das sie das Falsche tun. Spätestens bei Erreichen des nächsten grossen Projektmeilenstein kommt das böse Erwachen. Dann nämlich wird erkannt, dass die erstellte Lösung nicht den aktuellen Erfordernissen entspricht. Und statt den Quellcode der letzten zwei Wochen verwerfen zu müssen wird eventuell ihr Arbeitsergebnis der letzten zwei Monate als unbrauchbar eingestuft.

 
Ein Umdenken ist daher erforderlich. Weichen Sie Spezifikationsänderungen oder sonstigen Anpassungen im Projekt nicht aus. Im Gegenteil. Suchen Sie diese bewusst und fordern Sie diese ein.

 
Nicht nur die Softwareentwickler sollten versuchen den Projektleiter zu verstehen, sondern dies gilt natürlich auch umgekehrt. Am Anfang des Artikels habe ich typische Reaktionen der Entwickler aufgezeigt. Ein guter Projektleiter sollte sich bewusst sein, welche abweisenden und zum Teil abwertenden Reaktionen er mit Anforderungsänderungen hervorruft. Diese Anforderungsänderungen gut zu Begründen und dem Projektteam näher zu bringen erfordert ein gewisses Feingefühl, ist aber zwingend nötig. Noch besser ist es, wenn der Projektleiter umgekehrt vorgeht und dem Projektteam die geänderten Umweltbedingungen präsentiert. Zusammen mit dem Entwicklerteam sollte er dann Lösungsmöglichkeiten finden. Dies führt nicht nur dazu, dass die Entwickler diese Änderungen akzeptieren und im Idealfall sogar als zwingend nötig ansehen, sondern das Projektteam findet eventuell eine Lösung an die der Projektleiter bisher noch gar nicht gedacht hat.

 
Wenn ihr Projektleiter also das nächste Mal in Ihr Büro gestürmt komm und ruft „Wir müssen alles anders machen“, dann beruhigen Sie ihn erst einmal. Fragen Sie gezielt nach warum diese Änderungen nötig sind und welche Umweltbedingungen sich geändert haben. Versuchen Sie dann gemeinsam eine optimale Lösung zu finden. Dieses beidseitige Eingeständnis zum vernünftigen Umgang mit Spezifikationsänderungen wird die Zusammenarbeit im Projekt wesentlich verbessern.

Advertisements
Dieser Beitrag wurde unter Projektleitung abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s