Wofür steht die Abkürzung PRD?

PRD steht für Product Requirements Document, auf Deutsch Produktanforderungsdokument. Meist schreibt es die Person, die für das Produkt verantwortlich ist, zum Beispiel im Produktmanagement, bevor Design und Entwicklung beginnen. Es sagt, was gebaut werden soll und wozu, und überlässt das Wie dem Team.

Was unterscheidet ein PRD von einem Plan in featureloom?

Ein PRD umfasst meist ein ganzes Produkt oder eine ganze Funktion. Ein Plan in featureloom beschreibt ein Arbeitspaket, das ein Agent vollständig bekommt, liefert und meldet. Deshalb wird aus einem PRD oft ein Epic mit mehreren Plänen, deren Reihenfolge Abhängigkeiten festhalten.

Wie werden aus einem fertigen PRD Pläne in featureloom?

Fügen Sie seinen Text auf dem Bildschirm „Erfassung“ ein oder senden Sie es als PDF- oder Word-Dokument, und featureloom generiert daraus einen Plan nach der Planvorlage Ihres Projekts. Sie können es auch einem Agenten in einer Konsole als Textdatei geben, zusammen mit dem Befehl mit dem Prompt Planer: Der Prompt weist ihn an, Pläne in den Abschnitten der Vorlage zu schreiben und sie Epics zuzuordnen.

PRD: was ein Product Requirements Document ist

Was ein PRD enthält

Ein PRD beschreibt das Produkt aus der Sicht der Menschen, die es nutzen werden. Es beantwortet, was gebaut werden soll und wozu, und überlässt die technische Lösung dem Team, das es baut. Meist schreibt es die Person, die für das Produkt verantwortlich ist, und gelesen wird es von Design, Entwicklung und Test.

Die meisten PRDs behandeln dieselben Themen, auch wenn die Überschriften von Team zu Team verschieden sind:

Zweck. Das Problem, das das Produkt oder die Funktion löst, und warum es gerade jetzt wichtig ist.
Nutzer. Für wen das Produkt gedacht ist und in welchen Situationen es genutzt wird.
Anforderungen. Was das Produkt leisten soll, oft als User Storys oder als Liste von Funktionen, dazu Eigenschaften wie Geschwindigkeit, Sicherheit oder Barrierefreiheit.
Umfang. Was zu dieser Version gehört und was bewusst draußen bleibt.
Erfolgskriterien. Woran das Team erkennt, dass das Produkt tut, was es soll, zum Beispiel an messbaren Zielen oder Abnahmekriterien.
Annahmen und offene Fragen. Was das Team als gegeben annimmt, was von anderer Arbeit abhängt und was noch zu entscheiden ist.

Ein PRD hat verwandte Dokumente. Ein Marktanforderungsdokument (MRD, Market Requirements Document) beschreibt den Bedarf am Markt, auf den ein Produkt antwortet, noch bevor das Produkt selbst festgelegt ist. Ein funktionales Anforderungsdokument (FRD, Functional Requirements Document), auch funktionale Spezifikation genannt, geht eine Ebene tiefer und beschreibt genau, wie sich das System verhält. Das PRD liegt dazwischen: Es sagt, was das Produkt für seine Nutzer leistet.

Wie man ein PRD schreibt

Beginnen Sie mit dem Problem, nicht mit der Lösung: Beschreiben Sie in wenigen Sätzen, wer das Problem hat und was es ihn heute kostet. Schreiben Sie die Anforderungen dann so, dass sich jede überprüfen lässt. „Schnell“ lässt sich nicht prüfen, „Suchergebnisse erscheinen innerhalb einer Sekunde“ schon. Halten Sie fest, was außerhalb des Umfangs liegt, denn genau dort beginnen oft die Missverständnisse.

Ein PRD ist ein Arbeitsdokument. Es ändert sich, wenn das Team dazulernt. Deshalb lohnt es sich, es an einem Ort zu führen, an dem alle die aktuelle Fassung lesen, und Entscheidungen festzuhalten, sobald sie fallen.

Wenn ein KI-Agent nach einem PRD arbeitet, zählen diese Regeln noch mehr. Schreiben Sie offene Fragen auf, statt sie wegzulassen: Was das Dokument nicht sagt, muss ein Coding-Agent selbst erschließen. Ein PRD für ein ganzes Produkt ist meist zu groß für eine Sitzung eines Agenten. Teams, die so arbeiten, teilen es in kleinere Aufgaben mit jeweils eigenen Abnahmekriterien. Das ist der Kern von Spec-driven Development.

Das PRD in featureloom

In featureloom ist die Einheit der Arbeit der Plan: ein Dokument in Markdown auf dem Board, das ein Arbeitspaket beschreibt, das der Agent vollständig bekommt, liefert und meldet. Ein PRD beschreibt meist mehr, deshalb entstehen daraus mehrere Pläne, gebündelt in einem Epic und durch Abhängigkeiten geordnet.

Sie müssen ein PRD nicht von Hand abschreiben. Fügen Sie auf dem Bildschirm „Erfassung“ seinen Text in das Feld „Material“ ein oder senden Sie es als PDF- oder Word-Dokument, und featureloom generiert daraus einen Plan nach der Planvorlage Ihres Projekts. Die Anleitung Plan aus eingefügtem Text oder einem PDF- oder Word-Dokument zeigt jeden Schritt. Ob aus demselben Material mehr als ein Plan entstehen kann, hängt von der Einstellung Ihrer Organisation ab.

Die eingebaute Planvorlage fragt nach Ziel, Umfang, Schritten, Abnahmekriterien und Definition of Done: den Teilen eines PRD, die ein Agent braucht, um ein Arbeitspaket zu liefern. Die Vorlage passen Sie auf dem Bildschirm „Projekteinstellungen“ im Reiter „Planvorlage“ an Ihr Team an.

Sie können ein PRD auch einem Agenten in einer Konsole als Textdatei geben, zusammen mit dem Befehl mit dem Prompt Planer. Der Prompt weist den Agenten an, die Planvorlage des Projekts zu lesen, für ein Thema ohne Epic eines anzulegen, jeden Plan in den Abschnitten der Vorlage als ein Arbeitspaket für eine Agentensitzung zu schreiben und die Reihenfolge mit Abhängigkeiten festzuhalten. Dafür braucht die Person, die die Konsole verbunden hat, das Recht „Schreibt Pläne“.