Verpasste Aufgaben sind kein Menschenproblem
Warum verpasste Aufgaben im Projektmanagement kein Disziplinproblem sind – und wann Ihr Team ein System braucht, das sie automatisch auffängt.
By Ellis Keane · 2026-03-17
Wenn Ihr Team klein genug ist, dass Sie alle zusammen Mittag essen (oder es zumindest theoretisch könnten, falls Sie jemals zur gleichen Zeit in derselben Stadt wären), müssen Sie das hier wahrscheinlich nicht lesen. Schließen Sie den Tab. Bauen Sie etwas. Das Problem der verpassten Aufgaben ist in Ihrem Maßstab einen Slack-Reminder am Mittwochnachmittag davon entfernt, gelöst zu werden – und das meine ich aufrichtig.
Noch hier? Gut. Dann reden wir über verpasste Aufgaben im Projektmanagement – und insbesondere darüber, warum der übliche Rat nicht mehr greift, sobald das Team eine bestimmte Größe erreicht.
Bevor wir weitermachen
Wir entwickeln ein Tool, das dieses Problem angeht (Sugarbug – ich würde lügen, wenn ich so täte, als wäre das nicht so), aber die ehrliche Antwort ist, dass die meisten Teams, die das hier lesen, noch nicht brauchen, was wir entwickeln. Vielleicht nie. Was sie brauchen, ist zu verstehen, warum Aufgaben überhaupt verpasst werden – denn die Lösung hängt von der Ursache ab, und die Ursache ist fast nie das, was die meisten denken.
Warum Aufgaben verpasst werden
Fragen Sie die meisten Manager, warum Aufgaben verpasst werden, hören Sie eine vertraute Liste: Jemand hat vergessen, jemand hat nicht aufgepasst, jemand hat den Prozess nicht befolgt. Die Lösung sind also bessere Prozesse, mehr Erinnerungen, vielleicht ein Standup-Bot, der die Leute jeden Morgen anstupst.
Und ja, manchmal ist das tatsächlich das Problem. Wenn Ihr Entwickler vergessen hat, das Linear-Ticket zu aktualisieren, und der PM vor dem Sprint-Review nicht nachgeschaut hat, ist das ein menschliches Versehen und eine Prozesslücke. Checkliste hinzufügen. Weitermachen.
Aber das ist nicht die Art von verpasster Aufgabe, die Engineering-Manager nachts wachhält. Die wirklich schmerzhafte ist die, bei der alle ihren Job gemacht, den Prozess befolgt und ihre Tools aktualisiert haben – und trotzdem ist etwas durch die Lücke gefallen. Denn die Lücke liegt nicht zwischen einer Person und ihrer Aufgabe. Sie liegt zwischen einem Tool und einem anderen.
Hier ist, was ich meine. Ein Entwickler schickt einen PR ab, der ein GitHub-Issue schließt. Das Issue war mit einem Linear-Ticket verknüpft, und das Ticket wechselt auf „Erledigt". Gut. Nur: Die ursprüngliche Anforderung stammte aus einem Slack-Gespräch vor drei Wochen, in dem der PM auch eine Folgeanforderung erwähnte, die niemand als separate Aufgabe erfasst hat. Diese Folgeanforderung lebt in einem Slack-Thread vom Februar. Sie ist nicht in Linear. Sie ist nicht in GitHub. Sie ist in keinem Sprint. Es ist technisch gesehen eine verpasste Aufgabe – aber keine einzelne Person hat sie fallen lassen. Sie fiel durch die strukturelle Lücke zwischen Slack und dem Task-Tracker.
Dieses Muster taucht überall auf, wenn man erst einmal hinschaut. Ein Designer hinterlässt einen Kommentar in Figma, der darauf hinweist, dass ein Grenzfall dem Spec in Notion widerspricht – aber der Entwickler, der an dem Feature arbeitet, schaut nie in Figma, und der PM sieht den Kommentar nie, weil er in Linear lebt. Ein Customer-Success-Lead verspricht in einem Anruf ein Feature, fasst es in einer E-Mail zusammen, und es landet nie im Engineering-Backlog, weil niemand diese bestimmte Lücke überbrückt. Ein Incident-Post-Mortem identifiziert drei Folgepunkte, das Dokument wird in Slack geteilt, und zwei der drei werden nie zu nachverfolgten Aufgaben, weil die Person, die das normalerweise übernimmt, in der Woche krank war.
Die schädlichsten verpassten Aufgaben im Projektmanagement entstehen in den Lücken zwischen Tools – nicht in den Lücken zwischen Menschen und ihren Aufgabenlisten.
Der Prozessansatz (und wo er aufhört zu funktionieren)
Ich glaube aufrichtig, dass gute Prozesse die meisten dieser Probleme für die meisten Teams lösen. Hier ist, was funktioniert – und ich teile das ohne Hintergedanken, weil wir (um ehrlich zu sein) vor dem Launch sind und das Beste, was wir jetzt tun können, darin besteht, Vertrauen aufzubauen, indem wir nützlich sind.
Der wöchentliche Durchlauf. Eine Person – idealerweise der PM oder Engineering-Lead – verbringt jeden Freitag 30 Minuten damit, Slack-Threads, Meeting-Notizen und E-Mails durchzugehen, um alles aufzufangen, was besprochen, aber nie erfasst wurde. Mühsam? Absolut. Effektiv? Überraschend gut, bis zu einem gewissen Punkt.
Das Entscheidungsprotokoll. Jede Entscheidung aus einem Slack-Thread oder Meeting wird mit Datum, Entscheidungsträger und Folgemaßnahme in ein geteiltes Dokument eingefügt (Notion, Google Docs – spielt keine Rolle). Das klingt einfach, und ist es auch – bis man fünfzehn Entscheidungen pro Woche über vier Kanäle hinweg trifft und niemand mehr weiß, welche davon erfasst wurden.
Die Verlinkungsdisziplin. Jeder PR referenziert sein Linear-Ticket. Jedes Linear-Ticket verlinkt auf den Slack-Thread, in dem die Anforderung besprochen wurde. Jeder Notion-Spec verlinkt auf sein Linear-Epic. Wenn jemand die Kette unterbricht – und jemand wird es, es ist keine Frage des Ob –, bricht die Sichtbarkeit mit ihr.
Das sind alles gute Praktiken. Wir verwenden selbst Varianten aller drei. Aber sie haben einen gemeinsamen Schwachpunkt: Sie setzen voraus, dass Menschen eine kleine, langweilige Sache jedes Mal, für immer, zuverlässig tun. Und die Forschungslage dazu ist nicht ermutigend – ich muss das gar nicht zitieren. Wenn Sie jemals ein Team von mehr als fünf Personen geführt haben, wissen Sie das bereits.
Wenn der Prozessansatz aufhört zu skalieren
Es gibt einen Schwellenwert, und ich wünschte, ich könnte Ihnen eine genaue Zahl nennen, aber wir haben das noch nicht herausgefunden (ehrlich gesagt variiert das wahrscheinlich je nach Team und Disziplin). Unsere Arbeitsheuristik – und ich möchte deutlich machen, dass das eine Heuristik ist, keine gesicherten Daten – ist, dass die Dinge irgendwo ab vier oder fünf Tools, mehr als zehn Personen und mehreren parallelen Workstreams anfangen zu brechen.
Nicht weil jemand faul wurde. Nicht weil der Prozess schlecht war. Sondern weil das Volumen der Verbindungen zwischen Tools die Fähigkeit einer einzelnen Person übersteigt, sie manuell zu verfolgen. Der wöchentliche Durchlauf dauert 90 Minuten statt 30, und der PM fängt an zu überfliegen. Das Entscheidungsprotokoll veraltet, weil die Person, die es pflegt, im Urlaub war und niemand eingesprungen ist. Die Verlinkungsdisziplin hält für Linear und GitHub, bricht aber für Slack und Figma zusammen, weil diese Tools keine gleichartig strukturierten Referenzen haben.
Das ist – und das möchte ich klar sagen – ein Skalierungsproblem, kein Disziplinproblem. Ich habe wirklich hervorragende PMs und Engineering-Leads dabei beobachtet, wie sie damit kämpfen – Menschen, die ein straff geführtes Schiff fahren und sich sehr darum kümmern, dass nichts durch die Maschen fällt. Bei einer bestimmten Größenordnung überwächst das Problem die Lösung. Das ist kein Versagen der Person – es ist ein Versagen des Tool-Ökosystems darin, sich selbst zu verbinden.
"Die Belohnung dafür, seinen Tooling-Einsatz zu professionalisieren, ist eine komplexere Fehleroberfläche für verpasste Aufgaben. Das finde ich zutiefst ironisch." – Ellis Keane
Und hier ist der Teil, den ich für wirklich unfair halte: Je besser Ihr Team seine Tools einsetzt, desto mehr Angriffsfläche entsteht für Cross-Tool-Lücken. Ein Team, das Linear konsequent nutzt, Notion-Specs aktuell hält, aktive Figma-Reviews hat und in gut organisierten Slack-Kanälen kommuniziert, hat mehr Übergabepunkte als ein Team, das nur E-Mail und eine Tabellenkalkulation verwendet.
Warum Ihre Tools nicht helfen können
Das ist das, was ich an diesem Problem wirklich interessant finde und was meiner Meinung nach zu wenig diskutiert wird: Ihre Tools tun genau das, wofür sie entwickelt wurden. Linear ist hervorragend darin, Linear-Issues zu verfolgen. GitHub ist hervorragend darin, Code-Änderungen zu verfolgen. Notion ist hervorragend darin, Dokumente zu organisieren. Slack ist hervorragend darin ... Slack zu sein (für besser oder schlechter).
Aber keines davon wurde entwickelt, um die Verbindungen zwischen ihnen zu verfolgen. Und Arbeit – echte Arbeit – findet nicht in einem einzigen Tool statt, sie fließt durch alle. Die Übergabepunkte zwischen Tools sind dort, wo Dinge verschwinden, und kein noch so großes Verbessern eines einzelnen Tools behebt das. Sie können Linear besser im Verfolgen von Issues machen – aber das hilft nicht, wenn das Issue überhaupt erst auf Basis eines Slack-Gesprächs hätte erstellt werden sollen, das in einem Kanal stattfand, den der Engineering-Lead nicht überwacht.
Was das tatsächlich beheben würde
Ich war in diesem Beitrag absichtlich vage, was Produktangelegenheiten betrifft – das ist beabsichtigt. Ich wollte, dass das nützlich ist, egal ob Sie jemals etwas von dem verwenden, was wir entwickeln. Aber da Sie es so weit geschafft haben (und das schätze ich), möchte ich ehrlich darüber sein, wie die eigentliche Lösung meiner Meinung nach aussieht.
Es ist kein besserer Task-Tracker. Es ist kein besserer Prozess. Es ist kein Standup-Bot, kein wöchentlicher Review, keine geteilte Tabelle. All das hilft, und im kleinen Maßstab reicht es aus – aber alle behandeln das Symptom.
Die eigentliche Lösung ist etwas, das die Verbindungen zwischen Ihren Tools beobachtet und meldet, wenn etwas nicht stimmt. Wenn eine Slack-Entscheidung kein Ticket wird. Wenn ein GitHub-PR ein Issue schließt, aber noch ungelöste Kommentare vorhanden sind. Wenn ein Notion-Spec eine Anforderung referenziert, die in einem Gespräch deprioritisiert wurde, das der Spec-Autor nie gesehen hat.
Zur Verdeutlichung: Angenommen, Ihr System beobachtet sowohl Slack als auch Linear. Es sieht ein Gespräch in #engineering, in dem jemand schreibt: „Wir sollten auch den Fall behandeln, bei dem der Nutzer seine E-Mail noch nicht verifiziert hat" – das ist eine neue Anforderung. Wenn diese Anforderung innerhalb von, sagen wir, 48 Stunden nicht als Linear-Ticket auftaucht, markiert das System sie. Nicht mit einer Benachrichtigung, die auf Sie einschreit (niemand braucht davon mehr), sondern als Eintrag in einer Ansicht „noch nicht erfasste Entscheidungen", die der PM in seinem Freitagsdurchlauf prüfen kann. Gleiches gilt für GitHub-PRs, die Linear-Tickets schließen, aber noch offene Review-Kommentare haben, oder für Notion-Specs, die Features referenzieren, die seit dem Schreiben des Specs deprioritisiert wurden.
Ob Sie das intern entwickeln (manche Teams tun das, mit Webhooks, einer Message-Queue und etwas Kleber-Code), eine fertige Lösung verwenden oder verpasste Aufgaben schlicht als Betriebskosten akzeptieren – das liegt bei Ihnen. Wir entwickeln eine Version dieser Antwort, aber es ist nicht die einzige, und für viele Teams ist es noch nicht die richtige.
Wenn Sie wissen wollen, wann es die richtige für Sie sein könnte, hier ist meine ehrliche Heuristik: Wenn Ihr wöchentlicher Durchlauf mehr als 30 Minuten dauert und trotzdem noch Dinge durchfallen, haben Sie den manuellen Ansatz überwachsen.
---
Wenn der wöchentliche Durchlauf mehr als 30 Minuten dauert und trotzdem Dinge durchfallen, haben Sie den manuellen Ansatz überwachsen. Sugarbug überwacht die Lücken automatisch.
Q: Wie verhindert Sugarbug verpasste Aufgaben im Projektmanagement? A: Sugarbug erstellt einen Wissensgraph über alle Ihre Tools – Linear, GitHub, Slack, Figma, Notion – und verfolgt Aufgaben, Gespräche und Entscheidungen, während sie zwischen ihnen wechseln. Wenn etwas ins Stocken gerät oder die Verbindung zur ursprünglichen Anfrage verliert, macht Sugarbug es sichtbar, bevor es durch die Lücke fällt. Es ist kein Erinnerungssystem – es versteht die Beziehungen zwischen Elementen über Tools hinweg und meldet, wenn diese Beziehungen brechen.
Q: Kann Sugarbug Aufgaben aufdecken, die in Slack besprochen, aber nie erfasst wurden? A: Ja. Sugarbug überwacht Slack-Gespräche und erkennt, wenn eine Entscheidung oder ein Aktionspunkt besprochen, aber nie als Aufgabe in Linear oder Ticket in GitHub erfasst wurde. Es markiert die Lücke, damit jemand handeln kann. Wir verfeinern noch, wie aggressiv es melden soll (niemand möchte obendrein noch Benachrichtigungsmüdigkeit), aber die Kernerkennung funktioniert.
Q: Brauche ich ein Tool, um verpasste Aufgaben zu beheben, oder ist es ein Prozessproblem? A: Ehrlich gesagt hängt das vom Umfang ab. Kleine Teams mit zwei oder drei Tools können das meist mit besseren Gewohnheiten lösen – ein wöchentlicher Review, ein geteiltes Dokument, eine Verlinkungsdisziplin. Aber ab vier oder fünf Tools und mehr als zehn Personen hört der manuelle Ansatz auf zu skalieren, und man braucht etwas, das die Verbindungen automatisch verfolgt. Der Schwellenwert variiert je nach Team, aber Sie werden merken, wenn Sie ihn erreicht haben.
Q: Was ist der Unterschied zwischen einem Task-Tracker und einem Signalintelligenz-System für das Projektmanagement? A: Ein Task-Tracker zeichnet auf, was man ihm sagt. Ein Signalintelligenz-System beobachtet, was tatsächlich über alle Tools hinweg passiert, und meldet, wenn etwas nicht stimmt – eine Aufgabe, die als erledigt markiert ist, aber ungelöste Kommentare hat, oder eine Entscheidung, die in Slack getroffen, aber nie im Spec gespiegelt wurde. Es fängt die Dinge auf, die Menschen vergessen zu erfassen – was unserer Erfahrung nach der Ursprung der meisten dieser Lücken ist.