Wie verschiebe ich einen Client von UI-Modellen zu einer Reihe von realen Anforderungen?

Angenommen, Sie erhalten ein Modell von 25 Bildschirmen mit den visuellen Zuständen Ihrer Anwendung. Die Erwartung ist, dass dies ausreicht, um zuversichtlich zu sein, dass wir es entwickeln und als fertige Anwendung an den ursprünglichen Stakeholder oder Kunden übergeben können, und sie werden zufrieden sein. Natürlich werden Sie den Stakeholdern am Ende noch einmal viele Fragen stellen, die zur Erstellung der Benutzeroberfläche verwendet wurden, was verschwenderisch ist.

Ich habe jedoch viele Male festgestellt, dass dies sehr viel zu wenig ist. Im Laufe der Entwicklung der Anwendung verschwimmen die Anforderungen durch die Tatsache, dass wir eine Schnittstelle replizieren und der Kunde am Ende nicht so zufrieden ist, wie es zunächst schien als wir sie nach allen Informationen zum Erstellen der Benutzeroberfläche fragten.

Ich bin mir einfach nicht sicher, wonach ich sonst fragen soll. Ich habe versucht, genau zu sein und nach Anforderungen und Verständnis für das Gesamtziel zu fragen, aber ich weiß nicht, wonach ich fragen soll. Wenn ich jetzt anfange, wird viel Zeit verschwendet, um alle Informationen, die zur Benutzeroberfläche geführt haben, erneut zu analysieren. In dieser Phase gehen viele wichtige Gründe verloren, die der Kunde ursprünglich hatte.

Wie kann ich die Leute dazu bringen, zu verstehen, dass wir Anforderungen basierend auf UI-Mockups nicht sperren können, indem wir nach etwas Handlungsfähigem fragen, das sie für mich erstellen können?

Womit würden Sie im Idealfall beginnen, um die Aufgabe der Entwicklung einer Anwendung für Endbenutzer ordnungsgemäß auszuführen?

Einige andere Dinge, die Sie möglicherweise benötigen, sind:

• Anwendungsfälle oder Workflow-Beschreibungen: Wissen Sie, wie mit schlechten Eingaben umgegangen wird, nur weil Sie wissen, wie ein Bildschirm aussieht? Wissen Sie, wie Sie in ALLEN Fällen zwischen Bildschirmen wechseln können? Sie können hier auch die Fehlerbehandlung einbeziehen.

• Übergeordnete Systembeschreibung: Hier wird erklärt, wofür das gesamte System dieser 25 Bildschirme bestimmt ist und was sie bewirken.

• Datenmodell: Ist es möglich, ein Datenmodell von diesen Bildschirmen abzuleiten? Gibt es ein Datenmodell, das verwendet werden muss, oder steht es Ihnen frei, ein eigenes zu entwerfen, um die Arbeit zu erledigen?

• Technische Voraussetzungen: Sind die spezifischen Technoligies , die müssen wegen der Lizenzierung verwendet werden oder für die Integration Gründe?

• Leistungsanforderungen: Wenn es einen Suchbildschirm gibt, wird erwartet, was durchsucht werden kann und wie schnell die Antwort sein sollte? Was ist mit Antworten für andere Arten von Aktionen? Können oder sollten einige von ihnen asynchron sein (Benutzer übergibt Job und kommt später zurück)?

• Sicherheitsanforderungen: Speichert die Anwendung potenziell sensible / persönliche Daten, und wenn ja, welche Arten von Daten und welche Maßnahmen müssen getroffen werden, um die Sicherheit zu gewährleisten? Müssen Sie bestimmte Compliance-Anforderungen erfüllen (z. B. PCI-Compliance für Kreditkartenzahlungen)?

Gibt es auch spezielle Fachkenntnisse, die Sie benötigen, um Sie zu unterstützen? Einige Branchen wie Versicherungen, Banken, Krankenakten usw. haben alle möglichen komplexen Geschäftslogiken. Solche Projekte sollten nicht ohne die Hilfe eines Geschäftsanalysten durchgeführt werden, der diese Domäne kennt. Wenn es sich jedoch nur um eine Warenkorb- / Informationsseite für allgemeine Widgets handelt, benötigen Sie möglicherweise kein solches Teammitglied.

So bringen Sie die Leute dazu, zu verstehen, dass UI-Mocks nicht ausreichen, um ein funktionierendes Programm zu erstellen:

Ich würde das mit einer Analogie behandeln. Da ich ein bisschen verrückt bin, gehe ich diesen Weg.

"Stell dir vor, ich weiß nichts über Autos. Du gibst mir ein paar Fotos von einem Ferrari. Ein paar von außen und eines von innen im Auto (vom Fahrersitz aus, damit ich die Bedienelemente für das Auto sehen kann). Jetzt fragst du mich Um dir einen Ferrari zu bauen, komme ich mit einem Ding zurück, das aussieht wie auf den Bildern und alle Bedienelemente hat. Leider sind diese Bedienelemente mit nichts verbunden, weil ich (da ich nichts über Autos weiß) nicht weiß, was das ist Ich kann nicht einmal raten, weil ich nicht einmal weiß, was Autos tun sollen. Dann haben wir eine Unterhaltung wie diese:

"Also, was macht ein Ferrari?" "Es ermöglicht mir, mich schnell von einem Punkt zum anderen zu bewegen." "OK. Also, was macht diese Kreissache?" "Oh, das ist das Lenkrad. Indem Sie es drehen, können Sie ändern, in welche Richtung sich die Räder an der Außenseite des Autos bewegen. Dies ändert die Richtung, in die sich das Auto bewegt." "OK, und was ist mit dieser Pedalsache?" "Das ist das Gaspedal. Es macht den Motor schneller, was das Auto schneller macht." ... ein paar Minuten später ... "Okay, welche Art von Motor braucht es? Ich habe einige Nachforschungen angestellt und Motoren für Golfwagen und einige für Sportwagen gefunden. Welche soll ich verwenden?" ... etc. ..."

Dann können Sie die Analogie erklären. Wenn Sie den Entwicklern Mocks von Bildschirmen aushändigen, erfahren Sie nur, wie es aussieht und nicht, wie es funktioniert. Entwickler müssen wissen, welches Problem das Programm löst oder wie es verwendet wird (wie das Wissen darüber, was ein Auto tut, erleichtert es ihnen, das Auto zu entwerfen und fundierte Vermutungen darüber anzustellen, was zu tun ist). Sie müssen wissen, welche Art von Dingen sie verwenden sollen (z. B. der Golfwagenmotor im Vergleich zum Sportwagenmotor) und welche anderen Nicht-UI-Anforderungen es gibt (das Auto sollte schnell fahren).

Dinge, nach denen ich fragen würde:

Allgemeine / allgemeine Problembeschreibung

Use Cases / User Stories

Leistungsanforderungen

Erforderliche Technologien / Plattform (Windows, Linux, Web)

Alles, was FrustratedWithForms in seiner Antwort hat

Etwa 80% des Entwicklungsaufwands entfallen auf 20% der Randnutzungsfälle. Screenshots geben keinen Aufschluss über Anwendungsfälle, sodass Sie 80% Ihrer aktiven Entwicklung im Dunkeln verbringen.

Es ist gut, dass Sie versuchen, mehr herauszufinden und zu kommunizieren, wie wichtig es ist, dass der Kunde stärker in die Projektanforderungen einbezogen wird. Tun sie dies jedoch nicht, richten sie das Projekt auf Fehler ein das ist nicht deine schuld

Die meisten Softwareprojekte schlagen fehl, weil der Client nicht ausreichend in den Softwareentwicklungsprozess einbezogen ist. Dies ist kein neues Problem und es ist sicherlich kein Rätsel, warum Softwareprojekte scheitern, aber es passiert in der Branche aufgrund solcher Situationen immer wieder.

Sie können nicht einfach eine Menge Informationen über eine Mauer werfen und erwarten, dass Sie alle Ihre Hoffnungen und Träume in Form eines Softwarepakets zurückbekommen. Softwareentwicklung funktioniert so einfach nicht. Unabhängig davon, ob Sie ein agiler oder ein Waterfall-Shop sind, ist eine solide Kundenführung für den Erfolg oder Misserfolg eines Projekts erforderlich.

Eine Sache, die die Leute vergessen zu fragen scheinen: Wofür werden die Daten nach der Eingabe verwendet? Benötigen Sie Berichte? Müssen Sie einen Packzettel erstellen und zum Versand usw. an das Lager senden. Wenn Daten für die Verwaltungsentscheidung verwendet werden und Berichte erforderlich sind, kann dies das Datenbankdesign ändern. Abhängig von der Komplexität der Berichte kann die Entwicklung erheblich länger dauern.

Sie müssen auch sicherstellen, dass es für jede mögliche Entscheidung einen Pfad gibt. Wenn also eine Genehmigung für das Management erforderlich ist, was tun Sie, wenn dies abgelehnt wird, und was tun Sie, wenn dies genehmigt wird? Wenn es in X Zeit nicht genehmigt oder abgelehnt wird, was passiert dann damit? Was passiert mit der Bestellung, wenn sie ein Produkt auswählen und es nicht vorrätig ist? Diese Art von Fragen.

Sie müssen auch wissen, ob es bestimmte Grenzen gibt, welche Daten in die einzelnen Felder eingegeben werden sollen. Gibt es erforderliche Werte? Woher willst du sie bekommen? Wie werden sie aktualisiert? Sie müssen wissen, wie Sie mit Fehlern umgehen. Sie müssen wissen, ob die Datenbank überwacht werden muss oder ob Sie in der Lage sein müssen, Daten aus einer historischen Perspektive wiederherzustellen (zurück zu diesen lästigen Berichten).

Eine andere Sache, die mir auffällt, ist, dass Anwendungen möglicherweise nur bis zum Release entwickelt werden, ohne zu berücksichtigen, wie die Daten danach gepflegt werden. Benötigen Sie eine Admin-Seite, um sicherzustellen, dass sie ihre Liste der erforderlichen Werte aktualisieren können? Müssen Sie Daten an andere Systeme senden? Wie werden die anfänglichen Daten in die Datenbank aufgenommen?

Persönlich würde ich um ein halbtägiges bis tagelanges Treffen mit dem Kunden bitten, um das UI-Design und die Ziele zu erläutern und sicherzustellen, dass alles aufeinander abgestimmt ist.

Einfach anfangen. Lassen Sie sie verstehen, dass mit den Informationen, die Sie erhalten haben, keiner dieser Bildschirme etwas bewirken würde . Keine Details zu Anwendungsfällen, schlechtem Eingabeverhalten usw. Es wird einfach nicht funktionieren. Das Erklären einer stumpfen Verallgemeinerung ist einfacher als das Erklären von Details, da der Punkt nicht verloren gehen kann. Der Versuch, ihnen eine kompliziertere Begründung dafür zu geben, warum Bildschirmmodelle nicht ausreichen, gibt ihnen die Möglichkeit, Ihre Definitionen zu hinterfragen, anstatt das Problem anzuerkennen. Bitten Sie sie, sich vorzustellen, dass der Back-End-Entwickler kein Englisch spricht (oder in welcher Sprache auch immer die Bildschirme angezeigt werden). Fragen Sie dann, wie anders diese Situation für einen Entwickler ist, der überhaupt keine Kenntnisse hatihrer Geschäftsprozesse. Bauen Sie dann auf das realistischere Beispiel von Ihnen auf, das über einige Kenntnisse verfügt, jedoch zu Recht der Ansicht ist, dass es nicht angemessen ist , ihre Geschäftslogik für sie zu entscheiden.

Leute, die keine Software entwickelt haben, wissen nicht, was Softwareentwickler wissen müssen. Es ist nicht zu erwarten, dass sie Anforderungsspezifikationen und Anwendungsfälle selbst erstellen. Sie müssen Erhebungstechniken für Anforderungen anwenden , um die Informationen zu erhalten, die Sie kennen müssen. Arbeiten Sie mit dem Kunden (und hoffentlich mit einer Stichprobe von Benutzern aus verschiedenen Rollen) zusammen, um festzustellen, was sie benötigen oder wollen. Übliche Techniken hierfür sind Interviews und / oder Benutzerbeobachtungen, Identifizieren von Anwendungsfällen und Benutzergeschichten sowie Prototyping.

Ich würde die Anwendung von iterativen und inkrementellen Entwicklungstechniken in diesem Fall sehr empfehlen, da Sie vage, unvollständige oder schlecht verstandene Anforderungen haben. Schauen Sie sich die verschiedenen agilen Methoden zusammen mit dem Spiralmodell für die Adressierung der Lebenszyklusplanung an.

Beginnen Sie mit dem Erreichen des Geschäftsziels, das die Entwicklung dieser Software vorantreibt. Befragen Sie den Kunden und die Benutzer und sehen Sie ihnen bei der Arbeit zu, wenn Sie können. Versuchen Sie herauszufinden, welches Problem sie lösen möchten. Sehen Sie sich an, welche Tools sie aktuell verwenden und wie sie sie verwenden, damit Sie ihre aktuelle Arbeitsweise verbessern können. Nutzen Sie diese Gelegenheit, um die Domain und ihre Sprache zu lernen - die Kommunikation wird unendlich einfacher, wenn die Softwareentwickler und Kunden / Benutzer alle dieselbe Sprache sprechen (und nicht erwarten, dass Kunden / Benutzer in Software-Begriffen sprechen).

Sobald Sie die Ziele verstanden haben, können Sie mit den von Ihnen erstellten UI-Design-Mockups arbeiten und Use Cases und User Stories anhand der Zusammenhänge der verschiedenen Bildschirme "zurückentwickeln". Das User Story-Format würde wahrscheinlich gut funktionieren, um mit einem nicht-technischen Publikum fertig zu werden. Das Format von As a <user type>, I want to <action> so that <reason>funktioniert dahingehend, dass Entwickler und Kunden / Benutzer dieselbe Sprache sprechen. Sobald Sie mit den User Stories beginnen können, würde ich einen Prototyping-Ansatz für die Entwicklung verfolgen.

Ich denke, dass ich dies mit dem Einsatz von Prototyping angehen würde. Sie könnten dies entweder aus der Perspektive des Evolutions-Prototyping oder des Wegwerf-Prototyping betrachten , aber ich würde zuerst einen Ansatz des Evolutions-Prototyping in Betracht ziehen. Beginnen Sie mit den User Stories, mit denen Sie sich am besten auskennen und die Sie validiert haben, und beginnen Sie mit der Implementierung. Erhalten Sie bei der Implementierung Feedback vom Kunden und entwickeln Sie neue User Stories, verwenden Sie Anwendungsfälle und beheben Sie Missverständnisse.

Betrachten Sie dies auch nicht als "Implementierung einer Benutzeroberfläche mit Funktionen darunter". Stellen Sie es sich stattdessen als dünne vertikale Scheiben vor. Implementieren Sie nicht die gesamte Benutzeroberfläche auf einmal und kümmern Sie sich dann um die Funktionen. Verwenden Sie stattdessen die Benutzeroberflächenmodelle, um Features und andere Anforderungen zu identifizieren, und implementieren Sie anschließend einen vertikalen Schnitt von der Benutzeroberfläche bis zur Geschäftslogik und zum Datenspeicher. Wiederholen Sie dies für jede vertikale Scheibe. Sie können auch Vorschläge zur Verbesserung der Benutzeroberfläche machen, die auf den Anforderungen und Usability-Prinzipien basieren.

Ich würde empfehlen, zwei Bücher von Karl Wiegers zu lesen - Softwareanforderungen und mehr über Softwareanforderungen . Ich denke, dies wird Ihnen beim Anforderungs-Engineering und bei den Best Practices in diesem Bereich helfen.

Nun, dies ist eine peinlich offensichtliche Startreferenz, aber Wikipedia ist möglicherweise ein Ort, an dem Sie und die Benutzer anfangen können. Die Tatsache, dass es einen Eintrag über dieses Zeug gibt, könnte sie davon überzeugen, dass dies ein echtes Problem ist, und nicht, dass Sie ein Schmerz sind.

Sind Sie nur verblüfft, was die Anwendung leistet, selbst nachdem Sie die Modelle durchgesehen haben? Wenn ja, geben Sie es zu und versuchen Sie zu erklären, dass Sie keine Ahnung haben, welche Daten in den einzelnen Formularen angezeigt werden sollen oder woher sie stammen, ob sie von anderen Bildschirmen oder von externen Daten stammen.

Wenn Sie eine Idee, versuchen Sie mit Beispielen der Dinge zu kommen , dass Sie nicht wissen , wie zu tun ( "wird die Liste der Vorlagen auswählen , um eine globale Liste oder sind einer von ihnen durch Benutzer, oder etwas anderes? Wenn es Nicht vom Benutzer Soll ich es von zwei Personen gleichzeitig bearbeiten lassen? Was soll die Benutzeroberfläche anzeigen, wenn jemand anderes es bearbeitet? Gibt es einen Bildschirm dafür? Wenn jemand eine Vorlage für die Vorlagen verwendet hat, für die sie verwendet werden, wird die Vorlage bearbeitet Sollte diese Änderung auf das mit der Vorlage erstellte Objekt übertragen werden? ").

Machen Sie deutlich, dass Sie nach Ihrem derzeitigen Kenntnisstand für den Rest des Entwicklungszyklus etwa alle 90 Sekunden Antworten auf Fragen benötigen und dass Sie die meiste Zeit nicht weiterarbeiten können, bis Sie eine Antwort erhalten. Das Ziel sollte sein, klar zu machen, warum ein Prozess alles einfacher macht. Erwähnen Sie auch, dass die Qualitätssicherung dieselben Informationen benötigt, die Sie auch benötigen, damit Sie diese leichter aufschreiben können, damit sie für alle verfügbar sind und niemand etwas vergisst.

Es kann hilfreich sein zu erwähnen, dass sich ein Teil des Codes, den Sie schreiben, auf mehrere Bildschirme gleichzeitig auswirkt. Wenn Sie also möglichst viele Antworten im Voraus erhalten, können Sie den Code möglicherweise einfacher schreiben und müssen ihn später nicht mehr ändern.

Wenn Sie immer noch keine Anforderungen erhalten und nicht genau wissen, wie Sie vorgehen sollen, senden Sie jedes Mal eine E-Mail, wenn Sie weitere Informationen benötigen (z. B. Anforderungen). Wenn Sie ohne diese Informationen nicht weiterarbeiten können, geben Sie dies deutlich an können leider nicht weiterarbeiten, da der Code, den Sie schreiben müssen, je nach Antwort (en) auf Ihre Frage (n) sehr unterschiedlich sein wird. Beschweren Sie sich nicht, lassen Sie sie nur sehr professionell wissen, dass Sie das Programm erst schreiben können, wenn Sie wissen, was es tun soll.

Sie müssen die Grenzen und Bereiche für jedes Feld in der Anwendung kennen. Wenn es sich bei dem Feld beispielsweise um eine Telefonnummer handelt, erwarten sie, dass Sie +1 verarbeiten? Welche Felder sind erforderlich? Was soll die Anwendung tun, wenn der Benutzer "abc" in das Feld "phone #" eingibt? Befinden sich alle 25 Bildschirme in der Reihenfolge, in der alle Benutzer fortfahren müssen?

Ansonsten einfach alles als Textfelder erstellen und fertig! Wetten, dass das wie ein Bleiballon übergeht?