Projektübergreifende Sichtbarkeit ist ein Mythos
Warum Dashboards projektübergreifende Sichtbarkeit nicht liefern – und was wirklich hilft, wenn dein Team auf Linear, GitHub, Slack und Notion setzt.
By Ellis Keane · 2026-03-17
Jedes Projektmanagement-Tool auf dem Markt verspricht dir projektübergreifende Sichtbarkeit. Das tun sie seit fast zwei Jahrzehnten – ungefähr so lange, wie das Wort „Dashboard" als Ersatz für „wirklich wissen, was gerade los ist" gilt.
Und schau: Die Dashboards werden wirklich gut. Elegant. Echtzeit. Farbkodiert. Du kannst nach Sprint, nach Zuständigen, nach Label filtern – oder nach Mondphase, wenn dein Jira-Admin mal kreativ war. Das einzige Problem – und es ist ein kleines, kaum erwähnenswertes – ist, dass niemand in deinem Team seine Arbeit in einem einzigen Tool erledigt.
Das Sichtbarkeitsproblem, über das niemand spricht
Was projektübergreifende Sichtbarkeit eigentlich bedeuten soll: Du öffnest etwas, und siehst den Zustand deines Projekts. Nicht den Zustand deines Linear-Boards oder deines GitHub-Repos oder den Überblick deines Slack-Channels – sondern den Zustand der eigentlichen Arbeit.
In der Praxis passiert stattdessen Folgendes. Dein Designer hinterlässt einen Kommentar in Figma und markiert einen Sonderfall. Ein Engineer nimmt ihn auf (vielleicht – wenn er Figma an diesem Tag zufällig geöffnet hat) und erstellt ein GitHub-Issue. Das Issue wird in einem Slack-Thread besprochen. Jemand referenziert das ursprüngliche Linear-Ticket im Thread, verknüpft es aber nicht mit dem GitHub-Issue. Drei Tage später öffnet dein Engineering Manager Linear und sieht das Ticket als „In Progress" markiert. Er hat keine Ahnung von dem Figma-Kommentar, dem GitHub-Issue oder der Slack-Diskussion. Soweit es Linear betrifft, läuft alles wunderbar.
Das ist kein Sichtbarkeitsproblem. Das ist ein Problem der Informationstopologie. Die Daten existieren – sie sind nur über vier Tools verstreut, ohne verbindendes Element zwischen ihnen.
Warum Dashboards bei projektübergreifender Sichtbarkeit versagen
Die Standardantwort auf projektübergreifende Sichtbarkeit lautet: „Bau ein Dashboard." Daten aus deinen verschiedenen APIs abrufen, an einem Ort anzeigen, fertig.
Ich habe diese Dashboards gebaut. (Mehr als einmal – was dir wahrscheinlich etwas über die Qualität des ersten verrät.) Das Problem liegt nicht in der Technik. Die APIs existieren. Die Daten sind zugänglich. Das Problem ist, dass Daten zu aggregieren nicht dasselbe ist wie Kontext zu verstehen.
Ein Dashboard kann dir sagen, dass es 14 offene Issues in Linear und 7 offene PRs in GitHub gibt. Was es dir nicht sagen kann: dass 3 dieser PRs mit 2 dieser Issues zusammenhängen, dass beide Issues letzten Mittwoch im selben Slack-Thread besprochen wurden – und dass der Designer bereits in Figma ein Bedenken geäußert hat, das weder die Issues noch die PRs adressieren.
Dashboards aggregieren. Sie verbinden nicht. Projektübergreifende Sichtbarkeit erfordert ein Verständnis der Beziehungen zwischen Elementen – nicht nur deren nebeneinander Anzeige.
Ein Dashboard gibt dir ein Mosaik. Was du brauchst, ist eine Karte.
Und das Entscheidende: Dieses Dashboard schneller zu machen hilft nicht. Du kannst in Echtzeit zusehen, wie ein Linear-Ticket auf „Done" wechselt, während der entsprechende GitHub-PR mit drei ungelösten Kommentaren im Review liegt. Das Dashboard zeigt beide Fakten. Was es nicht zeigt: dass diese Fakten einander widersprechen – weil es keine Ahnung hat, dass das Ticket und der PR überhaupt zusammenhängen.
„Du kannst in Echtzeit zusehen, wie ein Linear-Ticket auf ‚Done' wechselt, während der entsprechende GitHub-PR mit drei ungelösten Kommentaren im Review liegt. Das Dashboard zeigt beide Fakten – hat aber keine Ahnung, dass sie einander widersprechen." – Chris Calo
Die Verbindungen zählen mehr als die Knoten. Ein System, das die Beziehungen zwischen deinen Tools versteht, bietet bessere projektübergreifende Sichtbarkeit als jedes Echtzeit-Dashboard, das jedes Tool als separates Universum behandelt.
Was wirklich funktioniert
Wenn Dashboards also nicht die Antwort auf projektübergreifende Sichtbarkeit sind – was dann?
Ich wünschte, ich könnte dir sagen, es gibt einen einfachen Trick – eine Namenskonvention oder Label-Taxonomie, die alles löst. Gibt es nicht. Ich habe den Namenskonventions-Ansatz etwa sechs Monate bei einem früheren Job ausprobiert. Was ich sagen kann: „PROJ-123" funktioniert wunderbar, bis jemand vergisst, es in seine Commit-Message aufzunehmen – was oft genug passiert, dass das ganze System innerhalb einer oder zwei Wochen still auseinanderfällt.
Was wirklich funktioniert, ist ein System, das Verbindungen über Tools hinweg von selbst auflöst. Kein System, das du mit Informationen füttern musst (das wirst du nicht konsequent tun – niemand tut es), sondern eines, das aus deinen bestehenden Tools liest und die Beziehungen selbst ableitet. Die Mechanik ist keine Magie: Webhook-Events und API-Polling-Daten erfassen, Bezeichner über Tools hinweg normalisieren (eine Linear-Issue-ID in einem Slack-Thread, ein GitHub-Branch-Name, der einem Ticket-Schlüssel entspricht, eine Figma-Datei-URL in einem Notion-Dokument) und dann einen Wissensgraph aufbauen, der zeigt, was womit verbunden ist. Das Schwierige ist nicht ein einzelner Link – es ist, alle kontinuierlich zu pflegen, ohne Menschen mit der Buchführung zu belasten.
Denke daran, wie ein guter Engineering Manager Kontext aufbaut. Er sitzt nicht mit Linear und GitHub nebeneinander und gleicht manuell Issue-Nummern ab. Er liest den Slack-Channel, bemerkt, wer worüber spricht, erinnert sich daran, dass die Figma-Diskussion von letzter Woche mit dem gerade eingegangenen PR zusammenhängt, und entwickelt ein mentales Modell. Die Sichtbarkeit entsteht durch das Verstehen der Verbindungen – nicht durch das Starren auf noch mehr Bildschirme.
Die Herausforderung ist, dass dieses mentale Modell nicht skaliert. Es lebt im Kopf einer Person. Wenn diese Person im Urlaub ist, verschwindet die Sichtbarkeit mit ihr.
Falls du noch nicht bereit bist, ein Tool dafür einzusetzen (und ehrlich gesagt sind die meisten Teams das noch nicht – noch nicht), gibt es Dinge, die du heute tun kannst, die helfen. Bestimme pro Projekt eine Person als „Kontexthalter", die explizit in einer wöchentlichen Zusammenfassung auf andere Tools verweist. Vereinbare eine Verlinkungsdisziplin: Jede PR-Beschreibung enthält die Linear-Ticket-URL, jede Slack-Entscheidung wird in das relevante Notion-Dokument zurückkopiert. Richte Slack-Erinnerungen ein, um Figma-Kommentare zu aktiven Projekten zu überprüfen. Nichts davon ist ideal – alles ist manuell, alles hängt davon ab, dass Menschen sich daran erinnern – aber es ist besser als so zu tun, als würde dein Dashboard das vollständige Bild zeigen.
Der Wissensgraph-Ansatz
Das ist die Idee hinter der Behandlung deiner Work-Tools als Knoten in einem Wissensgraph statt als Datenquellen für ein Dashboard. Bleib kurz dabei – es klingt weniger akademisch als es sich anhört.
Ein Slack-Thread, in dem drei Engineers einen Ansatz diskutierten. Ein Figma-Kommentar, in dem der Designer eine Einschränkung markierte. Ein Linear-Ticket zur Verfolgung des Features. Ein GitHub-PR, der es umsetzt. Ein Notion-Dokument mit der ursprünglichen Spezifikation. Das sind keine fünf getrennten Dinge – das sind fünf Perspektiven auf dasselbe Stück Arbeit.
Wenn du sie als Wissensgraph modellierst, hört die Frage auf, „Kann ich alle meine Tools an einem Ort sehen?" zu sein, und wird zu: „Kann ich den gesamten Kontext rund um dieses Stück Arbeit sehen?" Das ist eine grundlegend andere Frage – und es ist die, die wirklich zählt, wenn du herausfinden willst, ob ein Projekt auf Kurs ist.
Der Wissensgraph kümmert sich nicht darum, in welchem Tool die Information steckt. Er kümmert sich darum, was sie bedeutet und wie sie mit allem anderen zusammenhängt. Ein Kommentar in Figma, der denselben Sonderfall referenziert wie ein Kommentar auf einem GitHub-PR – das ist dasselbe Gespräch, das an zwei Orten stattfindet. Jedes System, das behauptet, Sichtbarkeit über Tools hinweg zu bieten, sollte das wissen.
Wie das in der Praxis aussieht
Lass mich ein konkretes Beispiel durchgehen – denn das abstrakte Zeug ist ja schön und gut, aber du fragst dich wahrscheinlich, was das konkret an einem Dienstagnachmittag bedeutet.
Angenommen, dein Team entwickelt einen neuen Onboarding-Flow. Der Designer iteriert seit einer Woche in Figma. Ein Engineer hat ein Linear-Ticket eröffnet, es in drei Teilaufgaben aufgeteilt und mit der ersten begonnen – ein PR ist auf GitHub offen. Inzwischen hat dein PM vor zwei Wochen eine Spezifikation in Notion geschrieben, die drei Anforderungen beschreibt, von denen eine in einem Slack-Gespräch deprioritisiert wurde – das weder der Engineer noch der Designer gesehen haben.
Öffne dein Dashboard. Du siehst: Figma hat Aktivität. Linear hat drei Teilaufgaben, eine in Bearbeitung. GitHub hat einen offenen PR. Notion hat eine Spezifikation. Slack hat… nun ja, Slack hat alles, also hilft das wenig. Alles sieht grün aus. Liefern, oder?
Nur dass der Engineer gegen eine Anforderung entwickelt, die vor zwei Tagen still und leise in einem Slack-Thread deprioritisiert wurde. Niemand hat ihn informiert. Auch den Designer nicht. Die Spezifikation in Notion listet sie noch. Das Dashboard kann den Widerspruch nicht markieren, weil es nicht weiß, dass diese Artefakte zusammenhängen – es kennt nur den Status jedes Tools für sich.
Stell dir jetzt dieselbe Situation vor, aber das System, das deine Arbeit verfolgt, versteht, dass die Notion-Spezifikation, die Linear-Teilaufgaben, der GitHub-PR, die Figma-Iterationen und dieser Slack-Thread alle Teil desselben Onboarding-Flows sind. Es verfolgt die Referenzen und Erwähnungen zwischen ihnen. Es kann den Konflikt aufzeigen: „Hey, die zugrundeliegende Anforderung dieser Teilaufgabe wurde deprioritisiert – du solltest das vielleicht prüfen, bevor du mergst." Das sind keine Dashboard-Daten. Das ist tatsächliche Sichtbarkeit darauf, ob dein Projekt auf Kurs ist.
Wann du das alles nicht brauchst
Hier kommt der ehrliche Teil (und ich verspreche, das ist aufrichtig gemeint – keine Vorbereitung für eine Verkaufspitch). Wenn dein Team aus fünf Personen besteht und ihr zwei Tools nutzt, braucht ihr keine Software für projektübergreifende Sichtbarkeit. Ihr braucht einen Slack-Channel und ein wöchentliches Sync. Das mentale Modell skaliert in dieser Größe gut. Jeder weiß, woran der andere arbeitet, weil ihr alle im selben Raum sitzt – buchstäblich oder metaphorisch.
Das Problem beginnt, wenn Teams über den Punkt hinauswachsen, an dem eine Person das gesamte Bild überblicken kann. In meiner Erfahrung passiert das irgendwo beim dritten oder vierten Tool, wenn sich Workstreams zu überschneiden beginnen und dein Monday-Morning-Standup zur Hälfte aus „Warte mal, davon wusste ich nichts" besteht.
Wenn du über diese Schwelle hinaus bist – wenn du bemerkt hast, dass das Bewusstsein deines Teams über die Arbeit der anderen umgekehrt proportional zur Anzahl der eingesetzten Tools ist – dann brauchst du etwas, das die Punkte wirklich verbindet.
---
Sugarbug baut einen Wissensgraph über deine Work-Tools – Linear, GitHub, Slack, Figma, Notion und mehr – damit projektübergreifende Sichtbarkeit nicht etwas ist, das du aufbaust. Sondern etwas, das einfach existiert. Zur Warteliste
---
Projektübergreifende Sichtbarkeit sollte kein Dashboard erfordern, das du aufbaust und wartest. Sugarbug baut den Wissensgraph, damit du das vollständige Bild automatisch siehst.
Q: Bietet Sugarbug projektübergreifende Sichtbarkeit? A: Ja. Sugarbug verbindet sich über API mit Linear, GitHub, Slack, Figma, Notion und anderen Tools und baut anschließend einen Wissensgraph auf, der Aufgaben, Gespräche und Personen über alle Tools hinweg verknüpft. Anstatt eines Dashboards, das Daten aus jedem Tool separat anzeigt, versteht Sugarbug die Beziehungen zwischen Elementen – sodass eine Slack-Diskussion, ein GitHub-PR und ein Linear-Ticket zum selben Feature alle verbunden sind.
Q: Wie verfolgt Sugarbug Arbeit über Linear und GitHub hinweg ohne manuelles Tagging? A: Sugarbug erfasst kontinuierlich Signale aus Linear und GitHub. Wenn ein GitHub-PR auf einen Linear-Issue verweist oder jemand eine Linear-Aufgabe in einem Slack-Thread bespricht, verknüpft Sugarbug diese Elemente automatisch im Wissensgraph. Kein manuelles Tagging, keine Namenskonventionen, keine „Bitte denk daran, den Projektcode in deine Commit-Message aufzunehmen"-Nachrichten in Slack.
Q: Kann ich Projektsichtbarkeit erhalten, ohne meine bestehenden Tools zu ersetzen? A: Absolut. Sugarbug ergänzt deinen bestehenden Stack. Es ersetzt weder Linear, GitHub, Slack noch Notion – es liest von ihnen und erstellt eine einheitliche Ansicht. Dein Team behält die Tools, die es bereits kennt und schätzt. Sugarbug macht nur die Verbindungen zwischen ihnen sichtbar.
Q: Was ist der Unterschied zwischen einem Dashboard und einem Wissensgraph für Projektsichtbarkeit? A: Ein Dashboard aggregiert Daten aus mehreren Quellen auf einem einzigen Bildschirm, aber jeder Datenpunkt bleibt isoliert – ein Linear-Issue ist nach wie vor nur ein Linear-Issue neben einem GitHub-PR. Ein Wissensgraph verknüpft Elemente über Tools hinweg und versteht, dass ein Slack-Thread, ein GitHub-PR und ein Linear-Issue alle Teil derselben Arbeit sind. Der Wissensgraph liefert Kontext; das Dashboard liefert Daten.