Benutzerkontakt - Interaktion, Kommunikation und
Fragetechnik
Zusammenfassung
Exkurs: Meetings
Interview
Workshop
Informelle Treffen
Spontane Interaktion
Beobachtung des Endanwenders
Mitarbeit beim Endanwender
Fragebogen und Schriftliche Umfrage
EMail
Telefongespräch
Arbeitspakete
Fragetechniken
Exkurs: Eskalation
Siehe evtl. auch Schwierige Kunden,
Situationen und Menschen, falls Sie eher Informationen zu
unsozialen Verhaltensweisen, stark politisierten Umgebungen oder
mangelhafter Projektunterstützung suchen.
Zusammenfassung
Dargestellt werden zunächst die verschiedenen Möglichkeiten
formeller und informeller Kommunikationsformen zwischen Analytiker und
Fachanwender. Dabei wird auf typische Probleme und Fehler ebenso
eingegangen, wie auf die Vorbereitung und Durchführung der
Kommunikation. In einem einführenden Exkurs wird auf Meetings
eingegangen, wobei Checklisten für Vorbereitung und
Durchführung angeboten werden. Bei den Fragetechniken im zweiten
Teil werden explizite Fragebeispiele für die für eine
Anforderungsanalyse spezifischen kritischen Stellen dargestellt. Ein
Exkurs über Verhörmethoden soll nachdrücklich zeigen,
was bei einer Interaktion zwischen Fachanwender und Business Analyst
nicht erreicht werden soll.
Exkurs: Meetings
Allgemeines
Ein Meeting ist stets ein mehr oder weniger formeller
Kommunikations-Prozess, der in irgend einer Weise dem
Informationsaustausch, der Entscheidungs- oder der Konsensfindung
dient. So beginnt z.B. jedes Projekt mit einem Kickoff-Meeting,
später treffen sich Projektgruppen regelmäßig zu
Status-Meetings, um auf dem Laufenden zu bleiben,
oder ein Dokument wird zum Review vorgelegt und ein zugehöriges
Review-Meeting findet statt.
Über Meetings werden gelegentlich böse Witze gemacht deren
gemeinsamer Hintergrund die fehlende Effektivität ist ("Feeling
lonesome? Nothing to do? Hold a meeting!"). Gibt es im Team oder
Unternehmen keine Regeln und keine Meetingkultur, so kann ein Treffen
eher kontraproduktiv werden. Meetings können missbraucht werden,
um Selbstdarstellung oder Lobbyismus zu betreiben. Ohne
Ergebnisorientierung wird es kein Ergebnis geben, der Unterschied zu
einem Projekt ohne klare Definition von Erfolg und Misserfolg ist
lediglich quantitativer Natur. Bedenkt man die Kosten, die ein Meeting
verursacht, so sollte die Notwendigkeit umfangreicherer längerer
Meetings nachvollziehbar bleiben. Eine
Verzögerung von ca. 15 Minuten kann bei einem Treffen von sechs
bis acht Personen ohne weiteres mit 150.- Euro angesetzt werden, sofern
noch kein Mitarbeiter des Managements dabei ist. Ein erfolgloser
zweitägiger Workshop mit zehn Teilnehmern kann 20000.- Euro kosten.
Bei typischen Projektmeetings ist es guter Stil, wenn jemand die
Moderation übernimmt und die Rolle des Moderators auch aktiv
wahrnimmt. Es ist nicht falsch, ein Meeting nach der allgemeinen
Begrüßung mit den Worten zu beginnen: "Ziel unseres heutigen
Treffen ist es..., wir wollen folgende Ziele erreichen...". Ein
Protokollführer sollte benannt sein, der alle Entscheidungen,
Vereinbarungen (auch verteilte Arbeitspakete), wichtige Aussagen und
Aussagen die auf Wunsch eines Teilnehmers aufgenommen werden sollen,
festhält. Dazu kommen Zuständigkeiten und Termine. Vorlage / Vorschlag für ein
Meetingprotokoll (word)
Im Laufe der letzten Jahre habe ich einige Checklisten, deren Quellen
ich leider verloren habe, meinen Bedürfnissen angepasst, und
verschiedentlich auch durchsehen lassen. Die Checklisten müssen
dem jeweiligen Rahmen angepasst werden, internationale Tagungen haben
andere Anforderungen als kleine firmeninterne Workshops,
Strategie-Meetings andere als Review-Meetings.
Vorbereitung
- Wurde eine Person beauftragt, das Meeting „technisch“
vorzubereiten? (Sekretärin?)
- Wurde ein Raum reserviert? Wurde ggf. beachtet, dass das Meeting
länger als geplant dauern kann?
- Ist der zeitliche Umfang des Meetings klar? Stehen
geplante Zeit und gewünschte Ziele / Beiträge in Relation?
- Ist klar, welche Arbeitsmittel für das Meeting notwendig
sind? Wird ein PC oder ein Projektor benötigt? Sollen
Notizblöcke für die Teilnehmer bereit liegen? Sollen
Unterlagen verteilt werden, wurden genügend Kopien angefertigt?
- Ist der Grund für das Meeting allen Teilnehmern klar?
Herrscht Konsens, welche Ergebnisse am Ende des Meetings herauskommen
sollen?
- Wurde eine schriftliche Agenda rechtzeitig vor dem
Meeting verschickt?
- Wurden alle notwendigen Teilnehmer eingeladen, und
in der Einladung ist Ort und Zeit des Meetings genannt worden? Wurde
ein Anreiseplan verschickt?
- Wurden für auswärtige Teilnehmer Hotels reserviert oder
eine Empfehlungsliste von Hotels verschickt? Ist der Transport vom
Hotel zum Meeting-Ort organisiert?
- Liegt eine Teilnahmebestätigung der Schlüsselteilnehmer
vor?
- Wurden einzelne Teilnehmer auf besondere Aufgaben hingewiesen,
sodass sie sich rechtzeitig vorbereiten können?
- Wurde bei längeren Meetings an Pausen gedacht? Stehen
Erfrischungen bereit? Gibt es Gelegenheit für ein Mittagessen in
entspannter Atmosphäre?
- Fallen Kosten für die Teilnehmer an? Sind sie
informiert?
- Gibt es ein Anmeldeformular? Wurde es den Teilnehmern zugeschickt?
- Gibt es einen Anmeldeschluss für die Teilnehmer?
- Wenn Teilnehmer etwas präsentieren: Gibt es „guidelines“,
z.B. Beschränkungen der Redezeit oder der Arbeitsmittel?
- Sind Namensschilder notwendig? Eine Sitzordnung?
- Wenn Material / Dokumente für das Meeting notwendig sind:
Wurden sie rechtzeitig verteilt?
Agenda
- Nennt die Agenda den Grund und das Ziel des Meetings?
- Bezieht sich das Meeting auf ein vorhergehendes Meeting? Wurden
Protokolle und Ergebnisse hieraus an die Teilnehmer verschickt?
- Welches Grundwissen wird vorausgesetzt? Worüber sollen sich
alle / bestimmte Teilnehmer vorab informieren?
- Werden Diskussionsthemen und zu bearbeitende Aufgaben / Probleme
spezifisch aufgeführt? Sind die Themen auch für alle
Teilnehmer interessant, oder brauchen einzelne Teilnehmer nur zeitweise
anwesend sein?
- Welche Entscheidungen sollen gefällt werden?
- Welche Konsequenzen werden die Entscheidungen haben? Ist klar,
wer von den Entscheidungen betroffen ist? Sind die Interessen dieser
Personengruppen klar?
- Sind die zu diskutierenden Punkte klar priorisiert?
Persönliche
Vorbereitung
- Wurde das Protokoll des/der letzten Meetings gelesen? Wurden
eigene Notizen des letzten Meetings durchgesehen?
- Das letzte Meeting sollte nochmals rekapituliert werden. Was
haben die Teilnehmer letztes Mal gesagt? Gibt es Widersprüche?
- Wurden relevante Punkte mit wichtigen Teilnehmern vorab
besprochen? Wo besteht Konsens, wo Dissens?
- Ist klar, welche Personen „schwergewichtig“ sind, wer Einfluss /
Druck ausüben kann? Wer entscheidungsbefugt ist, wer
wankelmütig, wer desinteressiert?
- Sind die Streitpunkte und gegensätzlichen Standpunkte klar?
Wer vertritt die Standpunkte? Bei demokratischen Entscheidungen: Sind
Parteien / Mehrheiten geformt?
- Wurden spezifische Fragen vorab gelöst? Ist klar, um was es
geht? Ist genügend Know How vorhanden / wurden alle notwendigen
Unterlagen gelesen, um kompetent mitwirken zu können?
Durchführung
- Wurden Rollen und Aufgaben verteilt? Wer ist der Moderator? Wer
Vorsitzender? Wer führt Protokoll?
- Wird die Agenda abgearbeitet? Wird auf die Priorisierung
einzelner Fragen geachtet?
- Wurden „versteckte“ Punkte in der Agenda schließlich
benannt und behandelt?
- Wird darauf geachtet, sich weder zu sehr im Detail
zu verlieren, noch zu oberflächlich zu sein?
- Wird darauf geachtet, dass Nicht-Agenda-Themen auch nicht im
Meeting besprochen werden? Wurde eine Protokollnotiz gemacht, dass
diese Themen ggf. beim nächsten Meeting auf die Tagesordnung
kommen?
- Ist sichergestellt, dass die Interessen all derer,
die von im Meeting getroffenen Entscheidungen berührt werden,
auch berücksichtigt werden?
- Ist sichergestellt, dass sich die Teilnehmer des Meetings als
Team verstehen, die an einer gemeinsamen Lösung arbeiten?
- Wird darauf geachtet, dass das Meeting nicht von Einzelpersonen
dominiert wird? (Ausnahme: Wenige Personen informieren viele.)
- Wurde ein Abstimmungsverfahren vorbereitet (sofern
notwendig)? Wurde es korrekt durchgeführt?
- Herrscht am Ende des Meetings Klarheit über Entscheidungen,
Verantwortlichkeiten, Zeitpläne und Aufgaben? Ist das
Berichtswesen klar? Wurden explizit Punkte für das nächste
Meeting definiert?
Aufgaben des Meeting-Leiters
- Das Meeting soll sich an die Agenda halten und nicht in
nebensächliche Themen abgleiten.
- Die Atmosphäre soll konstruktiv sein und einen freien
Meinungsaustausch fördern.
- Der Leiter muss aktiv an der Lösung von Konflikten mitwirken.
- Wird das Interesse an dem Meeting wachgehalten?
- Zwischenergebnisse sollen zusammen gefasst werden,
sodass unter den Meeting-Teilnehmern nicht unterschiedliche
Vorstellungen
der Ergebnisse entstehen.
- Die Teilnehmer müssen dabei unterstützt bzw. dazu
hingeführt werden, Punkte der Agenda auch abzuschließen.
- Positives Feedback geben (wo angebracht).
Nachbearbeitung
- Wurde das Protokoll an alle Teilnehmer verschickt?
- Wurde der Rücktransport der Meeting-Teilnehmer organisiert?
- Wurde dafür gesorgt, dass der Meeting-Ort auch wieder
aufgeräumt wird?
Interview
Beim Interview trifft sich der
Analytiker mit dem Fachanwender, um bestimmte Fragen
zu klären, deren Antworten dem Fachanwender bekannt
sind. Bei einer Istaufnahme geht es
i.d.R. unmittelbar um die
Tätigkeit
des Fachanwenders, bei einer Anforderungsanalyse
um seine Wünsche
und Ideen. Der Analytiker muss also wissen, welche Fragen er zu stellen
hat. Charakteristisch für solche Treffen ist, dass
es sich um eine kleine Gruppe handelt, einer oder vielleicht zwei
Analytiker
bzw. der Analytiker und der Projektleiter auf der IT-Seite mit einem
oder zwei Fachanwendern. Ein Übergewicht an Analytikern sollte
vermieden
werden, die Situation erinnert sonst zu sehr an ein Verhör und
könnte
kontraproduktiv werden.
Das Interview ist in allen Phasen einer Istaufnahme und einer
Anforderungsanalyse ein geeignetes Werkzeug, es kann sowohl zur
Klärung von Detailfragen als auch zum Finden einer Übersicht
benutzt werden.
Ein Interview sollte nach folgenden Kriterien vorbereitet werden:
- Eine klare Agenda, die auch das Ziel des Interviews enthält,
soll lange genug vor Beginn des Interviews
ausgehändigt werden.
- Das Interview soll an einem Ort stattfinden, an
dem man nicht gestört wird. Die normale Arbeitsumgebung
des Fachanwenders ist selten geeignet.
- Ein Flipchart oder Whiteboard sollte vorhanden sein; da man meist
nur zu zweit oder zu dritt ist, tut es auch Bleistift und Papier.
- Der Fachanwender soll geeignetes Anschauungsmaterial mitbringen,
bei einer Istaufnahme z.B. Ausdrucke, Screenshots, verwendete Belege,
bzw. bei einer Anforderungsanalyse Notizen und Zeichnungen über
Ideen.
- Der Fachanwender soll Arbeitsanweisungen etc. mitbringen, die
seine Tätigkeit beschreiben.
- Ein Interview ist eine anstrengende Sache, es sollte also nicht
zu lange dauern, ggf. sollten Pausen eingeplant werden.
Beim Interview gilt eine klare Rollenverteilung: Der Analytiker fragt,
der Fachanwender antwortet. Natürlich sind Verständnisfragen
des Fachanwenders erlaubt,
aber Diskussionen um Themen oder Details, die nicht auf der
Agenda stehen, sollten vermieden werden. Die Ergebnisse müssen
natürlich protokolliert werden, eine Kopie des Protokolls geht dem
Fachanwender zu. Wird dem Protokoll nicht widersprochen,
so gehen die gewonnenen Erkenntnisse in die Projektdokumente ein.
- Auch hier ist eine Messung der Qualität sinnvoll: Wie
häufig widerspricht der Anwender dem Protokoll? Wie häufig
wird
die Istaufnahme bzw. das Anforderungsdokument korrigiert, obwohl sie
dem Protokoll entspricht? Wie häufig stellt sich heraus, dass die
aufgenommenen Informationen unvollständig waren? Wie häufig
wusste der Analytiker nicht, welche Fragen er stellen soll?
Das EVA-Prinzip kann auch auf die
Tätigkeit eines Fachanwenders angewendet werden. Dabei sind im
Rahmen eines Interviews zur Tätigkeit eines Fachanwenders folgende
Fragen zu klären:
- Eingabe: Welche Informationen (und Dinge) benötigt der
Fachanwender, um seine Arbeit machen zu können. Woher / von wem
bekommt er diese Informationen (und Dinge)?
- Verarbeitung: Was tut der Fachanwender? Welchen
Randbedingungen / Vorgaben / Vorschriften ist er unterworfen?
Auf welche Weise und mit welchen Hilfsmitteln arbeitet der
Fachanwender?
- Ausgabe: Welche Ergebnisse erzielt der Fachanwender? Was macht er
mit diesen Ergebnissen, an wen werden die Ergebnisse in welcher Form
weiter gegeben?
Beim Interview zur Istaufnahme muss stets darauf geachtet werden, dass
tatsächlich nur der
Istzustand berichtet wird. Einige Fachanwender neigen dazu, sich
über das gewünschte System zu äußern, ohne
dabei klar zu stellen, dass es sich bei ihren Aussagen um Anforderungen
an den zukünftig gewünschten Sollzustand anstatt um den
aktuellen Istzustand handelt. Je nach Vorgehensweise muss man solche
Abschweifungen entweder von Anfang an zurück weisen, oder man
einigt sich darauf, dass sie als Stichwort festgehalten werden, jedoch
nicht jetzt sondern erst ein anderes Mal bei der Aufnahme
des Sollzustands weiter verfolgt werden.
Beispiel aus der Praxis
Im Rahmen einer Notfalllösung
ging es kurz vor dem ersten Produktionslauf nur noch um
eine Layout-Frage eines Reports, auf dem die Ergebnisse von
Auszahlungen und die Verteilung der Zahlungsströme stehen
sollten. Der Entwickler, der aufgrund des Zeitdrucks ohne schriftliche
Analyse auf Zuruf mit dem Fachanwender die Lösung erarbeitet
hatte, hielt deshalb Rücksprache. Der Fachanwender zeigte
sich verwundert über die Vielzahl implementierter Features
und wies den Layout-Entwurf des Reports zurück, da er diese
Ergebnisse
(die besondere Verteilung von Zahlungen nach einem bestimmten
Regelwerk)
erst in mittelferner Zukunft brauchte. Tatsächlich hatte der
Entwickler jedoch mehrmals konkrete Fallbeispiele mit dem Fachanwender
durchgerechnet, ohne dass der Fachanwender klar gestellt hatte,
dass er dieses relativ komplexe Feature erst irgendwann einmal
im Rahmen einer vollständigen Lösung brauchen würde,
aber nicht jetzt für das Provisorium.
Man sagt, dass man nicht mehr als zwei Messungen machen soll, wenn das
Ergebnis eine Gerade sein soll. Dadurch, dass man es nur mit einem oder
zwei Fachanwendern zu tun hat, kann man im Rahmen des Interviews lange
Sinn-Diskussionen vermeiden und rasch Ergebnisse erzielen. Zu
klären ist
jedoch, ob die Ergebnisse vom Fachanwender noch mit anderen Leuten
abgestimmt werden müssen; dies kann ein lähmender Prozess
werden. Bei einer Istaufnahme ist die Paralysegefahr jedoch
beschränkt, da ein vorhandener Prozess lediglich
beschrieben bzw. dokumentiert wird und somit keine Entscheidung
über die Zukunft des Prozesses gefällt werden muss. Der
Prozess selbst kann jederzeit gemessen werden, im Zweifelsfall
kann die Aussage des Interviewpartners vor Ort durch Beobachtung
des Endanwenders verifiziert werden. Bei einer Anforderungsanalyse kann
dagegen die Vorstellung des fiktiven
und noch zu erreichenden
Sollzustandes unter einzelnen Fachanwendern stark voneinander
abweichen. Besteht dann
noch Abstimmungsbedarf, kann recht rasch ein show stopper entstehen.
Wünschenswert ist daher, dass das Interview nur mit Personen
geführt wird, die kompetent und entscheidungsbefugt sind.
Die größte Gefahr des Interviews ist die Betriebsblindheit
der Gesprächsteilnehmer. Vier Augen sehen mehr als zwei, die
beschränkte Augenzahl beim Interview kann daher zur Folge haben,
dass
wesentliche Informationen unterschlagen werden, häufig, weil der
Fachanwender stillschweigend davon ausgeht bzw. als
selbstverständlich voraussetzt, dass der Analytiker diese
Informationen kennt. Dasselbe gilt für einen Analytiker mit tiefem
Wissen im zu untersuchenden Fach, er setzt u.U. bestimmte Abläufe
als selbstverständlich voraus und hinterfragt nicht die
betriebsspezifischen Charakteristika.
Workshop
Beim Workshop trifft sich der Analytiker mit mehreren Fachanwendern, um
bestimmte Ergebnisse
zu erarbeiten.
Für die Vorbereitung gilt dasselbe wie für ein Interview. Da
jedoch Ergebnisse oder Inhalte erarbeitet werden, wird man mehr Papier
für den Flipchart brauchen. Ab vier Teilnehmern sollte ein
Moderator bestimmt werden.
Ein Workshop ist in folgenden Fällen vorzuziehen:
- Mehrere Mitarbeiter (die auch am Workshop teilnehmen) machen bzw.
planen die selbe Tätigkeit und offenbaren
so verschiedene Blickrichtungen auf dieselbe Sache.
- Schnittstellen und Übergänge von einem Prozess zum
nächsten sollen nachvollzogen werden.
- Das für die Dokumentation des Ist- bzw. Sollzustands
notwendige Wissen ist diffus und auf mehrere Mitarbeiter verteilt.
- Der Analytiker will die Sicht einer Person durch eine andere
bestätigt wissen.
- Der Analytiker muss soziale Rücksichten nehmen, z.B. muss er
dafür sorgen, dass sich einzelne Mitarbeiter nicht übergangen
fühlen.
Häufig benutzt man Workshops, um sich zu orientieren oder einen
Konsens herbei zu führen. Bei Istzustandsanalysen ist eine
Konsensfindung nicht notwendig, denn man misst ja nur vorhandene
Prozesse. Dagegen ist die Konsensfindung bei Anforderungsanalysen an
noch nicht existierende Systeme ein Grundproblem. Insofern sollten die
Alarmglocken schrillen, wenn sich zwei Fachanwender über einen von
ihnen geplanten oder vollzogenen Vorgang nicht einig werden und
darüber diskutieren. Spätestens, wenn die Sinnfrage gestellt
wird ("Warum machen Sie das so?") muss davon ausgegangen werden, dass
keine einheitliche Vorgehensweise in
der Organisation zu ein und demselben Vorgang existiert. Die
Unterschiede zwischen beiden Vorgehensweisen sind dann zu erarbeiten.
Im Regelfall werden lediglich die Vorgehensweisen abweichen, nicht die
eingehenden Informationen. Das Ergebnis wird gelegentlich voneinander
abweichen, der eine Fachanwender erzeugt mehr Output als der
andere, z.B. in Form einer zusätzlichen Kontrollliste oder einer
optionalen Serviceleistung für seine Kunden.
Die größte Gefahr des Workshops besteht in der
Themaverfehlung, dass also der Workshop zu Ende geht, ohne dass das
angestrebte Ergebnis auch nur annähernd erreicht wird.
Charakteristisch ist, dass sich die Spezialisten, bei der Istaufnahme
also die Fachanwender, in der Diskussion von Details verlieren. Der
Analytiker muss her strikt eingreifen
und zunächst einen Haltepunkt oder einen Schnittstelle definieren,
hinter der diese Details erst relevant werden.
Informelle Treffen
Ein informelles Treffen kann auch verabredet sein und
sollte auch mit einer Agenda versehen sein. Im Großen und Ganzen
gilt ungefähr das gleiche wie für Interviews, Workshops
oder Meetings im allgemeinen. Wesentlicher Unterschied ist, dass kein
definiertes Schema abgearbeitet wird, sondern die Vorgehensweise, um
zum Ziel zu kommen, eher intuitiv ist. Raum für Kreativität
ist
vorhanden. Normalerweise werden in informellen Treffen in
Expertenrunden
Detaillösungen erarbeitet.
Informellen Treffen sollte zwar nicht jegliche Form fehlen, d.h. sie
sollten nicht strukturlos als Kaffeekränzchen und ohne Zielsetzung
stattfinden, aber sie finden ohne größere Verbindlichkeit
und häufig ohne den Einfluss von Hierarchien oder
Interessensgruppen statt.
Beispiel aus der Praxis
Ein technischer Mitarbeiter eines mittelständischen Unternehmens
war in Meetings stets mehr als nur zurückhaltend. Offensichtlich
war er durch seinen recht dominanten Vorgesetzten ziemlich
eingeschüchtert; die Umgangsweise des ansonsten sozial sehr
kompetenten Vorgesetzten hinterließ beim Beobachter den Eindruck,
als ob er diesen speziellen Mitarbeiter nicht für ganz voll nahm.
Beim Mittagessen in der Kantine war dieser Mitarbeiter aber eher das
Gegenteil. In informellen Treffen offenbarte er sich als Goldgrube
für
die Lösung kniffeliger Aufgaben. Im persönlichen Kontakt zu
anderen Mitarbeitern entwickelte er eine Proaktivität, die dem
Unternehmen sehr zu Gute kam, die er aber im formellen Kreis niemals
lebte.
Für einen Business Analysten sind informelle Treffen eine gute
Gelegenheit, Detailfragen zu klären und qualitätssichernde
Maßnahmen für sein Anforderungsdokument zu realisieren. Ein
Walkthrough zu einem definierten Prozess sollte m.E. zunächst
immer erst einmal informell statt finden, da im ersten Durchlauf
ohnehin Fehler gefunden werden.
Inwiefern Protokolle solcher Treffen angefertigt werden sollen oder ob
die erzielten Ergebnisse als Teil des Analyseprozesses sofort in das
Anforderungsdokument eingehen, ist eine Frage der Unternehmenskultur.
M.E. reichen Notizen, die nicht in einem (formellen) Protokoll
resultieren, und die erzielten Ergebnisse werden sofort ins
Anforderungsdokument übertragen und dann den
Gesprächspartnern nochmals zur Durchsicht gegeben.
Informelle Treffen bzw. jede Form informeller Interaktion machen den
Hauptteil der Interaktionen im Rahmen einer Anforderungsanalyse aus,
wobei auch Workshops oder Interviews einen eher informellen Rahmen
genießen können.
Gelegentlich gibt es in der untersten Management-Ebene ein
unbegründetes Misstrauen gegenüber informellen Treffen.
Nach meinen Erfahrungen wird dabei der Begriff "informell" nicht als
intuitive Arbeitsweise verstanden, sondern als nicht durch
das Management kontrollierbar.
Spontane Interaktion
Gemeint damit ist eine ungeplante Interaktion, die zu Ergebnissen
führt. Dies ist alles andere als ein formeller Prozess. Man trifft
sich zufällig in der Kaffeeküche, der Kantine oder im Gang,
oder im Rahmen einer gemeinsamen Freizeitaktivität, oder man
schweift in einem Telefongespräch plötzlich ab. Typisch
für solche spontanen Interaktionen ist, dass sie sehr kurz sind
und meist nur ein Detail betreffen, das einem gerade durch den Sinn
geht. Häufig handelt es sich dabei um eine intuitive aber
wichtige Erkenntnis, die jedoch der genaueren Untersuchung bedarf. Nach
kurzer Diskussion trennt man sich wieder und vergisst alles, wenn man
es nicht sofort festhält.
Pflicht ist es also, sofort eine Notiz zu machen, soz. ein
kleines Protokoll. Man kann seinem Gesprächspartner, und
zunächst nur diesem, eine kurze EMail zukommen lassen, dann
über die Angelegenheit nachdenken, und schließlich einen
informellen oder formellen
Rahmen zur Weiterarbeit suchen. Der Normalfall ist allerdings, dass
geklärte Details sofort in die Spezifikation eingehen, neue Fragen
entstehen
aus spontanen Interaktionen nur selten.
Beobachtung des Endanwenders
Wenn sich der Analytiker für die Beobachtung des Endanwenders
entscheidet, dann fand meist zuvor schon ein Interview oder ein
Workshop statt, und die beschriebenen Abläufe sollen nochmals
verifiziert werden. Ein anderer Grund kann sein, dass der Fachanwender
und der Analytiker keine gemeinsame Sprache gefunden haben und die
Beobachtung den einfachste und sichersten Weg darstellt, die vom
Fachanwender vollzogenen Prozesse zu definieren. Man sollte nicht
vergessen, dass die Mehrheit der Fachanwender lediglich einen
reproduktiven Anspruch hat, also ihre einmal erlernten Prozesse
fortwährend und mit möglichst geringen Abweichungen
reproduzieren. Der Anspruch, diese Prozesse auch im Sinne der IT
vollständig und richtig erklären zu können, liegt beim
normalen Fachanwender nicht vor.
Eine Beobachtung des Endanwenders sollte nach folgenden Kriterien
vorbereitet und durchgeführt werden:
- Der Vorgesetzte des Endanwenders ist informiert
und einverstanden.
- Der Endanwender selbst ist einverstanden und über das Ziel
der Beobachtung informiert worden.
- Der Endanwender hat zuvor rudimentär seine
Tätigkeit erklärt und soweit möglich schon
Arbeitsunterlagen oder Beispiele zur Sichtung zur Verfügung
gestellt.
- Der Vertreter des Endanwenders ist nach Möglichkeit anwesend
und kann ihn vom Tagesgeschäft entlasten, während er dem
Analytiker seinen Tätigkeit erklärt.
- Die Beobachtung findet zunächst in einer betriebsarmen Zeit
statt, sodass der Anwender Zeit für Erklärungen hat.
- Die Beobachtung findet später in einer sehr betriebsamen
Zeit statt, sodass der Analytiker auch eine Vorstellung von den Leiden
des Anwenders bekommt, die letztendlich durch eine
IT-Lösung reduziert werden sollen.
- Der Analytiker hat genügend Pufferzeiten vorgesehen, um ggf.
länger als geplant bleiben zu können.
- Der Analytiker trägt zu einer entspannten Atmosphäre
bei und kritisiert nicht die Arbeit des Fachanwenders.
Normalerweise wird der Analytiker sich die Tätigkeit neben der
Arbeit erklären lassen. Da das Tagesgeschäft nicht einfach so
zu bewältigen ist, sollte der Analytiker nicht davon ausgehen,
dass die Aufnahme der Tätigkeit unterbrechungsfrei stattfinden
kann. Zu vermeiden ist eine Situation, in der der Fachanwender
lediglich einen beispielhaft vorbereiteten Ablauf demonstriert und dann
den Analytiker wieder entläßt. Solch ein beispielhaft
vorbereiteter Vorgang kann sehr gut als erste Einführung dienen
oder bei einem Interview oder Workshop vorgeführt werden,
er wird jedoch kaum jemals die Ausnahmen, alternativen Abläufe und
Nebeneffekte des Prozesses darstellen. Der Regelfall wird
sein, dass der Analytiker Notizen macht und sich Unterlagen
kopiert und ggf. auch Screenshots
sammelt.
Die Kooperation der Fachanwender sollte geschätzt und auch
honoriert werden. Das Ergebnis der Beobachtung, d.h. das resultierende
Schriftstück sollte mit dem Fachanwender nochmals durchgesehen
werden, ehe es weiter verwendet werden. Ein reines Zusenden zur
Durchsicht ist kein probater Weg der Qualitätssicherung:
Fachanwender, die ihre eigene Tätigkeit nicht selbst IT-brauchbar
dokumentieren können, können meist auch die erstellten
Dokumente nicht korrigieren.
Die größte Gefahr bei der
Beobachtung des Endanwenders besteht darin, dass nur der
Geradeausflug studiert wird und die Ausnahmen, also gerade die für
ein IT-System kritischen Ereignisse, nicht erkannt werden. Der
Fachanwender vermeidet häufig auch mehr oder weniger bewusst diese
Ausnahmen, nicht selten im Glauben, dem Analytiker etwas gutes zu tun
und ihn nicht zu verwirren. Eine weitere Gefahr
besteht darin, dass sich manche Menschen nicht gerne bei der Arbeit
zusehen lassen und sich unter Druck gesetzt fühlen. Dem kann
nur durch hinreichende soziale Kompetenz begegnet werden, wobei sicher
gestellt sein muss, dass am Ende lediglich der Geschäftsprozess
und nicht die Person des Fachanwenders beschrieben wird; auch nicht
informell oder mündlich.
Mitarbeit beim Endanwender
Die Mitarbeit beim Endanwender
ist das letzte Mittel, das zur Istaufnahme angewendet
werden kann, wenn alle anderen Methoden versagen oder von Anfang an
nicht erfolgversprechend sind. Dabei wird der Grundsatz probieren
geht über studieren angewendet.
Die einzigen Gründe für die
Wahl dieser Methode sind die Komplexität der Materie
oder die Unmöglichkeit, mit dem Fachanwender eine gemeinsame
Kommunikationsebene zu finden, evtl. noch der Wunsch, bei besonders
sensiblen Prozessen Sicherheit über deren korrekte Beschreibung zu
erhalten. In diesem Fall bleibt dem Analytiker nur der Weg, die
Prozesse vor Ort selbst nicht nur zu studieren sondern auch zu
reproduzieren, um sie vollständig verstehen und umsetzen zu
können. Der typische Anwendungsbereich für diese Methode sind
komplexe rein
manuelle
Prozesse. Die Methode kann auch erwogen werden, wenn der Analytiker
von der zu analysierenden Materie noch gar keine Ahnung hat, ein nicht
unüblicher Wunsch von Auftraggebern, die Betriebsblindheit
vermeiden wollen.
Die Mitarbeit beim Fachanwender ist ein Prozess wechselseitigen Lernens
und Lehrens. So, wie der
Fachanwender dem Analytiker seine Tätigkeit und die damit
verbundenen letztendlich zu analysierenden und zu fixierenden Prozesse
nahe bringt, vermittelt der Business Analyst dem Fachanwender die
Bedürfnisse der IT-Welt, indem er ihn immer wieder darauf
aufmerksam macht, wie in einer gegebenen Situation ein dummes
IT-System reagieren würde. Dieser Schritt ist wichtig, da ja
ein gemeinsames Verständnis und eine gemeinsame Sprache
notwendig sind.
Man tritt als Analytiker eher als eine Art recht nerviger Praktikant
auf, der vor allem beim Tagesgeschäft stört. Insofern sollte
also irgendeine Form der Kompensation oder Motivation für den
Fachanwender vorgesehen werden, und sei es nur die Verpflichtung,
regelmäßig die Brotzeit zu beschaffen. Um die Konsequenzen
einer Tätigkeit im Detail kennen zu lernen, sollte man auch nicht
davor zurück schrecken, die möglichst unangenehmen Teile
einer Tätigkeit immer wieder zu wiederholen, z.B. die Diskussion
mit unzufriedenen Kunden. Ungeachtet seines berufsbedingten
Wissensdurstes muss sich der Analytiker über die Grenzen seiner
Kompetenzen stets im Klaren
sein: im Rahmen der Istaufnahme ist Kritik an den vorhandenen Prozessen
oder Methodiken nicht angebracht, man ist Praktikant und im aktuellen
Arbeitsumfeld nur geduldet und will zunächst die Prozesse nur
verstehen.
Da jede Einarbeitung geraume Zeit dauert und Business Analysten i.d.R.
gut bezahlte Leute sind, kann dieser Weg sehr teuer werden. Bei allen
Kostenbedenken bzw. gerade deshalb sollte nicht vergessen werden, dass
ein unbrauchbares und womöglich gar nicht nutzbares IT-System
wesentlich teurer kommt, als ein durch eine intensive Analysephase
scheinbar verteuertes System. Selbst die Einsicht, dass man besser kein
IT-System einführt, kann ein gutes Resultat sein. Die
günstigste Möglichkeit für einen Auftraggeber besteht
hier darin, den Analytiker nicht über ein Softwarehaus anzuheuern
und damit die Marge des Auftragnehmers mit zu bezahlen, sondern den
Analytiker direkt unter Vertrag zu nehmen; das dürfte zwischen 30%
und 60% billiger kommen. Weiterhin vermeidet der Auftraggeber damit
einen Interessenskonflikt, bei dem der Analytiker vom Auftragnehmer
unter Druck gesetzt wird, irgendwelche Ergebnisse zu liefern, auch wenn
diese für den Auftraggeber zu unbrauchbarer Software führen.
Die größte Gefahr bei der Mitarbeit beim Endanwender ist
sozialer Natur. Eine unangenehme Analytiker-Persönlichkeit wird
kaum die nötige Integration in das Team und somit ins
Tagesgeschäft bekommen. Eine andere große Gefahr ist
übermäßige und freundlich gemeinte Rücksichtnahme
auf den Analytiker, sodass er kritischen Prozessteile nicht
zu Gesicht bekommt oder nicht versteht.
Fragebogen und schriftlichen Umfrage
Die Verwendung eines Fragebogens bzw. einer schriftlichen Umfrage setzt
voraus, dass man
sehr genau weiß, welche Fragen man beantwortet haben will. Sie
kann benutzt werden, wenn man quantitative Ergebnisse oder
Meinungsbilder feststellen will. Im Rahmen der Anwendungsentwicklung in
der IT spielt diese Vorgehensweise eine untergeordnete Rolle.
Die schriftliche Umfrage unterscheidet sich im hier verwendeten Sinne
vom Fragebogen insofern, als der Befragte eher selbstformulierte
Antworten geben kann. Beispiel: Bei der Umfrage kann die Frage lauten
"Welcher Arbeitsablauf ist Ihnen am unangenehmsten und Sie wollen dort
bessere IT-Unterstützung?" und die Antwort kann auf einigen
Textzeilen frei formuliert werden. Beim Fragebogen würden noch
vorgefertigte Antworten evtl. zusammen mit einer Benotung oder
Gewichtung stehen, z.B. "Kundennummer zu lang zum Eintippen", "zu viele
Datenfelder auf den Formularen", "Kontrollliste zum aushaken wäre
wünschenswert" etc. Gemäß dieser Unterscheidung kann
bzw. muss eine schriftliche Umfrage bei einer kleineren Gruppe
stattfinden, z.B. bei einer repräsentativ ausgewählten
Stichprobe. Muss deshalb, da die Antworten relativ frei sein
können und daher die Auswertung aufwendig und teuer wird.
Sinnvoll angewendet kann ein Fragebogen nur dann werden, wenn eine sehr
große Anzahl zu befragender Personen vorhanden ist. Bevor man
einen Fragebogen verteilt, sollte man sich über die möglichen
Antworten den Kopf zerbrechen. Multiple Choice ist nur sinnvoll, wenn
auch alle möglichen Antworten aufgelistet sind oder zumindest der
aller größte Teil, sodass die Kategorie sonstiges
mit der dahinter stehenden Textzeile nicht all zu häufig angegeben
wird.
Ein Fragebogen kann dann angewendet werden, wenn eines oder mehrere der
folgenden Kriterien erfüllt
sind:
- Die Ergebnisse sind eher quantitativer Natur, man will z.B.
wissen, welche Prozessteile wie intensiv genutzt werden.
- Man will Bewertungen zu konkreten Fragen, z.B. die Stärken
und Schwächen in einem vorhandenen Prozess erkennen.
- Man will seltene Ausnahmen erkennen, die nur durch die Befragung
einer großen Personenzahl erkannt werden können.
- Man will einer großen Personengruppe eine sichtbare
Mitwirkungsmöglichkeit schaffen, um an der Gestaltung eines von
ihnen zu nutzenden Software-Produkts, ihres Arbeitsplatzes und der
Arbeitsprozesse mitwirken zu können.
Jeder Mensch fragt sich, was mit seinen Antworten gemacht wird. Man
sollte sich also entscheiden, ob eine Umfrage anonym stattfinden kann,
oder nicht. Eine Erklärung, wofür die Ergebnisse der Umfrage
verwendet werden, ist
ebenso sinnvoll wie die Veröffentlichung des Umfrageergebnisses
samt den daraus geschlossenen Resultaten.
EMail
Formelle EMails
EMails unterstützen das Prinzip der Schriftlichkeit, d.h. man
erhält ein Dokument, auf das man sich bei Widersprüchen
beziehen kann. Dabei sollte man allerdings wie auch im sonstigen
Geschäftsleben niemals aus dem Blickfeld verlieren, dass
Lösungen
gesucht werden, und nicht Schuldige. Wird also einmal ein gravierender
Widerspruch entdeckt, so sollte dies eine Gelegenheit sein, nach
weiteren
Schwächen im Lösungsansatz zu suchen und ihn zu verbessern,
nichts anderes.
Bei der EMail gibt es sowohl die formelle als auch die
informelle Variante. Zu unterscheiden sind die beiden Varianten
am ehesten durch den Verteiler, wobei in einen strategischen und
einen sachlichen Verteiler unterschieden werden kann. Im strategischen
Verteiler finden sich im günstigsten Fall Personen, die
Entscheidungen
fällen bzw. herbei führen können. Im ungünstigsten
Fall setzt der Absender lediglich deshalb Personen in geeigneten
Positionen
auf den Verteiler, um sich selbst zu profilieren.
Eine formelle EMail ist i.d.R. das Resultat eines anderen formellen
Prozesses. Sie dient dazu, zu informieren, und sie ist
häufig mit einem Arbeitspaket verbunden. Der Versand eines
Protokolls
aus einem Workshop kann solch eine informative Mail sein. Ebenso kann
der Versand einer ToDo-Liste bzw. eines Fragenkatalogs Grund für
eine formelle EMail sein.
Ein sinnvoller Einsatz eines strategischen Verteilers
ist eine Rückfrage bzgl. nicht eingehaltenen Terminen. Es kommt
erstaunlich häufig vor, dass Liefertermine für Arbeitspakete
ohne Kommentar nicht gehalten werden, oder aber, dass die
Arbeitsergebnisse
vollkommen unzureichend sind. Eine Rückfrage unter Einbeziehung
der Hierarchie hat dann den doppelten Effekt, dass einerseits daran
erinnert wird, dass ein Arbeitspaket nicht gut oder schnell genug
bearbeitet
worden ist, andererseits wird die Hierarchie über den Verzug
informiert. Für das mittlere und höhere Management ist es
essentiell zu wissen, was im Unternehmen und im Projekt vorgeht, es
besteht also letztendlich sogar eine Informationspflicht.
Beispiel aus der Praxis
Ein Projektleiter bestand darauf, dass jede EMail, die an den Kunden
gerichtet ist, auch an ihn in Kopie gehen sollte. Da er mehrere
Projekte parallel verwaltete, war der in seiner Mailbox auflaufende
Schriftverkehr beträchtlich. Gelegentlich wurde er von
Mitarbeitern auf EMails angesprochen, die er noch nicht beantwortet
hatte. Meist verwies er auf Zeitdruck und darauf, dass er noch
über 500 ungelesene Mails in seiner Inbox hätte. Feedback zu
EMails kam häufig erst mit mehrtägiger Verspätung an,
die aktuelle Fragestellung war meist bereits bearbeitet, sodass
Entscheidungen gelegentlich revidiert werden mussten. Dies führte
wiederum regelmäßig zu Ärger auf Kundenseite.
EMails tendieren dazu, sich unkontrolliert zu vermehren. Vergessen Sie
nicht, dass die Empfänger i.d.R. vielbeschäftigte Leute sind.
EMails sollten also knapp gehalten werden, sofern dies möglich
ist. Die Sicht auf eine Fragestellung und die dazu passende Antwort ist
oft abhängig vom Empfänger: Für einen
Geschäftsführer eines kleinen oder mittleren Unternehmens tut
es i.d.R. ein kurzes ja oder nein, wo der Software-Designer ein kleines
Buch erwartet.
EMails haben wie jede andere schriftliche Kommunikationsform auch den
Nachteil, dass weder Verständnisfragen sofort gestellt werden
können, noch kann man auf andere Weise mit seinem Gegenüber
interagieren, sodass die übermittelte Botschaft gelegentlich
missverstanden wird. Im Gegensatz zum klassischen geschäftlichen
Briefverkehr hat sich kein formalisierter Schreibstil bei diesem noch
recht jungen Kommunikationsmedium etabliert. Ein Mindestmass an
Höflichkeit
und Sachlichkeit sollte neben einem lesbaren Stil gewahrt bleiben.
Beispiel aus der Praxis
In einem kleinen mittelständischen Unternehmen trugen einige Leute
gelegentlich ihre Konflikte per EMail aus. Dies ging auch lange Zeit
gut, bis ein neuer Mitarbeiter des unteren Managements mit dieser
Streitkultur nicht zurecht kam. Fortan tendierte der Verteiler dazu,
bei jeder Antwort zu wachsen, bis schließlich die
Geschäftsführung mit drauf war.
Informelle EMails
Die informelle EMail ist i.d.R. mit einer oder einigen
wenigen Fragen oder einer kurzen Information verbunden. Gegenüber
einem Anruf hat man zwei Vorteile: Der Empfänger wird in seiner
Arbeit nicht unterbrochen und man erhält ein Dokument als
Resultat.
Informelle EMails gehen grundsätzlich an keinen strategischen
Verteiler. Die EMail wird zwar ausgewertet und geht in die eigenen
Arbeitsergebnisse ein, aber sie stellt kein offizielles Dokument dar.
Darüber sollte Konsens zwischen Sender und Empfänger
herrschen.
Beispiel aus der Praxis
Ein Projektleiter wollte von seinem Analytiker einen schriftlichen
Bericht über die Auswirkungen eines Änderungswunsches
des Kunden. Der Analytiker verfasste dazu eine recht locker formulierte
EMail, die er als informell ansah. Der Projektleiter kopierte ungefragt
Teile dieser EMail und schickte sie an den Kunden, wobei nicht
ersichtlich war, dass die kopierten Stellen vom Analytiker waren. Der
Kunde reagierte aufgrund der recht entspannten aber nicht
unhöflichen Wortwahl
der zitierten Stellen nicht erfreut. U.a. wurde davon gesprochen, dass
"das Konzept teilweise über den Haufen geworfen" worden war und
Teile
der Arbeit des Analytikers "für den Mülleimer" gewesen
wären. Als der Analytiker den Projektleiter zur Rede stellte,
erklärte
dieser, dass er jede EMail, die er bekäme, als formelle
Stellungnahme
betrachte.
Gelegentlich können gerade informelle Emails missverstanden
werden. Der Leser interpretiert eine Aussage in die Mail, die nicht
gegeben ist bzw. liest Dinge zwischen den Zeilen, die nicht drin
stehen. Als
Leser merkt man dies am ehesten an einer aufwallenden negativen
Emotion. Man sollte sich dann vor Augen halten, dass der erste Gedanke,
das erste Gefühl oder die erste Interpretationsweise nicht die
richtige sein muss. Man nimmt die EMail durch die eigene Brille wahr,
anstatt die Intention des Autors zu hinterfragen. -
Sinngemäß gilt dies natürlich immer.
Eine gute Taktik ist es dann, die EMail nicht sofort sondern erst nach
einigen Stunden, vielleicht erst am nächsten Tag zu beantworten
bzw. zunächst eine Antwort zu schreiben und dann zu speichern,
um sie später nochmals Korrektur zu lesen.
Telefongespräch
Normalerweise will ein Business Analyst etwas wissen, wenn er jemanden
anruft. Anders herum will ein Fachanwender so gut
wie immer eine neue Anforderung oder eine gewonnene Information an den
Analytiker kommunizieren. Ich selbst habe meist nur eine oder einige
Fragen, die zu klären sind, was aber abhängig von der
Komplexität der Fragen nicht heißt, dass das Gespräch
in wenigen Minuten beendet ist. Ist der Kunde räumlich zu weit
entfernt, so müssen teilweise recht ausführliche Diskussionen
telefonisch erledigt
werden. Wenn dies vor Gesprächsbeginn bekannt ist, dann sollte
auch
ein Gesprächstermin vereinbart werden; niemand schneidet sich
gerne eine Stunde aus seiner Tagesplanung.
Es ist eine Philosophie-Frage, ob man zu jedem
Telefongespräch auch eine Gesprächsnotiz anfertigen sollte.
Auch hier führt eine Überbürokratisierung lediglich zu
Ineffektivität. Wenn eher wichtige Auskünfte gegeben werden,
derer Verbindlichkeit relevant für das Projekt ist, dann ist diese
Frage sicher zu bejahen. Eine kurze zusammenfassende EMail an den
Angerufenen tut es meistens.
Das Telefon kann zum Zeitkiller werden. Zumindest als Anrufer kann man
dem entgegen wirken, indem man vor dem Gespräch seine Fragen und
den Zweck des Anrufs niederschreibt. Auf diese Weise vermeidet man
auch, dass man im Gespräch ein Thema vergisst. Man kann auch EMail
und Telefon kombinieren, indem man die Fragen an seinen
Gesprächspartner schickt, am Telefon die Antworten diskutiert und
ausarbeitet und
dann in einer weiteren EMail festhält. Wesentlicher Unterschied
zur EMail-Anfrage ist hier die Interaktion: Anrufer und Angerufener
erarbeiten gemeinsam die richtigen Antworten, häufig
überhaupt
erst die richtigen Fragen.
Arbeitspakete
Formelle Arbeitspakete
Ein Arbeitspaket ist eine Menge von Aufgaben, die bis zu einem
bestimmten Termin zu erledigen sind. Wenn ein Meeting oder
Workshop veranstaltet wird, dann ist es mit dem Treffen nicht getan.
Am Ende des Meetings werden normalerweise Ziele vereinbart, die
wiederum
zu Arbeitspaketen geschnürt und verteilt werden.
Arbeitspakete, die ein Analytiker vergibt, sind fast
ausschließlich die Bearbeitung von Fragekatalogen bzw.
ToDo-Listen mit zu beschaffenden Unterlagen oder Informationen, und
gelegentlich die nachdrückliche Forderung nach einer beim Kunden
oder in der Fachabteilung ausstehenden verbindlichen Entscheidung. Die
korrekte Erledigung solcher Arbeitspakete ist meist kritisch für
die Vervollständigung des Anforderungsdokuments. Wird ein
formeller Weg eingeschlagen, um Arbeitspakete zu erledigen, dann nicht
zuletzt deshalb, damit auch ein formeller Eskalationsweg
beschritten werden kann, wenn die Arbeitspakete in unzureichender Weise
bearbeitet werden.
Informelle Arbeitspakete
Informelle Arbeitspakete unterscheiden sich von formellen entweder
dadurch,
dass jemand gebeten wird, ein Arbeitspaket nebenbei zu übernehmen,
das
er nach seinen Tätigkeitsmerkmalen nicht übernehmen muss; es
gibt
keinen formellen Weg, ihm dieses Paket zu übertragen. Oder dieses
Arbeitspaket
könnte zwar formell vergeben werden, jedoch wird ein informeller
Weg
gewählt, meist, da dadurch im Einzelfall schneller Ergebnisse
erwartet
werden können.
Auch informell vergebene Arbeitspakete sind Arbeitspakete, die erledigt
werden müssen. Da jedoch der formelle Rahmen fehlt, fehlt auch
eine Möglichkeit, unzureichende Ergebnisse nachzufordern bzw. zu
sanktionieren. Man bittet also seinen Partner mehr um die Erledigung
der Arbeitspakete, als dass dies angeordnet wird. Der Empfänger
des Arbeitspaktes hat auch eher eine Möglichkeit, die Bearbeitung
zurückzuweisen, als wenn der formelle Weg eingeschlagen wird. Im
Projektgeschäft ist der Übergang vom formellen zum
informellen
Arbeitspaket fließend, denn i.d.R. ist der Projektleiter nicht
der disziplinarisch Vorgesetzte seines Projektteams. Für den
Business
Analysten gilt darüber hinaus, dass er seinen Kunden keine
Anordnungen
geben kann.
Arbeitspakete, die ein Analytiker vergibt, sind auch bei der
informellen Variante meist nur die Beschaffung von Informationen und
Dokumenten, die Bearbeitung von Fragenkatalogen oder die
Herbeiführung von Entscheidungen. Letzteres geht allerdings auf
informellem Wege nicht in jedem Umfeld. Allerdings spricht nichts
dagegen, dass eine
informelle Anfrage zu einem formell kund getanen Ergebnis führt.
Fragetechniken
Allgemeines
Ein Analyseprozess für ein IT-System sollte nicht mit den
Fragetechniken in einem polizeilichen Verhör verwechselt werden.
Zwar lohnt es sich auch für Business Analysten die grundlegenden
Methoden einer Vernehmung zu studieren, aber die Anwendung z.B. der
Reid-Methode oder das Ausspielen verschiedener Fachanwender
gegeneinander ist in höchstem Maße kontraproduktiv,
unprofessionell bzw. schlichtweg dumm. Ich weise hierauf deshalb
nochmals drastisch hin, um den Unterschied zwischen der Suche nach
Lösungen und der Suche nach Schuldigen deutlich zu machen. Beim
Bau eines IT-Systems wird nach einer Lösung gesucht, nachdem das
richtige Problem definiert bzw. die richtige Fragestellung formuliert
wurde. Dabei wird es immer wieder
menschliche Nachlässigkeiten oder Fehler geben. Es gibt seltene
Ausnahmefälle, bei denen ein Projektleiter, Business Analyst oder
Fachanwender ausgewechselt werden muss, da er seinen Pflichten nicht
nachkommt. Häufiger kommt es jedoch vor, dass einige
Team-Mitglieder ungeduldig und entnervt reagieren, wenn von anderen
Team-Mitgliedern Fehler gemacht werden. Man kann dann die
Normalität der menschlichen Unvollkommenheit nur immer wieder
betonen.
Selbstverständlich versagt jede Befragungstechnik, wenn der
Befragte konsequent die Aussage verweigert. Da geht es einem
Polizisten nicht besser, als einem Business Analysten.
Als Analytiker hat man die Verantwortung, die Quote der
zweitteuersten Fehler im Projekt niedrig zu halten. Nach
Projektplanungsfehlern schlagen falsche oder unvollständige
Anforderungen am massivsten zu Buche.
Exkurs: Theoretischer
Hintergrund
zur Befragungstechnik anhand von Verhörmethoden
Vgl. z.B. http://media.wiley.com/product_data/excerpt/12/04708446/0470844612.pdf
und http://www.reid.com/critic-techniquedefen.html
google zu interrogation method
google zu Verhörmethoden (geprüfte
Treffer Stand 10/2003 waren in Bezug auf diese Site wenig bis gar nicht
interessant)
Allgemeines
In der Kriminalistik sucht man nach Schuldigen, im Geschäftsleben
dagegen nach Lösungen. Dies zu verstehen ist notwendig. Bei
Verhören benutzte Methoden sind offensichtlich kein geeignetes
Mittel, um von Fachanwendern Informationen zu bekommen. Eher bewirken
sie das Gegenteil. Ein Fachanwender, der in eine hilflose oder
bedrohliche Situation gebracht wird bzw. der unter psychischen oder
physischen Druck gesetzt wird, wird schlagartig die Kooperation
einstellen und zu Recht ggf. den Vorfall eskalieren. Die theoretische
Kenntnis der Methoden ist m.E. jedoch nützlich,
da sie einerseits aufzeigen, was man im Geschäftsleben nicht
erreichen soll, andererseits wird auch Verkaufspersonal oder
Mitarbeiter von Personalabteilungen, die Einstellungsgespräche
führen, in Befragungstechniken unterrichtet, die auf
Vernehmungsmethoden beruhen.
Verhörtechniken und Befragungsmethoden, um Kriminelle zu
Geständnissen zu bringen, haben eine lange Geschichte. Der Wert
des Geständnisses wird auch heute noch so hoch geachtet, dass
Folter selbst in den sog. zivilisierten Ländern gelegentlich noch
immer als probates Mittel diskutiert oder sogar eingesetzt wird. Ein
Verhör ist prinzipiell kein freundliches Beisammensein, sondern
ein Machtspiel im weiteren Sinne, bei dem es darum geht, den Widerstand
und somit den Willen des Verhörten zu brechen. Hierzu wird Druck
ausgeübt, auch in Rechtsstaaten wird dabei manchmal sehr nahe an
den
Grenzen der Legalität gearbeitet wird, wobei die Interpretation
dieser
Grenzen von Land zu Land verschieden ist. Moderater Schlafentzug durch
Dauerverhöre, Verweigerung des Ganges zur Toilette, Reduzierung
der
Nahrung oder "moderate physical preassure" sind nichts
ungewöhnliches. Die weniger physiologisch orientierten Methoden
der professionellen Vernehmung basieren im Wesentlichen darauf, eine
emotionale Beziehung zum Verhörten aufzubauen, "undercover" sich
in das Vertrauen des Verdächtigten einzuschleichen, oder ihn mit
erfundenen "Beweisen" (z.B. dass ein Mordopfer noch lebt und den
Verdächtigten identifiziert hätte) unter Druck zu setzen.
Druck ist ein Grundprinzip, z.B. erzeugt das ständige wiederholen
lassen
einer vom Verdächtigten erzählten Story, unterbrochen von
smaltalk, bereits Druck. Negative Emotionen wie Zorn oder Wut sollen
sowohl beim Vernehmenden als auch beim Vernommenen vermieden werden, da
sie sich nicht konstruktiv auf die Interaktion auswirken.
In gewissen Sinne sind sowohl ein Vernehmer, als auch ein befragender
Business Analyst auf der Suche nach der Wahrheit. Sie haben einen
begründeten Verdacht, dass eine Person die Wahrheit kennt, aber
nicht nennen will. Und sie wollen diese Wahrheit in Erfahrung bringen.
- Im Regelfall geht der Verhörende davon aus, dass er
tatsächlich mit einem Schuldigen, und nicht mit einem
Beschuldigten zu tun hat. Die Möglichkeit, ein falsches
Geständnis zu bekommen, wird kaum beachtet.
Allerdings ist die Motivation des "Verdächtigen" komplett anders.
Ein schuldiger Krimineller ist sich seiner Tat und der
Zurückhaltung der Wahrheit bewusst. Er will nicht, dass sie ans
Licht kommt, wobei nach gängiger Meinung sowohl die Angst vor
Strafe als auch Schamgefühle eine Rolle spielen. Ein befragter
Fachanwender hält dagegen die Wahrheit nur unbewusst zurück,
er weiß u.U. gar nicht, was der Analytiker von ihm wissen will,
oder er hat keine Vorstellung davon, dass fachlich unbedeutende
Ereignisse für das Funktionieren eines
IT-Systems von herausragender Wichtigkeit sind. Er ist normalerweise
engagiert
und will sich an der Wahrheitsfindung aktiv beteiligen. Selten
können jedoch gemachte Fehler zu einer Verschleierungshaltung
führen,
und zwar immer dann, wenn die Unternehmenskultur bzw. der direkte
Vorgesetzte Fehler bestraft.
Offshe-Modell
Nach dem Offshe-Modell muss zunächst erreicht werden, dass sich
der Verdächtige zunächst auf ein (Zu-) Geständnis
einlässt bzw. dass ihm dies entlockt wird, und dann das volle
Geständnis folgt. Um nun ein erstes Zugeständnis zu
erreichen, muss der Verdächtige davon überzeugt werden, dass
an seiner Schuld keinerlei Zweifel besteht. Dazu muss er mit Beweisen
soz. überrannt werden, nötigenfalls auch mit fiktiven (also
frei erfundenen) Beweisen. Zudem soll der Eindruck vermittelt werden,
dass der Vernehmende um so verärgerter wird, je länger das
Geständnis aus ich warten lässt. Eines der wesentlichen Ziele
des Vernehmenden ist es zunächst, den Verdächtigen in eine
subjektiv hilflose Situation zu bringen, z.B. mit Aussagen wie "Sie
kommen hier nicht eher heraus, bis Sie gestehen" oder "Es besteht kein
Zweifel an Ihrer Schuld, fraglich ist nur noch das Strafmaß".
Sobald der Zustand subjektiver Hilflosigkeit erreicht ist, wird der
Verdächtige motiviert bzw. animiert, zu gestehen. Dazu wird Druck
aufgebaut. Eine typische "schwach motivierende" Phrase hierzu ist "Sie
werden sich besser fühlen, wenn Sie uns die Wahrheit gesagt
haben", eine "stark motivierende" ist "Wenn Sie nicht gestehen, werden
Sie zur Höchststrafe verurteilt. Ihre Kinder landen in einem
Heim." Sobald ein erstes Geständnis abgegeben wurde, wird im
zweiten Teil der Befragung auf die Details
des Verbrechens eingegangen, also darauf, wie es begangen worden ist.
Dabei muss auch nachgewiesen werden, dass das Geständnis echt ist.
Neben Differenzen zwischen echten Beweisen und Aussagen des
Verdächtige, und dem Fehlen von (neuen) Details, die den Verdacht
erhärten, gilt auch die vollkommene Übereinstimmung der
Aussagen des Verdächtigen mit den Annahmen bzw. Unterstellungen
der Polizei als Hinweis auf ein
falsches Geständnis.
Reid-Methode
Die z.Z. durch die deutsche Presse geisternde und immer wieder
kritisierte Reid-Methode, die nun auch bei der deutschen Polizei
geschult wird, basiert auf zwei Prinzipien:
- Brechen des Widerstandes und des Unterbinden des Abstreitens der
Tat.
- Förderung des Wunsches zu gestehen.
Zunächst wird eine informelle Befragung empfohlen, bei der es
nicht notwendig ist, den Verdächtigten über seine Rechte
aufzuklären. Zweck ist es, eine positive Atmosphäre des
Vertrauens herzustellen und Informationen über die
Persönlichkeit des
Verdächtigten zu erhalten, die anschließend genutzt werden
können,
um den Widerstand gegen ein Geständnis zu brechen. Das
neunstufiges
Modell der Reid-Methode lässt sich grob wie folgt zusammen fassen:
- Zuerst wird der Verdächtige direkt konfrontiert. Der
Vernehmende drückt sehr klar seine Überzeugung aus, dass der
Verdächtige schuldig ist. - Dabei geht es auch darum, etwas
über die Persönlichkeit des Verdächtigen heraus zu
bekommen und einen Anknüpfungspunkt zu definieren.
- Dem Verdächtigen wird Verständnis für die Tat
vermittelt. Dabei werden monologartig moralische (aber nicht
juristische) Gründe und Rechtfertigungen für die Tat auf
mitfühlende Art vorgetragen. Empfohlen wird dabei bei emotionalen
Verdächtigen u.a. zu kommunizieren, dass jeder andere auch in
derselben Situation dasselbe Verbrechen begangen hätte.
Schuldgefühle des Verdächtigen sollen reduziert werden, z.B.
indem man ihm
kommuniziert, dass andere Leute schlimmeres getan haben. Bei
unemotionalen
Verdächtigen wird der Versuch empfohlen, ihn bei einer Lüge
zu erwischen, wodurch sofort ein psychologischer Nachteil für den
Befragten entsteht. Ebenso soll unterstellt werden, dass das Motiv
hinter dem Verbrechen nicht kriminell war. Der Verdächtige soll
soweit gebracht werden, zuzugeben, dass er in irgend einer Weise mit
dem Verbrechen verbunden ist, z.B. dass er in der Nähe des Tatorts
war. Sind mehrere Personen in das Verbrechen involviert, können
sie
gegeneinander ausgespielt werden. - Ziel ist es, dem Verdächtigen
ein Geständnis zu erleichtern und seine inneren Widerstände
zu überwinden, z.B. sein Selbstwertgefühl.
- Der Verdächtige wird i.d.R. bislang jede Schuld bestritten
haben. Je hartnäckiger er leugnet, um so unwahrscheinlicher ist
es, dass er gesteht. Wiederholtes hartnäckiges Bestreiten
der Schuld gilt als psychologischer Nachteil für den Vernehmenden.
Wenn er sich darauf einlässt, entgleitet ihm die Kontrolle
über
das Verhör. Der Vernehmende tritt jedem Versuch entgegen, die
Schuld zu bestreiten, und zwar sowohl verbal als auch mit
Körpersprache. ("Stopp, einen Moment." mit einer ablehnenden
Geste)
- Verdächtige, denen es nicht gelingt, den Vernehmenden von
ihrer Schuldlosigkeit zu überzeugen, tendieren gelegentlich dazu,
das Verhör "auszusitzen" und die Kooperation einzustellen. Dies
wird als Tiefpunkt für den Verdächtigen betrachtet und
es ist nun wichtig, nicht den "Kontakt" zu ihm zu verlieren, sondern
seine Widerstände zu überwinden.
- Der Verdächtige sollte in diesem Stadium des Verhörs
einen niedergeschlagenen Eindruck hinterlassen. Nun muss die
Aufmerksamkeit des Verdächtigen wieder gewonnen werden. Dazu wird
emotionale Nähe geschaffen, i.d.R. durch "freundliche"
Körpersprache, z.B. auch durch Körperkontakt.
- Da der Widerstand des Verdächtigen so gut wie
gebrochen ist, reagiert er besser auf Appelle des Vernehmenden. Er
appelliert direkt an Anstand, Ehre, Religion und zeigt sich abermals
verständnisvoll und mitfühlend. Einige Verdächtige
fangen
nun zu weinen an, schließlich brechen sie emotional zusammen. Ein
Blick ins Leere und komplette Stille sind oft ein Anzeichen, dass nun
ein Geständnis folgt.
- Nun wird eine Alternativ-Frage gestellt, eine
Frage, bei der zwei Antworten vorgegeben sind, die beide auf ein
Schuldgeständnis hinaus laufen. Die eine Antwortsvariante bietet
ein Geständnis ohne Gesichtsverlust an. Dem Verdächtigen wird
dadurch eine Gelegenheit gegeben, eine Erklärung oder
Entschuldigung für das Verbrechen zu geben, was aber auf ein
Schuldeingeständnis hinaus läuft. Etwa 80% der
Verdächtigen gestehen nun.
- Aus dem "Ansatz" in Schritt 7 wird nun ein vollständiges
mündliches Geständnis. Dazu werden Details der Tat
hinterfragt. Um den Verdächtigen nicht zu verunsichern, ist der
Vernehmende zunächst alleine mit ihm. Später wird dann das
Geständnis vor Zeugen wiederholt, falls keine schriftliches
Geständnis erreicht werden kann.
- Das schriftliche Geständnis hat vor allem juristischen Wert.
Literaturhinweis: Fred E. Inbau, John E. Reid, Joseph P. Buckley III,
Brain C. Jayne: Criminal Interrogation and Confesions, 4th Edition. -
Das Buch wird regelmäßig zitiert, ich habe es aber selbst
nicht gelesen.
"Mutt and
Jeff"
- Technik
Diese Befragungstechnik wird auch als friendly-unfriendly oder, im
deutschen Sprachraum, als good guy - bad guy bezeichnet. Der
Verdächtige wird dabei von zwei oder drei Vernehmern befragt, die
jeweils eine freundliche bzw. moderierende und unfreundliche bzw.
aggressive Rolle übernehmen. Arbeitet man zu dritt, so tritt einer
jeweils als unfreundlich, moderat und freundlich zurückhaltend
auf. Der Unfreundliche
kritisiert dabei, kann laut, bedrohlich oder auch körperlich
aggressiv
sein, z.B. mit einem Tritt in den Bauch in weniger rechtsstaatlich
orientierten
Ländern, oder einen Tritt gegen den Tisch in zivilisierteren
Gegenden.
Der Moderator schickt dann den "ausgeflippten" Kollegen kurz raus, der
Freundliche bietet vielleicht eine Zigarette an. Zweck ist es dabei vor
allem, den Unterschied zwischen einem freundlichen und unfreundlichen
Ansatz zu demonstrieren, wobei der Verdächtige sich eher dem
freundlichen Vernehmer zuwenden wird.
Da diese Technik jedoch schon so abgedroschen und bekannt ist; jeder
hat sie schon mal in einem Vorstellungsgespräch erlebt;
sind die Gegenmaßnahmen hinlänglich bekannt. Dem
Unfreundlichen wird freundlich begegnet, dem Freundlichen dagegen
unfreundlich. Nicht zuletzt deshalb wechseln die Vernehmer dann
ebenfalls die Rolle, es
soll ja vor allem die Differenz zwischen beiden Verhaltensweisen
demonstriert werden.
Die Technik kann als Teil anderer Techniken benutzt werden, z.B. in
Stufe 3 der Reid-Methode.
Exkurs: Die üblichen
Verdächtigen
Sowohl bei der Entwicklung als auch beim produktiven Einsatz von
IT-Systemen lassen sich jeweils ein Paar üblicher
Verdächtiger ausfindig machen, wobei die Verdächtigungen
innerhalb des Paares auf Gegenseitigkeit beruhen.
Während der Entwicklung eines IT-Systems verdächtigt das
Entwicklerteam die Fachanwender, nicht alle relevanten Informationen zu
kommunizieren, nicht zu priorisieren, nicht rechtzeitig Arbeitspakete
zu erledigen, sich zu weigern Entscheidungen zu fällen und
generell nicht zu kooperieren. Im Gegenzuge verdächtigen die
Fachanwender die IT-Leute, dass sie nicht alle Anforderungen umsetzen
wollen, kein Verständnis für die Prioritäten des
Fachbereichs aufbringen, das Projekt
verschleppen, "offensichtlich" einfache Anforderungen verkomplizieren,
das Projekt verteuern und generell nicht zu kooperieren.
Im produktiven Einsatz funktioniert gelegentlich ein IT-System nicht
so, wie es der Fachanwender erwartet. Üblicherweise wird dann das
IT-System und letztendlich das Entwicklerteam verdächtigt, einen
Fehler gemacht zu haben. Die Beweislast wird dem IT-Team zugeschoben,
aus einer juristisch korrekten Unschuldsvermutung wird eine
IT-Schuldvermutung. Das IT-Team wiederum verdächtigt die
Fachanwender, das System nicht korrekt zu bedienen. - Tatsächlich
liegt bei einem etablierten
System, das schon einige Monate oder Jahre im Einsatz ist, fast immer
ein Bedienfehler vor. Da man allerdings die Nicht-Existenz von etwas
nach üblicher wissenschaftlicher Denkweise nicht beweisen kann,
bleibt es regelmäßig am IT-Team hängen, die Effekte
des Systems nachzuvollziehen und dem Fachanwender am Ende seinen
Bedienungsfehler
nachzuweisen.
Fragetechnik in der
Anforderungsanalyse
Wie schon mehrfach betont sucht man auch oder gerade bei IT-Projekten
nach Lösungen, nicht nach Schuldigen. Gewisse Parallelen zu
Vernehmungstechniken lassen sich zwar gelegentlich erkennen, die Ziele
sind jedoch unterschiedlich. Im Rahmen einer Befragung soll der
Befragte zur Kooperation
bewegt werden: die Kooperation einer Person, die eines Verbrechens
verdächtigt wird, wird mit einem Geständnis gleich gesetzt;
die Kooperation eines Fachanwenders liegt ähnlich, er soll
für die Entwicklung relevante Informationen liefern. Auf einen
Verdächtigen kann Druck ausgeübt werden, die Kooperation kann
bis zu einem gewissen Maß erzwungen werden. Ähnlicher Druck
auf Fachanwender ausgeübt wird allerdings zu einer Blockadehaltung
führen. Der Fachanwender kann das "Verhör" auch jederzeit
abbrechen, ein eines Verbrechens verdächtigter allerdings nicht.
Nach meinen Erfahrungen eignet sich
folgende Vorgehensweise am ehesten:
- Entspannung der Situation. Der Fachanwender soll sich sicher
fühlen, insbesondere muss er die Sicherheit haben, dass er
für Fehler, die aus seiner Initiative und Unterstützung
für das Projekt versehentlich entstehen, nicht bestraft wird.
- Darstellung eines Prozesses, der hinterfragt werden soll, z.B.
durch einen Walkthrough.
- Eine starke positive Stimmung erzeugen, z.B. durch den expliziten
Dank für die bisherige gute Kooperation und Anerkennung für
erbrachte Leistungen. Hierdurch
soll der Wille zur Kooperation gefördert werden.
- Hinterfragen, ob man selbst (also der Analytiker), einen Fehler
gemacht hat. Appell an den Fachanwender, bei der Fehlersuche
zu helfen. Situationsabhängig kann Unglaube ausgedrückt
werden, dass der Prozess wirklich schon vollständig oder korrekt
sei, man hat "ein intuitiv schlechtes Gefühl", könne dies
aber nicht
begründen. Alternativ kann der Glaube kommuniziert werden, dass
der Prozess bereits richtig bzw. fast richtig sei, und man ein gutes
Gefühl hat. Sofern man logische Widersprüche gefunden hat,
oder aus einer anderen Quelle zusätzliche Informationen vorliegen,
können diese als "Beweismaterial" dargelegt werden. Es ist die
Regel, dass die erste Beschreibung eines
Prozesses, die mit einem Fachanwender z.B. in einem Interview
erarbeitet
worden ist, logische Widersprüche enthält oder offensichtlich
unvollständig ist. Die Vorlage solch "konkreten" Beweismaterials
ist sehr wichtig, da sonst eine gewisse Gleichgültigkeit oder
Gutgläubigkeit
("passt schon") entsteht, die die weitere Verbesserung bzw.
Vervollständigung der Prozessbeschreibung untergräbt. Wichtig
ist, dass das Beweismaterial nicht zu Vorwürfen führt,
sondern als Aufhänger benutzt wird, der Prozess-Beschreibung zu
misstrauen und sie zu verbessern.
- Korrektur der gefundenen Lücken bzw. Widersprüche,
sofern welche vorhanden waren. Dabei werden klare ja-nein-Fragen
gestellt. Alle Abweichungen vom Thema oder Sinndiskussionen werden
strikt unterbunden. Man kann die Themen sammeln und später
bearbeiten ("Ein guter Punkt, den ich mir notieren will. Lassen Sie uns
darauf zurück kommen,
wenn dieser Prozess korrigiert wurde." - Man sollte natürlich
wirklich diesen Punkt später wieder aufgreifen.)
- Hinterfragen der Vollständigkeit des Prozesses.
- Hinterfragen der Richtigkeit des Prozesses.
- "Freundlichen" Druck erzeugen, z.B. durch die Aussage: "Ich
bekomme ziemlichen Ärger, wenn der Prozess jetzt nicht korrekt und
vollständig ist." oder "Es gibt keinen Weg zurück. Wenn die
Implementierung erst begonnen hat, wird jede weitere Änderung sehr
teuer." Damit soll erreicht werden, dass sich der Fachanwender auch
noch nach dem Treffen mit der Thematik auseinander setzt, wobei es egal
ist, ob dies bewusst oder unbewusst geschieht.
- Entspannung der Situation und Appell, sich die Prozesse nochmals
durch den Kopf gehen zu lassen. Sofern es wahr ist, kann man z.B.
sagen: "Ich habe jetzt ein gutes Gefühl, dass wir den Prozess
korrekt abgebildet haben. Wenn Ihnen noch etwas einfällt, dann
lassen Sie es mich wissen. Ansonsten beantrage ich übermorgen den
Review."
- Rückfrage einen oder zwei Tage später, ob dem
Fachanwender noch etwas eingefallen ist.
Bei all dem sollte man weder sich noch seinen Ansprechpartner
belügen. Beim dritten Schritt sollte man Feedback-Regeln im Auge
behalten: Zuerst das Positive, dann das Negative. War die Kooperation
bislang nicht all zu gut, so kann man dies kommunizieren und Anregungen
zur weiteren Arbeitsweise platzieren, muss aber darauf achten, keine
Blockade-Haltung zu erzeugen.
Mich würde Ihre Vorgehensweise interessieren! Kontakt
Entspannung der Situation
Eine wie auch immer geartete Benutzerbefragung ist eine
anstrengende Angelegenheit. Konzentriertes Arbeiten, evtl. verbunden
mit Zeit- und Erfolgsdruck, ist nicht jedermanns Sache. Die Einleitung
sollte eher zu einer entspannten Situation führen, in der sich
der befragte Fachanwender sicher fühlt. Eine Tasse Kaffee zusammen
mit einem kurzen Gespräch über den letzten Urlaub kann hier
Wunder wirken. IT-Mitarbeiter und somit auch Analytiker werden
häufig
als Wesen aus einer fremden Welt betrachtet, man sollte also klar
demonstrieren, dass man auch nur ein Mensch ist.
Nachdem die eigentliche Arbeit getan ist, sollte man sich auch noch ein
paar Minuten gönnen, um die Anspannung wieder abfallen zu lassen.
I.d.R. wird man dabei nochmals die Arbeitsergebnisse der Befragung
rekapitulieren und sehr häufig fallen dann noch Unklarheiten auf.
Evtl. gibt man sich auch noch Feedback, ob die Kooperation in dieser
Form zufrieden stellend war und was man verbessern könnte.
Die ja-nein-Frage
Computer arbeiten binär, Software ist letztendlich
nichts anderes als eine Abfolge von ja-nein-Verzweigungen. Für
einen Menschen ist auch eine ja-nein-Frage die am leichtesten zu
beantwortende Frage. Im echten Leben gibt es jedoch auf die
ja-nein-Frage häufig noch eine dritte Antwort: ich weiß es
nicht, bzw. ich bin mir nicht
sicher. Für eine Analyse ist es weitaus besser, ein ehrliches "ich
weiß es nicht" zu hören und die korrekte Klärung der
Frage abzuwarten, als eine vermeintlich korrekte Antwort zu erhalten,
die die weitere Analyse nachhaltig beeinflusst und die Wochen
später revidiert wird.
Typische ja-nein-Formulierungen sind:
- Ist das so? Stimmt das so?
- Wenn die Bedingung A gegeben ist, dann wird B gemacht, sonst wird
C gemacht. Ist das so richtig?
- So lange die Bedingung X gegeben ist, wird Y gemacht. Ist das so
ohne eine einzige Ausnahme richtig?
Stellt man eine ja-nein-Frage und der Befragte antwortet mit
ausschweifenden
Erklärungen, ohne ein klares Ja oder Nein von sich zu geben, dann
ist
die Situation verdächtig. Wahrscheinlich hat man die falsche Frage
gestellt:
was dem Frager einfach erscheint, ist in Wirklichkeit eine längere
Geschichte.
Man beachte hierbei eine alte Analytikerweisheit: "All difficult
questions
have a simple answer. And it is wrong." - Alle schwierigen Fragen haben
eine
einfache Antwort. Und sie ist falsch.
Das Antwort-Verhalten kann allerdings auch in der Person des Befragten
liegen. Manche Menschen geben prinzipiell keine direkten Antworten;
dann muss man hartnäckig bleiben. Es ist aber auch möglich,
dass der Befragte die Frage gar nicht verstanden hat, und nicht den Weg
einer direkten Rückfrage ("Das habe ich nicht verstanden,
können Sie es mir nochmals erklären?") wählt, sondern
das fehlende Wissen auf etwas verschlungenen Pfaden durch eine
Diskussion erarbeiten will, oder ganz einfach nicht zugeben will, dass
er die Frage nicht verstanden hat.
Gelegentlich will aber der Befragte nur vom Thema ablenken um eine
Festlegung
zu vermeiden, in politisch verzwickten Situation gar, um Verwirrung zu
stiften.
Eine Rückfrage ("Ich hatte eine Frage gestellt, die man mit ja
oder
nein beantworten kann. Ich verstehe nicht, weshalb dies nicht
geschieht.")
ist angezeigt, will man nicht versehentlich Antworten auf Fragen
bekommen,
die nicht gestellt wurden oder wesentliche Entscheidungen offen lassen.
Frage nach
Vollständigkeit
Die Frage nach der Vollständigkeit bedeutet lediglich, dass es
für jeden Weg in ein System hinein, also für jede Eingabe,
auch einen Weg hinaus gibt. Für alle bekannten Daten lassen sich
z.T. recht formale, z.T. intuitive Beweisverfahren abarbeiten. Offen
bleibt, was der Fachanwender alles nicht gesagt hat. Sehr
häufig arbeiten Fachanwender nicht mit Regeln sondern mit
Beispielsammlungen. Dabei werden zwar seltene, aber wichtige Ausnahmen
übersehen.
Beispiel aus der Praxis
Im Börsenbereich gibt es den Begriff "Pennystock".
Darunter versteht man alle Aktien, deren Kurswert kleiner als ein
Euro bzw. ein Dollar ist. Für eine Anwendung wurde eine
Aktienauswahl
von ca. 600 Werten getroffen. Das vom Kunden kommunizierte Regelwerk
schloss Operationen auf Pennystocks im Rahmen der Anwendung aus.
Hieraus
ließen sich bereits in der Frühphase der Analyse logische
Fehler in der Anwendung nachweisen, da ein Wert zwar anfangs oberhalb
eines Euros notieren, jedoch im Laufe der Zeit bei sinkenden Kursen zum
Pennystock werden konnte. Der Kunde gab hierzu die Auskunft, dass so
etwas bei den ausgewählten Werten praktisch nicht vorkommen
könne. Ein vom Analytiker als Domain-Experte befragter
früherer
Börsenhändler wollte gar eine Wette darauf abschließen.
Eine Sichtung des Datenmaterials ergab jedoch, dass etwa ein Prozent
der Werte knapp oberhalb eines Euros notierten, durchweg Werte
nicht-europäischer Unternehmen, die der frühere
Börsenhändler niemals näher betrachtet hatte. Im Laufe
der folgenden Tage nach der Sichtung fielen tatsächlich einige
Werte unter einen Euro. Die Erweiterung des Regelwerks für diesen praktisch
nicht vorkommenden Fall war unvermeidbar.
Typische Fragen, die gestellt werden können, um die
Vollständigkeit zu gewährleisten, sind:
- Gibt es hierzu noch mehr Beispiele?
- Gibt es Ausnahmen von der Regel?
- Gibt es alternative Wege?
- Was kann eigentlich alles schief gehen?
- Was ist das Schlimmste, das Ihnen mit diesem Vorgang passiert ist?
- Was ist das Schlimmste, das Sie sich vorstellen können?
- Ist diese Information / Liste / Sammlung vollständig?
- Wenn die Bedingung A gegeben ist, dann wird B gemacht, sonst wird
C gemacht. Ist A das einzige Entscheidungskriterium an dieser Stelle?
- Wenn die Bedingung A gegeben ist, dann wird B gemacht. Was wird
gemacht, wenn A nicht gegeben ist, sondern das Gegenteil von A?
- Muss ich noch mehr wissen?
- Wenn ich jetzt 1000.- wetten würde, dass ich
ein Szenario finde, mit dem der Vorgang nicht funktioniert, würden
Sie dann annehmen?
Frage nach Korrektheit
Eine Frage nach Korrektheit ist fast eine ja-nein-Frage, jedoch wird
der Befragte dabei ermuntert, seine Überlegungen laut kund zu tun.
Bei der Korrektheit geht es darum zu beweisen, dass ein Verfahren auch
das tut, was sich der Fachanwender vorstellt. Diese Vorstellung
kann erheblich von dem abweichen, was kommuniziert und auch
dokumentiert
wurde. An einer anderen Stelle auf diesen Seiten wurde ein Fallbeispiel
zitiert, in dem ein Fachanwender von ihm selbst definierte
Preisstaffeln
nicht mehr nachvollziehen konnte. Korrektheit kann man nur anhand
konkreter
Szenarien nachweisen, man führt sozusagen einen Schreibtischtest
aus. Sehr viele Fachanwender zeigen aber eine moderate
Verweigerungshaltung,
wenn es darum geht, mit Zeit- und Arbeitsaufwand Prozesse im Detail
nachzuvollziehen, von denen man doch weiß, dass sie
richtig sind.
Typische Fragen, um die Korrektheit einer Aussage zu
gewährleisten, sind:
- Ist dieses Zwischenergebnis richtig?
- Ist es egal, welche Werte (im Rahmen des definierten
Wertebereichs) hier verarbeitet werden?
- Können Sie mir bitte erklären, wie dieses Ergebnis zu
Stande kommt? (Ich habe gerade den Faden verloren...)
- Widersprechen sich diese Aussagen nicht?
- Was könnte man hier falsch machen?
- Was muss ich tun, um das System kaputt zu machen?
- Was müsste ich hier tun, um Sie wirklich zu ärgern?
- Wenn ich jetzt 1000.- wetten würde, dass ich ein Szenario
finde, das zu falschen Ergebnissen führt, würden Sie dann
annehmen?
Exkurs: Eskalation
Allgemeines
Die Eskalation ist ein Standardvorgehen im Konfliktfall. Normalerweise
lösen Mitarbeiter entstehende Konflikte innerhalb eines Projekts
auf gleicher Ebene nach sachlichen Kriterien und technischen
Erfordernissen. Es kommt jedoch regelmäßig vor, dass die
Priorisierung der anstehenden Fragestellung für beide Mitarbeiter
so hoch ist, dass sie den Konflikt nicht selbst lösen können
bzw. im Rahmen einer eigenverantwortlichen Entscheidung ihre
Kompetenzen überschreiten würden. In diesem Fall wendet man
sich an eine Schlichtungsstelle. Dies kann der gemeinsame Vorgesetzte
sein, in der Projektarbeit ist die erste Eskalationsstufe i.d.R. der
Projektleiter. Liegt der Konflikt projekt- oder
abteilungsübergreifend, dann lässt man den Konflikt von
seinem Vorgesetzten oder Projektleiter erledigen. Letzteres ist der
Regelfall, wenn ein Konflikt zwischen Fachabteilung und
IT-Projektgruppe entsteht.
Die Nicht-Anwendung dieses Standardvorgehens äußert sich
meist darin, dass ein Problem im Kreise herum geschoben wird, mehrfach
an bestimmten Leuten vorbei segelt, aber nicht gelöst wird. Das
Unverständnis des Eskalationsverfahrens kann dabei ziemliche
Blüten treiben und wird auf jeden Fall ein Zeitkiller,
Kostentreiber und es ist für die Projektmitarbeiter frustrierend.
Beispiel aus der Praxis (aus einer
Zuschrift)
In einem Projekt im Gesundheitswesen sollte ein OP-Planungssystem
eingeführt werden. Für die Analysephase wurden ein
OP-Pfleger und zwei Ärzte als
Ansprechpartner benannt. Einer der Ärzte wollte bestimmte
Dokumente zur Datenerfassung erstellt haben. Der Wunsch war kein
wirkliches Problem, der Arzt schickte den sogenannten
DGAI-Kerndatensatz zum Fachberater des beauftragten Systemhauses, der
daraus ein Konzept entwarf. Dabei entstanden einige Fragen, die dem
Arzt zugestellt wurden. Damit begann eine der wohlbekannten
Endlosschleifen: Der Arzt schickte das gleiche Dokument nochmals mit
dem Kommentar, der Fachberater solle es doch bitte aufmerksam lesen, da
stünde alles drin. Das ging mehrere Male so hin und her, bis es
zum Projektleiter eskaliert wurde (vom Systemhaus, nicht
vom Arzt, der im Hause des Projektleiters Mitarbeiter war). Die
Zuschrift endete mit dem Satz: "Die Probleme ließen sich in einer
moderierten Telefonkonferenz in etwa 20 Minuten beheben, aber durch die
präferierte Vorgehensweise waren etwa 4 Wochen Projektzeit
verloren gegangen."
In der Zuschrift zeigt sich noch ein zusätzlicher kritischer
Punkt: Sitzt der Projektleiter beim Auftraggeber, so wird der
Auftragnehmer stets etwas zurückhaltender sein, einen Konflikt zu
eskalieren, auch wenn er offensichtlich von einem Mitarbeiter beim
Auftraggeber verursacht wurde. Den konkreten Fall kann man durchaus als
Verletzung der Mitwirkungspflicht des Auftraggebers werten. Das Prinzip
der Eskalation ist im Hause nicht verstanden worden, noch schwerer
wiegt aber, dass der Projektleiter überhaupt erst nach 4 Wochen
vom Konflikt erfahren hatte. Weiterhin zeigt das Beispiel, dass bei der
Interaktion ein grundsätzlicher Fehler gemacht wurde: Wird eine
Informationsmenge (z.B. einige Dokumente) zur Verfügung gestellt,
und auf Basis dieser Informationsmenge werden Fragen gestellt, dann
darf nicht einfach davon ausgegangen werden, dass die
ursprüngliche Informationsmenge ausreicht. Statt dessen sollten
die Fragen ganz einfach beantwortet werden.
Die Eskalation will verstanden
sein!
Die Eskalation ist wie bereits erwähnt ein Standardverfahren,
allerdings eines, das häufig nicht verstanden wird
Niemand würde heutzutage noch auf die Idee kommen, sich auf Grund
einer Streitigkeit zu Duellieren, statt dessen wird eine
Schlichtungsstelle oder ein Gericht angerufen. Ungeachtet dessen gibt
es eine Menge Leute, die eine Eskalation mit petzen ("kann nichts
informell regeln"), Sturheit oder Uneinsichtigkeit ("gibt nie nach"),
Unselbständigkeit ("traut sich nicht, etwas selbst zu
entscheiden") oder Geltungssucht ("will sich profilieren")
gleichsetzen. Beschreitet man den Eskalationsweg vernünftig, so
ist dies nicht der Fall.
Allerdings gibt es auch tatsächlich einige Leute mit sozialen
Defiziten, die Eskalationen strategisch und nicht sachlich
einsetzen
oder es doch versuchen. Entscheidend sollten am Ende stets die besseren
Argumente sein. Insofern kann man der Eskalationsinstanz durchaus nach
Darstellung der objektiven Sachlage mitteilen, dass man selbst der
Meinung ist, dass die Eskalation nicht sachlicher Natur war. Ihr
Vorgesetzter wird sich seinen Teil denken, und zwar i.d.R. den
richtigen.
Sofern die eigenen Kompetenzen klar abgegrenzt sind, kann man auch
selbst entscheiden und eine Angelegenheit regeln, sei es nun auf
formellem oder informellem Wege. Die Eskalation wird nur dann
notwendig, wenn man außerhalb der eigenen Kompetenzen handeln
müsste. Häufig reicht schon eine informelle
Rückfrage beim Projektleiter, ob ein fraglicher Konflikt auf eine
bestimmte Weise eigenverantwortlich gelöst werden kann.
Frustrierend wird es bei einer "save my arse"-Mentalität. Geht die
Kontrolle in einem Projekt verloren und beginnt langsam die Suche nach
Schuldigen, anstatt nach Lösungen, dann tendieren manche Leute
dazu, jede Kleinigkeit zu eskalieren. Sofern man seinen Job gut gemacht
hat und auch solide belegen kann, dass man die fragliche Kleinigkeit
nicht perfekt genug erledigt hat, weil man wichtigeres zu tun hatte,
kann man solch eine Eskalation schulterzuckend akzeptieren und stets
auf die Unsinnigkeit derselben hinweisen. Da Kosten stets das
Hauptargument sind, wird es lächerlich, wenn die Eskalation selbst
teurer wird, als der Streitgegenstand. Nützlich ist es dann, bei
der Eskalationsinstanz seine Tätigkeiten recht genau nachzuweisen
und um eine Priorisierung zu bitten. Die Grundidee dahinter ist, dass
die strategischen Unternehmensentscheidungen und daher die
Priorisierung von Konflikten ("Was ist zu tun, was ist wichtig?") stets
eine Frage des Managements und nicht der ausführenden Stellen ist.
Beispiel aus der Praxis
In einem Projekt kochten die Emotionen langsam über.
Schließlich wurde jeder Pfurz eskaliert. Die Blüte war
schließlich, dass ein Mitarbeiter eine Präsentation zum
Projektstatus aus dem Stegreif machte, anstatt sie mit einer
schönen Präsentationssoftware mit einigen Stunden oder Tagen
Vorbereitungszeit durchzuführen. Der Vorfall wurde eskaliert Der
Mitarbeiter konnte belegen, dass er ca. 50h/Woche damit
beschäftigt war, die Produktion sicher zu stellen und für die
optisch ansprechende Vorbereitung einer rein berichtenden
Präsentation beim besten Willen keine Zeit hatte. Er stellte
lediglich lakonisch die Frage, ob die Produktion wegen der Vorbereitung
der Präsentation unterbrochen werden sollte, dann war das Thema
erledigt.
Eskalationswege
In jedem Projekt sollte es zwei formell definierte Eskalationswege
geben:
- Die reguläre Eskalation
für den Fall, dass ein Konflikt
auf gleicher Ebene nicht gelöst werden kann.
- Die Eskalation am Vorgesetzten
vorbei, für den Fall, dass
die Loyalität des Vorgesetzten in Frage gestellt werden muss, der
Vorgesetzte den eigentlichen Konfliktpunkt darstellt (z.B. weil er jede
Form von Initiative der Projektmitarbeiter blockiert und bestraft),
oder der
Vorgesetzte den Konflikt nicht befriedigend löst (meist mangels
Sachkompetenz, die zur Entscheidung notwendig ist, gepaart mit
mangelnder sozialer Kompetenz, dies auch zuzugeben und andere um Hilfe
zu bitten).
Es ist guter Stil, die Eskalationswege bereits in der Einladung zum
Kickoff-Meeting eines Projekts festzuschreiben.
Die reguläre Eskalation wird idealerweise einvernehmlich
vorgenommen. Die betroffenen Mitarbeiter stellen dabei gemeinsam fest,
dass sie nicht in der Lage sind, den Konflikt zu lösen, sammeln
gemeinsam ihre Argumente und formulieren auch gemeinsam
Lösungsvorschläge, die dann der nächsten
Eskalationsstelle vorgetragen werden. Dieses Vorgehen ist in
professionellen Arbeitsumgebungen der Normalfall. Die Alternative zu
dieser Form der Eskalation ist eine simple Nicht-Erledigung des
anstehenden Arbeitspakets. In seltenen Fällen verweigert eine der
beteiligten Parteien die gemeinsame Eskalation. Dann bleibt nichts
anderes, als die Eskalation nicht einvernehmlich durchzuführen,
will man nicht auf bessere Zeiten warten. Solch eine
Verweigerungshaltung hat grundsätzlich keine sachlichen
Gründe, das Vertrauensverhältnis zwischen den Parteien ist
dann meist schon gestört.
Die Eskalation am Vorgesetzten vorbei, also das Überspringen einer
Eskalationsstufe, sollte wohl überlegt vorgenommen werden. In der
Praxis ist dies eine seltene Ausnahme. Betroffen ist normalerweise der
eigene Projektleiter, und die Gründe für eine Eskalation an
der ersten Vertrauensperson im Projekt vorbei liegen auf der Hand: der
Projektleiter ist entweder technisch oder sozial inkompetent, oder er
verfolgt offensichtlich (persönliche) Ziele, die nicht mit dem
Projektziel
überein stimmen. Man sollte stets davon ausgehen, dass die
angerufene Instanz die übersprungene Instanz anspricht. D.h., dass
man genügend Material in der Hand haben muss, um die Eskalation zu
begründen. Typischerweise betreffen solche Eskalationen bzw.
Beschwerden stets dieselben Mitarbeiter, und man hat nur dann
Ärger zu erwarten, wenn man der Erste ist, der ein konsequentes
Fehlverhalten seines Projektleiters bemängelt. Man sollte
keinesfalls beim ersten Zweifel an seinem Projektleiter diesen
Eskalationsweg beschreiten, dagegen sollte der Projektleiter direkt auf
die Effekte seines Verhaltens angesprochen werden. Zeigt sich der
Projektleiter jedoch uneinsichtig und die anderen Teammitglieder oder
der Kunde bemängeln ähnliche Schwierigkeiten (d.h. man steht
mit seiner Überzeugung offensichtlich nicht alleine da), dann
lässt sich im Sinne des Projekterfolgs eine Eskalation nicht
vermeiden. Der Normalfall ist, dass solche Projektleiter früher
oder später abgelöst und schließlich unter irgend einem
Vorwand gekündigt oder weg gelobt werden.
home - top - Kontakt - letzter Update 14.6.2004 -
© Karl Scharbert