Analyst, geh aus Deiner Höhle raus!

Vonadmin

Analyst, geh aus Deiner Höhle raus!

Wenn ich die Analyse-Ergebnisse manch studierter IT-Berater ansehe, muss ich dabei oft an Platons Höhlengleichnis denken. Scheinbar sieht der Analyst nur das, was man ihm auf leichtem Weg zu sehen gibt. Und das ist – wie bei Platons Gefangenen in der Höhle, nur ein Schatten der Wirklichkeit. Wie könnte nun der Business-Analyst seine Fesseln ablegen und die Wahrheit erkennen, die sich hinter dem scheinbar wirren Geschwafel seiner Kunden versteckt? Hier ein paar Tipps, um bei der Anforderungsanalyse ans Licht zu gelangen.

Wiederhole in anderen Worten

Egal was Dein Kunde sagt, wiederhole es in eigenen Worten und zumindest zwei verschiedenen Varianten. Wenn bei der ersten Wiederholung noch alle nicken, sind spätestens bei der zweiten Wiederholung unterschiedliche Meinungen anzufinden. Frag nach, ob es denn wirklich so ist, oder biete zwei unterschiedliche Varianten an.

Verstehe die Tätigkeiten deiner Kunden

Am besten schaue jedem einzelnen Mitarbeiter über die Schultern und lass Dir erklären, was er genau macht und wozu. Erst wenn Du die Arbeit verstehst, kannst Du den Prozess verstehen und weisst, wo der Schuh drückt. Mit dieser Grundlage können wirkliche Verbesserungen erzielt werden.

Schließe das Gegenteil aus

Wenn Dein Kunde etwas sagt, skizziere Du das Gegenteil und frage, ob dies garantiert ausgeschlossen werden könne. Dadurch relativiert sich oft das gesagte, und man erkennt dann, dass man oft nur über einen Spezialfall spricht. Eine gute Software-Lösung müsste dann aber wohl auch andere Dinge abbilden können. Ein Beispiel aus meiner letzten Analyse: Kunde sagt: wir haben drei Ebenen zur Verwaltung festgelegt: Thema, Modul und Submodul. Ich sage: „Also Sie können garantiert ausschließen, dass später nicht noch eine Ebene zwischen Thema und Modul dazukommt?“ – Schon am nächsten Tag kam mein Kunde mit einer neuen Ebene, allerdings zwischen Modul und Submodul 😉

Zähle Gemeinsamkeiten zwischen einzelnen Teilbereichen auf

Wenn Du mal erkannt hast, welche Gemeinsamkeiten einzelne Software-Bereiche haben, wird die Entwicklung mit einem generischen Ansatz viel einfacher und kürzer sein. Dazu musst Du aber zuerst Deinen Kunden mit lästigen Fragen quälen, in der Art: „Also Thema, Modul und Submodul können gespeichert, bearbeitet, verschoben oder gelöscht werden. Ist das bei allen drei Ebenen gleich, oder müssen z.B. Submodule anders behandelt werden als ein Thema?“

Zeige ähnliche Anwendungen

Mockups sind gut, aber oft ist es nötig, deinem Kunden in einer anderen Anwendung etwas herumklicken zu lassen, um ein Gespür für die Abläufe zu bekommen. Dies kannst Du in Demo-Varianten von verschiedenen Open Source Lösungen z.B. sehr einfach bewerkstelligen. Ich zeige meinen Kunden z.B. den Seitenbaum in Typo3, die Tag-Cloud von WordPress oder die Startseite von SugarCRM. So bekommt der Kunde einen Blick für das, was möglich ist, und wo er meistens noch nicht einmal daran gedacht hat.

Bau nicht alles, was Dein Kunde sagt, als Regel in Dein Programm ein

Denk daran, Du siehst nur einen Schatten auf der Wand, wenn Du die Worte Deines Kunden hörst. Dies ist eine flachgedrückte, Schwarz-Weiß-Abbildung einer 3D-Realität. Dein Modell sollte offen sein für künftige Änderungen dieser Realität. Und sei es nur, dass Die Sonne Deinen Kunden mal von vorne beleuchtet, und nicht mehr von hinten. Um die Wünsche des Kunden doch zu erfüllen, baue einen Schalter, mit dem Du das dann später wieder einfach ab- oder umschalten kannst 😉

Verifiziere, indem Du möglichst alle Varianten durchspielst

Auch wenn Du glaubst, du hast den Algorithmus begriffen, denn das Programm braucht, Du erklärst ihm Deinem Kunden, und er nickt dazu: das heißt noch nicht, dass Du das verstanden hast, was Dein Kunde will. Ich hatte erst unlängst die folgende Situation: Mein Kunde schickte mir eine Excel-Tabelle mit 23 Regeln, aufgeteilt in zwei Gruppen. Ich sagte: zuerst prüfe ich Gruppe A, dann unter bestimmten Umständen  Gruppe B, Kunde nickte.  Das Ergebnis war aber in seinen Augen falsch. Nach einer kurzen Analyse erkannte ich, dass mein Kunde zuerst die zweite Gruppe prüfen wollte, und wenn da kein Treffer war, die erste Gruppe. Dieses Problem hätten wir durch durchgehen verschiedener Kombinationen in der Analyse-Phase verhindern können.

 

Über den Autor

admin administrator