So erstellen Sie ein Briefing für eine individuelle Anwendung, ohne eine technische Spezifikation zu schreiben.

Ein Entwicklungsauftrag muss nicht mit einem Datenbankdiagramm beginnen, sondern muss einen Job erklären, den jemand erledigen kann, und das Ergebnis, das Ihr Unternehmen daraus benötigt.

Das Ziel des ersten Briefs ist es, das Projekt diskussionsfähig zu machen: Sie können technische Entscheidungen offen lassen, während Sie präzise über die Arbeit sind, die die Anwendung unterstützen muss.

Beginnen Sie mit einem Benutzer und einer Aufgabe

"Build a portal" benennt eine Art von Software. "Lassen Sie einen zugelassenen Kunden eine Serviceanfrage einreichen und sehen Sie den Fortschritt" beschreibt einen nützlichen ersten Workflow.

In diesem Beispiel muss ein Mitarbeiter die Anfrage überprüfen und ihren Status aktualisieren. Das bedeutet, dass der Auftrag bereits zwei verschiedene Rollen und einen gemeinsamen Datensatz enthält.

Vermeiden Sie es, mit "eine App für alle" zu beginnen. Verschiedene Benutzer benötigen möglicherweise unterschiedliche Berechtigungen, Bildschirme und Informationen. Entscheiden Sie, welche Rolle im ersten Release am wichtigsten ist.

Erklären Sie, was heute passiert

Beschreiben Sie die aktuellen Schritte in normaler Sprache. Vielleicht sendet ein Kunde Informationen per E-Mail, ein Mitarbeiter kopiert sie in eine Tabelle und eine andere Person sendet eine Fortschrittsaktualisierung. Zustand, in dem Verwirrung oder wiederholte Bemühungen auftreten, ohne anzunehmen, dass die Software jedes umliegende Problem löst.

Ein redigiertes Beispiel für das aktuelle Formular oder den aktuellen Datensatz kann nützlicher sein als eine polierte Präsentation.

Beschreibung einer vollständigen Fahrt

Folgen Sie einer repräsentativen Aufzeichnung von Anfang bis Ende. Was beginnt damit? Welche Informationen sind erforderlich? Wer trifft die nächste Entscheidung? Was kennzeichnet sie als vollständig?

Eine Anfrage kann unvollständig sein, ein Rezensent kann sie ablehnen oder ein Benutzer muss möglicherweise einen Fehler korrigieren.

Sie müssen nicht jedes seltene Ereignis in dieser Phase erfinden. Konzentrieren Sie sich auf die Ausnahmen, die den Hauptworkflow davon abhalten würden, nützlich zu sein.

Benennen Sie die Daten und Abhängigkeiten

Nennen Sie die wichtigen Datensätze: Benutzer, Anfragen, Produkte, Buchungen, Dateien oder andere Informationen, erklären Sie, woher sie kommen und wer für ihre Pflege verantwortlich ist.

Nennen Sie für eine Integration den anderen Dienst und stellen Sie seine Dokumentation zur Verfügung, wenn verfügbar. „Connect to our CRM lässt wichtige Fragen offen. Das nützliche Detail ist, welcher Datensatz sich bewegen soll, in welche Richtung und nach welchem Ereignis.

Identifizieren Sie, ob Designs, Produktinhalte, Kontozugriffe oder Geschäftsregeln bereits verfügbar sind. Fehlende Materialien sind keine automatischen Blocker, sondern benötigen einen Eigentümer und einen Platz im Plan.

Definieren Sie die erste nützliche Version

Trennen Sie die Kernlieferung von späteren Ideen. Ein erstes Portal unterstützt möglicherweise die Erstellung einer Anfrage, die Überprüfung und die Anzeige des Status. Messaging, erweiterte Berichterstattung und eine mobile App können spätere Diskussionen sein, anstatt unausgesprochene Anforderungen des ersten Builds.

Der gewählte Workflow sollte von Anfang bis Ende funktionieren. Die Grenze liegt zwischen kompletten Workflows, nicht zwischen einem attraktiven Bildschirm und der Logik, die er noch braucht.

Schreiben Sie ein Akzeptanzbeispiel

Versuchen Sie einen Satz, den jemand testen könnte:

Ein zugelassener Kunde kann eine Anfrage einreichen, seinen Status nach der Anmeldung einsehen und nur seine eigenen Anfragen einsehen; ein autorisierter Mitarbeiter kann den Status aktualisieren, und der Kunde sieht diese Änderung.

Dies ist eine illustrative Anforderung, keine Beschreibung eines bestehenden Client-Projekts, sondern macht das erwartete Verhalten viel klarer als „ein modernes, sicheres Portal.

Hinzufügen praktischer Einschränkungen

Geben Sie Ihren gewünschten Zeitpunkt an, ob es sich um eine Präferenz oder ein festes externes Datum handelt, und geben Sie den Budgetbereich an, sofern bekannt.

Beschreiben Sie auch Release- und Übergabeerwartungen. Wer wird das Hosting und die Konten besitzen? Muss ein anderer Entwickler den Code erhalten? Diese Fragen beeinflussen die Lieferung, auch wenn sie nicht auf einem Bildschirm erscheinen.

Eine kurze, die Sie verwenden können

Wir wollen bauen: Anwendung oder Workflow. Die Hauptnutzer sind: Menschen und Rollen. Sie müssen die Hauptaufgabe und das abgeschlossene Ergebnis. Heute geschieht dies durch: den aktuellen Prozess. Die erste Version muss enthalten: Der wesentliche komplette Workflow. Es muss sich verbinden mit: die bekannten Systeme und Dokumentation. Wir haben bereits: Designs, Inhalte, Accounts oder Beispieldaten. Noch unentschlossen: Fragen zu lösen. Zeitplan, Budget und Entscheidungsträger: die praktischen Zwänge.

Der Auftrag ist ein Ausgangspunkt für die Definition des Projekts, kein Test, den Sie bestehen müssen, bevor Sie mit einem Entwickler sprechen.

Besprechen Sie eine benutzerdefinierte Web-Anwendung oder Senden Sie Ihren Brief.