Hauptgedanke

Eine Abfrageoberfläche, ein Export, ein Dashboard, ein Abfragewerkzeug, von einem Produktteam aufgesetzt, liegen neben dem Produkt: Sie konsumieren APIs, führen Informationen zusammen und liefern eine Oberfläche, die dem nützt, der sie gebaut hat, oder seinem Team. Wenn sie kaputtgehen, geht nur das Werkzeug selbst kaputt.

Ein Modul, ein Ablauf oder eine fachliche Variante, gebaut auf der Codebase des Unternehmens, liegen in seiner Verlängerung. Sie nutzen die vorhandenen Bausteine, die Fachsprache des Codes, die hauseigenen Komponenten – und sie landen im selben Repository, mit denselben Abhängigkeiten und denselben Kunden am Ende. Wenn sie kaputtgehen, geht das Produkt kaputt.

Der Unterschied liegt nicht in Größe oder Ehrgeiz, sondern in der Wirkungsfläche, und sie sollte über die Anforderungen entscheiden – nicht die Frage, ob jemand aus dem Produkt oder ein Entwickler an der Tastatur sitzt.

Warum das wichtig ist

Das liefert ein operatives Kriterium, wo die Diskussion sonst beim Niveau der Person hängen bleibt. „Daneben“ oder „in der Verlängerung“ lässt sich feststellen, indem man nachsieht, wo der Code landet und wer von ihm abhängt; „kompetent genug“ lässt sich nicht feststellen.

Es zeichnet auch zwei getrennte, nicht gleichwertige Wege: Entwickler von kleinen internen Werkzeugen zu entlasten, ist ein bescheidenes und erreichbares Ziel; Produktleuten zu erlauben, zum Produkt selbst beizutragen, ist ein anderes Thema, mit anderen Bedingungen.

Nuancen und Grenzen

Die Grenze ist nicht dicht. Ein danebengebautes Werkzeug, das in die Produktionsdatenbank schreibt, hat die Wirkungsfläche eines Objekts in der Verlängerung, egal wo es im Repository liegt.

Und der Unterschied im Risiko sagt nichts über den Unterschied im Wert: Das nützlichste Objekt ist nicht immer das, das das Produkt berührt.

Offene Fragen

• Wie weit kann eine Organisation Produktleute in der Verlängerung des Produkts bauen lassen, ohne die technische Kontrolle, die Kohärenz und die Sicherheit des Ganzen zu verlieren?