Rollen und Berechtigungen: die richtige Team-Matrix

Warum eine Rollenmatrix vom ersten Tag an

In einem Team von fünf Personen kann annähernd jeder alles tun. Das ist kein Problem, solange sich niemand fragt, wer ein Projekt gelöscht oder einen Sprint geändert hat. An dem Tag, an dem die Frage aufkommt, ist es zu spät: Es gibt keine klare Spur.

Eine Rollenmatrix beantwortet drei einfache Fragen. Wer kann ein Projekt erstellen? Wer kann jemanden einladen? Wer kann Daten löschen? Wenn Sie diese nicht in zehn Sekunden beantworten können, beruht Ihre Governance auf Erinnerungen, nicht auf Regeln.

Die Kosten dieser Klärung sind gering. Eine Stunde zu Beginn des Projekts, dann eine Überprüfung bei jedem Eintritt oder Austritt. Die Kosten des Fehlens von Regeln hingegen zahlen sich in Nachbereitungssitzungen und vergessenen Zugriffen aus.

Die zwei Fehler, die immer wiederkehren

Zu viele Admins

Aus Bequemlichkeit werden die ersten drei angekommenen Personen zu Admins ernannt. Ergebnis: Niemand weiß mehr, wer tatsächlich für die Einstellungen, die Rechnungen oder die Integrationen verantwortlich ist. Wenn ein Admin-Konto kompromittiert wird, ist die Auswirkung maximal.

Die nützliche Regel: maximal zwei Admins in einem Team von weniger als dreißig Personen. Ein Inhaber, ein Stellvertreter. Die anderen Rollen decken 90 % des täglichen Bedarfs ab.

Gäste ohne Rahmen

Ein Gast wird oft als Mitglied mit Leserechten wahrgenommen. In der Praxis kann er Tabellen, Kommentare, manchmal Anhänge sehen. Wenn Sie seinen Umfang nicht definieren, entdeckt er das Tool vor Ihnen.

Drei Fragen, die vor jeder Einladung zu stellen sind: Worauf soll diese Person einwirken, für wie lange, und wer entfernt sie, wenn der Bedarf wegfällt? Ohne Antwort wartet die Einladung.

Die Matrix aufbauen: von den Aktionen ausgehen, nicht von den Titeln

Eine effektive Matrix listet keine Stellenbezeichnungen auf. Sie listet konkrete Aktionen auf und ordnet dann jeder Aktion eine Rolle zu. Hier ist eine Methode in vier Schritten.

1. Die sensiblen Aktionen auflisten. Ein Projekt erstellen, ein Mitglied einladen, eine Karte löschen, die Rechnungseinstellungen ändern, eine Integration verbinden, Daten exportieren.
2. Nach Häufigkeit und Risiko einordnen. Eine häufige und wenig riskante Aktion kann offen sein. Eine seltene und riskante Aktion muss reserviert bleiben.
3. Eine Rolle pro Aktion zuordnen. Nur eine verantwortliche Person pro Zeile. Wenn zwei Rollen dasselbe tun können, ist die Regel unklar.
4. Die Matrix an einem realen Fall testen. Ein Neuer kommt am Montag. Was kann er am Dienstag tun? Wenn die Antwort eine Besprechung erfordert, ist die Matrix unvollständig.

Dieser Ansatz vermeidet die klassische Falle: die Matrix eines anderen, größeren Unternehmens zu kopieren, dessen Zwänge nicht Ihre sind.

Die von Ever Earlier vorgeschlagenen Rollen

Ever Earlier strukturiert die Zugriffe um fünf Rollen, von der weitesten zur restriktivsten.

• Eigentümer: verantwortlich für die Organisation, die Rechnungsstellung und die globalen Einstellungen.
• Admin: verwaltet die Mitglieder, die Workspaces und die laufende Konfiguration.
• Manager: steuert die Projekte, die Sprints und das Backlog seines Bereichs.
• Mitglied: arbeitet an den Karten, den User Stories und den Kommentaren.
• Gast: begrenzter Zugriff, gedacht für einen punktuellen Mitwirkenden oder einen Kunden.

Diese Rollen kombinieren sich mit den Organisationen und den Workspaces. Eine Person kann Manager in einem Projekt und Mitglied in einem anderen sein. Diese Aufteilung ermöglicht es, globale Beförderungen aus Bequemlichkeit zu vermeiden.

Konkretes Beispiel: Ein Team von acht Personen bereitet eine Funktionalität für einen externen Kunden vor. Der Kunde wird in einen einzigen Workspace eingeladen, mit der Rolle Gast. Er konsultiert das Kanban-Board, kommentiert die Karten, berührt aber weder die Sprints noch die Einstellungen. Das Team behält die Kontrolle über die Planung.

Einladungen per Link: praktisch, aber einzugrenzen

Ever Earlier ermöglicht es, Personen per Link einzuladen. Das ist schnell, und genau das erfordert eine Regel.

Ein Link, der in einem falschen Kanal zirkuliert, gibt Personen Zugriff, die Sie nicht identifiziert haben. Drei Vorsichtsmaßnahmen genügen in den meisten Fällen.

• Die Links den restriktivsten Rollen vorbehalten, wie Gast oder Mitglied.
• Niemals einen Admin-Einladungslink in einem öffentlichen Raum oder einem breiten Diskussionsthread teilen.
• Die Mitgliederliste nach jeder Einladungskampagne überprüfen und dann ungenutzte Zugriffe entfernen.

Auf technischer Ebene ist die feine Verwaltung der Berechtigungen ein Thema für sich. Projekte wie Cerbos zeigen die Komplexität eines kontextuellen Autorisierungssystems, bei dem die Regeln vom Prinzipal, der Aktion und der Ressource abhängen. Ein kleines Team braucht diese Tiefe nicht, aber es gewinnt, sich davon inspirieren zu lassen: die Regeln definieren, bevor man sie erleidet.

Die Matrix bei jeder Teamveränderung überprüfen

Eine Rollenmatrix ist kein starres Dokument. Sie veraltet beim ersten Austritt, beim ersten Eintritt, bei der ersten Umfangsänderung.

Zwei Termine genügen. Bei jedem Eintritt: die minimal notwendige Rolle zuweisen, nicht die, die Freude macht. Bei jedem Austritt: den Zugriff am selben Tag entfernen, nicht am Ende der Kündigungsfrist.

Ein vierteljährlicher fünfzehnminütiger Punkt ermöglicht es, unnötig gewordene Rollen zu erkennen. Ein Manager, der kein Projekt mehr zu steuern hat, ein Gast, dessen Mission beendet ist, ein stellvertretender Admin, der nie gedient hat. Diese ruhenden Zugriffe sind die am leichtesten zu vergessenden und die am schwersten bei einem Audit zu rechtfertigenden.

Governance muss nicht schwer sein. Sie muss geschrieben, bekannt und überprüft sein. Drei Eigenschaften, die auf eine Seite passen.