Benutzer Sicht
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (letzte Änderung) (keine anderen Diffs, Normalansicht)

Verändert: 1,2c1
Als Technischer Redakteur bin ich AnwaltDesBenutzers?.
Das erfordert, dass ich dessen Standpunkt und Blickrichtung einnehmen kann.
Als Technischer Redakteur bin ich Anwalt des Benutzers. Das erfordert, dass ich dessen Standpunkt und Blickrichtung einnehmen kann.

Verändert: 10,11c9,10
Der Benutzer hat eine Sicht von außen auf die Maschine. Er kann Dinge sehen, die der Entwickler nicht mehr sehen kann (ProduktBlindheit).
Der Benutzer erwartet also eine Dokumentation, die ihn im Blick von außen unterstützt. Das Innen interessiert ihn nicht, verwirrt ihn eher.
Der Benutzer hat eine Sicht von außen auf die Maschine. Er kann Dinge sehen, die der Entwickler (ProduktBlindheit) nicht mehr sehen kann .
Der Benutzer erwartet also eine Dokumentation, die ihn im Blick von außen unterstützt. Das Innen interessiert ihn nicht, verwirrt ihn eher.

Als Technischer Redakteur bin ich Anwalt des Benutzers. Das erfordert, dass ich dessen Standpunkt und Blickrichtung einnehmen kann.

Der Architekt, Designer, Entwickler, Inschenöör, kann der das?
Soll er das? Darf er das überhaupt?

Schließlich hat er seine EntwicklerSicht, die ihn dazu befähigt zu entwickeln.
Diese Sicht geht von innerhalb der Maschine aus.

Der Benutzer hat eine Sicht von außen auf die Maschine. Er kann Dinge sehen, die der Entwickler (ProduktBlindheit) nicht mehr sehen kann . Der Benutzer erwartet also eine Dokumentation, die ihn im Blick von außen unterstützt. Das Innen interessiert ihn nicht, verwirrt ihn eher.

-- GuntherWüsthoff


Diskussion

Ich stimme dem obigen nicht voll zu. Ich finde, ein SoftwareEntwickler sollte sich auch in die Lage des Benutzers versetzen können. Der SoftwareEntwickler ist ein Mittler zwischen dem Computer und dem Benutzer. Um diese Rolle auszufüllen, sollte er beide gleichermaßen verstehen und ihre Sichtweisen einnehmen können. Wenn er dies nicht kann, benötigt er zusätzliche Vermittler: z. B. den Berater, der eine Spezifikation erstellt; oder den Redakteur, der Inhalte in die Sprache des Benutzers überträgt. Dies reduziert potentiell die Qualität. -- HelmutLeitner

Dies ist idealistisch gedacht. Sehen wir uns die Realität an (ich greife in meinem Kopf auf sechs Projekte zurück, an denen ich zumindest als Beobachter beteiligt war):
Da ist die Entwicklungsfirma, die hat einen Vertrag mit dem Anwender und stellt ein geeignetes Entwicklerteam ab. Die Mitglieder des Teams haben jeweils einen Vertrag mit der Entwicklungsfirma. Da ist der Anwender (das ist die Firma, die die zu entwickelnde Software einsetzen will), die hat einen Vertrag mit der Entwicklungsfirma und mit allen ihren Angestellten. Was passiert jetzt? Alle ganz wichtigen Leute des Anwenders (z.B. Buchhalter, Controller) setzen sich mit den wichtigen Leuten des Entwicklerteams (Architekten) zusammen und bekakeln die Funktionalität der Software. Die Benutzungsschnittstelle ist standardisiert. Der Benutzer kommt in dem ganzen Spiel erst dann vor, wenn die Software in den produktiven Einsatz geht (die Testphase wird kostenhalber ausgelassen). Selbstverständlich ist der Benutzer dann unzufrieden. Die arme Maus, die möglichst schnell ihre gesammelten Buchungssätze in den Zehnerblock tasten will, muss sich durch unsinnige Menüs hangeln, um in völlig unübersichtlichen 'Masken' herumzurangieren, nicht ohne dabei buchhalterisch absolut überflüssige 'Kennziffern' eintippen zu müssen. Ich gebe zu, das hört sich übertrieben an. Aber das ist Realität. Die Buchhaltungsmaus hat nämlich keinen Vertrag mit dem Entwickler. Sie kann im Sehnenscheidenschadensfall zwar ihren Brötchengeber wegen Verletzung der Sorgfaltspflicht verklagen, aber ihr wird kaum ein Gericht recht geben. -- gw

Wir stimmen völlig überein. Diese beiden Situtationen sind Randbereiche eines Spektrums. Was du als idealistisch bezeichnest ist jedoch genauso in der Realität anzufinden, meist jedoch bei kleineren Projekten. Je größer Projekte werden, umso mehr Personen und Firmen sind beteiligt, umso größer werden die Probleme in der Kommunikation, Willensbildung und Informationsintegration. Das bedeutet jedoch IMO nicht, dass man diese oft chaotische, oft schlechte Qualität erzeugende Sitation zur Norm erheben soll. BenutzerSicht und EntwicklerSicht kategorisch zu trennen und für inkompatibel zu erklären, würde genau das tun. Deswegen mein Einwand. --hl

Der SoftwareEntwickler und auch der SystemAdministrator kann aber die BenutzerSicht nur zu einem gewissen Teil einnehmen, weil beide bis zu einem bestimmten Grad Grundwissen voraussetzen müssen. Die Frage ist dabei, wo hört Grundwissen auf, und wo beginnt das Fachwissen? Ein Beispiel: Während einer Schulung wies ich die Schüler an, die Maus nach oben, unten, links und rechts zu bewegen, um auszuprobieren, welchen Einfluß das auf den Mauszeiger hat. Da beklagte sich eine Schülerin, links und rechts würde funktionieren, aber oben und unten nicht. Bei genauerem Hinsehen bemerkte ich, daß sie die Maus vom Tisch anhob und so nach "oben" und "unten" bewegte. Das wirft das Problem für den SoftwareEntwickler auf, bis zu welchem Wissengrad er heruntergehen muß, um die BenutzerSicht einzunehmen. Wenn einem Fahrschüler das Autofahren beigebracht werden soll, muß man davon ausgehen, daß er den Unterschied zwischen nah und fern, schnell und langsam kennt. So stellt sich bei der Dokumentation immer die Frage: Welche Kenntnisse darf man beim EndBenutzer annehmen? -- lr

The only "intuitive" interface is the nipple. After that, it's all learned. -- Bruce Ediger, bediger@teal.csn.org, in news:comp.os.linux.misc, on X interfaces.


Thesen

These 1: Zwischen BenutzerSicht und EntwicklerSicht gibt es keinen fließenden Übergang.

Nehmen wir modellhaft an, die WeltRepräsentation? in meinem Kopf sei ein Netz (meinetwegen vieldimensional). Dieses Netz ist anfangs größtenteils sehr weitmaschig und wird mit Zunahme von Wissen (Welterfahrung) enger gemascht (neues Wissen erzeugt (irgendwann) neue Knoten). Hierbei sei angenommen, dass Wissen aus eigener Erfahrung sehr bald Knoten erzeugt, regelhaft aufgenommenes (Schul-)Wissen jedoch zunächst nicht, weil der Ort des Knotens nicht ohne Weiteres bestimmbar ist. Erst nach einer Verifizierung wird ein Knoten geknüpft. end model

Nehmen wir an, beim Entwickler E sei der Bereich X der Topographie seines Weltrepräsentationsnetzes für die Entwicklung von Software zuständig und der Bereich Y für die Benutzung von Software.

1. Frage: Überschneiden sich X und Y bei E notwendigerweise?

--gw /to be continued


Gedanken

Ist die Situation nicht ähnlich wie zwischen Schüler, Lehrer und Universitätsprofessor? Je weiter das Wissen der Personnen auseinanderklafft, umso schwieriger wird die Vermittlung von Wissen. Der technische Redakteur mag wie der Lehrer auf die Wissensvermittlung spezialisiert sein und dafür eine besondere Ausbildung und/oder Begabung haben, aber eine Garantie gibt es dafür nicht. So gibt es Uni-Professoren, die ihr Wissen einfach, interessant und auf jedem Niveau vermitteln können; und Lehrer ohne pädagogisches Talent. --hl

Das kann ich in diesem Zusammenhang nicht sehen. Du sprichst hier einerseits von einer linearen Skala vom Nicht-Wissen zum Wissen, andererseits um, sagen wir neutral, gute und schlechte Vermittlung von Wissen.
Die Differenzierung von BenutzerSicht und EntwicklerSicht setzt gerade voraus, dass beide sich bereits in einem Fachgebiet bewiesen haben (Prinzip der gleichen Wertigkeit). --gw

Habe ich schlecht ausgedrückt. Zwischen einem auseinanderklaffendem Wissen (Wertigkeit) und auseinanderklaffender WissensRepräsentation (Gleichwertigkeit) sehe ich keinen fundamentalen Unterschied. In beiden Fällen muss bei der Kommunikation berücksichtig werden, dass die Partner unterschiedliche Standpunkte, Interessen, Begriffe, Sprache ... haben. D. h. der eine muss sich in die Situation des anderen versetzen können. --hl

Ich will meinen letzten Punkt in Bezug auf den Begriff 'Sicht' etwas vertiefen. (Habe ich nicht irgendwo hier über Paramecium caudatum geschrieben?) Die Sicht (des Benutzers und des Entwicklers) entsteht aus der Praxis des alltäglichen Lebens. Dabei dauert es nicht lange, bis elementare natürliche Wirkmechanismen ihre Spuren in der Hirnvernetzung hinterlassen: Implikation als Folge von Adaption. Übersetzt nach deutsch: Stillschweigende Annahmen als Folge von Gewöhnung (...Angewohnheiten).

So.

Und das bedeutet, dass jeder sich dem Anderen wohlmeinend und wohlwollend beliebig weit zuneigen kann, er wird seinen eigenen Blickpunkt (seine Sicht) nicht verlassen und den Anderen nur bedingt verstehen können. Alles andere würde die Rück-Programmierung des eigenen Hirns erfordern. (Nicht schlecht! Leider nur mit sehr, sehr viel Aufwand in sehr, sehr engen Grenzen möglich.)

--gw


KategorieDokumentation KategoriePhilosophie
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 19. Januar 2005 0:03 (diff))
Suchbegriff: gesucht wird
im Titel
im Text