Übereinstimmung darüber herstellen, welches Problem gelöst wird.
Die einfachste Methode, um Einigkeit über die Definition eines Problems zu erhalten, ist es, das Problem aufzuschreiben
und festzustellen, ob alle zustimmen.
Fragen Sie die Gruppe: Was ist das Problem?
-
Häufig wird zu schnell versucht, eine Lösung zu entwickeln, obwohl das Problem selbst noch nicht im Detail
verstanden wurde. Schreiben Sie das Problem auf und stellen Sie fest, ob alle dieser Definition zustimmen.
Fragen Sie die Gruppe dann erneut: Was ist das Problem?
-
Suchen Sie nach den eigentlichen Fehlerursachen, also dem Problem hinter dem Problem. Das echte Problem ist oft von
dem verdeckt, was als Problem gesehen wird.
Akzeptieren Sie nicht die erste Beschreibung eines Problems. Fragen Sie weiter nach dem Warum. Erkunden Sie die Natur
des Problems.
Manchmal ist die Gruppe so stark auf eine mögliche Lösung fixiert, dass es schwer ist, sie dazu zu bewegen, das
tatsächliche Problem zu beschreiben. Es kann in solchen Fällen sinnvoll sein, die Leistungen der Lösung zu beleuchten
und dann über die Probleme zu sprechen, die dadurch gelöst werden. Im weiteren Verlauf können Sie dann feststellen, ob
es sich um "echte" Probleme in der Organisation handelt. Allgemeine Techniken, mit denen man das Problem hinter dem
Problem findet, sind Brainstorming, Tannenbaumdiagramme und Pareto-Diagramme.
|
Stakeholder identifizieren
Abhängig vom Fachwissen des Entwicklerteams kann die Identifikation der Stakeholder sehr einfach sein (oder eben
nicht). Oft genügt es, Entscheidungsträger, potenzielle Benutzer und andere Interessierte einzubeziehen. Folgende
Fragen sind hilfreich:
-
Wer benutzt das System?
-
Wer ist der Geldgeber für das System?
-
Auf wen wirkt sich die Systemausgabe noch aus?
-
Wer nimmt das System ab, wenn es geliefert und implementiert ist?
-
Gibt es interne oder externe Benutzer des Systems, deren Bedürfnisse berücksichtigt werden müssen?
-
Wer wird das System verwalten?
-
Wer sonst noch?
-
Und wer noch?
Beginnen Sie mit der Entwicklung der Profile potenzieller (oder tatsächlicher) Systembenutzer. Erste Informationen zu
Hauptbenutzern und ihrer Umgebung sollten im Visionsdokument beschrieben werden.
|
Systemgrenzen definieren
Die Systemgrenze ist die Grenze zwischen der Lösung und der realen Welt, die die Lösung umgibt. In anderen Worten, die
Systemgrenze beschreibt den Umschlag, in dem sich das System befindet. Information in Form von Ein- oder Ausgabe wird
vom System empfangen oder zu Benutzern gesendet, die sich außerhalb des Systems befinden. Alle Interaktionen mit dem
System finden über Schnittstellen zwischen System und externer Welt statt.
In vielen Fällen sind die Systemgrenzen deutlich erkennbar. Beispiel: Die Grenzen eines handelsüblichen
Adressverwaltungsprogramms für Einzelbenutzer, das unter Microsoft Windows® ausgeführt wird, sind recht klar definiert.
Es gibt nur einen Benutzer und eine Plattform. Die Schnittstellen zwischen Benutzer und Anwendung bestehen aus den
Dialogen, auf die der Benutzer zugreift, um Informationen einzugeben, und den Ausgabeberichten und
Kommunikationspfaden, die das System nutzt, um die sich ergebenden Daten zu übertragen.
|
Einschränkungen des Systems identifizieren
Es gibt verschiedene Quellen für Einschränkungen. Es folgt eine Liste mit potenziellen Quellen und den zu stellenden
Fragen:
-
Gibt es interne oder externe geschäftspolitische Themen, die sich auf mögliche Lösungen auswirken können? Wie sieht
es zwischen den einzelnen Abteilungen aus?
-
Wirtschaftlicher Aspekt: Gibt es finanzielle Einschränkungen? Gibt es Kosten für verkaufte Produkte oder
Überlegungen zu Produktpreisen? Gibt es Lizenzierungsfragen?
-
Umgebung: Gibt es umgebungsbedingte Einschränkungen oder Vorgaben durch Anwendungsstandards? Gesetze? Sonstige
Vorschriften?
-
Technik: Gibt es Einschränkungen bei der Auswahl der Technologie? Müssen bestehende Plattformen oder Technologien
verwendet werden? Dürfen neue Technologien verwendet werden oder nicht?
-
Realisierbarkeit: Ist der Zeitplan definiert? Dürfen nur vorhandene Ressourcen verwendet werden? Können externe
Mitarbeiter eingesetzt werden? Können Ressourcen erweitert werden? Temporär? Permanent?
-
System: Soll die Lösung auf den eigenen Systemen basieren? Ist Kompatibilität mit bestehenden Lösungen
erforderlich? Welche Betriebssysteme und Umgebung sollen unterstützt werden?
|
Problembeschreibung formulieren
Verwenden Sie Flip-Charts und füllen Sie mit der ganzen Gruppe die folgende Vorlage für jedes identifizierte Problem
aus:
Das Problem: <Problembeschreibung>
Auswirkungen auf: <Liste der betroffenen Stakeholder>
Auswirkung: <Beschreibung der Auswirkung>.
Eine erfolgreiche Lösung: <Liste mit wichtigen Leistungen einer guten Lösung>.
Sinn und Zweck der Vorlage ist es, besser zwischen Lösungen/Antworten und Problemen/Fragen unterscheiden zu können.
Beispiel:
Das Problem: Unpassende und falsche Lösungen für Kundenserviceprobleme.
Auswirkungen auf: Unsere Kunden, Kundenunterstützung und Servicetechniker.
Auswirkung: Unzufriedenheit der Kunden, gefühlte Qualitätsmängel, frustrierte Mitarbeiter und
Umsatzverluste.
Eine erfolgreiche Lösung: Bietet Zugriff in Echtzeit auf eine Datenbank zur Fehlerbehebung durch die
Unterstützungsfunktion, erleichtert das zeitnahe Entsenden von Servicetechnikern nur an solche Lokationen, an denen sie
wirklich benötigt werden.
|
Features des Systems definieren
Entwickeln Sie auf der Basis der Leistungen, die in der Problembeschreibung aufgelistet sind, eine Liste der Features,
die im System vorhanden sein sollen. Beschreiben Sie sie kurz und vergeben Sie Attribute, um ihre allgemeinen Zustand
und ihre Priorität im Projekt festzulegen.
|
Ergebnisse auswerten
In diesem Stadium sollten Sie die Vision prüfen, um sicherzustellen, dass Sie mit der Arbeit auf dem richtigen Weg
sind, sie aber nicht im Detail untersuchen. Weitere Informationen enthält die Prüfliste: Vision).
|
|