tpo42 entstand aus der praktischen Notwendigkeit heraus, die Lücke zwischen Product Management und Software Architecture zu schließen.

Während ein arc42 Dokument die Frage:

  • Was sollen wir über unsere Architektur kommunizieren/dokumentieren?

und ein req42 Dokument die Frage:

  • Warum sollen wir uns über unser Produkt Gedanken machen?

getrennt beantwortet, verbindet tpo42 die Fragen und benutzt das Wie sollen wir kommunizieren/dokumentieren? weiter.

1. Struktur

Die einfachen Templates von arc42 und req42 bleiben erhalten. Dieses Template unterstellt, dass man sich zuerst Gedanken um das Warum macht, weswegen arc42-Kapitel im Zweifel Inhalte aus req42-Kapiteln einschließen.

Als Technical Product Owner verbringt man weniger Zeit im Backlog - diese Aufgabe teilt man sich mit dem "hohen Projektmanagement", dass die gesamte Produkt-Vision verantwortet. Dafür ist der Brückenschlag zur Architektur wichtiger. Das bedeutet. die Kapitel:

  • Scope-Abgrenzung

  • Qualitätsanforderungen

  • Modelle zur Unterstützung

werden wichtiger, Kapitel wie

  • Stakeholder

  • Randbedingungen

  • Produkt-Backlog

erhalten einen zu dem blauen einen roten Aspekt[1].

2. Redundanzen im Überblick

req42 arc42 redundancy