Idee

Das Recht, Code zu produzieren, bemisst sich am Verhältnis zwischen Kompetenz und Risiko des Produkts, nicht an der Kompetenz allein

Info

Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.

Hauptgedanke

Die Frage „Kann ein Product Manager jetzt mit einem Assistenten entwickeln?“ verlangt nach einem Ja oder Nein, und genau das macht sie unbrauchbar. Keine Organisation geht mit ihren eigenen Entwicklern so vor: Einem Berufseinsteiger öffnet man nicht am ersten Tag das kritischste Repository, und man gibt ihm auch nicht alle Zugänge, alle Daten und alle Rechte. Die Kompetenz entscheidet nicht allein; sie entscheidet im Verhältnis zu dem, was auf dem Spiel steht.

Die brauchbare Formulierung ist also kein Recht, sondern ein Spielraum. Ein kleines internes Werkzeug, persönlich, kurzlebig und ohne Wirkung, verträgt wenig Formalismus: Wenn es kaputtgeht, wirft man es weg. Ein geteiltes Werkzeug mit begrenzten Schreibzugriffen und fachlichen Abhängigkeiten verlangt schon mehr. Ein Produkt, das sensible Kundendaten, Berechtigungen, Abrechnung oder unumkehrbare Schreibvorgänge berührt, gehört in eine ganz andere Kategorie.

Dieselbe Überlegung gilt für die Kompetenz, und nicht nur beim Einstieg: Wer bei einem internen Werkzeug in Kauf nimmt, manche Teile des Codes nicht erklären zu können, kann dieselbe Unschärfe bei einem kritischen Produkt ablehnen. Der Regler ist kein Charakterzug, sondern eine Abwägung je Produkt.

Warum das wichtig ist

Das holt die Diskussion aus dem Streit um Legitimität heraus. Darüber zu debattieren, ob Produktleute „das Recht“ haben zu coden, ergibt keine Richtlinie; festzulegen, was sie tun dürfen, in welchen Repositories, mit welchen Rechten und ab welcher Tragweite, ergibt eine.

Es verschiebt auch die Beweislast. Es geht nicht mehr darum nachzuweisen, dass ein Product Manager gut genug ist, sondern darum, die Produkte danach einzuordnen, was ein Fehler dort kosten würde – eine Arbeit, die die Organisation ohnehin leisten muss, auch für ihre Entwickler.

Nuancen und Grenzen

Die Regel setzt voraus, dass die Risikokategorie eines Objekts bekannt ist, wenn man es baut. Das ist selten der Fall, und ein Werkzeug kann durch seine Verbreitung die Kategorie wechseln, ohne dass der ursprüngliche Rahmen neu verhandelt wird.

Sie sagt auch nichts darüber, welches Anforderungsniveau für jede Kategorie gelten soll: Sie legt die Frage fest, nicht das Raster, und dieses Raster hängt vom jeweiligen Unternehmen ab.

Offene Fragen

  • Wer in einer Organisation ist befugt, ein Produkt einer Risikokategorie zuzuordnen – das technische Team, die Sicherheit, der Fachbereich, der davon abhängt?