Im ersten Teil der Geschichte schildert der Projektleiter Stefan seiner Frau Probleme aus dem IT-Projektmanagement seiner Firma und bekommt von ihr wichtige Tips: IT-Projektmanagement: Wann Prozesse und Tools nutzlos sind (1)
Lesen Sie nun, was Stefan daraus macht…
Am nächsten Tag fuhr Stefan beschwingt in die Firma. Er machte sich eine Tasse Kaffee und setzte dann ein Meeting mit seinem Entwicklerteam um 10:00 Uhr an. Pünktlich trafen sich alle im Besprechungsraum.
Stefan ließ kurz den Blick in die Runde schweifen. Sein Team bestand aus drei Entwicklern, die zur Zeit für die Software der Videothek ‚Video pur!‘ zuständig waren.
Andreas war ein Seniorentwickler und mehr oder weniger der Kopf der Gruppe. Er war Ende 40 und arbeitete bereits seit über 10 Jahren für die Firma. Aufgrund seiner Erfahrung traf er meistens die kritischen Entscheidungen und wurde auch häufig von den anderen um Rat gebeten.
Boris war Mitte 30 und vor 5 Jahren aus der Ukraine nach Deutschland gekommen. Inzwischen hatte er sich gut eingelebt und arbeitete seit 18 Monaten mit Andreas zusammen.
Natalie hatte gerade ihr Studium beendet und war vor drei Monaten neu ins Team gekommen. Sie schien gut mit den anderen beiden auszukommen und war fleißig dabei, sich in die neue Materie einzuarbeiten.
Stefan räusperte sich:
„Ihr habt sicherlich schon von dem Treffen gestern mit Herrn Krawinger von ‚Video pur!‘ gehört. Na ja, was soll ich sagen: Ich hatte schon entspanntere Meetings.“
Stefan zog eine leichte Grimasse und die Teammitglieder grinsten vorsichtig. Ein bisschen unwohl fühlten sie sich schon, immerhin hatte der Flurfunk schon gemeldet, dass es einigen Ärger gegeben hatte.
„Es geht mir nicht darum, mit dem Finger auf jemanden zu zeigen und zu sagen ‚Du bist Schuld!‘ „, fuhr Stefan fort, „aber ich möchte sehr gerne solche unangenehmen Situationen in Zukunft vermeiden. Schließlich ist das nicht unbedingt ein Aushängeschild für die Firma, wenn wir nicht in der Lage sind, unsere Zusagen einzuhalten.
Gestern hatte ich ein sehr interessantes Gespräch mit meiner ‚häuslichen Beraterin‘ und sie hat mich auf einen wichtigen Punkt hingewiesen: Solange wir nicht die Ursache unserer Probleme verstehen, werden uns neue Softwareentwicklungsprozesse und Tools auch nicht weiterbringen.
Deshalb sitzen wir jetzt hier. Ich möchte gerne mit Euch erarbeiten, wo genau die Defizite bei der Umsetzung der Anforderungen liegen und was wir in Zukunft dagegen machen können. Dazu sollten wir uns vielleicht eine Anforderung vornehmen, welche uns viele Schwierigkeiten bereitet hat.“
„Das ist nicht schwer“, sagte Boris spontan. „Nehmen wir doch einfach den letzten Change Request für die Ergänzung des Erscheinungsjahres des Films. Da haben wir praktisch alles zweimal entwickelt.“
„Mindestens!“, stöhnte Andreas.
„Ok, dann schauen wir uns doch einmal die Beschreibung dafür genau an.“, sagte Stefan. Er öffnete das zugehörige Dokument und projizierte es auf die Leinwand:
„Hmm, sieht eigentlich ganz simpel aus. Inwiefern weicht die jetzige Implementierung von der Beschreibung ab?“, fragte Stefan die Anderen.
„Das Hauptproblem lag darin, dass die Angabe des Erscheinungsjahres allein nicht ausreichend war.“, sagte Boris. Er hatte diesen Change implementiert.
„Es musste auf jeden Fall noch der Monat ergänzt werden. Das hat der Kunde aber erst gesehen, als wir die Entwicklung schon abgeschlossen hatten und es in den Abnahmetest ging.“
„In Ordnung“, sagte Stefan, „hat jemand einen Vorschlag, wie wir den Kunden dazu bringen sich vorher über so etwas Gedanken zu machen?“.
Eine Weile grübelten alle vor sich hin. Dann meinte Andreas: „Ich glaube, wir gehen das Problem von der falschen Seite an. Man braucht ein gewisses Know-How, um eine gute Anforderung schreiben zu können.
In der Software-Analyse geht es darum, zentrale Bestandteile einer Anwendung zu identifizieren und sie zueinander in Beziehung zu setzen. Auch ein Softwareentwickler braucht Zeit und Erfahrung, um das zu lernen. Wir können nicht wirklich erwarten, dass ein Kunde, der ansonsten mit Softwareentwicklung nichts am Hut hat, die nötigen Qualifikationen dafür besitzt.
Nehmen wir als Beispiel das Erscheinungsjahr des Films. Laut Anforderung sollte es bei den Daten für den Ausleihvorgang hinterlegt werden. Mit entsprechend geschultem Blick sehen wir schnell, dass es dort eigentlich nicht hingehört weil das zu Redundanzen führt und dass man es besser bei den Filmdaten speichert. Der Kunde dagegen ist fokussiert auf sein aktuelles Problem und kümmert sich nicht um Redundanzen.
Deshalb denke ich, dass wir selbst dafür verantwortlich sein sollten die Anforderungen zu definieren.“, schloss er. „Natürlich muss der Kunde sein Fachwissen beisteuern, aber wir haben das entsprechende Know-How für die Analyse und wissen, worauf wir achten und wo wir nachhaken müssen.“
Stefan machte sich eine entsprechende Notiz. „Boris, du hast den Change implementiert und weißt am meisten darüber. Hast Du eine Idee, wie man von vornherein erkannt hätte, dass der Monat fehlt? Wonach hätten wir suchen müssen?“.
„Wir müssen nach dem Zweck fragen, nach der ursprünglichen Motivation für den Change.“, antwortete Boris nach einer Weile. „Der Kunde hat uns zwar gesagt, dass er die Information für einen Report benötigt. Aber das ist nicht seine eigentliche Motivation: Niemand entwickelt Reports, weil er so gerne einer Maschine zuguckt wie sie Papier bedruckt.
Der Zweck des Reports bestand darin herauszufinden, wie lange es, vom Erscheinungsdatum an gerechnet, dauert bis ein Film nicht mehr häufig ausgeliehen wird. Daraufhin kann man dann Maßnahmen treffen, z.B. entsprechende Rabatte für selten ausgeliehene Filme oder das Entfernen aus dem Lager. Sobald man diesen Hintergrund kennt, kann man viel besser überprüfen, ob die Vorschläge und Angaben des Kunden sinnvoll sind.“
„Genau!“, ergänzte Andreas, „der Kunde hat uns sozusagen schon seine eigene unvollständige Lösung beschrieben, statt erst einmal zu sagen welches Problem eigentlich gelöst werden soll. Das hat auch etwas damit zu tun, dass in der Anforderungsbeschreibung schon konkret auf Bestandteile der Anwendung Bezug genommen wurde. Man kann den Zweck einer Anforderung leichter erkennen, wenn der Kunde sein Problem beschreibt ohne auf technische Begriffe wie Datenbank, Eingabemaske, Report et cetera zurückzugreifen.
„Ok“, sagte Stefan, „das macht Sinn. Also schlagt ihr vor, dass wir dem Auftraggeber eine Liste mit Richtlinien zur Verfügung stellen, die er für die Beschreibung seiner Anforderungen nutzen soll?“
„Nein, ich glaube das ist keine gute Idee!“, meldete sich Natalie zu Wort. „Ich denke, dass Anforderungen am besten im direkten Gespräch geklärt werden. Deswegen finde ich es sehr wichtig, sich persönlich mit den Fachexperten des Kunden zu treffen. Da können wir sofort jede Unklarheit ansprechen und klären.
Wie Andreas schon sagte, wir haben das Know-How für die Analyse und sollten ein solches Treffen leiten. Wir überlegen uns vorher, welche Informationen wir benötigen, also z.B. Zweck der Anforderung, beteiligte Daten und Formate sowie der
Ablauf der betroffenen Geschäftsprozesse. Und dann erstellen wir daraus ein Dokument und der Kunde genehmigt es.“
Alle waren sich einig, dass dieses Vorgehen Sinn machte. Nach dem Treffen blieb Stefan noch eine Weile sitzen und protokollierte stichwortartig die Ergebnisse des Meetings. Er hatte dabei das gute Gefühl, sich auf dem richtigen Weg zu befinden.
Stefan’s Checkliste für Anforderungen
Den Rest des Tages verbrachte er damit, eine Präsentation über das neue Verfahren zu erstellen, die er in den nächsten Tagen den beteiligten Entscheidungsträgern sowohl in seiner Firma als auch beim Kunden vorführte.
Schon die ersten Erfahrungen mit dem neuen Verfahren waren sehr ermutigend. Die Kunden nahmen es sehr positiv auf, bei der Definition der Anforderungen von Stefan’s Team unterstützt zu werden. Die Aufwandsschätzungen und damit auch das Projektmanagement stabilisierten sich deutlich. Auch wenn es immer noch vorkam, dass größere Fehler in der Anforderungsbeschreibung erst nach der Entwicklung gefunden wurden, nahm deren Häufigkeit sichtbar ab.
Im Laufe der nächsten 12 Monate verfeinerten Stefan und sein Team ihre Methode und erarbeiteten weitere Richtlinien für die Klärung von Anforderungen. Dabei stellten sie fest, dass es nicht nur inhaltliche Probleme zu bewältigen galt: Manchmal waren die Menschen ein viel größeres Problem.
Eine klare und eindeutige Kommunikation zwischen allen Beteiligten wurde zuweilen zu einer echten Herausforderung. Es gab sogar Situationen, in denen Stefan auf die Hilfe eines Kommunikationstrainers zurückgriff, um Konflikte in den Griff zu bekommen und konstruktive Gespräche zu ermöglichen.
Und hier endet die Geschichte – vorläufig. Wenn Sie Interesse an weiteren Erkenntnissen und Techniken zum Klären von Anforderungen haben, finden Sie zusätzliche Informationen im Seminar IT-Projektmanagement: Anforderungen im Griff.
