Governance in Software- und Produktentwicklung

Was diese Landschaft besonders macht

Entwicklung und Forschung arbeiten mit Experimenten, wechselnden Datenständen und vorläufigen Ergebnissen. Ein guter Versuch ist noch kein dauerhaft betreibbares Produkt. Telemetrie für Fehleranalyse, Produktverbesserung und Training kann denselben technischen Ursprung haben, aber unterschiedliche Nutzungsgrenzen.

• Experiment, Datenstand und reproduzierbare Ergebnisversion verbinden.
• Produktfreigabe von Repository- oder Store-Administration trennen.
• Telemetrienutzung und externe Datenweitergabe ausdrücklich unterscheiden.

Welche Werkzeuge zu welcher Aufgabe passen

Ausgangspunkt sind die Aufgabe und die vorhandenen Systeme. Die Beispiele zeigen geeignete Einsatzgebiete; vor einer Auswahl müssen Datenzugriff, Funktionsumfang und laufender Betriebsaufwand im eigenen Bestand geprüft werden.

Die folgenden Kapitel vertiefen die einzelnen Grenzen und Problemfelder:

• Experiment-Register mit Exit
• Telemetrie-Zweck spalten
• Promotion Experiment zu Produkt
• Partner-Share-Vertrag
• Feature-Freigabe versus Store-Admin

Einstieg

Softwareentwicklung, Produktentwicklung und Research arbeiten eng zusammen. Für Governance sind es aber nicht dieselben Entscheidungen.

Softwareentwicklung verändert Systeme: Code, Schnittstellen, Releases, Feature Flags und Betriebszustände. Produktentwicklung verändert Zusagen: Welche Funktion gehört zum Produkt, welche Kennzahl ist offiziell und welche Nutzergruppe ist betroffen? Research und R&D testen Hypothesen, bauen Prototypen, arbeiten mit Partnern und berühren geistiges Eigentum.

Ein Experiment darf lernen. Ein Produkt muss halten. Software muss betreibbar sein. Governance sorgt dafür, dass diese Zustände nicht still dieselben Tabellen, Events, Notebooks oder Dashboards verwenden.

Wenn du nur fünf Minuten hast

1. Starte mit dem Zustand: Experiment, Telemetrie, Produktzusage, Partner-Share oder Feature.
2. Kläre Zweck, Owner, Datenumfang, Enddatum und Exit, bevor Daten weiterverwendet werden.
3. Trenne Lernen im Experiment von offizieller Produktwahrheit.
4. Promotiere Kennzahlen, Features und Modelle bewusst, statt sie aus PoCs zu übernehmen.
5. Begrenze Partner-Shares nach Zweck, Form, Kanal, Frist, IP-Grenze und Löschpflicht.

Begriffe vor dem Lesen

• Experiment — befristeter Test mit Hypothese, Zweck, Datenumfang und Enddatum.
• Produktzusage — verbindliche Zusage gegenüber Kunden, Nutzern oder internen Teams.
• Telemetrie — Nutzungs- und Laufzeitdaten wie Events, Klicks, Fehler, Performance-Signale oder Testläufe.
• Promotion — bewusste Freigabe, mit der ein Experiment in ein Produkt oder produktives Verhalten überführt wird.
• Feature — abgeleitetes Merkmal, das ein Modell, eine Regel oder eine Analyse nutzt.
• IP-Grenze — Grenze für geistiges Eigentum: was intern bleibt, was geteilt werden darf und in welcher Form.
• Partner-Share — kontrollierte Weitergabe an Partner, Kunden im Pilotbetrieb, Forschungspartner oder Dienstleister.

Warum diese Landschaft kritisch ist

R&D- und Produktteams arbeiten schnell. Sie kopieren Daten in Notebooks, testen Modelle, teilen Prototypen, bauen Feature Stores, aktivieren Releases und zeigen Ergebnisse in Dashboards.

Das ist nicht automatisch falsch. Es wird gefährlich, wenn ein Lernstand plötzlich als Produktwahrheit gilt.

Typische Bruchstellen sind:

• Testdaten werden später für Modelltraining genutzt, obwohl Training nie freigegeben wurde.
• Eine PoC-Kennzahl erscheint im offiziellen Produkt-KPI-Dashboard.
• Ein Partner bekommt Rohdaten, obwohl nur aggregierte Ergebnisse erlaubt waren.
• Ein Store-Admin kann ein Feature technisch veröffentlichen und wird dadurch faktisch zum Produktfreigeber.
• Experimentkopien bleiben nach Projektende in Drives, Repositories oder Workspaces liegen.

Das Grundmuster

Die Serie trennt fünf Zustände, die oft technisch ineinanderlaufen.

Was diese Serie klärt

Diese Serie ist der Einstieg für Software- und Produktentwicklung. Sie zeigt, wie Experimente, Telemetrie, Produktfreigaben, Partnerdaten und Features sauber getrennt werden, ohne Innovation zu bremsen.

Die sechs Teile bauen aufeinander auf:

• Dieser Teil erklärt die Landschaft.
• Teil 2 führt das Experiment-Register mit Exit ein.
• Teil 3 trennt Telemetrie-Zwecke.
• Teil 4 erklärt Promotion vom Experiment zum Produkt.
• Teil 5 regelt Partner-Shares und IP-Grenzen.
• Teil 6 trennt technische Feature-Bereitstellung von fachlicher Freigabe.

Produkte und Entscheidungen

Experiment-Register

Das Register beschreibt, welche Experimente laufen, wer sie verantwortet, welcher Zweck gilt, welche Daten genutzt werden und wann das Experiment endet.

Wichtige Entscheidung: Wird der Test beendet, verlängert, gelöscht oder bewusst ins Produkt überführt?

Telemetrie-Zweckkarte

Eine Zweckkarte beschreibt, wofür Events genutzt werden dürfen. Produktanalyse, Training, Support und Partnerreporting sind unterschiedliche Zwecke.

Wichtige Entscheidung: Darf dieses Event für diesen neuen Zweck genutzt werden?

Promotionsnachweis

Promotion ist der bewusste Übergang vom Experiment in produktives Verhalten. Der Nachweis beschreibt Umfang, KPI, Zielgruppe, Rollout, Betrieb und Rückbau.

Wichtige Entscheidung: Ab wann ist die neue Funktion oder Kennzahl eine Produktzusage?

Partner-Share-Vertrag

Ein Partner-Share beschreibt Zweck, Form, Kanal, Zeitraum, Empfänger, IP-Grenze und Löschpflicht. Ein Geheimhaltungsvertrag allein reicht nicht.

Wichtige Entscheidung: Was darf in welcher Form über welchen Kanal nach außen?

Feature-Freigabe

Ein Feature Store oder eine Modell-Registry stellt Merkmale technisch bereit. Die fachliche Freigabe entscheidet aber Product oder Model Ownership.

Wichtige Entscheidung: Für welches Modell, Produkt oder welche Entscheidung darf dieses Feature genutzt werden?

Rollen in einfachen Worten

Product Owner oder Product Lead verantworten Produktzusage, KPI, Zielgruppe und Kundenauswirkung. Research Owner oder Model Owner verantworten Hypothese, Trainingsnutzung und Modellwirkung. Engineering verantwortet Release, Betrieb, Sicherheit, Rollback und technische Umsetzung. Legal, Datenschutz und IP-Counsel prüfen rechtliche Grenzen, Personenbezug und geistiges Eigentum. Data Stewards halten Experiment-IDs, Zwecke, Partnerfreigaben und offene Entscheidungen nachvollziehbar. Data Custodians betreiben Notebook-Plattformen, Feature Stores, Zugriffe und Ablagen.

Der zentrale Punkt: Technische Veröffentlichbarkeit ist keine fachliche Freigabe.

Mini-Fall

Ein Team testet eine neue Empfehlung in einem Pilotkundenkreis. Die Events landen zuerst in einem Notebook. Später nutzt ein Modell dieselben Events für Training. Product Management zeigt die Ergebniszahl im KPI-Dashboard. Ein Partner erhält einen Export, um das Verhalten zu analysieren.

Alle Nutzungen können sinnvoll sein. Aber sie sind nicht automatisch erlaubt.

Die saubere Lösung: Das Experiment bekommt eine ID, Zweck und Enddatum. Telemetrie wird nach Produktanalyse, Training und Partnernutzung getrennt. Promotion macht aus dem Pilot erst dann eine Produktzusage, wenn Product die Zielgruppe, KPI und Rollback-Regel freigibt. Der Partner bekommt nur einen genehmigten Share über einen genehmigten Kanal.

Erster Umsetzungsschnitt

1. Ein aktuelles oder kürzlich beendetes Experiment auswählen.
2. Experiment-ID, Hypothese, Datenumfang, Zweck und Enddatum dokumentieren.
3. Prüfen, ob Telemetrie schon für Training, Support oder Partner genutzt wird.
4. Eine PoC-Kennzahl aus offiziellen Dashboards entfernen oder bewusst promoten.
5. Einen Partner-Share mit Form, Kanal, Frist und Löschpflicht beschreiben.
6. Ein Feature prüfen, das mehr als einmal genutzt wird.
7. Owner, Steward und technischen Custodian getrennt benennen.

Exit-Kriterien

• Jedes wichtige Experiment hat ID, Zweck, Owner und Enddatum.
• Telemetrie unterscheidet Produktanalyse, Training, Support und Partnernutzung.
• Produktkennzahlen entstehen nur über bewusste Promotion.
• Partner-Shares nennen Zweck, Form, Kanal, Frist und Löschpflicht.
• Feature Stores und Notebook-Plattformen ersetzen keine fachliche Freigabe.

In der Serie weiterlesen

• Experiment-Register mit Exit