Startseite > Hardware > IT-Spezifikation: Weniger schreiben, mehr kommunizieren

Gastbeitrag:

IT-Spezifikation: Weniger schreiben, mehr kommunizieren

17. Dezember 2009, 5:29 Uhr |

Fortsetzung des Artikels von Teil 1

Kleiner planen

Oft kennen sich zu Beginn des Spezifizierungsprozesses die Fachleute und die IT-ler noch nicht. Sie müssen sich erst finden und eine gemeinsame Sprache entwickeln, um Missverständnisse zu vermeiden. Das Grundprinzip, um Vertrauen zu schaffen, lautet: Klein anfangen und rasche Erfolge erzielen. Der Vorteil eines »langsamen« Starts ist: Die Arbeitsprozesse zwischen Fachabteilung und IT-Lieferant können sich einspielen. Und beiden Seiten lernen die Bedürfnisse und Denkweise der jeweils anderen kennen. Das ist eine Grundvoraussetzung für Vertrauen.

Planen Sie deshalb nicht zu groß. Fangen Sie mit einer relativ kleinen Funktionalität an. Diese sollte jedoch keine Spielwiese sein, sondern eine Funktionalität, die bereits erkennbar zu einer Verbesserung der Arbeitsprozesse beiträgt. Das kann so etwas wie die automatische Daten-übernahme zwischen zwei Systemen sein, sodass niemand mehr die Daten manuell eingeben muss. Versuchen Sie den Funktionsumfang so klein zu halten, dass zwischen dem Beginn der Spezifikation und der fertigen Implementierung maximal vier bis acht Wochen vergehen.

Gewinnen Sie den Überblick – gemeinsam

»It's all about Scope.« In IT-Projekten dreht sich fast alles um die Frage: Was sollte das System können, und was nicht? Denn was nützt den Beteiligten das modernste IT-System, wenn darin wichtige Funktionen fehlen? Doch welches sind die wichtigen Funktionalitäten? Und welche blähen das System unnötig auf? Und welches sind Nice-to-have-Funktionen, auf die man eventuell verzichten kann?

Sich hierüber (vorläufig) zu verständigen, fällt oft leichter, wenn man bedenkt: Der Scope, also der Inhalt und Umfang von komplexen IT-Projekten, verändert sich in deren Verlauf stets – zum Beispiel weil sich Rahmenbedingungen wandeln. Oder weil dem Anwender erst im Verlauf des Entwicklungsprozesses (oder bei den Funktionalitätstests) klar wird, was zum Beispiel aufgrund der Arbeitsprozesse wirklich wichtig ist. Deshalb macht es wenig Sinn, vorab 100-seitige Spezifikationsdokumente zu schreiben, die sich in allen Details verlieren. Sinnvoller ist es, das Dokument im Verlauf des Projekts immer weiter zu konkretisieren und dieses fortlaufend zu aktualisieren.