Lastenheft schreiben: klare Aufgabe mit Vorlage

Die meisten Projekte, die schiefgehen, gehen nicht im Code schief. Sie gehen in der ersten E-Mail schief, wenn „ein einfacher Export in die Buchhaltung“ für den, der ihn geschrieben hat, etwas anderes bedeutet als für den, der ihn gelesen hat. Sechs Wochen später haben beide recht, und beide sind unzufrieden.

Um das zu vermeiden, brauchen Sie kein vierzigseitiges Lastenheft. Sie brauchen drei kurze Abschnitte, schriftlich, bevor jemand eine Zeile Code schreibt.

1. Was Sie heute haben

Beschreiben Sie den Ausgangspunkt, so wie er heute ist, nicht wie er sein sollte.

Die beteiligten Systeme. „Ein Onlineshop auf PHP 7.4, eigener Code. Buchhaltung in Xero. Lagerbestand in einer Tabelle, die das Lager jeden Abend aktualisiert.“
Wer sie nutzt, und wie viel. „Drei Leute im Büro, etwa 40 Bestellungen am Tag, im Dezember doppelt so viele.“
Was wehtut. „Jemand überträgt jede Bestellung von Hand in Xero. Das dauert eine Stunde am Tag, und Fehler fallen erst am Monatsende auf.“

Screenshots helfen. Die langweiligen Zahlen auch: wie viele Produkte, wie viele Bestellungen, wie alt der Server ist. Ein Entwickler, der weiß, dass der Server PHP 7.4 hat, wird nichts vorschlagen, was PHP 8.4 braucht, ohne es Ihnen zu sagen.

2. Was es können soll

Beschreiben Sie jetzt das Ergebnis: was Menschen sehen und tun werden, nicht wie es gebaut werden soll.

Wenn eine Bestellung im Shop bezahlt ist, erscheint innerhalb von fünf Minuten eine Rechnung mit denselben Positionen, Preisen und derselben Mehrwertsteuer in Xero. Kann sie nicht erstellt werden, bekommt das Büro eine E-Mail mit Bestellnummer und Grund.

Das ist eine gute Aufgabe. Achten Sie darauf, was sie nicht sagt: nichts über APIs, Warteschlangen, Cronjobs oder Frameworks. Das ist Sache des Entwicklers. Ihre Sache ist, beim Ergebnis genau zu sein:

Nennen Sie die Sonderfälle, die Sie schon kennen. Rückerstattungen. Bestellungen, die in zwei Teilen bezahlt werden. Kunden außerhalb der EU. Ein Produkt, das nach der Bestellung gelöscht wurde.
Sagen Sie, was nicht dazugehört. „Der Abgleich der Lagerbestände ist nicht Teil dieser Aufgabe.“ Was nicht dazugehört, ist der nützlichste Satz jeder Aufgabe: Hier enden die meisten Diskussionen, bevor sie beginnen.
Sagen Sie, was sich nicht ändern darf. „Die Kasse muss genau so aussehen wie jetzt.“

3. Wie Sie es prüfen

Diesen Abschnitt lassen die meisten weg, und er ist der wichtigste. Schreiben Sie auf, bevor die Arbeit beginnt, woran Sie entscheiden, dass sie fertig ist.

„Wir geben zehn Testbestellungen auf, darunter eine Rückerstattung und eine Bestellung aus der Schweiz. Alle zehn erscheinen korrekt in Xero.“
„Wir schalten die Verbindung zu Xero für eine Stunde ab. Das Büro bekommt eine E-Mail pro fehlgeschlagener Bestellung, und nichts geht verloren, wenn sie wieder steht.“
„Die Person, die heute Bestellungen abtippt, hört eine Woche lang damit auf, und nichts geht schief.“

Das sind Abnahmekriterien. Sie machen aus „Ich glaube, es funktioniert“ ein „Es funktioniert, und so wissen wir es“. Sie machen auch den Preis klarer: Ein Entwickler, der die Ziellinie sieht, kann Ihnen sagen, was der Weg kostet.

Vier Sätze, die Ärger machen

„Wie Amazon, nur einfacher.“ Einfacher in welcher Hinsicht? Sagen Sie, welche Teile Sie meinen.
„Es soll schnell sein.“ Wie schnell, gemessen wo? „Die Produktseite lädt auf dem Smartphone in unter zwei Sekunden“ lässt sich prüfen.
„Die üblichen Funktionen.“ Es gibt keine üblichen Funktionen. Zählen Sie sie auf.
„Wir wissen es, wenn wir es sehen.“ Das stimmt, aber erst nachdem Sie die Versionen bezahlt haben, die Ihnen nicht gefallen. Wenn Sie es wirklich noch nicht wissen, sagen Sie das und beginnen Sie stattdessen mit einer kleinen bezahlten Vorstudie.

Wenn Sie es nicht selbst aufschreiben können

Manchmal lautet die ehrliche Antwort auf „Was soll es können?“: „Wissen wir noch nicht genau.“ Das ist in Ordnung und kommt oft vor. Dann ist die erste Arbeit die Aufgabe selbst: eine kurze Vorstudie, die mit diesen drei Abschnitten auf Papier und einem Preis für den Rest endet. Sie kostet ein wenig, und sie ist der günstigste Teil des Projekts, den man richtig machen kann.

Eine Vorlage

Was wir heute haben
- Systeme:
- Nutzer und Mengen:
- Was wehtut:

Was es können soll
- Das Ergebnis, wie Menschen es sehen werden:
- Bekannte Sonderfälle:
- Gehört nicht dazu:
- Darf sich nicht ändern:

Wie wir es prüfen
- Test 1:
- Test 2:
- Fertig, wenn:

Kopieren Sie sie, füllen Sie sie aus und schicken Sie sie uns oder einem anderen Entwickler. Sie bekommen von allen eine bessere Antwort und einen besseren Preis.

Unser Anfrageformular fragt die ersten beiden Abschnitte in zwei Fragen ab. Fangen Sie dort an.