Blog

Mit 7x Kommunikation dem Nadelöhr Software-Entwickler begegnen

Wie Kommunikation das Wissen der User in Ihre Software bringt.

Ausgehend vom Nadelöhr Software-Entwickler haben wir in den vergangenen Wochen laut nachgedacht, welche Ansätze nachweisbar die Entwicklungsressourcen schonen. Die kompakten Zusammenfassungen sorgten für einige Aufmerksamkeit.

Fortsetzend widme ich mit diesem Artikel ausschließlich der Kommunikation während der Software-Entwicklung. Zur ihr gibt es so viel zu wissen, dass ich den kurzen Themenanriss aus dem letzten Artikel vertiefen möchte.

Kommunikation kostet Sie die Qualität

Kommunikation ist mehr als Reden. Wie soziale Faktoren den zwischenmenschlichen Informationsfluss vom Anwender bis hin zum Entwickler prägen, verdeutlicht unter anderem das Vier-Ohren-Modell von Friedemann Schulz von Thun.

Für Ihre Anforderungsentwicklung hat das weitreichende Folgen. Mit der Absicht die umsatzstarken Anforderungen zu identifizieren, machen Ihnen menschliche Eigenschaften wie Primacy & Recency Effekt oder Halo-Effekt einen Strich durch die Rechnung. Ohne etablierte Gegenmaßnahmen verhindert jeder dieser Effekte eine wiederholbar hohe Qualität.

Moderierte Kommunikation für lohnende Entscheidungen?

Mittels Moderation sind Entscheidungen zielführend und schnell zu treffen. Professionelle Moderation versachlicht die Diskussion der Argumente und setzt Methoden für objektive Entscheidungen ein. Mit ihr sind die sozialen Einflüsse wie Hierarchieeffekte oder soziale Erwünschtheit zu Gunsten umsatzstarker Entscheidungen auszuschließen.

Im Kontext Ihrer Software-Entwicklung brauchen Sie jedoch spezialisierte Moderationsmethoden, um die erfolgreichen Anforderungen für Ihre Software vorherzusagen. Sie erst sorgen für nachhaltige Ergebnisse in der persönlichen Kommunikation.

Persönliche Kommunikation für erfolgreiche Releases

Kommunikation kostet Zeit. Doch wurde die Kommunikation versäumt, ist der Preis um ein Vielfaches höher. Bortzenhardt und Maedche (2011) zeigen, dass erfolgreichen Releases signifikant mehr persönliche Meetings, persönliche Telefonate und Gruppenmeetings vorausgingen als den nicht erfolgreichen Releases.

Das Medium der Kommunikation

Neben der Häufigkeit der Kommunikation hat das Medium einen Einfluss auf den Informationsverlust, der Missverständnisse begünstigt. Unterhalten Sie sich Face to Face mit Kollegen oder Anwendern, ist Ihr Informationsverlust am geringsten. Vom Telefon bis hin zur E-Mail steigt Ihr Informationsverlust immer weiter an.

Artefakte schaffen Konsens

Entgegenwirken können Sie diesem Informationsverlust durch eine begleitende Kommunikation auf Basis von Artefakten. Mit einer Spezifikation allein entdecken Sie zu wenige der Akzeptanzhürden in einer Software. Um mehr Hürden zu finden sind aus Sicht der Problemlösepsychologie Arbeitsmittel nötig, die auf die Fachkompetenz der Beteiligten zugeschnitten sind. Wir nennen diese Artefakte.

Beispielsweise eignen sich UML Diagramme hervorragend für Entwickler, um die Software-Architektur zu diskutieren. Ein effizienter Austausch mit anderen Fachbereichen und den Endanwendern ist mit UML Diagrammen unmöglich. Hier sind je nach Entwicklungsfrage storytelling-basierte Szenarien oder UI-Prototypen hilfreich.

Ungeeignete Artefakte zur Kommunikation sind ein häufiger Grund für Missverständnisse mit den Kunden oder zwischen Bereichen mit unterschiedlichem Fachjargon.

Schnelles Feedback schafft Erfolg

Spät erkannte Missverständnisse mit den Endanwendern kosten extra. Dies erfahren Hersteller regelmäßig bei der Einführung ihrer Software.

In der Anfangszeit der Software-Entwicklung genügten die langen Wege der Kommunikation wie über den Vertrieb oder Support um etwaige Bedienprobleme zu beheben. Dieser Weg wird mehr und mehr zum K.O. Kriterium für die Software-Hersteller.

Ein vielfach schnelleres Feedback während der Entwicklung liefern Usability-Tests für eine gelungene Softwareeinführung. Mit einem Usability-Test tragen Sie mehr als 80% des Feedbacks innerhalb weniger Stunden bis Tage zusammen.

Bei Verzicht auf Usability-Tests erhalten die anwendernahen Fachbereiche das Feedback über mehrere Monate verteilt. Dieses kommt zumeist vereinzelt unter Informationsverlust in der Entwicklung an und hat ressourcenfressende Änderungen zur Folge.

Kommunikation leben

Dieser und die vorhergehenden Beiträge zeugen von den vielen Faktoren für effiziente Software-Entwicklung bei gleichzeitiger Schonung von Entwickler-Ressourcen. Die eigentliche Herausforderung liegt darin, den Nutzen der Maßnahmen im Unternehmen zu erfahren und zu realisieren.

Change Management heißt der Weg, mit dem Sie die notwendige Erfahrung in das Unternehmen bekommen. Basis für jede Art von Veränderung ist das Wissen, Ihrem Rohstoff der Zukunft. Das gilt für die Methoden genauso wie für die Befürchtungen derjenigen, die sie einsetzen.

Fazit

Kommuniziert Ihr Unternehmen intern effizient, entwickeln Sie Ihre Software mit hoher Usability schnell und zielgerichtet. So sparen Sie nicht nur wichtige Ressourcen in der Entwicklung, sondern vermeiden auch frustrierende Rückschläge. Mit der passenden Kommunikation verschaffen Sie sich außergewöhnlichen Erfolg.

Quelle: Nicola Döring. Kommunikation im Internet: Neun theoretische Ansätze. In Bernard Batinic (2000). Internet für Psychologen. 2. überarbeitete und erweiterte Auflage. Hogrefe Verlag für Psychologie.

Mit dem Kano-Modell effizient zur Kundenzufriedenheit

Wie Sie mit dem Kano-Modell das Optimum an Kundenzufriedenheit erreichen. Für Ihre Produktentwicklung ist es wichtig, Prioriäten zu setzen. Zwischen einer unendlichen Menge an Features muss entschieden werden, was letztendlich umgesetzt wird. Dabei ist es wichtig zu wissen, was Zufriedenheit bei Ihren Kunden auslöst. Das Kano-Modell liefert hier wichtige Erkenntnisse. Mit seiner Hilfe lassen sich Qualitätsfaktoren wie Features oder Aufgaben nach Ihrem Einfluss auf die Zufriedenheit klassifizieren. So wird das Budget und die zur Verfügung stehende Zeit effizient eingesetzt.

Das Kano-Modell ist seit Langem im User Research etabliert. Vom Japaner Noriaki Kano in den 1980er Jahren entwickelt, bereichert dieses Modell die Arbeit im Usabilitybereich vielfältig und qualitätssteigernd. Es hilft Ihnen dabei, ein differenziertes Bild der Einflussfaktoren auf die Kundenzufriedenheit zu gewinnen. Hierbei berücksichtigt es außerdem die in der Psychologie bekannte Unabhängigkeit von Zufriedenheit und Unzufriedenheit. Die zugehörige Untersuchungsmethode dient dazu, Eigenschaften eines Produkts hinsichtlich dessen Potentials zu klassifizieren.

Aus der Klassifikation lassen sich direkte Handlungsempfehlungen für Ihren Entwicklungsprozess ableiten. Sie erfahren, welche Produktmerkmale von Ihren Kunden zwingend erwartet werden. So messen Sie diesen wichtigen Faktoren die nötige Bedeutung bei. Ergänzend dazu, erfahren Sie, was Ihre Kunden begeistern würde. Gerade solche Informationen sind wertvoll, da diese sehr schwer zu gewinnen sind. Die Kano-Methode hilft Ihnen dabei, an diese oft unbewusste Bewertung zu gelangen.

Wollen auch Sie die Vorteile des Kano-Modells für sich nutzen? Zu diesem Zweck bieten wir Ihnen ein kostenloses E-Paper an. Es vermittelt in Kürze die Grundlagen des Modells und liefert Ihnen somit das nötige theoretische Verständnis.   Der Hauptteil bietet Ihnen eine beispielhafte um eine Durchführung zur Kano Methode. Von der Konzeption bis zur Auswertung beschreiben wir alle relevanten Schritte. Mit geringem Aufwand können Sie so zielgerichtet für die Bedürfnisse Ihrer Kunden entwickeln.

DIN EN ISO 15005

Die Grundsätze und Prüfverfahren des Dialogmanagements bezüglich Fahrerinformationssysteme sind in der DIN EN ISO 15005 definiert. Im Detail beschreibt sie Ihnen die Hauptkriterien wie Kompatibilität, Fehlertoleranz und Steuerbarkeit bei der Dialogführung in Kraftfahrzeugen. In Verbindung mit der DIN EN ISO 9241-110 bildet diese Norm das Zentrum bezüglich der Dialogführung in der Automobilindustrie.

Nadelöhr Software-Entwickler – Zeit, Kosten und Qualität

Wie Sie trotz Mangel an Entwicklern schneller hochwertige Software produzieren.

Aus dem Thema Nadelöhr Software-Entwickler ist ein Dialog zwischen Andreas Rudolph, dem Betreiber von produkt-manger.net und mir entstanden. Begeistert von den möglichen Lösungsansätzen setzen wir den Austausch in unseren beiden Blogs fort, um Ihnen einen Einblick in unsere Erfahrung zu gewähren.

Zeit, Kosten und Qualität in der Software-Entwicklung

Bisher haben wir mindestens die folgenden vier Faktoren herausgearbeitet, die den Software-Entwicklern Zeit sparen:

• Klare Anforderungen
• Anforderungen, welche die Probleme der Kunden lösen
• Automatisiertes Testen
• Förderung der Mitarbeiter

Alle Punkte halte ich für wichtig um dem Nadelöhr Software-Entwickler zu begegnen. Ergänzen möchte ich folgende Punkte:

Software-Entwickler sind keine Psychologen

Die Weiterbildung von Mitarbeitern ist wichtig. Das gilt ohne Frage auch für Entwickler. Mindestens genauso wichtig ist die Auswahl der Mitarbeiter nach dem Tätigkeitsfeld, in dem sie sich bewegen sollen.

In diesem Zusammenhang zeigt mir meine Erfahrung immer wieder, dass Informatiker beim Requirements Engineering anders vorgehen als Psychologen. Ein anwenderzentriertes Vorgehen spart mit den richtigen Methoden Zeit und Geld. Letztlich führt es so zu einer höheren Qualität der Software.

Automatisiertes Testen ersetzt keinen Usability Test

Beim Stichwort ‘automatisiertes Testen’ fallen mir reflexartig Usability Tests ein. Beide Ansätze verfolgen das Ziel die Qualität einer Software zu steigern. Was für die Technik mit der richtigen Infrastruktur automatisiert Zeit einspart, ist für Software mit User Interfaces nur zusammen mit Menschen möglich.

Zeit sparen Sie Ihren Software-Entwicklern mit Usability Tests indem Sie in der Anforderungsentwicklung Ihre UI-Prototypen durch die User bewerten lassen. Erkannte Probleme können Sie noch im User Interface Prototypen beheben. Diese sind einfacher und schneller weiterzuentwickeln als der fertige Code. Abgesicherte Anforderungen an ein User Interface Design ersparen Ihren Entwicklern die wiederholten Änderungen des Codes aufgrund von Geschmacksfragen.

Kommunikation ist mehr als Reden

Ausgehend vom Usability Test mit Usern komme ich zwangsläufig zur Kommunikation mittels einer Produktvision.

Eine klare Produktvision spart den Software-Entwicklern Zeit. Dies liegt am geteilten Wissen zu einem Produktziel. Wo das gegenseitige Verständnis fehlt, müssen die Entwickler Zeit aufwenden um sich austauschen und einander anzunähern.

Geteiltes Wissen schafft Verständnis in der Entwicklung. Über die Notwendigkeit jeder Anforderung entscheidet im ersten Schritt eine vorhandene Produktvision. Dieser Punkt ist genauso banal wie er häufig missachtet wird.

Auf weitere kostensparende Punkte im Zusammenhang mit der Kommunikation gehe ich gern im nächsten Teil ein.

Zusammenfassung

Die Möglichkeiten, mit denen einem Mangel an Software-Entwicklern zu begegnen ist, mehren sich. Mit der nachfolgenden Übersicht fasse ich die Maßnahmen noch einmal zusammen und zeige auch den jeweiligen Kollateralnutzen auf, den jede für mich hat:

Wie stehen Sie zu den genannten Maßnahmen um dem Mangel an Software-Entwicklern entgegenzuwirken? Beteiligen Sie sich gern an unserem Austausch und hinterlassen Sie einen Kommentar.

Nadelöhr Software-Entwickler

Wie Sie mit Hilfe der User Ihre Software-Entwickler entlasten.

Der IT-Branche fehlen Software Entwickler. Das verdeutlicht die Bitkom anhand der 32.250 offenen Stellen im September 2012. Software-Entwickler machen mit 75% den größten Anteil der 43.000 fehlenden IT-Experten aus.

Die Gründe für den Mangel an Software-Entwicklern sind vielfältig. Die Medien zitieren gern den fehlenden Nachwuchs oder die aufwändigen Programme auf dem Cloud-Server, welche die Apps erst so praktisch machen. Doch Software-Entwickler, die keine „Programmiersklaven“ mehr sein wollen, deuten eine weitere Sichtweise an.

Änderungen kosten die Software-Entwickler Zeit

Regelmäßig treffe ich auf Entwickler, die mir von widersprüchlichen subjektiven Meinungen zur Usability eines User Interfaces (UI) und daraus folgenden Änderungen an der Software erzählen. Aufgrund der wiederholten Änderungen können sich die Entwickler nicht den neuen Aufgaben widmen. Sie fallen im Zeitplan zurück. Das setzt eine Kettenreaktion in Gang, die zu Zeitdruck gefolgt von Frust führt. Darauf reagieren die IT-Hersteller gern mit einem höheren Bedarf an Sofware-Entwicklern. Kommt Ihnen das auch bekannt vor?

Maßnahmen gegen den Mangel an Software-Entwicklern

Aus Sicht der DIN EN ISO 9241-11 ist ein Großteil der wiederholten Änderungen vermeidbar. Die Norm fordert, unter den Entwicklern Konsens zum Nutzungskontext einer Software herzustellen. Dafür ist der Nutzungskontext aus Sicht der User zu beschreiben und zu bewerten.
Zu den wesentlichen Bestandteilen Ihres Nutzungskontextes gehören die Zielgruppe, Szenarien und das UI-Prototyping. Nachfolgend erhalten Sie einen kurzen Überblick zu ihrem jeweiligen Zweck.

1. Greifbare Zielgruppen mit Personas

Die Fähigkeiten und Fertigkeiten Ihrer Zielgruppe bestimmen, wie Ihre User Ihre Software samt User Interface Design verstehen. Mit Methoden wie der Persona machen Sie die Eigenschaften Ihrer User für alle Entwickler greifbar. Welche Eigenschaften der User Ihre Software berücksichtigen muss, um erfolgreich zu sein, erkennen Sie mittels einer psychologischen Anforderungsanalyse.

2. User verstehen mit Szenarien

Situative Faktoren wie Zeitdruck oder Schutzausrüstung sowie der Workflow prägen ebenfalls den Umgang der User mit der Software. Diese Informationen fließen in Szenarien ein. Sie verdeutlichen den Entwicklern die wesentlichen Einflüsse auf die Bedienung einer Software. Das notwendige Wissen für die Szenarien sammeln und priorisieren Sie effizient mit psychologischen Methoden.

3. User Interfaces effizient gestalten mit UI-Prototyping

Mit Personas und Szenarien herrscht unter den Entwicklern Konsens zu den Anwendern, deren Aufgaben und Situation. Darauf aufbauend finden Sie mit UI-Prototyping schnell ein Navigationskonzept, das allen Bedingungen des Nutzungskontextes genügt.

Fazit

Ein Vorgehen, das die Anwender effizient in die Entwicklung einbindet, spart die wertvolle Zeit der Software-Entwickler. Im Kern geht es darum, Software nicht auf der Basis von Annahmen zu entwickeln, sondern ausgehend von geteiltem Wissen.

Annahmen leiten überall dort die Entwicklung, wo Produktmanager,  Vertriebler und Co. ihre Erfahrungen mit den Anwendern unstrukturiert an Entwickler weitergeben. Das bietet unter anderem Platz für den Halo-Effekt.

Schaffen Sie unter Ihren Entwicklern wissensbasierten Konsens zu den Personas, Szenarien und UI-Prototypen. Auf Basis des Nutzungskontextes vermeiden Sie die teuren Änderungen an Ihrer Software und Frust bei den Entwicklern. So bringen Ihre Software-Entwickler mehr auf den Weg.

DIN EN ISO 14915 – 1-3

Die DIN EN ISO 14915 – 1-3 macht Ihnen die Gestaltungsgrundsätze und Rahmenbedingungen bezüglich Multimedia-Benutzungsschnittstellen deutlich. Sowohl Begriffe zum Thema Multimedia, als auch Leitsätze zu statischen und dynamischen Medien sind darin definiert.

In einem weiteren Abschnitt erhalten Sie hilfreiche Information zur Multimedia-Navigation und Steuerung. Beschrieben werden Navigationsarten, -strukturen, Steuerelemente und Möglichkeiten zur Verlinkung unterschiedlicher Inhalte.

Ziel dieser Teilnorm aus der DIN EN ISO 14915 – 1: Auswahl und Kombination von Medien ist es, Ihnen die Informationsarten wie beispielsweise begrifflichen oder räumlichen Informationen näher zu bringen. Mit Unterstützung von Tabellen und Abbildungen zeigt Ihnen diese Norm wie unterschiedliche Informationsinhalte auf geeignete Medienart (Präsentation des Inhalts) darzustellen sind.

Wie finde ich die sprichwörtliche Nadel im Heuhaufen? – oder: Wissensmanagement mit Microsoft SharePoint.

Wir freuen uns an dieser Stelle einen Gastbeitrag des Autors Andreas Könighofer von vision2feature – the sharepoint experts präsentieren zu können.

Ist Ihnen das auch schon einmal passiert? Sie glauben genau zu wissen, dass Sie oder ein Kollege etwas schon einmal gemacht und auch dokumentiert haben, Sie können sich nur beim besten Willen nicht erinnern, wer bzw. ob und wo und in welcher Form es abgelegt ist. Oft gibt man mit der Suche nach der Nadel im Heuhaufen dann irgendwann auf und beginnt, das Problem aufs Neue zu lösen. Das kostet wertvolle Zeit, Nerven und bringt Stress und im schlimmsten Fall Projektverzug mit sich, wenn es häufig vorkommt.

Stellen Sie sich jetzt vor, das geht nicht nur Ihnen sondern auch Ihren Mitarbeitern und Kollegen so. Wie viele Stunden, Tage, Wochen, ja Monate werden da in Ihrem Unternehmen wohl jährlich mit dem „Neuerfinden des Rades“ zugebracht?

Wissenschaftlicher Exkurs

Wie kann ich das ändern? Was hat das mit Wissensmanagement bzw. Microsoft SharePoint zu tun?  Und welchen Nutzen bringt Ihnen vision2feature?

Bevor ich diese Frage beantworte, zunächst ein kurzer Ausflug in die Begriffsdefinition von Wissen:

Zeichen

Kleinstes bei einer Programmausführung zugreifbares Datenelement (siehe auch Hansen, 1992), das aus Zahlen, Buchstaben und Zeichen jeder Art bestehen kann. (z.B.: 5)

Daten

Daten sind das Gegebene zur Verarbeitung ohne Verwendungshinweise (siehe auch DIN 44300, DIN 1972). (z.B.: 50)

Information

In den Kontext eines Problemzusammenhangs gestellte Daten sind Informationen (siehe auch Picot, 1988). (z.B.: Diese Tasse am Flohmarkt kostet 50 Cent.)

Wissen

Zweckorientierte Vernetzung von Information und besteht aus vielen Informationen (siehe auch Steinmüller, 1993). (z.B.: Verschiedene Merkmale der Tasse lassen auf ihren Ursprung in der Ming Dynastie schließen.)

Implizites Wissen (siehe auch Polanyi, 1958)

„Know-how“: Subjektive Einsichten und Intuition. Um implizites Wissen innerhalb einer Organisation speichern, verarbeiten und übertragen zu können, muss es dokumentiert und als explizites Wissen verfügbar gemacht werden (siehe auch Nonaka/Takeuchi, 1995).

Explizites Wissen (siehe auch Polanyi, 1958)

Der Wissende weiß von seinem Wissen und kann es mit Worten kommunizieren. Nur explizites Wissen ist für Organisationen nutzbar, in denen eine klassische Weitergabe von Wissen durch gemeinsame Handlungspraxis zwischen Lehrer und Schüler aufgrund der Größe, Verteiltheit oder Schnelligkeit der Organisation nicht möglich ist (siehe auch Nonaka, 1994).

 Wissensmanagement

Meint die Gesamtheit organisationaler Strategien zur Schaffung einer intelligenten Organisation (siehe auch Wilke, 2001).

Ich möchte den wissenschaftlichen Hintergrund nicht überstrapazieren und gleich zur praktischen Anwendung von Wissensmanagement in unserer Beispielproblemstellung kommen. Dazu bediene ich mich eines konkreten Instruments des Wissensmanagements, des Mikroartikels (siehe auch Wilke, 2001).

Ein gemeinsames Nadelverständnis – der Mikroartikel

Ein Mikroartikel hat den Sinn, den essentiellen Kern einer (normalerweise) individuellen Lernerfahrung, Idee, Überlegung, Kenntnis, etc. im Rahmen einer halben Stunde bis Stunde Aufwand auf maximal einer Seite in Worte zu fassen. Zur Erleichterung der Verfassung und Lesbarkeit von Mikroartikeln trägt eine durch den professionellen Dienstleister Ihres Vertrauens (z.B. Apliki) an das Unternehmen bzw. die Arbeitnehmer angepasste, gut konzipierte und standardisierte Vorlage essentiell bei.

Die wahre Bestimmung des geschriebenen Mikroartikels ist, dass er im Bedarfsfall gefunden wird und einen Wissenstransfer ermöglicht bzw. erleichtert. Ein solcher relevanter Mikroartikel repräsentiert in unserer Problemstellung die Nadel im Heuhaufen, die gefunden werden will. Und genau hier kommt die Expertise von vision2feature als Wissensmanagement Lösungsanbieter und SharePoint als Tool ins Spiel.

Wie finde ich nun die Nadel?

In einem eigenen Terminologiespeicher können in Microsoft SharePoint Metadaten bequem zentral angelegt und verwaltet werden. Diese Metadaten ermöglichen bei der Erstellung und Ablage von Dokumenten eine einheitliche (hierarchische) Kategorisierung bzw. Verschlagwortung derselben. Dokumente werden in SharePoint in sogenannten Dokumentenbibliotheken abgelegt. Dabei lassen sich je Dokumentenbibliothek verschiedene Inhaltstypen mit unterschiedlichen Metadaten und je Inhaltstyp eigene Dokumentenvorlagen hinterlegen.

Durch die zentrale Ablage und Verwaltung aller Dokumente in Microsoft SharePoint ist der Einstiegspunkt meiner Suche klar definiert. Jetzt habe ich als Suchender die Qual der Wahl:

Datensuche (beispielhaft)

• Titel
  Möchte ich nach dem Titel oder Teilbereichen daraus suchen?
• Inhalt
  Möchte ich nur oder auch den Inhalt durchsuchen?

Metadatensuche (beispielhaft)

• Verfasser
  Weiß ich, in wessen Zuständigkeitsbereich meine Problemstellung fällt und möchte nur nach Dokumenten mit dem entsprechenden Verfasser suchen?
• Erstellungsdatum
  Handelt es sich um ein kürzlich schon mal aufgetretenes Problem und kann ich den Erstellungszeitraum des Dokuments eingrenzen?
• Kategorien
  Lässt sich die Problemstellung einer Kategorie zuordnen und kann ich dadurch die Ergebnisliste verkürzen?
• Metadaten-Tagcloud
  Möchte ich kontextspezifisch suchen und die Möglichkeit einer raschen Eingrenzung der Resultate nutzen? Über mehrere abhängige Tagclouds lassen sich hier semantische Suchen innerhalb der Hierarchien der Metadaten-Terminologien implementieren.

Kombination
Die oben genannten Alternativen lassen sich natürlich auch kombinieren.

Da ist die Nadel!

In Bezug auf mein sprichwörtliches Beispiel mit der Nadel im Heuhaufen wird durch das Konzept und die Dokumentenvorlage des Mikroartikel ein einheitliches Nadeldesign und -verständnis geschaffen und die Verschlagwortung mit Metadaten eröffnet hocheffiziente Möglichkeiten, diese Nadel zu finden. Ich weiß nun, eine Nadel ist aus feuerfestem, ferromagnetischem Eisen, zünde den Heuhaufen an und hole die Nadel mit einem Magneten aus der Asche. Verbeugung. Vorhang.

Wir freuen uns über Feedback und Anfragen an vision2feature.

DIN EN ISO 10075 – 1-3

Die DIN EN ISO 10075 – 1-3 befasst sich mit den ergonomischen Grundlagen bezüglich psychischer Belastungen.

Der erste Teil erklärt Ihnen die Begriffe und konzeptionellen Zusammenhänge dieser Thematik. Allgemein richtet sich die Norm an die positive Beeinflussung von Arbeitsgestaltungsmaßnahmen an Bildschirmgeräten.

Im zweiten Teil der Norm werden Ihnen die Leitsätze zu diesem Thema erläutert. Diese behandeln die optimierende (und nicht minimierende) Gestaltung von Arbeitsaufgaben, – mitteln und -systemen. Sowohl die Beeinflussung der Intensität, als auch der zeitlichen Verlauf der Belastung finden hier Beachtung.

Teil drei behandelt die Erfassung und Messung psychischer Belastung und Beanspruchung. Er zeigt Ihnen die Anforderungen an den Mess-Verfahren auf, geht aber nicht auf die Verfahren selbst ein.

Die Norm gibt Gütekriterien für den jeweils zu messenden Gültigkeitsbereich (z.B. Belastung oder Monotonie) vor. Ziel dieses Abschnitts ist es, eine höhere Transparenz und bessere Beurteilungskriterien für den Anwender zu schaffen.

Messwiederholung zur Evaluation neuer Arbeitsmethoden

Wie Messwiederholung Ihre Arbeitsmethoden evaluiert.

Die stetige Weiterentwicklung eines Unternehmens erfordert die regelmäßige Erprobung neuer Arbeitsmethoden. Doch wie können Sie sicher beurteilen, ob diese auch wirkungsvoll sind? Die Evaluation mit Mitteln wie der Messwiederholung liefert hier die entsprechenden Werkzeuge.

Messwiederholung kompakt erklärt

Die beteiligten Komponenten sind:

• Die durchgeführte Veränderung, repräsentiert über zwei Zustände: Den Ursprungszustand und die abgeänderte Variante. In der empirischen Forschung bezeichnet man dies als unabhängige Variable. Unabhängig, weil Sie von Ihnen verändert werden kann. In der Softwareentwicklung ist dies beispielsweise die Einführung einer neuen Arbeitsmethode wie der Persona.
• Die Variable, die als Maß für den Erfolg dient. Dies ist ein Ergebnis, das für Ihr Produkt von Bedeutung ist. Im Entwicklungsprozess ist dies beispielsweise die Zufriedenheit der Anwender mit Ihrem User Interface Design. In der Statistik wird dies als abhängige Variable bezeichnet, weil Sie von einem Einfluss durch Ihre Maßnahme ausgehen.
• Eine Stichprobe, die zur Messung herangezogen wird. Diese sollte repräsentativ sein, um zuverlässige Rückschlüsse zu erlauben. Dies können sie beispielsweise darüber erreichen, sie zufällig zu ermitteln. Im konkreten Beispiel würden Sie so eine bestimmte Menge Ihrer Mitarbeiter für die Untersuchung auswählen.

Vorgehen bei der Wiederholungsmessung

Im Vortest befindet sich die unabhängige Variable noch im Ausgangszustand. Dies kann beispielsweise vor der Einführung einer neuen Arbeitsmethode der Fall sein. Nun erheben Sie mit einem Messinstrument die Sie interessierende Größe.

Anschließend wird die geplante Maßnahme umgesetzt und die selbe Messung, mit dem selben Instrument und den selben Teilnehmern erneut durchgeführt.

Ein statistischer Vergleich der zu beiden Zeitpunkten erhobenen Werte ermöglicht nun den Rückschluss auf das Ausmaß und die Richtung der Veränderung.

Mögliche Probleme

Ihr erklärtes Ziel ist es natürlich eine zuverlässige Aussage über den Evaluationsgegenstand treffen zu können. Also, ob die neue Arbeitsmethode zu einer Verbesserung geführt hat. In der Regel können eine ganze Reihe von Effekten Ihre Messergebnisse beeinflussen und verfälschen. Dazu gehören:

• Testeffekte: Dieselben Personen nehmen zweimal an derselben Untersuchung teil. Eventuell erinnern Sie sich an Ihre Antworten bei der ersten Durchführung und versuchen konsistent zu antworten, anstatt sich auf ihre aktuelle Situation zu beziehen.
• Zeiteffekte: Dies kann auftreten, wenn zwischen den beiden Messzeitpunkten auch andere systematische Veränderungen neben der interessierenden Maßnahme aufgetreten sind. Vielleicht wurde nicht nur eine neue Arbeitsmethode eingeführt, sondern es gab auch eine Welle von Gehaltserhöhungen bei Ihren Anwendern.

Fazit

Klar ist: Im Betrieb eines laufenden Unternehmens können Sie nicht alle Einflüsse kontrollieren. Schließlich soll die Evaluation sich möglichst störungsfrei in den Arbeitsalltag einfügen. Mit sorgsamer Planung können Sie aber beispielsweise die Untersuchung so terminieren, dass sie möglichst wenige Störeinflüsse vermuten müssen. Auf diese Weise erreichen Sie zuverlässige Maße, die Ihnen Auskunft über die Wirksamkeit neuer Arbeitsmethoden liefern.

Requirements Engineering ist keine psychologische Anforderungsanalyse

Was wir unter einer psychologischen Anforderungsanalyse verstehen.

Regelmäßig habe ich mit dem Requirements Engineering von IT-Herstellern zu tun. Meine Beobachtungen vermitteln mir den Eindruck, dass Requirements Enginering die Kunst ist, die eigenen Annahmen zu den Produktanforderungen zu dokumentieren. Anschließend sind sie als Bedarf der Anwender zu verkaufen.

Per Definition beschäftigt sich das Requirements Engineering damit, die Anforderungen des Auftraggebers für ein zu entwickelndes System zu erheben. Im besonderen Fokus steht dabei der Übersetzungsprozess zwischen Fachseite und Entwickler.

Psychologische Anforderungsanalyse

Dem gegenüber konzentriert sich die psychologische Anforderungsanalyse auf die Ableitung der Anforderungen aus dem Nutzungskontext. Dieser umfasst

• die Fähigkeiten der Anwender,
• die Situation, in der sie diese zeigen (sollen) und
• das organisatorische System, in dem sie agieren.

Psychologie für Requirements Engineering

Diesem Vorgehen nähern sich das Institute of Electrical and Electronics Engineers (IEEE) und das International Institute of Business Analysis (IIBA) an. Sie unterteilen das  Requirements Engineering in verschiedene Phasen und betonen auch die Aufnahme der Anforderungen bei den Stakeholdern.

Doch in den zumeist ingenieursgetrieben Projekten erlebe ich regelmäßig, dass die tatsächlichen User häufig nicht zu den Stakeholdern zählen. In diesen Fällen versuchen die IT-Hersteller „mit vielen Jahren Markterfahrung“ den Anwendungskontext ihres Produktes zu erahnen ohne das Konsens über die Eigenschaften der User besteht.

In diesem Punkt schaffen das systematische Vorgehen und die Methoden psychologischer Anforderungsanalyse Sicherheit. Während der Erhebung kann beispielsweise jeder ein Interview führen, doch nur trainierte Versuchsleiter wie Psychologen kommen effizient immer zu vergleichbaren Ergebnissen.

Ausgehend von diesen nachhaltigen Ergebnissen ist der Nutzungskontext bzw. Problemraum im Sinne des Problemlösens zu simulieren. Dieser setzt sich aus sogenannten Artefakten zusammen. Jedes Artefakt wird systematisch aus den gewonnenen Erkenntnissen abgeleitet. In ihrem Zusammenspiel schaffen sie Konsens über den Nutzungskontext eines Produktes.

Fazit

Das geteilte Wissen über den Nutzungskontext ist die belastbare Basis für die Übersetzung der Anforderungen also das Requirement Engineering. Für den Nutzungskontext ist nun eine Lösung, die Anforderungen, zu erschaffen, welche die richtigen aber zunächst unbekannten Anreize eines Produktes für den Markt sind. Zu den Marktanreizen eines Produktes zählen sowohl die Funktionen, für die Kunden Geld ausgeben als auch ein anwenderorientiertes User-Interface Design, das zu dauerhafter Kundenbindung führt.