Das Pflichtenheft, das den Bau übersteht
Die meisten Kostenüberschreitungen in der Individualsoftware entstehen nicht durch schwierigen Code, sondern durch eine Richtung, die sich ändert, nachdem der Code geschrieben ist. Ein klares Pflichtenheft ist der günstigste Weg, dieses Risiko zu senken.
Individualsoftware sprengt das Budget selten, weil die Technik zu anspruchsvoll war. Sie sprengt es, weil sich das Ziel verschoben hat. Eine Funktion wird gebaut, dann zeigt sich, dass sie das falsche Problem gelöst hat, und die Arbeit wird zurückgenommen und neu gemacht. Jede dieser Kehrtwenden wird zweimal bezahlt. Das Pflichtenheft ist der Ort, an dem Sie sie abfangen, bevor sie etwas kosten, und genau das macht ein gutes Pflichtenheft zur günstigsten Absicherung im ganzen Projekt.
Das Problem benennen, nicht die Lösung
Ein brauchbares Pflichtenheft beginnt mit dem Problem in betrieblichen Begriffen: was das Team erreichen will, wo der heutige Ablauf bricht und wie ein besserer Arbeitstag aussieht, sobald die Software steht. Es widersteht dem Drang, Bildschirme und Schaltflächen zu beschreiben. Sobald ein Pflichtenheft eine Oberfläche festlegt, hat es die Antwort still entschieden, bevor die Frage überhaupt verstanden war. Beschreiben Sie das Ergebnis und die Rahmenbedingung, und lassen Sie die Discovery die Form finden, die beiden dient.
Der Ablauf, in den es passen muss
Software läuft nicht im luftleeren Raum. Sie läuft in einer realen Abfolge von Handlungen, die Menschen bereits ausführen, oft mit Schritten, die in keinem Diagramm auftauchen. Ein Pflichtenheft zeigt seinen Wert, indem es genau diesen tatsächlichen Ablauf erfasst, samt Ausnahmen und Übergaben, nicht die aufgeräumte Fassung für die Folie. Es sollte ausserdem die Systeme benennen, neben denen das neue Werkzeug bestehen muss, die Daten, die es lesen und schreiben soll, und die Stellen, an denen es an Ihren Bestand andockt. An den Schnittstellen werden stille Annahmen teuer, deshalb gehören diese Ränder früh schriftlich festgehalten.
Fertig definieren, bevor Sie starten
Ein Pflichtenheft ohne eine Definition von fertig lässt dem Umfang freien Lauf, sich auszuweiten. Halten Sie klar fest, was die Software leisten muss, um als abgeschlossen zu gelten, in Begriffen, die jemand prüfen und nicht bestreiten kann. Hier zahlt sich auch Zurückhaltung aus. Lassen Sie die Wunschliste weg, die sich aus Hoffnung statt aus Bedarf angesammelt hat, und lassen Sie die frühe Festlegung auf einen Mechanismus weg, den niemand an der echten Arbeit erprobt hat. Jeder Punkt, der sich seinen Platz nicht verdient hat, ist eine künftige Änderung, die nur auf ihren Anlass wartet.
Ein lebendes Dokument, kein Vertrag
Das Pflichtenheft wird während der Discovery geschärft, nicht am ersten Tag eingefroren. Discovery ist genau dazu da, ans Licht zu bringen, was der erste Entwurf nicht wissen konnte, und ein Pflichtenheft, das diese Erkenntnisse nicht aufnehmen kann, ist schlechter als gar keines. Behandeln Sie es als das gemeinsame, aktuelle Verständnis der Arbeit, das mitwächst, sobald dieses Verständnis besser wird. Es gibt ein verlässliches Signal, dass es noch zu vage ist: vernünftige Menschen lesen dasselbe Dokument und stellen sich verschiedene Systeme vor. Sobald das aufhört, sind Sie bereit zu bauen.
Nichts davon nimmt einem Individualprojekt die Unsicherheit. Es verschiebt die Unsicherheit nach vorne, wo ein Sinneswandel ein Gespräch kostet und keinen Neubau. Das ist der gesamte wirtschaftliche Grund, das Pflichtenheft ernst zu nehmen, bevor jemand eine einzige Zeile schreibt.