Fragen ist wichtig \u2013 wir k\u00f6nnen schlie\u00dflich nicht Gedanken lesen! Fragen stellen ist auch ein wichtiges Werkzeug bei der Erhebung von Anforderungen. In diesem Artikel gehe ich darauf ein, wie das Fragenstellen denn konkret realisiert werden kann.<\/p>\n
Ein Weg zum Fragenstellen sind \u00fcbrigens Umfragen. Ich habe schon \u00f6fter Umfragen durchgef\u00fchrt und auch hier ver\u00f6ffentlicht, wie bspw. die Umfrage zu Modellierungswerkzeugen<\/a>. Oder auch die Ergebnisse von anderen ver\u00f6ffentlicht, wie die Frage zur Bedeutung von Systems Engineering<\/a>.<\/p>\n Und ich m\u00f6chte diesen Artikel zum Anlass nehmen, meine Leserinnen und Leser zum Ausf\u00fcllen von einer\u00a0Umfragen einzuladen. Das Ergebniss wird\u00a0ver\u00f6ffentlicht, was f\u00fcr mich eine wichtige Voraussetzung zum\u00a0Weiterleiten ist. Das Thema ist\u00a0\u201eProduktentwicklung: Stand der Praxis\u201c (Englisch). Schon mal vielen Dank f\u00fcrs Helfen! Zur Umfrage >><\/a><\/p>\n Aber nun zu der Frage, wie man im Projekt richtig Fragen stellt, um an gute Anforderungen zu kommen.<\/p>\n Es ist leicht, falsch zu fragen: Ohne Vorbereitung zu Fragen ist keine gute Idee. Auch schlecht ist es zu Fragen, und das Ergebnis nicht zu nutzen (passiert leider viel zu h\u00e4ufig!). Auch zum falschen Zeitpunkt zu fragen kann ein Problem sein. Hier sind ein paar Richtlinien die helfen, richtig zu fragen.<\/p>\n Eine Umfrage<\/strong> ist ein Weg zu fragen. Diese l\u00e4sst aber keine Nachfrage zu, was im Gespr\u00e4ch<\/strong> m\u00f6glich ist. Dieses kann pers\u00f6nlich<\/strong> oder telefonisch<\/strong> gef\u00fchrt werden, oder sogar als Chat<\/strong> oder E-Mail-Dialog<\/strong>. Das pers\u00f6nliche Gespr\u00e4ch erlaubt es, die K\u00f6rpersprache mit einzubehiehen, das Telefonat immerhin noch den Sprachton. E-Mail (oder eine andere asynchrone) Technik sind hilfreich, wenn die andere Person wenig Zeit hat, oder in einer anderen Zeitzone lebt. Daf\u00fcr dauert dann das „Gespr\u00e4ch“ entsprechend l\u00e4nger.<\/p>\n Fragen k\u00f6nnen synchron oder asynchron, einzelnen oder Gruppen gestellt werden.\u00a0[tweetthis]Fragen k\u00f6nnen synchron oder asynchron, einzelnen oder Gruppen gestellt werden.[\/tweetthis]<\/p><\/blockquote>\n Gespr\u00e4che k\u00f6nnen auch in Gruppen durchgef\u00fchrt werden, was dann je nach Ausrichtung eine\u00a0Fokusgruppe<\/strong> oder ein Workshop<\/strong> sein kann (zu Workshops kann ich das Buch Workshops im Requirements Management<\/a> sehr empfehlen).<\/p>\n Den Fragen kann auch ein Kontext gegeben werden: Zum Beispiel kann man einem\u00a0Nutzer beim Arbeit \u00fcber die Schulter schauen, und dann fragen, warum er das eine so oder so macht. Dann wird aus dem Fragen eher ein Zeigen.<\/p>\n Gefragt werden sollten die Stakeholder<\/strong>, die hoffentlich ermittelt wurden. Dabei sind nicht alle Stakeholder gleich wichtig, und es ist durchaus akzeptabel, nicht alle Stakeholder (bzw. Repr\u00e4sentanten aller Stakeholdergruppen) zu befragen. Das Risiko, eine Stakeholdergruppe auszulassen, sollte allerdings bewertet<\/strong> werden.<\/p>\n Es ist auch nicht ungew\u00f6hnlich, das selbst wichtige Stakeholder nicht zug\u00e4nglich sind, aus welchen Gr\u00fcnden auch immer. Dann ist es wichtig, jemanden zu finden, der so einen Stakeholder zumindest einsch\u00e4tzen kann.<\/p>\n Die Ziele einer Befragung<\/strong> sollten klar verstanden und am besten schriftlich fixiert werden. Dann kann bei Erstellung des Fragenkatalogs darauf geachtet werden, dass auch alle Fragen zielf\u00fchrend sind.<\/p>\n In der Regel (aber nicht immer) sind offene Fragen<\/strong> zu bevorzugen. Offene Fragen k\u00f6nnen nicht mit Ja\/Nein beantwortet werden und haben den Vorteil, dass der Befragte in dessen Antworten nicht eingeschr\u00e4nkt wird. Allerdings m\u00fcssen\u00a0offene Fragen auch von Hand ausgewertet werden. Wenn viele Menschen befragt werden, etwa \u00fcber eine Online-Umfrage, dann bietet es sich an, Auswahlfragen<\/strong> zu stellen. Das erh\u00f6ht in der Regel auch die Anzahl der Antworten.<\/p>\n Fragen m\u00fcssen nicht in menschlicher\u00a0Sprache beantwortet werden: die Antwort\u00a0kann auch ein Bild sein.\u00a0[tweetthis]Fragen m\u00fcssen nicht in Sprache beantwortet werden: die Antwort kann auch ein Bild sein.[\/tweetthis]<\/p><\/blockquote>\n Eine Antwort muss \u00fcbrigens nicht unbedingt Schriftform<\/strong> haben: Eine Skizze oder ein Knetmodell k\u00f6nnen auch legitime Antworten darstellen.<\/p>\n Es h\u00e4ngt von der Zielsetzung ab, wann gefragt wird. Grunds\u00e4tzlich sollte so fr\u00fch wie m\u00f6glich gefragt werden, sobald ausreichend Information f\u00fcr die Frage zur Verf\u00fcgung steht. Ein Extrembeispiel: Um eine Befragung zum Fahrgef\u00fchl durchf\u00fchren zu k\u00f6nnen, muss zumindest ein Prototyp existieren, mit dem dieses bewertet werden kann.<\/p>\n Es sollte nicht \u00fcberraschen, dass Fragen stellen eine wichtige Aufgabe im Systems Engineering ist. Wenn jedoch nicht richtig gefragt wird, kann das zu Frust und schlechten Ergebnissen f\u00fchren. Sich ein paar Fragen zu den Fragen zu stellen zahlt sich aus!<\/p>\n PS: Nicht vergessen: Ich freue mich \u00fcber eine rege Teilnahme an der Umfrage \u201eProduktentwicklung: Stand der Praxis (Englisch).\u201c Jetzt Umfrage beantworten >><\/a><\/p>\nRichtig Fragen<\/h2>\n
Wie Fragen?<\/h2>\n
Wen Fragen?<\/h2>\n
Was Fragen?<\/h2>\n
Wann Fragen?<\/h2>\n
Fazit<\/h2>\n