Contextual Inquiry - Weshalb beobachten besser ist als fragen
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Contextual Inquiry - Weshalb beobachten besser ist als fragen

on

  • 523 views

Haben Sie alle relevanten User bei der Erhebung der Anforderungen einbezogen und trotzdem sind diese sind am Schluss unzfrieden mit dem Resultat? Meistens liegt es daran, dass die Anwender ihre ...

Haben Sie alle relevanten User bei der Erhebung der Anforderungen einbezogen und trotzdem sind diese sind am Schluss unzfrieden mit dem Resultat? Meistens liegt es daran, dass die Anwender ihre Anforderungen selbst formulieren, sei es in Workshops oder in Textdokumenten. Genau das aber fällt Anwendern schwer: Sie verstehen sich zwar ausgezeichnet auf ihre Arbeit, aber sie können nur unzureichend erklären, was sie tun und was sie benötigen. Die Methode der Contextual inquiry nimmt sich genau dieses Problems an: Statt Mitarbeiter zu befragen, werden diese bei ihrer Arbeit beobachtet. Wir führen in die Methode ein und zeigen anhand von Beispielen aus dem Projektalltag, wie damit vollständige Anforderungen erhoben werden und die Falle des «Wunschkonzerts» von Anforderungen vermieden wird.

Statistics

Views

Total Views
523
Views on SlideShare
523
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Contextual Inquiry - Weshalb beobachten besser ist als fragen Presentation Transcript

  • 1. © by Zeix 2014 Contextual Inquiry: Weshalb beobachten besser ist als fragen.
  • 2. © by Zeix 2014 2 Software … > Nervt. > Ist unintuitiv. > Ist mühsam zu bedienen. > Zwingt die Nutzer zu unnötigen Schritten. > Führt dauernd zu Fehlern und stürzt laufend ab. > Unterstützt die Nutzer beim Erledigen ihrer täglichen Arbeit. > Vereinfacht den Nutzern die Arbeit. > Hilft beim Vermeiden von Fehlern. > Steigert die Effizienz. > Macht Freude. > Hilft. Leider oftmals die Realität
  • 3. © by Zeix 2014 3 Um benutzerfreundliche Software zu entwickeln … … müssen die Benutzer in den Entwicklungsprozess mit einbezogen werden.
  • 4. © by Zeix 2014 4 User einbeziehen im Projektverlauf Anforderungs- erhebung / Analyse Konzeption/ Design/ Prototyping Umsetzung Betrieb & Optimierung Heute Fokus auf die Anforderungserhebung
  • 5. © by Zeix 2014 5 Die User fragen a) schriftlich
  • 6. © by Zeix 2014 6 Die User fragen b) In Bedürfnisworkshops ?
  • 7. © by Zeix 2014 7 User im Arbeitsalltag beobachten
  • 8. © by Zeix 2014 8 Erfahrungen mit den Methoden Die User fragen a) schriftlich Die User beobachten Die User fragen b) Bedürfnisworkshops
  • 9. © by Zeix 2014 9 > … können oftmals ihre Bedürfnisse nur ungenügend formulieren. > … formulieren ihre Anforderungen so, dass sie von anderen Personen (z.B. den Requirements Engineers oder UX Architects) > falsch verstanden werden oder > unterschiedlich verstanden werden. > … priorisieren eigennützig. Einzelne User …
  • 10. © by Zeix 2014 10 > … sind oft politisch ausgewählt. > … sind selber nicht oder nur begrenzt Nutzer der Software. > … verwechseln «Anforderungen» mit «Beschreiben der IST- Situation» > Meist dominieren einzelne Individuen die Meinung in der Gruppe. Die Teilnehmer von Bedürfnisworkshops …
  • 11. © by Zeix 2014 11 > Andere Menschen > Arbeitsteilung, Unterstützung, Kommunikation, Hierarchien > Die Arbeitskultur > Gesamte Arbeitsabläufe > Für eine Aufgabe zwischen Personen, für alle Aufgaben einer Person > Einbezug von Hilfsmitteln > Arbeitsumgebung > Äussere Bedingungen, Lichtverhältnisse, Platz, Lärm Der Kontext ist relevant Deshalb heisst die Methode «Beobachten am Arbeitsplatz» auch «Contextual Inquiry»
  • 12. © by Zeix 2014 12 > Wieso der gesamte Arbeitsprozess relevant ist für das Applikationsdesign. Projektbeispiel
  • 13. © by Zeix 2014 13 Projektbeispiel > Vereinheitlichung der Geschäftsprozesse nach Integration eines neuen Unternehmens Ausgangslage
  • 14. © by Zeix 2014 14 Projektbeispiel > Portal mit benutzerfreundlicher Darstellung der Geschäftsprozesse und Links auf Zusatzinformationen. > Beschaffung einer Software für die Abbildung und Verwaltung der Geschäftsprozesse. Projektziele
  • 15. © by Zeix 2014 15 Projektbeispiel > «Remote-Beobachtung» mit 7 Personen. > Mit Screen-Übertragung und per Telefon wegen räumlicher Distanz. > Befragung zur Art der Arbeit, Zusammenarbeit, Stärken und Schwächen der aktuellen Prozesse und Tools. > Details zu den verwendeten Tools und Systemen. Erhebung der Anforderungen
  • 16. © by Zeix 2014 16 Projektbeispiel > Erfahrung ist zentral für die Erledigung der Arbeit. > Information ist schwer auffindbar und oft nicht aktuell. > Regelmässiger Austausch und persönlicher Kontakt sind die wichtigsten Arbeitsinstrumente. > Workflow-Funktionalitäten sind eher sekundär. > Empfehlung: Ein zentraler Zugang zu den Systemen, Weisungen etc. , visualisiert gemäss dem Geschäftsprozess. Ergebnisse Anforderungsanalyse
  • 17. © by Zeix 2014 17 Projektbeispiel > Umsetzung der Systemanforderungen in einem klickbaren Prototyp. > Usability Tests (remote) mit 6 Personen. Überprüfung der Anforderungen
  • 18. © by Zeix 2014 18 Visualisierung macht urteilsfähig … … und vereinfacht die Kommunikation.
  • 19. © by Zeix 2014 19 Projektbeispiel > Anforderungen waren richtig verstanden und umgesetzt. > Erfüllung der Anforderungen konnte besser gewichtet werden. > Eine Anforderung, die in den Interviews als eher nebensächlich bewertet worden war, wurde durchgehend als sehr wichtig eingestuft. > Viele Details können optimiert werden, z.B. > Benötigte Tiefe der Information. > Unterschiedliches Verständnis von Prozessen und Definitionen. > Viele wichtige Zusatzinformationen am Ende des Nachinterviews. > Gewisse Diskrepanz zwischen Stärken des eingesetzten Tools und Benutzerbedürfnissen. Ergebnisse Usability Test
  • 20. © by Zeix 2014 20 Die User fragen a) schriftlich + Kostengünstig + Hoher Abdeckungsgrad unterschiedlicher User − Heterogenität von Qualität und Detaillierungsgrad der Anforderungen − Missverständnisse & Fehlinterpretationen − Führt zu Wunschkonzert Der Vergleich Die User beobachten + Arbeitskontext fliesst in die Anforderungen mit ein + Bessere Erfassung individueller Bedürfnisse + Bessere Gesamtprozess- betrachtung und – optimierung + Sehr gute Kooperation − Im Vergleich aufwändiger − Allenfalls die Arbeit störend Die User fragen b) Bedürfnisworkshops + Relativ kostengünstig − Einbezug der falschen Personen − Dominanz einzelner Personen − Falsche Priorisierung der Anforderungen − Häufig Kompromiss- Anforderungen − Führt zu Wunschkonzert
  • 21. © by Zeix 2014 21 Danke. Fragen können Sie nicht nur jetzt. Gregor Urech gregor.urech@zeix.com Andrea Rosenbusch andrea.rosenbusch@zeix.com