Teil 1
Governance in Software- und Produktentwicklung
Software- und Produktentwicklung klingt oft nach einem gemeinsamen Bereich. Für Governance sind es aber unterschiedliche Blickwinkel.
Softwareentwicklung verändert Systeme: Code, Releases, Feature Flags, Schnittstellen, Lauf
Begriffe vor dem Lesen
- Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
- verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
- technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
- Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.
zeitdaten, Sicherheitslücken und Betriebszustände. Produktentwicklung verändert Zusagen: Welche Funktion ist Teil des Produkts, welche Kennzahl zeigt Erfolg, welche Kundengruppe ist betroffen, welche Telemetrie darf erhoben werden und wann wird aus einem Experiment ein versprochener Standard.
Research und R&D liegen daneben, aber nicht einfach darunter. Dort werden Hypothesen getestet, Prototypen gebaut, Modelle trainiert, Partner eingebunden und IP-Grenzen berührt. Ein Experiment darf lernen. Ein Produkt muss halten. Software muss betreibbar sein. Governance sorgt dafür, dass diese drei Zustände nicht still dieselben Tabellen, Events oder Dashboards verwenden.
KMU — ein Experiment-Register, eine Release-/Promotion-Regel und ein sauberer Telemetrie-Zweck reichen oft als erster Schnitt. Mid-Market — Product Operations, Engineering und Stewardship trennen Experiment, Feature, Produkt-KPI und Partner-Share sichtbar. Enterprise — föderierte Labs, mehrere Produktlinien, Security, IP-Counsel, Plattformbetrieb und Datenprodukte brauchen verbindliche Übergaben mit Evidenz.
Ausgangslage
Ein Team testet eine neue Funktion im Lab. Die Telemetrie landet in einem Notebook, später in einem Feature Store und danach in einem Dashboard für Product Management. Parallel nutzt ein Partner einen Export aus dem PoC. Nach einigen Monaten gilt die Zahl als Produkt-KPI, obwohl niemand entschieden hat, ob die Daten für Training, Partneranalyse oder Kundenkommunikation freigegeben waren.
Das Problem ist nicht das Notebook und nicht der Feature Store. Das Problem ist die fehlende Trennung zwischen Experiment, Software-Release, Produktzusage, Telemetrie-Zweck und IP-Grenze. Wenn diese Grenze unklar bleibt, werden technische Möglichkeiten zu fachlichen Entscheidungen.
Was diese Serie klärt
- Wie Softwareentwicklung und Produktentwicklung governance-seitig zusammenhängen, aber unterschiedliche Entscheidungen brauchen
- Wann ein Experiment noch lernen darf und wann daraus eine Produktzusage mit verantwortliche Person, KPI und Betriebspflicht wird
- Welche Telemetrie für Produktanalyse, Training, Support oder Partnernutzung verwendet werden darf
- Warum Ablage für Modellmerkmale-, Notebook-, CI/CD- oder Plattform-Admins keine fachliche Produktfreigabe ersetzen
- Welche KPIs typisch sind: Adoption, Aktivierung, Retention, Feature-Nutzung, Fehlerrate, Release-Stabilität, Time-to-Recovery, Experiment-Ergebnis und Kundenauswirkung
Begriffe und Kürzel vor dem Lesen
- Experiment — befristeter Lernraum mit Hypothese, verantwortliche Person, Datenscope und Ausstieg. Kein stilles Produkt.
- Software-Release — technische Änderung an System, Schnittstelle oder Verhalten. Braucht Tests, Rückbau, Security-Check und Betriebsnachweis.
- Produktzusage — fachliches Versprechen gegenüber Kundinnen, Nutzern oder internen Nutzer. Braucht verantwortliche Person, Umfang, KPI und Änderungsregel.
- Telemetrie — Nutzungs- und Laufzeitdaten. Erhebung, Produktanalyse, Training und Partnernutzung sind unterschiedliche Zwecke.
- Produktfreigabe — bewusster Übergang von Experiment zu Produkt, nicht das Kopieren einer Tabelle.
- IP-Grenze — Regel, welche Daten, Modelle, Spezifikationen oder Aggregate intern bleiben oder kontrolliert geteilt werden.
Software- und Produktentwicklung ist eine Peer-Karte in Erweiterte Funktions-Governance. Sie verbindet Product, Engineering, Research, Security, Legal/IP und Datenplattform, ohne eine dieser Rollen zur alleinigen Governance-Zentrale zu machen.
Nachbar-Karten: ← Customer Service · Software- und Produktentwicklung (diese Seite) · Procurement →
Konzept halten — Last-Säulen: Verantwortung, PII, Quality und Lifecycle tragen diese Kette. These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.
Orientierungskarte — Software, Produkt und Research trennen
| Blickwinkel | Governance-Frage | Typische Owner | Beweis nach 90 Tagen | Nicht tun |
|---|---|---|---|---|
| Softwareentwicklung | Welche Änderung darf in Produktion und wie wird sie zurückgerollt? | Engineering Lead / Service Owner | Release-Gate mit Test, Security-Check und Rollback-Nachweis | Deploy-Recht als Produktfreigabe behandeln |
| Produktentwicklung | Welche Funktion oder Kennzahl ist Teil der Produktzusage? | Product Owner / Product Lead | Feature-Contract mit Scope, KPI, Zielgruppe und Änderungsregel | Experiment-Zahl als offiziellen KPI verwenden |
| Research / R&D | Was ist Hypothese, was darf geteilt werden und wann endet der Lernraum? | Research Owner / Model Owner | Experiment-Register mit Zweck, Datenscope, IP-Grenze und Exit | Research Lake als dauerhafte Wahrheit aufbauen |
Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation
Produkte und Entscheidungen
Software- und Produktentwicklung braucht nicht „einen Research Lake“ und auch keinen allmächtigen Feature Store. Sie braucht geschnittene Governance-Produkte, die jeweils eine konkrete Entscheidung tragen.
Experiment vs. Produkt vs. Partner-Share
Dieses Produkt beschreibt die dreifache Grenze, nicht eine Tabelle mit einem Flag.
Es benötigt:
- Experiment-ID; Hypothese; Product- oder Research-verantwortliche Person; fachliche Ebene; Systeme; geplanter Ausstieg; Promotionsregel; Partnerfreigabe-Status.
Entscheidungen:
- Ist dieser Stand noch Experiment oder schon Produktzusage?; Wer darf promoten?; Was muss am Ausstieg vernichtet oder zurückgeholt werden?; Welcher Partner sieht welches fachliche Ebene?
IP-Grenze
Die Grenze ist kein NDA-Absatz. Sie ist Klassifikation plus Kanal plus Form.
Entscheidungen:
- Was darf hinaus (Rohdaten, Aggregat, Modellgewicht, Spezifikation)?; Wer bindet einen Partnerfreigabe nach Counsel-Meinung?; Welche Schatten-Uploads (Drive, Chat, privates Repo) sind verboten?; Welche Vernichtungs- oder Rückgabepflicht gilt?
Telemetrie-Zweck
Erhebung ist ein Zweck. Training ist ein zweiter. Partner-Analytik ist ein dritter.
Entscheidungen:
- Welcher Zweck deckt dieses Event ab?; Wann braucht Training eine neue Zweckbindung?; Wer schließt einen Zweck?; Welche Retention gilt pro Zweck, nicht pro Pipeline?
Promotion und Feature-Freigabe
Promotion ist die Brücke, nicht das Kopieren der Tabelle.
Entscheidungen:
- Wer unterschreibt die Produktfreigabe?; Welche Experiment-Felder dürfen nicht ins Produkt-fachliche Ebene?; Wie wird Rückbau nachgewiesen?; Welcher Nutzer hängt ab wann an der neuen Zusage?
Wo Governance hängt
Zwischen Notebook und Produkttabelle
Ein Export ohne Promotion ist Theater. Der Custodian braucht eine maschinenlesbare Promotionsliste, nicht nur einen Slack-Thread.
Zwischen Telemetrie-Erhebung und Training
Dieselben Events dienen oft „Produktanalytik“, landen aber im Feature Store. Ohne Zweckspaltung gehört das Training stillschweigend dazu — bis Auskunft oder IP-Streit die Kopien zählt.
Zwischen NDA und freigegebenem Austauschweg
Ein unterschriebener Geheimhaltungsvertrag reicht nicht. Es muss zusätzlich feststehen, über welchen Kanal welche Daten in welcher Form geteilt werden dürfen. Drive-Links und private Repositories umgehen diese Grenze.
Zwischen IP-Counsel und Product Owner
IP-Counsel bewertet, welche Ideen, Spezifikationen oder Schutzrechte das Unternehmen verlassen dürfen. Der Product- oder Research-Owner bindet die konkrete Partnerfreigabe und das Restrisiko. Eine Person entscheidet verantwortlich; die andere berät.
Zwischen Modellablage-Admin und Produktfreigabe
Wer eine Tabelle für Modellmerkmale anlegen kann, ist nicht berechtigt zu entscheiden, ob ein Experiment zum Produkt werden darf.
Rollen-Mapping
Data Owner (R&D / Produkt)
Head of Product, Research Lead oder benannter Product-/Research-Owner ist verantwortlich für Zweck der Experiment- und Produktdaten, Telemetrie-Zwecke, akzeptables IP-Restrisiko und Freigabe zentraler Partnerfreigaben. Der Owner entscheidet nicht, wie Tabellen im Warehouse modelliert werden. IP-Counsel berät die Grenze, ersetzt den Owner aber nicht.
Data Steward
R&D Operations oder Product Operations prüft Partnerfreigaben, pflegt Experiment-IDs, überwacht Telemetrie-Zwecke und Exit-Fristen und eskaliert widersprüchliche Kopienlisten.
Data Product Owner
Priorisiert Experiment-Register, Telemetrie-Vereinbarung und Partnerfreigaben-Index. Nutzen und Lieferbarkeit — nicht die IP-Auslegung.
Data Architect
Schützt die fachliche Ebene der Daten: Ein Experimentlauf, ein freigegebenes Produktdatenpaket und ein Partner-Export sind drei unterschiedliche Dinge. Außerdem hält der Architect fest, aus welchen Daten etwas abgeleitet wurde und welche Änderungen abhängige Nutzer oder Systeme brechen würden.
Data Custodian
Zugriffsverwaltung, Ablage für Modellmerkmale, Notebook-Plattform und Objektspeicher setzen Zugriff, genehmigten Kanal und Entzug technisch um. Wer ein System konfigurieren kann, entscheidet damit nicht automatisch über Produktfreigaben oder Partnerfreigaben.
Data Consumer
Produktanalytik, Modelltraining und Partner nutzen die Daten nur mit gebundenem Zweck. IP-Counsel prüft Partnerfreigaben. Abweichungen laufen über denselben Anfrageweg — keine stillen Drive-Dumps.
Mini-Fall
Anwendungsbeispiel (Lehrfall, keine Kundendaten).
Symptom: Während eines Proof of Concept wurden Telemetrie-Events, also Messwerte und Nutzungsereignisse aus Tests, in einen gemeinsamen Partner-Drive gelegt. Sechs Monate später nutzt ein Produktionsmodell genau diese Testereignisse als Trainingsdaten. Zusätzlich zeigt ein Dienstleister-Dashboard Kennzahlen aus denselben Testdaten, obwohl nie geklärt wurde, ob sie für Training oder Partner-Reporting freigegeben sind.
Typischer Fehlstart: Eine technische Ablage für Modellmerkmale kaufen und im Katalog research=true setzen, ohne die Zwecke und geteilten Kopien wirklich zu trennen.
Vereinbarung: Jede Experiment-ID bekommt Enddatum und Rückbau. Jede Partnerfreigabe beschreibt Form, erlaubten Zweck, Schutzgrenze und Vernichtungspflicht. Telemetrie darf erst für Training oder Produktnutzung verwendet werden, wenn dieser neue Zweck ausdrücklich gebunden ist.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Product-/Research-Owner | R&D-Ops / Steward | Experiment-, Produktfreigabe- oder Partnerfreigabe-Entscheidung mit Identifier und Zweck |
| Steward | Plattform-Custodian | Zugriff / genehmigter Share-Kanal / Entzug |
| Steward | Architect / Engineering | Regel, wann Experimentdaten zu Produktdaten oder Partnerdaten werden dürfen |
| IP-Counsel | Owner | Grenzmeinung; Owner bindet die Partnerfreigabe |
| Partner / Requestor | Steward | Freigabeanfrage mit Umfang, Form, Frist und Vernichtung |
| Custodian | Owner | Nachweis zum Share-Kanal: welche Experiment- oder Produktdaten geteilt wurden, mit welchem Partnerumfang und welchem Vernichtungsnachweis |
Anti-Patterns
- Experiment und Produkt in einer Tabelle ohne bewusste Produktfreigabe
- Telemetrie-Zweck „Research“, der Training und Partner mitabdeckt
- IP-Grenze nur als NDA, Partnerfreigabe über privates Drive
- Admin der Modellmerkmale-Ablage entscheidet über Produktfreigabe, nur weil die Oberfläche es technisch erlaubt
- Partnerfreigabe ohne Enddatum und Vernichtungsnachweis
- Notebook als System of Record für Zweck und verantwortliche Person
Erster Umsetzungsschnitt
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
Schritt 1: Rahmen und Entscheidung klären
Ein laufendes oder jüngstes Experiment wählen, das bereits in Produkt oder Partner geleakt hat. Identifier, Kopien, Zwecke und Shares aufnehmen. Experiment-Register mit fünf Einträgen schneiden.
Schritt 2: Control und Nachweis umsetzen
Telemetrie-Zweck an einem Event-Strom binden. Einen Partner-Share mit Exit-Datum führen. Negativtest: Trainingsjob ohne Trainingszweck muss fehlschlagen.
Schritt 3: Testen und Ausnahmen sichtbar machen
Eine Promotion Experiment → Produkt und einen Share-Entzug mit Owner-Entscheidung durchspielen. IP-Counsel-Meinung und wirksame Kanalkonfiguration zum Share-Tag rekonstruieren.
Schritt 4: Messen und begrenzt ausrollen
Aufwand und Lücken messen. Nur bestandene Muster (Register, Zweck, Share) auf ein zweites Lab oder eine zweite Produktlinie übertragen.
Exit-Kriterien
- Experiment-Register hat verantwortliche Person, Zweck und Enddatum.
- Produkt-fachliche Ebene entsteht nur über eine gebundene Produktfreigabe.
- Telemetrie-Zwecke trennen Erhebung, Training und Partner.
- Partner-Partnerfreigaben nennen Form, Kanal und Vernichtungspflicht.
- technischer Betreiber liefert Konfigurationsnachweis ohne mündliche Brücke.
Weiterlesen
- Extended Functions Deep Dive
- Functions Hub — R&D / Product
- Procurement Dienstleister Nachweis
- R&D-IP-Grenze
- Partner-Onboarding: Vertrag zum Katalog
