Diese Bauweise erklärt Stärken und Grenzen. Wer Software, Datenprodukte oder technische Infrastruktur baut und mit GitHub arbeitet, bekommt Planung ohne Systemwechsel und ohne Doppelerfassung. Wer hingegen Kapazitäten mehrerer Abteilungen gegen Aufwände plant, Zeiten abrechnen oder Dateien formal freigeben muss, stößt schnell an eine Wand, die nicht durch Konfiguration verschwindet.
Ein zweiter Punkt gehört zur ehrlichen Einordnung: Projects ist anspruchslos in der Einführung und anspruchsvoll in der Disziplin. Ein brauchbares Board steht in einer Viertelstunde; ob nach einem Jahr noch belastbare Auswertungen möglich sind, entscheidet sich daran, ob jemand Felder, Statuswerte und Konventionen konsequent gepflegt hat. Das Werkzeug erzwingt sehr wenig — es belohnt Klarheit und bestraft Beliebigkeit.
Die kleinste Einheit ist das Issue — ein Vorgang mit Titel, Beschreibung in Markdown, Verantwortlichen, Labels, Kommentarspur, Verweisen auf andere Vorgänge und optional einem Milestone. Issues gehören zu einem Repository, nicht zu einem Projekt; das ist eine wichtige Unterscheidung. Ein Project sammelt Issues und Pull Requests aus einem oder mehreren Repositories und ergänzt sie um eigene Felder, die nur im Projekt existieren: Status, Priorität, Aufwandsgröße, Zielquartal, Team, Iteration und was die Organisation sonst braucht.
Auf diesen Datenbestand setzen die Ansichten auf — Tabelle, Board und zeitliche Roadmap, jeweils mit eigenen Filtern und Gruppierungen. Ansichten sind Blickwinkel, nicht Kopien. Ergänzend gibt es Drafts: Notizen im Projekt, die noch kein Issue sind und sich später in eines umwandeln lassen — praktisch für Ideensammlungen, aber zu begrenzen, weil sie außerhalb der Repository-Logik leben.
Klassische Projektwerkzeuge stehen neben der eigentlichen Arbeit und müssen mit ihr abgeglichen werden; GitHub Projects steht mitten darin. Ein Pull Request, der ein Issue schließt, bewegt es automatisch in die Spalte Fertig, ein Release verweist auf die enthaltenen Vorgänge, eine Diskussion steht neben dem Code, den sie betrifft. Die Kehrseite ist eine Zugangsfrage: Für Vertrieb, Buchhaltung oder Geschäftsführung ist die Umgebung ungewohnt, und Lesezugriff allein löst das nicht. Wer Projects einführt, sollte früh klären, welche Rollen tatsächlich darin arbeiten und wer stattdessen einen Bericht bekommt.
Im deutschsprachigen Mittelstand begegnet uns Projects in drei Konstellationen: das interne Entwicklungsteam, das Software für den eigenen Betrieb oder als Produktbestandteil baut; die IT- oder Digitalisierungsabteilung, die Automatisierungen, Schnittstellen und Infrastruktur als Code betreibt; und der Dienstleister, der Kundenprojekte technisch abwickelt und die Zusammenarbeit über Issues organisiert.
Auffällig ist, was fehlt: Marketing, Verwaltung, Fertigungssteuerung, kaufmännische Auftragsdurchläufe. Als Regel gilt, dass der Nutzen mit der Nähe zur technischen Arbeit steigt und mit der Entfernung davon rasch abnimmt. Wer Projects über die ganze Organisation ausrollen will, weil es lizenzseitig ohnehin vorhanden ist, sollte diese Grenze kennen, bevor er sie überschreitet.
In der Free-Stufe steht Projects für persönliche Konten und Organisationen zur Verfügung: Boards, Tabellen, eigene Felder, Roadmap-Ansicht, Issues, Milestones und Labels. Für kleine Teams ist das erstaunlich weit tragfähig. Grenzen liegen weniger in Projects als in der Umgebung — bei Rechten, Automatisierungsvolumen und Verwaltungsfunktionen.
Die Team-Stufe zielt auf Organisationen, die verbindlich zusammenarbeiten. Charakteristisch sind erweiterte Berechtigungen auf Repository- und Team-Ebene, geschützte Branches, Review-Regeln und ein größerer Rahmen für Automatisierung. Für den typischen mittelständischen Fall — ein bis drei Entwicklungsteams, private Repositories, geregelte Freigabe von Änderungen — ist diese Stufe der realistische Ausgangspunkt. Die Projects-Fähigkeiten fühlen sich hier bereits vollständig an; was fehlt, betrifft Governance, nicht Planung.
Die Enterprise-Stufe in der Cloud adressiert nicht den Funktionswunsch der Anwenderin, sondern die Anforderungen von IT, Datenschutz und Revision. Im Vordergrund stehen die Anbindung an die zentrale Identitätsverwaltung mit Single Sign-on und automatischer Benutzerbereitstellung, umfangreiche Protokollierung administrativer und sicherheitsrelevanter Vorgänge, Richtlinien auf Unternehmensebene, Zugriffsbeschränkungen nach Netzbereichen sowie die Möglichkeit, mehrere Organisationen unter einem Dach zu verwalten. In größeren Häusern ist diese Stufe häufig keine Option, sondern Voraussetzung für die Freigabe durch die eigene IT.
Für Projects hat das eine Nebenwirkung: Erst auf dieser Ebene lassen sich organisationsweite Konventionen durchsetzen — verbindliche Feldstrukturen, einheitliche Vorgangstypen und Auswertungen über viele Repositories hinweg.
Neben der Cloud existiert GitHub Enterprise Server — eine Ausführung, die im eigenen Rechenzentrum oder in einer selbst verantworteten Cloud-Umgebung betrieben wird. Für Organisationen mit hohen Souveränitätsanforderungen ist das die datenschutzrechtlich einfachste Variante, weil Quellcode, Vorgänge und Metadaten das eigene Verantwortungsgebiet nicht verlassen. Der Preis dafür ist Betriebsverantwortung: Bereitstellung, Aktualisierung, Sicherung, Wiederherstellung, Skalierung und Überwachung liegen im Haus oder beim Partner.
Wichtig ist eine nüchterne Erwartung an den Funktionsgleichstand: Die selbst betriebene Ausführung folgt der Cloud in Versionssprüngen, weshalb neuere Fähigkeiten zeitversetzt oder mit abweichendem Zuschnitt ankommen können. Wer eine bestimmte Fähigkeit als tragende Säule einplant, sollte deren Verfügbarkeit für die geplante Version schriftlich bestätigen lassen.
Das Issue ist bewusst schlank gehalten: Titel, Markdown-Beschreibung mit Aufgabenlisten, Verantwortliche, Labels, Verweise, Anhänge und eine Kommentarspur. Vieles, was andere Werkzeuge in Pflichtfelder gießen, entsteht hier durch Konvention — und genau das ist Stärke und Risiko zugleich. Mit Sub-Issues lassen sich Vorgänge hierarchisch zerlegen, sodass ein größeres Vorhaben seine Bestandteile trägt und deren Fortschritt sichtbar wird. Ergänzend erlauben Vorgangstypen auf Organisationsebene, Vorgänge fachlich zu unterscheiden, statt alles über Labels zu behelfen.
Labels sind das flexibelste und am häufigsten missbrauchte Ordnungsmittel. Sie eignen sich für Merkmale, die quer zu allem liegen — Fehler, Sicherheitsrelevanz, Kundenbezug, technisches Gebiet. Sie eignen sich nicht als Statusersatz und nicht als Prioritätsskala, weil sie sich nicht auswerten lassen wie ein Feld mit definierten Werten. Milestones wiederum bündeln Vorgänge eines Repositories auf einen Zieltermin, etwa ein Release oder einen Auslieferungsstand, und zeigen einen einfachen Fortschrittsbalken. Sie sind bewusst simpel und ersetzen keine Terminplanung mit Abhängigkeiten.
Das eigentliche Datenmodell entsteht im Projekt über eigene Felder. Verfügbar sind unter anderem Text, Zahl, Datum, Auswahl mit definierten Werten und Iteration — ein Feld, das Zeitabschnitte wie Sprints oder Wochenzyklen abbildet und dabei automatisch fortschreibt. Zahlenfelder eignen sich für Aufwandsgrößen oder Wertbeiträge, Auswahlfelder für Status, Priorität und Kategorie. Der praktische Rat lautet, wenige Felder mit klar definierten Werten anzulegen und für jedes zu benennen, wer es pflegt. Ein Feld ohne Verantwortliche bleibt leer, und ein leeres Feld verdirbt jede Auswertung.
Auf diesem Modell arbeiten die drei zentralen Ansichten. Die Tabelle ist die Arbeitsfläche für Sortieren, Filtern und Massenpflege und die schnellste Möglichkeit, viele Vorgänge zu ordnen. Das Board stellt einen ausgewählten Feldwert als Spalten dar — üblicherweise den Status — und dient der täglichen Steuerung. Die Roadmap legt Vorgänge auf eine Zeitachse, gruppiert nach Team, Iteration oder Ziel, und beantwortet Fragen zur zeitlichen Verteilung. Wichtig für eine realistische Erwartung: Die Roadmap ist eine Zeitdarstellung, kein rechnender Terminplan — Vorgänger-Nachfolger-Beziehungen mit automatischer Verschiebung gehören nicht zu ihrem Modell.
Für die Auswertung bietet Projects Insights: konfigurierbare Diagramme über die Vorgänge eines Projekts, etwa Verteilung nach Status, Entwicklung offener Vorgänge über die Zeit oder Summen über Zahlenfelder. Damit lassen sich die typischen Fragen eines Entwicklungsteams beantworten — wie viel liegt in Arbeit, wie entwickelt sich der Rückstand, wie verteilt sich die Last auf Kategorien. Für die operative Steuerung reicht das in vielen Fällen aus, und der Aufwand dafür ist gering.
Die Grenzen sind klar zu benennen. Auswertungen sind projektbezogen; portfolioweite Betrachtungen erfordern Zusatzarbeit über die Schnittstelle oder ein nachgelagertes Auswertungswerkzeug. Kennzahlen zu Aufwand und Auslastung existieren nur, soweit sie in Feldern gepflegt werden, denn eine Zeiterfassung ist nicht enthalten. Zudem gelten Mengenbegrenzungen je Projekt, die beim Anbieter zu prüfen sind. Wer belastbare Wirtschaftlichkeitsrechnungen erwartet, braucht eine zusätzliche Datenschicht.
Auf der ersten Ebene stehen eingebaute Workflows im Projekt selbst. Sie folgen einem Muster aus Auslöser und Aktion und werden ohne Programmierung aktiviert: Ein neues Issue erhält den Status Backlog, ein geschlossener Vorgang wandert nach Fertig, ein Pull Request in Prüfung setzt den Vorgang in die Review-Spalte. Diese Regeln sind unspektakulär und genau deshalb wirksam, weil sie die häufigste Ursache veralteter Boards beseitigen — das manuelle Nachziehen von Status.
Die zweite Ebene sind GitHub Actions, die ursprüngliche Automatisierungsschicht der Plattform. Sie reagieren auf Ereignisse im Repository und in Projects und können praktisch beliebige Abläufe ausführen. In der Projektsteuerung haben sich unter anderem diese Muster bewährt:
Die KI-Funktionen der Plattform sind unter dem Namen Copilot zusammengefasst und betreffen Projects nicht direkt, sondern über das Umfeld. Drei Felder sind für die Steuerung relevant. Das erste ist die Assistenz beim Formulieren und Erschließen von Vorgängen: Zusammenfassen langer Diskussionen, Ableiten von Teilaufgaben aus einer Beschreibung, Vorschläge für die Strukturierung eines größeren Vorhabens. Der Zeitgewinn ist echt, die fachliche Prüfung bleibt notwendig, denn Vorschläge sind plausibel, nicht zwingend richtig.
Das zweite Feld ist die Unterstützung bei der Umsetzung, die den Engpass von der Erstellung zur Bewertung verlagert. Das dritte ist die agentische Bearbeitung, bei der ein Assistent einen Vorgang aufgreift und einen Änderungsvorschlag vorlegt — der am stärksten zu begleitende Bereich.
Datenschutzrechtlich ist dieser Block der sensibelste des Kapitels, weil Inhalte — Beschreibungen, Kommentare, Quellcode — zur Verarbeitung an einen Dienst gegeben werden. Vor der Freigabe gehört geklärt, welche Verarbeitung genau stattfindet, ob Inhalte zum Training verwendet werden, wo verarbeitet wird, wie protokolliert wird und ob sich die Funktion für bestimmte Bereiche oder Repositories abschalten lässt.
Automatisierung hat in GitHub eine spezifische Schattenseite: Sie ist Code und damit unbegrenzt formbar, aber auch unbegrenzt vermehrbar. Regeln gehören deshalb verständlich benannt, zentral dokumentiert und halbjährlich geprüft; was niemand erklären kann, gehört abgeschaltet.
Zweitens gilt eine sinnvolle Reihenfolge der Mittel: zuerst prüfen, ob eine klarere Feldstruktur oder ein Issue-Formular das Problem löst; dann die eingebauten Workflows nutzen; erst danach eigene Actions bauen; und ganz zuletzt eine externe Integrationsplattform einbinden. Jede zusätzliche Station erhöht Kosten, Abhängigkeit und Prüfaufwand. Drittens berühren Automatisierungen, die Bearbeitungszeiten protokollieren oder Vorgänge Personen zuordnen, potenziell Leistungs- und Verhaltensdaten — und in GitHub gilt das in besonderem Maß, weil ohnehin jede Änderung mit Zeitstempel und Urheber festgehalten wird. Dieser Punkt gehört ausdrücklich in die Abstimmung mit der Arbeitnehmervertretung.
Die wichtigste Integration ist die, über die niemand spricht, weil sie eingebaut ist. Ein Pull Request lässt sich mit einem Issue verknüpfen und schließt es beim Zusammenführen; damit ist der Statuswechsel im Board nicht Pflege, sondern Nebenwirkung der eigentlichen Arbeit. Releases und Tags stellen den Bezug zwischen Vorgängen und ausgelieferten Ständen her, was für Nachvollziehbarkeit und Übergaben wertvoll ist. Actions verbinden Planung, Prüfung und Auslieferung in einer Kette.
Weil GitHub zum Microsoft-Konzern gehört, sind die Verbindungen in dessen Umgebung gut ausgebaut. Für Microsoft Teams und ebenso für Slack existieren Anwendungen, mit denen Vorgänge in Kanälen erscheinen, sich kommentieren und schließen lassen und Benachrichtigungen gezielt zugeschnitten werden. Ergänzend bestehen Brücken zu Azure DevOps sowie zu Entwicklungsumgebungen, in denen Vorgänge direkt im Editor sichtbar sind. Für Häuser, die vollständig in Microsoft 365 arbeiten, verkleinert das den Abstand zwischen Reden und Arbeiten erheblich.
Zu Chat-Integrationen gehört dieselbe Warnung wie überall: Wer sämtliche Systemereignisse in einen Kanal spiegelt, erzeugt Rauschen und trainiert das Team darauf, Benachrichtigungen zu ignorieren. Wirksam ist die selektive Variante — nur wenige, handlungsrelevante Ereignisse melden, etwa blockierte Vorgänge, fehlgeschlagene Auslieferungen und ausstehende Prüfungen. Jenseits davon zählen Verbindungen zu Ticketsystemen im Kundendienst, damit aus einer Kundenmeldung ein technischer Vorgang wird, und zu Überwachungswerkzeugen, damit ein Störungsalarm nicht in einer Mail endet, sondern als Vorgang im Board landet.
Für alles Weitere steht eine Programmierschnittstelle bereit, wobei Projects vor allem über die GraphQL-Schnittstelle ansprechbar ist — Vorgänge und Felder lesen und schreiben, Projekte anlegen, Elemente verschieben. Dazu kommt das offizielle Kommandozeilenwerkzeug, mit dem sich Projekte auch aus Skripten heraus bedienen lassen, sowie Webhooks, die Änderungen an andere Systeme melden. Diese Kombination macht Projects für technische Organisationen ungewöhnlich gut automatisierbar; sie setzt aber voraus, dass jemand im Haus damit umgehen kann.
Der Marktplatz ergänzt das um fertige Erweiterungen für Qualitätssicherung, Sicherheitsprüfung, Zeiterfassung und Portfoliosichten. Gerade weil Projects bei Zeit und Portfolio bewusst schmal bleibt, wandern Anforderungen dorthin. Hier lohnt Vorsicht: Jede Erweiterung ist ein zusätzlicher Verarbeiter mit eigenen Rechten auf Vorgänge und teils auf Quellcode — und damit ein eigener Prüfpunkt für Datenschutz und Sicherheit.
Jira ist der etablierte Gegenpol: prozessgeführt, tief konfigurierbar, mit erzwungenen Statusübergängen, Rollen- und Berechtigungsmodellen, Feldschemata, umfangreicher Auswertung und einer eigenen Abfragesprache. Wo Nachweisbarkeit, formale Abläufe und feingranulare Rechte gefordert sind, ist Jira weiterhin stärker. Der Preis ist Verwaltungsaufwand: Jira braucht jemanden, der es pflegt, und neigt in gewachsenen Installationen zu Komplexität, die niemand mehr überblickt. GitHub Projects ist im Vergleich radikal schlanker — weniger Zwang, weniger Nachweis, weniger Pflege, dafür Nähe zum Code.
Linear tritt mit einem anderen Versprechen an: hohe Geschwindigkeit, ausgeprägte Meinung darüber, wie Produktentwicklung ablaufen sollte, sehr gute Bedienung. Es liegt funktional näher an GitHub Projects als an Jira und ist in Zyklusplanung und Auswertung meist ausgereifter, kostet aber zusätzlich und bringt ein weiteres System mit eigener Synchronisation ins Haus. Wer keinen zusätzlichen Anbieter will und mit Konventionen statt Vorgaben arbeitet, kommt mit Projects weit.
Azure DevOps stammt aus derselben Konzernfamilie und bietet mit seinen Arbeitselementen ein deutlich formaleres Planungsmodell — Hierarchien, Prozessvorlagen, Abfragen, Berichte und eine engere Verzahnung mit klassischer Projektsteuerung. Für Organisationen, die aus einer Microsoft-geprägten Entwicklungswelt kommen und Nachweisführung brauchen, ist es die schwerere, aber vollständigere Antwort. GitHub Projects ist leichter und moderner in der Bedienung, verlangt dafür Selbstdisziplin statt Prozesszwang.
GitLab ist der direkteste Vergleich, weil es Codeverwaltung, Automatisierung und Planung ebenfalls vereint und mit Epics, Iterationen und Roadmaps ein etwas ausgebauteres Planungsmodell mitbringt; zudem lässt es sich selbst betreiben, was die Datenschutzdiskussion vereinfacht. Umgekehrt hat GitHub das größere Ökosystem und in vielen Teams die vorhandene Erfahrung. Die Entscheidung fällt hier meist auf Plattformebene, nicht anhand der Projektfunktionen.
Gegenüber allgemeinen Work-Management-Plattformen wie Asana, monday, ClickUp oder dem schlanken Trello ist die Trennlinie klar: Diese Werkzeuge sind für gemischte Belegschaften gebaut, verstehen Ressourcen, Auslastung, Formulare, Freigaben und teilweise Zeiterfassung und lassen sich von jeder Abteilung bedienen. GitHub Projects kann das nicht und will es nicht. Umgekehrt können jene Werkzeuge nicht, was Projects auszeichnet — die verlustfreie Verbindung von Vorgang, Codeänderung und Auslieferung. Der häufigste sinnvolle Zuschnitt lautet deshalb: technische Arbeit in GitHub, abteilungsübergreifende Vorhaben im Work-Management-Werkzeug, mit klar dokumentierter Grenze.
Für Organisationen, denen europäische Anbieterstruktur und einfache Prüfbarkeit wichtiger sind als das größte Ökosystem, gehören zusätzlich DACH-Anbieter in die Betrachtung, die wir in dieser Kategorie separat behandeln. Wichtig ist, die Frage nicht zu vermischen: Für die reine Entwicklungssteuerung ist die Nähe zum Code oft ausschlaggebend, für Vorhaben quer durch das Haus fast nie.
Wir führen die Auswahl entlang von vier Fragen. Erstens: Wo liegt die Arbeit wirklich? Wenn Quellcode, Konfiguration und Auslieferung in GitHub liegen, ist jede andere Planungsheimat eine Synchronisationsaufgabe. Zweitens: Welchen Nachweis verlangt die Organisation? Regulierte Abläufe mit erzwungenen Übergängen und Auditpflichten sprechen für prozessgeführte Systeme. Drittens: Wer soll mitarbeiten? Sobald nicht-technische Rollen aktiv planen müssen, wird die Umgebung zum Hindernis. Viertens: Welche Auswertungen werden verlangt? Ohne Zeit- und Aufwandsdaten bleiben Wirtschaftlichkeitsfragen unbeantwortet.
Die erste Entscheidung betrifft die Ebene der Projekte. Ein Projekt kann an ein Repository gebunden sein oder auf Organisationsebene liegen und Vorgänge aus vielen Repositories bündeln. Für Teams, die an mehreren Repositories arbeiten — was in der Praxis fast immer der Fall ist — ist das Projekt auf Organisationsebene das robustere Muster: Es folgt dem Team und nicht der technischen Ablage. Ein Projekt je Repository führt schnell zu einem Flickenteppich, in dem niemand mehr eine Gesamtsicht hat.
Die zweite Entscheidung betrifft die Felder und Statuswerte. Hier gilt der Grundsatz der Sparsamkeit: nur Felder anlegen, die für eine Entscheidung oder eine Auswertung tatsächlich gebraucht werden, mit klar definierten Auswahlwerten statt Freitext, und je Feld festlegen, wer es pflegt. Für den Status haben sich fünf bis sieben Werte bewährt; mehr macht das Board unlesbar. Bewährt hat sich die knappe Regel „Status beschreibt den Ablauf, Labels beschreiben den Inhalt“ — wer sie einhält, behält auswertbare Daten.
Die Betriebsfrage ist bei GitHub keine Nebensache, weil sie den datenschutzrechtlichen Rahmen bestimmt. Die Cloud bietet den vollen und aktuellsten Funktionsstand, keinen Betriebsaufwand und die schnellste Einführung; die Prüfung dreht sich um Auftragsverarbeitung, Datentransfer, Datenresidenz und Zugriffe des Anbieters. Der selbst betriebene Server verlagert diese Diskussion in das eigene Haus, verlangt dafür Kapazität für Bereitstellung, Aktualisierung, Sicherung, Wiederherstellung und Überwachung — und akzeptiert einen zeitversetzten Funktionsstand.
Wer den Eigenbetrieb wählt, um eine Datenschutzdiskussion zu vermeiden, ohne die Betriebskapazität dafür zu haben, tauscht ein Papierproblem gegen ein Verfügbarkeitsproblem.
GitHub unterscheidet Rechte auf mehreren Ebenen — Unternehmen, Organisation, Team, Repository und Projekt. Für Projects ist besonders relevant, dass die Sichtbarkeit eines Projekts und die der enthaltenen Vorgänge nicht dasselbe sind: Wer ein Issue nicht sehen darf, sieht es auch im Board nicht vollständig. Wer eine belastbare Gesamtsicht braucht, muss die Leseberechtigungen entsprechend planen.
Eine tragfähige Governance besteht aus wenigen Punkten: eine verantwortliche Person je Projekt, eine zentrale Zuständigkeit für Felder, Vorgangstypen und Vorlagen, eine Freigaberegel für neue Actions und Marktplatz-Anwendungen sowie eine wiederkehrende Rechteprüfung. Besonders wichtig ist die Kontrolle über Erweiterungen, weil installierte Anwendungen weitreichende Rechte auf Vorgänge und Quellcode erhalten können. Und auch Projects braucht eine Aufräumroutine: abgeschlossene Projekte schließen, verwaiste Drafts auflösen, Zugänge ausgeschiedener Personen entziehen.
Das häufigste Szenario ist das interne Entwicklungsteam ohne eigenes Projektwerkzeug. Ausgangslage ist meist eine Mischung aus Tabellen, Chatnachrichten und Erinnerungsvermögen: Der Code liegt in GitHub, die Planung nirgends. Der Nutzen entsteht sofort — Issues statt Zuruf, ein Board mit fünf Statuswerten, eine Iteration je Zyklus, automatischer Statuswechsel beim Zusammenführen. Nach wenigen Wochen ist sichtbar, was in Arbeit ist, was wartet und was hängt.
Das zweite Szenario ist die IT- und Digitalisierungsabteilung, die Infrastruktur als Code betreibt. Automatisierungen, Schnittstellen, Skripte und Konfigurationen liegen ohnehin im Repository; Störungen, Änderungswünsche und Vorhaben lassen sich als Issues aufnehmen und über Formulare strukturieren. Der Gewinn ist doppelt: Die Abteilung bekommt einen geregelten Eingangskanal statt Zuruf, und jede Änderung ist mit ihrem Anlass verknüpft — was bei Störungsanalysen und Nachfragen aus der Revision erheblich Zeit spart.
Das dritte Szenario ist die Zusammenarbeit mit externen Dienstleistern. Wer Entwicklungsleistung einkauft, kann Vorgänge, Prüfungen und Abnahmen in einem gemeinsamen Repository organisieren, statt Statuslisten per Mail zu tauschen. Der wertvolle Nebeneffekt: Arbeitsergebnisse und ihre Geschichte liegen in der eigenen Organisation, nicht im Werkzeug des Dienstleisters — bei Wechseln und Übergaben regelmäßig der entscheidende Punkt.
Der stärkste Effekt ist der Wegfall der Doppelpflege. Wo vorher ein Projektwerkzeug neben der Entwicklungsplattform stand, verschwindet eine ganze Klasse von Reibungen: kein Abgleich, keine widersprüchlichen Statuswerte, kein Streit darüber, welches System recht hat. Teams beschreiben diesen Effekt oft deutlicher als jeden Funktionsgewinn — und er wirkt sofort, nicht erst nach einem Reifeprozess.
Der zweite Effekt ist die niedrige Einstiegshürde: Wer täglich in GitHub arbeitet, muss nichts Neues lernen. Der dritte betrifft Nachvollziehbarkeit — weil jede Änderung mit Urheber, Zeitpunkt und Anlass verknüpft ist, lassen sich Fragen aus Revision oder Qualitätsmanagement ohne Archäologie beantworten.
Es gibt Situationen, in denen wir ausdrücklich abraten. Die erste ist die gemischte Belegschaft als Hauptnutzergruppe: Sobald Vertrieb, Marketing, Verwaltung oder Geschäftsführung aktiv planen sollen, ist die Umgebung eine Hürde, die durch Schulung nicht verschwindet. Die zweite ist der Bedarf an Ressourcen-, Zeit- und Abrechnungsdaten. Wer Auslastung steuern, abrechenbare Stunden erfassen oder Margen je Auftrag betrachten muss, findet in Projects keine eingebaute Antwort und baut sich sonst eine Sonderlösung, die niemand wartet.
Die dritte Situation ist der hohe Nachweis- und Prozesszwang: Wo Statusübergänge erzwungen und Abläufe auditfest dokumentiert werden müssen, sind prozessgeführte Systeme die passendere Wahl. Der vierte Fall ist die Fehlbesetzung des Anwendungsfalls — Projects ist kein Ticketsystem für hohe Fallzahlen, kein Dokumentenmanagement mit Aufbewahrungspflichten, kein CRM. Jede Biegung in diese Richtungen erzeugt Sonderlogik, die niemand mehr wartet, wenn die Person geht, die sie gebaut hat.
Eine belastbare Kalkulation umfasst deutlich mehr als den Preis je Nutzer und Monat. Der erste zusätzliche Posten ist der verbrauchsabhängige Anteil: Automatisierungsläufe, Rechenzeit für gehostete Ausführungsumgebungen, Speicher für Artefakte und Pakete und je nach Nutzung weitere Dienste werden nach Verbrauch abgerechnet, wobei je Edition ein Grundvolumen enthalten ist. Wer stark automatisiert, sollte den Verbrauch von Beginn an beobachten, weil er mit der Zahl der Vorgänge und Änderungen wächst und nicht mit der Zahl der Nutzer.
Der zweite Posten sind Zusatzprodukte — KI-Assistenz, erweiterte Sicherheitsprüfungen, Marktplatz-Anwendungen —, die getrennt beschafft werden. Der dritte ist der Einführungs- und Betreuungsaufwand für Konventionen, Vorlagen, Automatisierungen, Schulung und Pflege; er ist geringer als bei prozessgeführten Systemen, aber nicht null. Der vierte fällt beim Eigenbetrieb an: Betriebskosten für Infrastruktur, Aktualisierung, Sicherung und Überwachung. Und schließlich der einmalige Aufwand für Datenschutzprüfung, Verarbeitungsverzeichnis und Mitbestimmungsabstimmung — regelmäßig vergessen, aber real.
Der zentrale Prüfpunkt ist die Frage, wo Daten gespeichert und verarbeitet werden. Für die Cloud existieren Angebote mit Datenresidenz, mit denen sich der Speicherort von Kundendaten auf eine Region wie die Europäische Union festlegen lässt. Ob eine solche Option für die gewünschte Edition, für Neu- und Bestandsverträge, für alle betroffenen Datenarten und für die geplanten Zusatzprodukte gilt, ist produkt- und stichtagsabhängig und muss beim Anbieter konkret geprüft und schriftlich bestätigt werden. Pauschale Aussagen dazu sind unseriös, weil sich Betriebsmodelle ändern.
Ebenso wichtig ist die Unterscheidung zwischen Inhaltsdaten — Vorgänge, Kommentare, Quellcode, Anhänge — und der Verarbeitung von Metadaten, Protokolldaten und Supportzugriffen, die abweichend geregelt sein kann. Auch bei regionaler Speicherung findet in der Regel Verarbeitung durch Konzerngesellschaften, Unterauftragsverarbeiter und den Support statt, teils aus Drittländern. Weil der Anbieter dem Recht eines Drittlandes unterliegt, ist der Datentransfer gesondert zu betrachten und stützt sich üblicherweise auf die einschlägigen Angemessenheits- beziehungsweise Transfermechanismen sowie ergänzende Garantien im Vertragswerk. Grundlage jeder Nutzung ist ein Auftragsverarbeitungsvertrag mit dokumentierten technischen und organisatorischen Maßnahmen und einer beobachteten Liste der Unterauftragsverarbeiter.
Die datenschutzfreundlichere Variante ist der Eigenbetrieb mit GitHub Enterprise Server: Liegen Vorgänge, Quellcode und Metadaten im selbst verantworteten Rechenzentrum, entfällt ein erheblicher Teil der Transfer- und Zugriffsdiskussion; übrig bleiben Lizenz- und Supportverhältnis sowie optional angebundene Cloud-Dienste. Zu prüfen ist, welche Funktionen im Eigenbetrieb verfügbar sind, welche eine Verbindung nach außen benötigen und welche Pflichten — Aktualisierung, Sicherung, Härtung — auf die eigene Seite wandern.
Weil in GitHub jede Änderung mit Urheber und Zeitstempel festgehalten wird und Vorgänge Personen zugeordnet sind, ist die Plattform geeignet, Verhalten und Leistung zu überwachen — unabhängig davon, ob das beabsichtigt ist. Auswertungen über Durchlaufzeiten, Anzahl bearbeiteter Vorgänge oder Beiträge je Person sind technisch ohne Weiteres möglich. In Deutschland löst diese Eignung in Betrieben mit Betriebsrat die Mitbestimmung nach § 87 BetrVG aus. Bei KI-Funktionen und agentischer Bearbeitung kommt eine zweite Ebene hinzu, weil sich Rollen und Bewertungsmaßstäbe verschieben.
Der pragmatische Weg ist, die Arbeitnehmervertretung früh einzubinden — vor der Konfiguration, nicht nach dem Rollout — und in einer Betriebsvereinbarung festzuhalten, welche Auswertungen entstehen, auf welcher Aggregationsebene, wer sie einsehen darf und wie lange Protokolldaten aufbewahrt werden. Bewährt hat sich die Zusicherung, dass Kennzahlen nur auf Team- und Vorhabenebene genutzt und nicht zur individuellen Leistungsbewertung herangezogen werden. Für Österreich und die Schweiz gelten eigene Regelungen.
Technisch sind drei Stellschrauben entscheidend: die Rechte- und Rollenstruktur über Unternehmen, Organisationen, Teams und Repositories hinweg, insbesondere für externe Beteiligte; die Datensparsamkeit im Inhalt — keine besonderen Kategorien personenbezogener Daten, keine Kundendatensätze in Fehlerberichten, keine Zugangsdaten, weil versionierte Vorgänge nachträglich schwer zu bereinigen sind; und Aufbewahrung, Löschung und Export mit klar geregelter Archivierung und regelmäßigen Datenexporten.
Wer aus strategischen oder regulatorischen Gründen europäische Anbieter oder vollständigen Eigenbetrieb bevorzugt, findet tragfähige Wege: neben dem selbst betriebenen GitHub europäische Betriebs- und Partnermodelle für vergleichbare Entwicklungsplattformen und, für die Steuerung nicht-technischer Vorhaben, Anbieter aus dem DACH-Raum, die wir in dieser Kategorie separat behandeln. Funktionsumfang und Ökosystemgröße sind kleiner, die datenschutzrechtliche Bewertung dafür erheblich einfacher.
Die Abwägung sollte anhand der eigenen Anforderungsliste erfolgen, nicht anhand des Herkunftslands allein: zuerst die Funktionen benennen, ohne die das Vorhaben scheitert, dann prüfen, welche Anbieter und Betriebsmodelle diese abdecken, erst zuletzt Herkunft und Vertragswerk bewerten.
