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.
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.
Warum Sie den Nutzungskontext Ihrer Software nach DIN EN ISO 9214-11 einsetzen können, um Ihre Entwicklung zu beschleunigen.
Was ist ein Nutzungskontext?
Aus der DIN EN ISO 9241-11 können Sie entnehmen, dass Aussagen über die Usability einer Software nur für ein bestimmtes Umfeld gelten. Dieses Umfeld wird als Nutzungskontext bezeichnet. Die Norm fordert, dass die Aspekte des Nutzungskontextes reproduzierbar sind, die einen bedeutsamen Einfluss auf die Usability haben können. Doch warum fordert sie das?
Der Nutzungskontext ist Teil der Entwicklung
Entwickler merken mir gegenüber hin und wieder an, dass sie es keinem Recht machen können. Egal welche Lösung sie für ein User Interface Design vorschlagen, immer kommt ein neues Gegenargument. Warum das so ist, bleibt für sie verborgen. Erleben auch Sie Entwicklungsziele als sprichwörtliches Moving Target?
Hauptgrund hierfür sind die verschiedenen Annahmen der Beteiligten zum Nutzungskontext einer Software. Sie bilden die individuelle Basis für das Feedback zum User Interface. Erschwerend kommt hinzu, dass den Menschen im Moment ihres Feedbacks nur wenige Annahmen einfallen, auf die sie ihre Bewertung stützen. Nicht selten greifen sie beim nächsten Feedback sogar auf andere Annahmen zurück. Das liegt daran, dass Menschen Informationen besser wiedererkennen als sich aktiv an sie zu erinnern. Somit empfehle ich Ihnen, das Wissen zu Ihrem Nutzungskontext zu dokumentieren.
Die zumeist unausgesprochenen, vereinzelt erinnerten Annahmen stören die Effizienz, mit der die Rückmeldungen sinnvoll in die Entwicklung einfließen. Konsens im Verständnis des Nutzungskontextes fördert sowohl die Interface Qualität als auch die Effizienz der Entwicklung.
Den Nutzungskontext aktiv einsetzen
Der Nutzungskontext eines Software-Produktes richtet die Blicke von allen Beteiligten auf das Ganze. Betrachten Sie die Produktanforderungen einfach als die Funktionen, die vom Nutzungskontext abhängig sind. Nur zusammen ergeben Produktanforderungen und Nutzungskontext ein rundes Bild.
Die Psychologie bietet Ihnen reichlich Ansätze, wie Sie Menschen und ihre Umwelt beschreiben können. Wenden Sie diese auf die Produktentwicklung an, erhalten Sie verschiedene Arbeitsmittel, die zusammen den Nutzungskontext beschreiben. Strukturieren Sie Arbeitsmittel wie Vision, Persona, Szenario und Prototypen nach psychologischen Erkenntnissen, unterstützen Sie zudem die Erinnerung der Beteiligten für eine schnellere Entwicklung.
Der Nutzungskontext ist Ihre Basis für eine effiziente Entwicklung
Zusammenfassend fördert ein dokumentierter Nutzungskontext den Konsens in der Entwicklung. Zum Einen, weil er das Gedächtnis der Beteiligten unterstützen. Zum anderen, weil die Arbeitsmittel zur Beschreibung des Nutzungskontextes als Kommunikationsmittel dienen. Mit ihnen moderieren Sie die Kommunikation zwischen allen Beteiligten. Das beschleunigt Ihre Entwicklung enorm.
Schon der Philosoph Plutarch meinte: „Der Geist ist kein Schiff, das man beladen kann, sondern ein Feuer, das man entfachen muss.“
Bezüglich der Entscheidungsfindung in einem Kaufprozess ist das Feuer das Kaufbedürfnis. Entfacht wird es durch die menschlichen Motive. Nur Produkte, die zu unseren Motiven passen, zünden demnach das Kaufbedürfnis an. Dies und mehr muss Ihre Beratungs-Software oder Ihre Online-Shop berücksichtigen, um Menschen bei Kaufentscheidungen zu unterstützen.
Der Bauch entscheidet
Wie Sie wissen, muss das Bauchgefühl stimmen, um eine Wahl als richtig zu empfinden. Richten Sie das Layout und die Inhalte Ihres User-Interfaces-Designs an den Motiven Ihrer User aus. Diese Tatsache erhöht die Qualität Ihrer Produkte und verschafft Ihnen Vertrauen seitens der Kunden. Mit Hilfe dieses Wissen gewinnen Unternehmen von Autohäusern bis hin zur Online-Zoohandlung Kunden für ihre Produkte.
Durch wirkungsvoller Kommunikation punkten
In unserem E-Paper zu Entscheidungsprozessen zeigen wir Ihnen, welche Phasen ein Mensch für seine Entscheidung durchläuft. Lernen Sie auf diese einzelnen Schritte einzuwirken und fördern Sie mit Unterstützung von Werbewirkungs-Prinzipien, wie dem AIDA-Modell Ihren Verkauf.
Wieso werden die Bedürfnisse der User mit dem Apliki-Vorgehen besser erfasst als mit herkömmlichen Verfahren (z.B. Pflichtenheft, Use-Case etc.)?
Die genannten Beispiele sind umsetzungsnahe Dokumentationsmethoden. Doch welche Anforderungen der User sind überhaupt relevant um dokumentiert zu werden? Darauf liefern die fundierten Erhebungsmethoden und Erkenntnisse der Psychologie Antworten. Und unsere Dokumentationsmethoden simulieren Anwender, ihre Ziele, Aufgaben und Situationen aus Sicht der User. Mit ihnen lassen sich Designideen kreieren, evaluieren und anschließend die wesentlichen Anforderungen in Pflichtenhefte überführen, die zu erfolgreichen Produkten führen.
