Beginnen Sie mit einer Aufgabe, die Ihre Mitarbeitenden erledigen müssen. Beschreiben Sie, wodurch sie ausgelöst wird, wer sie bearbeitet, wie ein gutes Ergebnis aussieht und wo es schwierig wird. So hat ein Entwickler etwas Konkretes zu besprechen, auch wenn Sie noch nicht wissen, was gebaut werden soll.
„Wir brauchen ein besseres Buchungssystem“ ist ein völlig vernünftiger Anfang. Die nächste nützliche Frage lautet: Was geschieht, wenn jemand einen Platz buchen möchte?
Beschreiben Sie vor dem ersten Gespräch mit einem Entwickler einen Arbeitsablauf von der ersten Anfrage bis zum fertigen Ergebnis. Nehmen Sie auch die Stelle auf, an der es schwierig wird. Das können Sie mit einfachen Worten erklären, auch wenn Sie noch keine Vorstellung vom technischen Aufbau der Software haben.
Stellen Sie sich ein erfundenes Schulungsunternehmen vor. Ein Kunde fragt per E-Mail nach zwei Plätzen in einem Kurs. Eine Koordinatorin prüft die Verfügbarkeit, antwortet dem Kunden und erfasst die Buchung. Ist der Kurs voll, muss jemand entscheiden, was stattdessen angeboten wird.
Das reicht für den Anfang eines brauchbaren Briefings. „Bauen Sie ein Portal mit Dashboard“ lässt für den Entwickler viel mehr offen: Wer nutzt es, welche Aufgabe soll damit abgeschlossen werden und was gilt überhaupt als Buchung?
Der Leitfaden der britischen Regierung zur Klärung eines Problems vor der Entwicklung eines Dienstes empfiehlt, die Nutzer, ihren weiteren Weg und die Rahmenbedingungen zu betrachten. Der dortige Prozess für staatliche Dienste gehört in seinen eigenen Kontext. Für unser Schulungsunternehmen lautet die hilfreiche Ausgangsfrage schlicht: Was muss geschehen, damit dieser Kunde an einem Kurs teilnehmen kann?
Bitten Sie die Person, die die Arbeit erledigt, Sie durch einen aktuellen Fall zu führen. Schreiben Sie auf, was Sie beobachtet haben. Beschreiben Sie danach, was anders laufen soll. In unserem erfundenen Unternehmen könnten die Notizen so aussehen:
Die Koordinatorin prüft die Kurstabelle, antwortet per E-Mail und trägt eine bestätigte Buchung in den Kalender ein. Wir haben gesehen, dass ein Platz angeboten wurde, während noch eine andere Antwort ausstand.
Die Koordinatorin soll sehen, welche Anfragen noch eine Antwort brauchen, und entscheiden können, ob sie einen Platz anbietet. Wann ein Platz als belegt gilt, müssen wir noch klären.
Der erste Teil beschreibt den heutigen Ablauf. Der zweite schlägt eine Änderung vor und macht eine offene Entscheidung sichtbar. Das ist wichtig, wenn Mitarbeitende unterschiedlich vorgehen: Eine Person hält Plätze vielleicht frei, während sie auf eine Antwort wartet, eine andere lässt sie verfügbar. Halten Sie beide Varianten fest, bevor der Entwickler eine davon zur Regel machen soll.
Für die Kursanfrage könnte eine praktische Skizze diese Punkte enthalten:
Das sind Vorschläge für dieses Beispiel, keine feststehenden Regeln für jedes Schulungsunternehmen. Fragen Sie, was „vereinbarte Buchung“ bei Ihnen bedeutet. Ist ein Platz nach dem Angebot, nach der Zusage des Kunden oder erst nach der Zahlung belegt? Eine festgehaltene Frage können Sie gemeinsam klären.
Ergänzen Sie ein kleines durchgespieltes Beispiel mit erfundenen Datensätzen: Im Kurs A am 12. Mai ist ein Platz frei; Anfrage B bittet um zwei. Zeigen Sie das erwartete Ergebnis und wer die Entscheidung trifft. Dann kann der Entwickler zu einem konkreten Fall nachfragen.
Verwenden Sie erfundene Namen und Datensätze, wenn sie die Arbeit verständlich machen. Echte Beispiele geben Sie nur weiter, wenn Sie dazu berechtigt sind. Entfernen Sie unnötige persönliche oder vertrauliche Angaben und vereinbaren Sie einen geeigneten Weg für die Weitergabe.
Erforderlich: Die Koordinatorin muss sehen können, welche Anfragen noch auf eine Antwort warten. Erklären Sie den Grund: Sonst muss jemand im gemeinsamen Postfach nach unerledigter Arbeit suchen.
Idee zur Diskussion: Kunden könnten selbst einen anderen Kurstermin wählen. Lassen Sie das eine Möglichkeit bleiben, bis Sie den Aufwand und den Nutzen für die Beteiligten betrachtet haben.
Offene Frage: Wann soll ein Platz reserviert werden und wer darf ihn wieder freigeben? Benennen Sie die Schulungsleitung als Entscheidungsträger, statt die Geschäftsregel stillschweigend dem Entwickler zu überlassen.
Nennen Sie auch tatsächliche Grenzen. Vielleicht muss der vorhandene Kalender bleiben, nur bestimmte Mitarbeitende dürfen Kundendaten sehen oder ein bestimmter Kurs muss bis zu einem bekannten Datum unterstützt werden. Sagen Sie, welche Grenzen feststehen und warum. Wenn Termin oder Budget bisher nur ein Wunsch sind, kennzeichnen Sie das.
„Einfacher zu bedienen“ braucht ein Beispiel. In diesem Unternehmen sollte die Koordinatorin eine Anfrage bis zu ihrer Antwort verfolgen und alle noch offenen Anfragen finden können. Besprechen Sie anhand einer normalen Buchung und des Falls mit nur einem freien Platz, was die fertige Arbeit zeigen muss.
Sie können auch ein heutiges Problem festhalten, das Sie messen möchten, etwa wie oft Mitarbeitende in mehreren Werkzeugen nach einer unbeantworteten Anfrage suchen. Sagen Sie, was Sie beobachtet haben und was noch geprüft werden muss. Vereinbaren Sie ein Ziel erst, wenn klar ist, womit Sie es vergleichen.
Geben Sie das Briefing vor dem Versand den Menschen, die die Arbeit erledigen. Sie können auf einen fehlenden Schritt hinweisen oder erklären, warum eine scheinbare Abkürzung Probleme verursachen würde. Lassen Sie offene Punkte im Dokument stehen und benennen Sie für jeden eine Person, die ihn klären kann.
Wir entwickeln individuelle Software für Unternehmen. Wenn Sie ein Projekt mit uns besprechen möchten, bringen Sie eine solche Aufgabe mit: Was geschieht heute, was soll sich ändern, ein Beispiel und Ihre offenen Fragen. Umfang und Konditionen lassen sich dann anhand der Arbeit besprechen. Das Briefing eröffnet dieses Gespräch; die technische Untersuchung und der Entwurf stehen noch aus.
Sie können mit der Aufgabe beginnen: Wer erledigt sie, welche Werkzeuge werden verwendet und welches Ergebnis wird gebraucht? Der technische Entwurf kann nach der Untersuchung folgen. Wenn Sie eine echte technische Vorgabe kennen, halten Sie sie fest und erklären Sie, warum sie wichtig ist.
Beschreiben Sie die Abläufe, die Sie tatsächlich beobachtet haben, und fragen Sie die Beteiligten nach den Gründen. Kennzeichnen Sie Unterschiede, die nötig sind, und solche, über die noch entschieden werden muss. Benennen Sie eine Person, die diese Entscheidung treffen kann.
Schreiben Sie die Frage auf, was Sie bereits wissen und wer bei der Antwort helfen kann. Zum Beispiel: „Wann gilt ein Kursplatz als belegt: wenn er angeboten, angenommen oder bezahlt wurde?“ Halten Sie das getrennt von vereinbarten Anforderungen.
Letzter Newsletter: mehr Geld aus einer Abo-Website oder App verdienen, die Ihnen bereits gehört.
Der davor: wie man KI-Unsinn von echten Erfolgsgeschichten unterscheidet.
Interessiert?
Wöchentlich Oder sagen Sie uns Bescheid, und wir passen es für Sie an. Klingt gut?
