Frage ins Publikum
Was fällt Ihnen zur folgenden Frage ein:
Wie erschließt man sich komplexe Sachverhalte?
Stellen Sie sich vor, die Frage wird Ihnen von Frau Müller gestellt. Frau Müller ist IT-Spezialistin und arbeitet in der Firma X. Dort ist sie für die Kommunikation zwischen verschiedenen Abteilungen zuständig, in einer Art 'Vermittler- und Moderatorenrolle'. Wenn Herr Maier aus Abteilung_1 ihr nun etwas aus seinem Fachgebiet erklärt (irgendwas komplexes Kaufmännisches; Frau Müller ist keine Kauffrau), wie verhält sich Frau Müller dabei am besten? Was kann sie im Gespräch (oder später) beitragen, um den komplexen, ihr fachlich fremden Gegenstand möglichst sicher und 'gut' zu 'verstehen' (was heißt das eigentlich, und wann weiß sie eigentlich, 'ob'?) - um dann später anderen Menschen (Fräulein Weichbrodt in der Abteilung_2; die Leute dort sind weder ITler noch Kaufleute) davon berichten zu können?
[Ein kleines Schaubild dieser Kommunikationslandschaft folgt in Kürze!]
Wie erschließt man sich komplexe Sachverhalte?
Stellen Sie sich vor, die Frage wird Ihnen von Frau Müller gestellt. Frau Müller ist IT-Spezialistin und arbeitet in der Firma X. Dort ist sie für die Kommunikation zwischen verschiedenen Abteilungen zuständig, in einer Art 'Vermittler- und Moderatorenrolle'. Wenn Herr Maier aus Abteilung_1 ihr nun etwas aus seinem Fachgebiet erklärt (irgendwas komplexes Kaufmännisches; Frau Müller ist keine Kauffrau), wie verhält sich Frau Müller dabei am besten? Was kann sie im Gespräch (oder später) beitragen, um den komplexen, ihr fachlich fremden Gegenstand möglichst sicher und 'gut' zu 'verstehen' (was heißt das eigentlich, und wann weiß sie eigentlich, 'ob'?) - um dann später anderen Menschen (Fräulein Weichbrodt in der Abteilung_2; die Leute dort sind weder ITler noch Kaufleute) davon berichten zu können?
17 Kommentare - Kommentar verfassen - 0 Trackbacks
yonosequepasara - 14. Jan, 09:10
Aus eigener Erfahrung als eine solche Schnittstelle (was habe ich den Job geliebt!) zwischen Redaktion, EDV, Marketing, Vertrieb und Geschäftsführung:
- Zuhören. Und zwar richtig und vorbehaltslos, ohne der Einstellung: "Das check ich eh nie". Richtiges, interessiertes Zuhören wird vom Gegenüber bemerkt und honoriert.
- Nachfragen: Egal was, und egal, wie dämlich die Frage erscheinen mag. Es gibt keine blöden Fragen, nur blöde Antworten...
- Das vermeintlich Verstandene vereinfacht wiedergeben ("Kann man also sagen, dass es im Grunde so und so ist?"), da Erklärungen oft mit Details überfrachtet sind, die für das Gesamtbild nicht sehr von Belang sind. Außerdem treten so Verständnisprobleme sehr rasch zutage.
- Aktiv nach weiteren Faktoren nachfragen, die eventuell eine Rolle spielen könnten: Vieles wird stillschweigend vorausgesetzt.
acqua - 14. Jan, 09:14
Da kann ich nur noch wenig ergänzen:
Als erstes versuchen, das Grosse ganze zu erkennen: Wozu dient das Konzept? Wer macht damit was für wen?
Wenn man die Erklärung nicht versteht, sich genau überlegen, welchen Teil davon man nicht versteht oder ab welchem Punkt man abgehängt war und möglichst präzise danach fragen.
Als erstes versuchen, das Grosse ganze zu erkennen: Wozu dient das Konzept? Wer macht damit was für wen?
Wenn man die Erklärung nicht versteht, sich genau überlegen, welchen Teil davon man nicht versteht oder ab welchem Punkt man abgehängt war und möglichst präzise danach fragen.
books and more - 14. Jan, 11:47
Danke für die Antworten! Cool!
Mir fiel zusätzlich noch ein:
(1) Während des Gesprächs Bildchen und (ganz einfache) Diagramme malen, um zu visualisieren, was man verstanden hat. Dazu Feedback einholen: 'Ich habe das so verstanden. Ist es das?'
(2) Nach dem Gespräch kurze Zusammenfassung schreiben (vielleicht in Form einer nummerierten Liste der wesentlichen Punkte; bei zeitlich geordneten Abläufen ist das zugleich die Abfolge, die man glaubt verstanden zu haben). Dem Informationsträger zumailen und um Feedback bitten.
(3) Wenn es sich um eine ganze Sequenz von Gesprächen mit einem (oder wechselnden) Informationsträgern handelt, wesentliche Kernbegriffe der 'Wissenswelt' des Anderen nachschlagen, sich aneignen!
Anmerkung zu (3): Fachbegriffe sind oft mit Hintergrundtheorie aufgeladen. Eine Fremdwort-Deutschwort-Übersetzung genügt oft nicht. Es ist besser, das Wort als eingebettet in seine Theorielandschaft zu recherchieren, z.B. durch Wikipedia-Artikel und ein bisserl in den Querverweisen rumsurfen.
Mir fiel zusätzlich noch ein:
(1) Während des Gesprächs Bildchen und (ganz einfache) Diagramme malen, um zu visualisieren, was man verstanden hat. Dazu Feedback einholen: 'Ich habe das so verstanden. Ist es das?'
(2) Nach dem Gespräch kurze Zusammenfassung schreiben (vielleicht in Form einer nummerierten Liste der wesentlichen Punkte; bei zeitlich geordneten Abläufen ist das zugleich die Abfolge, die man glaubt verstanden zu haben). Dem Informationsträger zumailen und um Feedback bitten.
(3) Wenn es sich um eine ganze Sequenz von Gesprächen mit einem (oder wechselnden) Informationsträgern handelt, wesentliche Kernbegriffe der 'Wissenswelt' des Anderen nachschlagen, sich aneignen!
Anmerkung zu (3): Fachbegriffe sind oft mit Hintergrundtheorie aufgeladen. Eine Fremdwort-Deutschwort-Übersetzung genügt oft nicht. Es ist besser, das Wort als eingebettet in seine Theorielandschaft zu recherchieren, z.B. durch Wikipedia-Artikel und ein bisserl in den Querverweisen rumsurfen.
iqminimalist - 14. Jan, 12:24
Ergänzend zu den genannten Vorschlägen hat mir eine "Engpass"-Betrachtung oft weiter geholfen: wo steckt in einem komplexen System der Engpass, was wird dadurch ausgelöst/kann ausgelöst werden (Folgen, Konseqzenzen), und wie kann man dem begegnen? Dann hat man zumindest schon einmal den kritischen Punkt identifiziert.
books and more - 14. Jan, 16:04
Das ist sicher in vielen Fällen ein sehr nützlicher Fokus!
steppenhund - 14. Jan, 12:47
nicht ganz ernst gemeint
Es gibt keine komplexen Systeme - es gibt nur komplexe Erklärungen;)
yonosequepasara - 14. Jan, 12:58
Aber auch ja nicht so ganz unrichtig mit wahrem Kern.
Edit:
Was nicht auf einer einzigen Manuskriptseite zusammengefaßt werden kann, ist weder durchdacht noch entscheidungsreif.
Dwight D. Eisenhower
Edit:
Was nicht auf einer einzigen Manuskriptseite zusammengefaßt werden kann, ist weder durchdacht noch entscheidungsreif.
Dwight D. Eisenhower
steppenhund - 14. Jan, 13:10
Ich stimme mit einem lachenden Auge zu. In Hinblick auf den weiter unten stehenden Text wäre die eine A4-Seite das Kontextdiagramm, in dem alle zusammengehörigen Komponenten verbunden sind.
Ich habe aber vor ca. 5 Jahren ein Korollar dazu ergänzt. Eine Präsentation ist nur dann gut, wenn die Aussage der Präsentation auf einer Serviette Platz hat. Das habe ich einige Zeit so durchgezogen, dass es in meinen Präsentationen immer das eingescannte Bild einer Serviette mit der Aussage oder einem Bildchen vorhanden war:)
Ich habe aber vor ca. 5 Jahren ein Korollar dazu ergänzt. Eine Präsentation ist nur dann gut, wenn die Aussage der Präsentation auf einer Serviette Platz hat. Das habe ich einige Zeit so durchgezogen, dass es in meinen Präsentationen immer das eingescannte Bild einer Serviette mit der Aussage oder einem Bildchen vorhanden war:)
yonosequepasara - 14. Jan, 13:21
Die verhinderten Powerpoint-Designer vom VHS-Kurs heulen auf!
books and more - 14. Jan, 16:08
@Serviette
SEHR cool! Darf ich das mal kopieren und bei Gelegenheit anwenden?
Könnte man noch zielgruppenspezifisch weiterspinnen. Präsentation vor Ärzten: '... wenn es auf einem Rezeptblock Platz hat'. Vor Metzgern: '... wenn es auf einem mittleren Wiener Schnitzel Platz hat'. Vor Bäckern: '... wenn es auf die Oblate eines Elisenlebkuchens passt', etc.
Könnte man noch zielgruppenspezifisch weiterspinnen. Präsentation vor Ärzten: '... wenn es auf einem Rezeptblock Platz hat'. Vor Metzgern: '... wenn es auf einem mittleren Wiener Schnitzel Platz hat'. Vor Bäckern: '... wenn es auf die Oblate eines Elisenlebkuchens passt', etc.
steppenhund - 14. Jan, 13:07
konkret
Es war und ist teilweise einer meiner Jobs, Menschen diese Art von Kommunikation zu ermöglichen.
Was ich jetzt schreibe klingt kompliziert, ist aber bewährt im Austausch von Information zwischen Fachbereich und Entwicklern oder Testern oder auch Architekten.
Es gibt eine lingua franca für den Informationsübergang, die heißt UML (unified modeling language)
Dabei gibt es ein Diagramm, dass nennt sich Usecase-Diagramm. (zu deutsch Anwendungsfalldiagramm)
1997 war das eines einer der Schlüsselpunkte für die Software-Entwicklung in einem vernünftig steuerbaren Ablauf. Später wurde die Darstellungsmethode, die mit 5 Elementen auskommt, durch eine textuelle Usecase-Beschreibung ergänzt. (Alistair Cockburn: Effektives Schreiben von Usecases ... oder so ähnlich)
Was ist das Geheimnis dahinter?
Der Fachbereich denkt geschäftsbezogen. "Was soll ein komplexes System überhaupt leisten?" Statt seine Eigenschaften zu beschreiben, beschreibt man das, was der Anwender damit tun kann.
Was will er tun (da gibt es eine Reihe von sogenannten Anwendungsfällen)?
Was erzeugt den Wunsch, dass er was tut? (z.B. Anweisung vom Chef)
Was muss gewährleistet sein, etc.)
Was bekommt der Anwender, wenn er sich brav durchgeklickt hat?
...
Auf diese Fragen muss der Fachbereich antworten können - und das kann er meistens auch.
Dann kommt Frau Müller und bringt die Antworten in eine entsprechend formale Beschreibung. Pro Anwendungsfall reichen ca. 1,5 Seiten.
Durch die Beschreibung, lässt sich der Nutzen des Programmes wieder beschreiben.
Die unterbutterte Information "Warum das alles geschieht" stellt den magischen Klebstoff dar, die auch eine inhaltliche Rekonstruktion für eine weitere Person ermöglicht.
Als Software-Architekt hatte ich mit großen und größten Systemen zu tun.
Anwendungsfälle, Kontextdiagramm (wie sind die Einheiten miteinander verbunden) und Sequenz.Diagramme (Ablauffolgen) reichen mir in der Regel, um einen ziemlichen schnellen Überblick und gleichzeitiges Verständnis über ein System zu bekommen.
Ein nettes Beispiel wird in einem UML-Buch gezeigt, dass ungefähr "projektbezogenes UML" (drei deutsche Autoren) heißt.
Die oben genannten Merkmale wie Zuhören, Fragestellen sind natürlich unumgänglich.
Für ein strukturelles Verständnis ist es aber notwendig eine Abkürzungssprache zu verwenden. (So wie in der Mathematik, damit man nicht immer bei Adam und Eva beginnen muss.)
Ich kann die Effizienz dieser Methodik auch durch Praxis-Beispiele belegen. Es gehört auch beim Software-Test dazu, dass die Tester eben jenes Verständnis über die Anwendungsfälle besitzen.
(Aus Gründen der Eigenwerbung füge ich jetzt doch hinzu, dass ich selbst entsprechende UML-Schulungen und Usecase-Schulungen durchführe:) Es ist immer ein erhebendes Gefühl, wenn der Groschen dann so meistens am 2. Tag fällt und die Aussage zu hören ist: "So betrachtet ist das ja ganz einfach. Ist das wirklich alles?"
Was ich jetzt schreibe klingt kompliziert, ist aber bewährt im Austausch von Information zwischen Fachbereich und Entwicklern oder Testern oder auch Architekten.
Es gibt eine lingua franca für den Informationsübergang, die heißt UML (unified modeling language)
Dabei gibt es ein Diagramm, dass nennt sich Usecase-Diagramm. (zu deutsch Anwendungsfalldiagramm)
1997 war das eines einer der Schlüsselpunkte für die Software-Entwicklung in einem vernünftig steuerbaren Ablauf. Später wurde die Darstellungsmethode, die mit 5 Elementen auskommt, durch eine textuelle Usecase-Beschreibung ergänzt. (Alistair Cockburn: Effektives Schreiben von Usecases ... oder so ähnlich)
Was ist das Geheimnis dahinter?
Der Fachbereich denkt geschäftsbezogen. "Was soll ein komplexes System überhaupt leisten?" Statt seine Eigenschaften zu beschreiben, beschreibt man das, was der Anwender damit tun kann.
Was will er tun (da gibt es eine Reihe von sogenannten Anwendungsfällen)?
Was erzeugt den Wunsch, dass er was tut? (z.B. Anweisung vom Chef)
Was muss gewährleistet sein, etc.)
Was bekommt der Anwender, wenn er sich brav durchgeklickt hat?
...
Auf diese Fragen muss der Fachbereich antworten können - und das kann er meistens auch.
Dann kommt Frau Müller und bringt die Antworten in eine entsprechend formale Beschreibung. Pro Anwendungsfall reichen ca. 1,5 Seiten.
Durch die Beschreibung, lässt sich der Nutzen des Programmes wieder beschreiben.
Die unterbutterte Information "Warum das alles geschieht" stellt den magischen Klebstoff dar, die auch eine inhaltliche Rekonstruktion für eine weitere Person ermöglicht.
Als Software-Architekt hatte ich mit großen und größten Systemen zu tun.
Anwendungsfälle, Kontextdiagramm (wie sind die Einheiten miteinander verbunden) und Sequenz.Diagramme (Ablauffolgen) reichen mir in der Regel, um einen ziemlichen schnellen Überblick und gleichzeitiges Verständnis über ein System zu bekommen.
Ein nettes Beispiel wird in einem UML-Buch gezeigt, dass ungefähr "projektbezogenes UML" (drei deutsche Autoren) heißt.
Die oben genannten Merkmale wie Zuhören, Fragestellen sind natürlich unumgänglich.
Für ein strukturelles Verständnis ist es aber notwendig eine Abkürzungssprache zu verwenden. (So wie in der Mathematik, damit man nicht immer bei Adam und Eva beginnen muss.)
Ich kann die Effizienz dieser Methodik auch durch Praxis-Beispiele belegen. Es gehört auch beim Software-Test dazu, dass die Tester eben jenes Verständnis über die Anwendungsfälle besitzen.
(Aus Gründen der Eigenwerbung füge ich jetzt doch hinzu, dass ich selbst entsprechende UML-Schulungen und Usecase-Schulungen durchführe:) Es ist immer ein erhebendes Gefühl, wenn der Groschen dann so meistens am 2. Tag fällt und die Aussage zu hören ist: "So betrachtet ist das ja ganz einfach. Ist das wirklich alles?"
acqua - 14. Jan, 13:14
Ob dieser Kommentar nun aber auf eine A4 Seite passen würde? ;-)
yonosequepasara - 14. Jan, 13:16
Ja, ja, und ja.
Das einzige, was UML fehlt, ist eine Erweiterung zur "bosspersuasion".
"Ich weiß ja im Grunde schon, wie es gemacht gehört, aber ich lass euch mal machen und sage dann wie es zu laufen hat."
:-)
Welche Wohltat, wenn einem endlich die Kompetenz zugestanden wird, die man auch tatsächlich inne hat...
Edit: Kopieren, einfügen: ja, passt.
Das einzige, was UML fehlt, ist eine Erweiterung zur "bosspersuasion".
"Ich weiß ja im Grunde schon, wie es gemacht gehört, aber ich lass euch mal machen und sage dann wie es zu laufen hat."
:-)
Welche Wohltat, wenn einem endlich die Kompetenz zugestanden wird, die man auch tatsächlich inne hat...
Edit: Kopieren, einfügen: ja, passt.
acqua - 14. Jan, 14:42
Aber knapp und bei nicht allzu grosser Schrift.
steppenhund - 14. Jan, 15:21
Ich verwehre mich gegen diese Aussage. Eine Schriftgröße von 12pt gilt durchaus als großer und angenehmer Zeichensatz.
books and more - 14. Jan, 16:27
@Steppenhund
Vielen Dank für diesen gehaltvollen Beitrag, in dem ich sehr nützliche, ja geniale Anregungen für ein aktuelles Projekt gefunden habe! Morgen wird wieder Fräulein Amazon an der Haustüre klingeln ... :-)
Trackback URL:
http://booksandmore.twoday.net/stories/frage-ins-publikum/modTrackback