Aufgaben über mehrere Tools tracken – den Überblick behalten
Jedes Team, das Aufgaben toolübergreifend verfolgt, landet am Ende bei einer Tabelle. Warum das scheitert – und wie eine systemische Lösung aussieht.
By Ellis Keane · 2026-03-13
Das beste System hielt elf Tage
Das beste System, das ich je genutzt habe, um Aufgaben über mehrere Tools hinweg zu verfolgen, war ein Spreadsheet. Es war sauber, logisch, angenehm farbig codiert – und überlebte etwa elf Tage, bevor sie von der Realität gefressen wurde. Das ist, soweit ich das beurteilen kann, ungefähr die universelle Halbwertszeit jedes manuellen Tracking-Systems, unabhängig davon, wie klug die Leute sind, die es pflegen, oder wie viele bedingte Formatierungsregeln sie liebevoll angelegt haben.
Wir hatten Spalten für das Linear-Ticket, den GitHub-PR – wenn es einen gab –, einen Link zu dem Notion-Doc, das den Kontext enthielt, und ein Statusfeld, das eigentlich den tatsächlichen Zustand widerspiegeln sollte. Alles völlig vernünftig, und innerhalb von zwei Wochen vollständig aufgegeben, weil niemand in einem Sechspersonenteam aus seiner eigentlichen Arbeit heraus einen Kontextwechsel vornehmen möchte, um eine Tabelle zu aktualisieren, die nur existiert, weil die eigenen Tools nicht in der Lage sind, sich selbst zu verfolgen. Das ganze Unterfangen – Arbeit über das Verfolgen von Arbeit zu leisten – fraß ungefähr eine halbe Stunde pro Person und Tag, was sich zu einer wirklich deprimierenden Summe addiert, wenn man die Mühe unternimmt, sie über ein Quartal zu rechnen. Wir bezahlten faktisch die Arbeitsstunden einer Vollzeitstelle, nur um ein Dokument zu pflegen, das bereits falsch war, wenn jemand es prüfte.
Die Sache ist aber: Die Informationen waren immer vorhanden – jedes Issue hatte einen Status, jeder PR hatte einen Review-Zustand, und der Slack-Thread, in dem der Ansatz geändert wurde, enthielt den gesamten Kontext, den man je brauchen würde. Das Problem war nie fehlende Information – sondern dass jedes Tool nur seine eigene kleine Ecke des Bildes kannte, und das Einzige, was die Ecken verband, das Gedächtnis von jemandem war, der wusste, wo er welches Stück gesehen hatte. Wenn dieses Gedächtnis versagte – und es versagt immer irgendwann, meistens genau an dem Tag, an dem es am meisten darauf ankommt –, fielen Aufgaben durch die Ritzen auf eine Art, die im Nachhinein wirklich schwer zu rekonstruieren war.
Warum man Aufgaben über mehrere Tools nicht mit einem weiteren Tool verfolgen kann
In unserer Branche hält sich hartnäckig der Glaube, dass die Lösung für toolübergreifendes Aufgaben-Tracking ein besseres Tool ist – eine intelligentere Projektmanagement-Plattform, ein leistungsfähigeres Dashboard, irgendetwas, das endlich die sagenhafte „Single Pane of Glass" über alles liefert, was das Team macht. Die Projektmanagement-Branche hat das letzte Jahrzehnt damit verbracht, genau diese Produkte zu bauen. Es gibt inzwischen Dutzende von ihnen, und die Tatsache, dass es Dutzende gibt, sollte uns eigentlich etwas darüber sagen, wie gut irgendeines davon das Problem gelöst hat. Wenn das erste geholfen hätte, bräuchten wir das siebenunddreißigste nicht.
„Wenn das erste geholfen hätte, bräuchten wir das siebenunddreißigste nicht." – Ellis Keane
Ich glaubte diesen Mythos eine Zeit lang. Wir probierten mehrere dieser Tools aus (ich werde sie nicht alle nennen, aber wenn Sie diesen Weg schon gegangen sind, haben Sie wahrscheinlich ein paar der gleichen ausprobiert), und alle hatten dieselbe grundlegende Einschränkung: Sie waren immer noch einzelne Tools. Ein Dashboard, das GitHub-Daten neben Slack-Threads und Notion-Seiten aggregiert, ist besser als eine Tabelle – klar –, aber es zwingt immer noch sein eigenes Modell davon auf, was eine „Aufgabe" ist, und versucht, das Modell aller anderen in sein Schema zu pressen. Die Informationen werden abgeflacht, die Beziehungen gehen verloren, und am Ende hat man eine sehr teure, schreibgeschützte Ansicht von Daten, auf die man bereits Zugriff hatte, präsentiert in einem Layout, das nicht ganz zu der Art passt, wie eines der Quell-Tools es ursprünglich organisiert hatte.
Und hier ist der rekursive Teil, den ich fast komisch perfekt finde: Eine „Single Pane of Glass", für die man Integrationen einrichten, Mappings konfigurieren, noch ein weiteres Dashboard pflegen und noch eine weitere App prüfen muss, reduziert nicht die Tool-Proliferation – sie erhöht sie. Man hat jetzt n+1 Tools statt n, und die Aufgabe des (n+1)-ten Tools besteht darin, die anderen n zu beobachten – was bedeutet, dass seine Genauigkeit in direktem Verhältnis dazu abnimmt, wie viele Tools es beobachtet und wie oft diese Tools ihre APIs ändern. Wir haben zu viele Tools, also nehmen wir ein Tool, um die Tools zu verwalten – und wenn dieses Tool nicht ganz funktioniert, nehmen wir noch ein Tool, um die Lücken zu füllen, die das Tool hinterlassen hat, das eigentlich die Lücken füllen sollte. Irgendwann tritt man einen Schritt zurück und erkennt, dass man eine Rube-Goldberg-Maschine aus SaaS-Abonnements gebaut hat, und die eigentliche Arbeit – die Arbeit, der all diese Tools dienen sollten – findet trotz der Tools statt, nicht ihretwegen.
Der Mythos ist, dass es ein Sichtbarkeitsproblem ist – dass man, wenn man alles an einem Ort sehen könnte, zufrieden wäre. Der eigentliche Mechanismus ist, dass es eigentlich ein Problem der Beziehungen ist. Kein einzelnes Tool kann Aufgaben über mehrere Tools hinweg verfolgen, weil jedes Tool sein eigenes Modell davon hat, was eine Aufgabe ist, und diese Modelle grundlegend inkompatibel sind. Ein Dashboard, das sie nebeneinander anzeigt, macht die Modelle nicht kompatibel. Es macht die Inkompatibilität nur hübscher.
Toolübergreifendes Tracking scheitert nicht daran, dass man die Daten nicht sieht, sondern daran, dass kein Tool versteht, wie die Daten zusammenhängen. Dashboards zeigen Fakten aus fünf Orten; sie wissen nicht, dass all diese Fakten zum selben Stück Arbeit gehören.
Was jedes Tool tatsächlich sieht
Lassen Sie mich das konkret durchgehen, weil ich glaube, dass die Abstraktion verbirgt, wie schlimm die Situation wirklich ist.
Nehmen wir ein einzelnes Arbeitsstück – sagen wir, die Implementierung eines neuen API-Endpunkts. In Linear ist das ein Issue mit einem Status, einem Zugewiesenen, einer Priorität und einem Zyklus. In GitHub ist es ein PR (oder vielleicht zwei – einer für das Backend, einer für den Client) mit einem Review-Zustand, CI-Checks und einem Merge-Status. In Slack ist es ein Thread, in dem jemand eine Frage zum Ansatz gestellt hat und drei Personen vierzig Nachrichten lang diskutiert haben, bevor sie bei einem völlig anderen Design angelangt sind. In Notion gibt es eine RFC-Seite, zu der zwei Personen beigetragen haben und eine Person vergessen hat, sie zu aktualisieren, nachdem das Slack-Gespräch alles geändert hat. Und irgendwo in Figma hat ein Kommentar zum ursprünglichen Design die gesamte Änderung überhaupt erst ausgelöst.
Das sind fünf Tools, eine Aufgabe – und keines dieser Tools hat irgendeine Ahnung, dass die anderen vier über dasselbe Ding sprechen. Der Figma-Kommentar weiß nicht, dass es das RFC gibt. Der Slack-Thread weiß nicht, dass es ein Ticket gibt. GitHub weiß nicht, dass sich der Ansatz geändert hat. Jedes Tool verfolgt seinen eigenen Bereich wunderbar – das Problem ist, dass kein einzelnes Tool den vollständigen Lebenszyklus einer Aufgabe sieht, die mehrere Tools umspannt, und in einem Team unserer Größe macht genau das jede Aufgabe, die länger als einen Tag dauert.
Das menschliche Gedächtnis ist die Brücke zwischen all diesen Inseln – und das menschliche Gedächtnis (wie jeder bestätigen kann, der jemals einen Slack-Thread verpasst hat, weil er in einem Call war) ist eine deprimierend begrenzte Ressource, auf die man seine gesamte Projekttransparenz aufbauen kann.
Die drei Wege, auf denen Aufgaben verschwinden
Nachdem wir beobachtet hatten, wie toolübergreifendes Tracking bei Dutzenden von Aufgaben scheiterte – und, ehrlich gesagt, selbst zu einer ordentlichen Anzahl dieser Fehler beigetragen hatten –, begannen wir, Muster zu erkennen. Es gibt wirklich drei unterschiedliche Fehlermodi, und ich denke, sie zu benennen ist nützlich, weil sie unterschiedliche Lösungen erfordern.
Die Geisteraufgabe. Arbeit existiert in einem Tool, taucht aber in den anderen nie auf. Jemand erstellt ein Issue, der zugehörige PR passiert, ohne dass jemand darauf zurückverweist, die Diskussion über den Ansatz findet in einem Channel statt, in dem der Issue-Ersteller nicht ist – und drei Wochen später sieht die Aufgabe für alle blockiert aus, außer für die Person, die sie still geliefert hat und weitergegangen ist. Die Arbeit wurde erledigt – niemand weiß es.
Der veraltete Status. Der Status einer Aufgabe in einem Tool driftet aus der Realität heraus, weil der tatsächliche Fortschritt woanders verfolgt wird. Das Ticket sagt noch immer „In Bearbeitung", aber der PR wurde gestern gemergt. Das Dokument sagt „Entwurf", aber das Team hat in einem Thread, den niemand mit einem Lesezeichen versehen hat, bereits einen anderen Ansatz genehmigt. Jeder, der die vermeintliche Quelle der Wahrheit prüft, bekommt das falsche Bild, und Entscheidungen werden auf Basis veralteter Daten getroffen – was in gewisser Hinsicht schlimmer ist als gar keine Daten zu haben, denn zumindest weiß man mit gar keinen Daten, dass man rät.
Der verwaiste Kontext. Das ist der subtilste – und (zumindest in meiner Erfahrung) der, der den meisten tatsächlichen Schaden verursacht. Ein Gespräch findet statt, das die Richtung einer Aufgabe ändert – vielleicht eine Einschränkung, die niemand vorhergesehen hat, vielleicht ein besserer Ansatz, auf den jemand gekommen ist –, aber dieses Gespräch wird nie in die ursprüngliche Spezifikation zurückgespiegelt. Zwei Wochen später greift jemand die Aufgabe auf Basis der ursprünglichen Anforderungen auf, baut das Falsche, und das Team verliert eine sprintlange Arbeit. Der Kontext existierte die ganze Zeit – er lebte nur in einem Tool, das die Aufgabe nicht kannte.
Alle drei Fehlermodi haben dieselbe Grundursache: Die Tools teilen kein Modell dessen, was gerade passiert. Sie sind Inseln mit Brücken aus menschlicher Aufmerksamkeit – und menschliche Aufmerksamkeit ist genau die Ressource, die immer knapp ist.
Was Sie jetzt tun können (ohne etwas zu kaufen)
Bevor ich zur systemischen Lösung komme (und ich verspreche, dass ich nicht auf eine Verkaufsmasche hinarbeite – nun ja, nicht vollständig), gibt es ein paar Dinge, die tatsächlich helfen, toolübergreifende Tracking-Fehler zu reduzieren – mit nichts als Disziplin und einigen leichten Prozessänderungen. Wir haben all das ausprobiert, bevor wir irgendetwas gebaut haben, und einiges davon zählt immer noch, auch mit besseren Tools.
Bestimmen Sie einen kanonischen Heimatort für jede Aufgabe. Wählen Sie ein Tool als Quelle der Wahrheit für den Status (bei uns ist es Linear) und machen Sie eine Teamregel, dass jede statusändernde Entscheidung innerhalb von 24 Stunden dort eingetragen wird, egal wo das Gespräch stattgefunden hat. Das löst das Problem nicht, reduziert aber den Fehlermodus „Veralteter Status" erheblich.
Führen Sie einen wöchentlichen Sweep für verwaisten Kontext ein. Einmal pro Woche lässt jemand (rotierend) die Slack-Threads der letzten Woche durch und prüft, ob eine Entscheidung oder Richtungsänderung im entsprechenden Ticket oder Dokument festgehalten wurde. Fünfzehn Minuten gezieltes Verbinden bringt mehr verpassten Kontext ans Licht, als man erwarten würde.
Verwenden Sie konsequent Cross-Links. Wenn Sie einen PR öffnen, verlinken Sie das Issue. Wenn Sie einen Slack-Thread über eine Aufgabe beginnen, hängen Sie die Ticket-URL in die erste Nachricht. Wenn Sie ein Dokument aktualisieren, erwähnen Sie es im Thread. Das ist langweilig, manuell, und niemand will es tun (weshalb es mit der Zeit schlechter wird) – aber solange es funktioniert, funktioniert es gut.
Setzen Sie eine SLA für veraltete Status. Wenn ein Ticket seit fünf Werktagen nicht aktualisiert wurde und im zugehörigen PR oder Thread Aktivität stattgefunden hat, markieren Sie es. Das kann so einfach sein wie ein wöchentlicher Linear-Filter, den jemand kurz überprüft.
Keine dieser Lösungen ist dauerhaft – sie alle hängen davon ab, dass Menschen daran denken, Dinge zu tun, was genau die Ressource ist, die wir als unzuverlässig identifiziert haben –, aber sie reduzieren den Schaden spürbar, während man herausfindet, ob das Problem schlimm genug ist, um eine strukturelle Lösung zu rechtfertigen.
Wie eine echte Lösung aussieht (und was wir noch herausfinden)
Ich möchte hier vorsichtig sein, weil ich gerade mehrere Absätze damit verbracht habe, sarkastisch über Tools zu sein, die zu viel versprechen – und das Letzte, was ich tun möchte, ist, mich umzudrehen und dasselbe Versprechen zu machen. Lassen Sie mich also beschreiben, wie eine echte Lösung aussieht, mit dem ehrlichen Vorbehalt, dass wir selbst einiges davon noch durcharbeiten.
Die zentrale Erkenntnis – und ich weiß, dass das offensichtlich klingt, sobald man es ausspricht, aber es hat uns eine Weile gedauert, dorthin zu gelangen – ist, dass man kein weiteres Dashboard braucht. Man braucht einen Wissensgraph. Nicht eine schreibgeschützte Aggregation von Daten aus den Tools, sondern etwas, das die Beziehungen zwischen Elementen über sie hinweg aktiv versteht. Wenn ein PR eine Issue-Nummer in seiner Beschreibung referenziert, jemand den Ansatz in einem Thread diskutiert, der beide erwähnt, und ein Design-Kommentar auf die ursprüngliche Spezifikation verweist, kann ein Wissensgraph all das automatisch verbinden – durch Abgleich expliziter Referenzen, durch semantische Ähnlichkeit zwischen dem Inhalt und durch zeitliche Nähe verwandter Aktivitäten –, ohne dass jemand sie manuell verknüpft.
---
Sugarbug verbindet Ihre fragmentierten Tools zu einem lebendigen Wissensgraph. Aufgaben, Personen, Gespräche – automatisch verknüpft über Slack, GitHub, Notion, Figma und mehr. Je länger es läuft, desto intelligenter wird es. Erfahren Sie mehr
---
Das ist es, was wir mit Sugarbug bauen. Es verbindet sich mit Ihren bestehenden Tools (Sie nehmen nichts Neues an – Sie nutzen weiterhin, was Ihr Team bereits kennt) und baut einen Graphen davon auf, wie alles zusammenhängt. Der Graph-Ansatz bedeutet, dass er alle drei Fehlermodi erfassen kann: Geisteraufgaben werden erkannt, weil das System die PR-Aktivität sieht, auch wenn niemand sie mit dem Ticket verknüpft hat. Veraltete Status werden markiert, weil das System weiß, dass der Code gemergt wurde, auch wenn das Issue nicht aktualisiert wurde. Verwaister Kontext wird aufgedeckt, weil das System die Thread-Entscheidung mit der betreffenden Aufgabe verknüpft, auch wenn das Gespräch irgendwo stattfand, wo der Aufgabeninhaber nicht aufpasste.
Ich sollte ehrlich sein, dass wir das noch nicht alles gleich gut hinbekommen haben – und ich weiß wirklich nicht, ob das Problem des verwaisten Kontexts vollständig lösbar ist, ohne dass menschliches Urteilsvermögen im Spiel ist, weil das Verstehen von Gesprächsabsichten immer noch wirklich schwer ist. Die Geisteraufgaben-Erkennung ist solide, das Markieren veralteter Status wird besser, und das Aufdecken von Kontext ist die Grenze, an der wir arbeiten. Aber die Architektur bedeutet, dass jede neue Verbindung alle bestehenden intelligenter macht – und dieser kumulative Effekt ist, ehrlich gesagt, der Teil dieses Projekts, den ich am interessantesten finde.
Was sich für uns geändert hat
Das Überraschendste daran, das toolübergreifende Tracking auch nur teilweise richtig hinzubekommen, ist, wie konkret die Zeitersparnisse sich anfühlen. Es ist keine abstrakte Produktivitätskennzahl in einem Quartalsbericht – es ist, dass ich aufgehört habe, jeden Morgen zwanzig Minuten damit zu verbringen, in Slack nach dem Thread zu suchen, in dem jemand erklärt hat, warum der Ansatz sich geändert hat, und ich habe aufgehört, „Hey, was ist mit X passiert?" zu fragen, nur um zu warten, bis jemand drei verschiedene Stellen überprüft hat, bevor er antworten konnte.
Unser Team verbrachte (nach grober Schätzung, keine kontrollierte Studie) vielleicht zwei bis drei Stunden täglich zusammen mit dem, was ich nur als Arbeit-über-Arbeit beschreiben kann: Tracking-Dokumente aktualisieren, Kontext über Tools hinweg suchen, Punkte manuell verbinden, die automatisch verbunden hätten sein sollen. Wenn das Tracking tatsächlich funktioniert – wenn man darauf vertrauen kann, dass das System weiß, wo die Dinge sind –, ändern sich ein paar Dinge.
Status-Meetings werden kürzer oder verschwinden ganz. Wir sind von täglichen Standups zu zweimal wöchentlichen Check-ins übergegangen, obwohl ich bemerken sollte, dass bessere asynchrone Gewohnheiten wahrscheinlich auch zu dieser Verschiebung beigetragen haben – also bin ich vorsichtig, das alles auf die Tools zurückzuführen. Kontext taucht auf, wenn man ihn braucht – wenn man eine Aufgabe aufgreift, sind die relevanten Threads, Dokumente und Kommentare bereits verknüpft, sodass man nicht die ersten fünfzehn Minuten damit verbringt, zu rekonstruieren, was passiert ist, bevor man involviert wurde. Und weniger Dinge fallen durch die Ritzen – nicht null Dinge (ich glaube nicht, dass irgendein System das vollständig eliminiert), aber dramatisch weniger, was sich ehrlich gesagt wie ein kleines Wunder anfühlt, nachdem man jahrelang dabei zugeschaut hat, wie Aufgaben still in der Lücke zwischen Tools sterben.
Ich erkenne, dass ein Teil davon wie eine Verkaufsmasche klingt, und ich möchte direkt sagen, dass wir immer noch auf dieses Ziel hinarbeiten und es noch nicht vollständig über jeden Randfall hinweg liefern. Aber die Richtung fühlt sich richtig an, und die frühen Ergebnisse waren ermutigend genug, dass wir entschlossen sind, es durchzuhalten.
Hören Sie auf, Aufgaben in den Lücken zwischen Tools zu verlieren. Sugarbug verbindet Linear, GitHub, Slack und Notion zu einem lebendigen Wissensgraph.
Q: Kann Sugarbug Aufgaben über GitHub, Slack, Notion und andere Tools automatisch verfolgen? A: Ja. Sugarbug verbindet sich mit GitHub, Slack, Notion, Linear, Figma, E-Mail und Kalendern und baut einen Wissensgraph auf, der verwandte Elemente über alle Tools hinweg verknüpft. Wenn ein PR auf ein Issue verweist und jemand den Ansatz in einem Thread diskutiert, erkennt Sugarbug, dass all das zur selben Aufgabe gehört – ohne manuelles Verknüpfen.
Q: Wie unterscheidet sich Sugarbug von einem Projektmanagement-Dashboard? A: Dashboards aggregieren Daten aus Ihren Tools in einer einzigen Ansicht, sind aber nur lesbare Momentaufnahmen, die Beziehungen nicht verstehen. Sugarbug baut einen lebendigen Wissensgraph auf, der Aufgaben, Personen und Gespräche über Tools hinweg verbindet – und mit der Zeit intelligenter wird. Er zeigt nicht nur, wo Dinge stehen, sondern erkennt, was kurz davor ist, durch die Maschen zu fallen.
Q: Verursacht das Verfolgen von Aufgaben über mehrere Tools wirklich so viele Probleme? A: Unserer Erfahrung nach ja – und in der Regel mehr, als Teams erkennen, bis sie anfangen zu messen. Das Problem liegt nicht darin, dass einzelne Tools schlecht sind. Das Problem ist, dass Kontext über die Tools hinweg fragmentiert wird und kein einzelnes Tool das vollständige Bild kennt. Aufgaben stocken, weil die Person, die handeln muss, nicht weiß, dass das relevante Gespräch anderswo stattgefunden hat.
Q: Kann ich Sugarbug neben meinen bestehenden Tools verwenden? A: Genau darum geht es. Sugarbug ersetzt Ihre bestehenden Workflow-Tools nicht – es verbindet sie. Sie nutzen weiterhin, was Ihr Team bereits kennt, und Sugarbug baut die Intelligence-Schicht auf, die alles miteinander verbindet. Keine Migration, keine neue Benutzeroberfläche, die man für die tägliche Arbeit erlernen muss.
Wenn Ihr Team immer wieder Stunden damit verliert, Aufgaben zu suchen, die in den Lücken zwischen Tools verschwunden sind, lohnt sich ein Blick auf Sugarbug.