GTD: Kontexte

By | 15. April 2015

Kontexte sind ein Kernelement des Getting-Things-Done-Prinzips (GTD). Was sind Kontexte eigentlich? Wie definiere ich eine gute Kontextstruktur? Und wie wendet ich diese prakmatisch an? Diese Fragen will ich in diesem Artikel für mich beantworten. Dazu habe ich verschiedenste Artikel und Meinungen zum Thema analysiert. Vielleicht könnt ihr daraus etwas für eure eigene GTD-Implementierung mitnehmen.

Was sind Kontexte?

Kontexte sind heiß diskutiertes Thema in der GTD-Community. Ein Kontext beschreibt eine Menge an Ressourcen und physikalischen Gegebenheiten, die notwendig sind um eine Liste von Aufgaben bearbeiten zu können. Alle Aufgaben in einem Kontext können nacheinander abgearbeitet werden, wenn die Ressourcen verfügbar sind.

Die typischen Beispiele für Kontexte von David Allen sind: @Zuhause, @Computer, @Büro und @Unterwegs

Der Namensgeber des Prinzip „Getting Things Done“ steht ganz eng mit dem Konzept der Kontexte in Verbindung. Man kann die Aussage dahingehend umschreiben: „Get the Next Actions done as soon as you are in the Kontext“. Um diesen Ansatz umzusetzen muss jede Aufgabe genau einem Kontext zuordnet werden.

Was bringt mir der Einsatz von Kontexten?

Durch die zusammenhängende Bearbeitung ähnlicher Aufgaben wird Zeit gespart, indem die vorhandenen Bedingungen optimal genutzt werden. Man kommt dadurch leichter in den Arbeitsfluss – Flow. Ein hin- und her wechseln zwischen Tools, Orten oder Personen wird vermieden. Dadurch wirkt die Fokussierung auf die Aufgaben eines Kontextes auch energiesparend.

Ein Kontext setzt den Rahmen einer Aufgabe und bestimmt über Wie, Wo, Wann und Womit. Die Aufgabe selbst definiert das Was. Dadurch wird eine klare Abgrenzung zwischen den Aufgaben ermöglicht.

Gerade bei einer großen Liste von Aufgaben wird durch klar abgegrenzte Kontexte Übersicht geschaffen. Eine aufwändige Priorisierung (A+++ :-D) wird unnötig, da Kontexte auf natürliche Art die nächsten Aktionen eingrenzen. Kontexte bringen dann auch Aufgaben zusammen, die nicht für das selbe Vorhaben (Projekt) erledigen werden müssen und bringen dadurch Abwechslung in die Abarbeitung.

Gerade heute haben viele „Wissensarbeiter“ – zu denen auch ich mich zähle – eine endlose Auswahl an zu erledigenden Aufgaben und die Auswahl was als nächstes erledigt werden soll fällt schwer und dauert länger. Hier schaffen Kontexte Abhilfe. Sie ermöglichen eine klare Fokussierung auf eine begrenzte Menge an Aufgaben. Für mich persönlich wird dabei auch meine Motivation etwas zu schaffen verbessert, da ich nicht immer die Gesamtheit meiner Aufgaben immer im Blick habe.

Wie bildet man einen Kontext?

Kontexte müssen immer eine nachvollziehbare und natürliche Einordnung von Aufgaben ermöglichen. Ohne großes Nachdenken und Abwägen muss die Zuordnung klar sein.

Wie man die geeigneten Kontexte für sich ableitet ist eine höchst individuelle und dabei spannende Aufgabe. Eine Kontextstruktur macht die eigene GTD-Umsetzung einzigartig. Sie drückt die persönliche Lebensgestaltung des Einzelnen aus. Einen Standard gibt es nicht.

Beispiel: Wenn ich (nahezu) immer mein Telefon Zugang zu einem Telefon habe muss ich keinen Kontext @Telefon haben, sondern eine andere Einteilung vornehmen, z.B. @Zuhause für private Anrufe und @Büro für dienstliche Aufrufe.

Es dauert dabei teilweise sehr lange ein geeignetes System für sich zu entwickeln. Man darf dabei nicht vergessen, dass sich die eigenen Lebensumstände im Laufe der Zeit auch verändern können. Auch die Kontextstruktur ist daher nicht statisch sondern muss von Zeit zu Zeit geprüft und angepasst werden. Fügt man einen neuen Kontext hinzu kann man diesen zunächst testen und später wieder verwerfen.

Meine Regeln für die Definition von Kontexten

Ich habe ein paar Regeln abgeleitet nach denen ich die Kontexte definieren sollte:

  • „Don’t repeat yourself“ (DRY) – abgeleitet aus dem Software-Entwurf sollte jeder Kontext eine eindeutige Grenze zu anderen Kontexten haben. Sobald eine Aufgabe mehr als einen Kontext zugeordnet werden könnten sollte geprüft werden, ob man durch eine Verallgemeinerung eines Kontextes eine Eindeutigkeit erreicht werden kann. Man sollte also Redundanzen in den Bedingungen von Kontexten vermeiden.
  • „Keep it simple“ – eine zu komplexe Struktur innerhalb der Kontexte macht die Einordnung neuer Aufgaben aus der Inbox schwierig und zeitaufwändig. Die Kontextstruktur sollte daher möglichst einfach bleiben. Ebenso ist es sinnvoll mit wenigen Kontexten zu starten und später bei Bedarf weitere Kontexte zu ergänzen und zu testen. Je weniger Kontexte man definiert desto besser ist das eigene System.
  • „Kontexte sollten keine immer vorhandene Bedingungen beschreiben“ – sobald ein Kontext eine immer verfügbare Ressource abbildet ist ein eigener Kontext dafür nicht notwendig. In diesem Fall gilt es zu prüfen, welche anderen Bedingungen für die Aufgaben erfüllt sein müssen. Wird diese Regel verletzt entstehen zu große Listen und die konkrete Einordnung von neuen Aufgaben fällt schwer.
  • „Kontexte sollten regelmäßige Lebensumstände abbilden“ – wenn man ganz selten in einem Kontext ist, dann werden dir vermutlich nur sehr spezielle Aufgaben eingeordnet. Es besteht das Risiko, dass die Aufgaben komplett vergessen und somit nie erledigt werden. In diesem Fall ist die Liste zu fein-granular und sollte verallgemeinert werden.
  • „Kontexte sollte nie mehr als 20 Aufgaben enthalten“ – zu große Aufgabenlisten in einem Kontext erschweren die Übersicht. Es ist jedes mal die Durchsicht aller enthaltenen Aufgaben erforderlich bevor etwas erledigt werden kann. Ein Kontexte sollte daher maximal 20 Aufgaben enthalten. Ist ein Kontext größer ist er zu allgemein und muss unterteilt werden.
  • „Kontexte wie @Irgendwo oder @Sonstiges vermeiden“ – diese Listen werden leicht zu „Mülleimern“ und verletzten die letzte Regel. Außerdem ist für fast jede Aufgabe irgendeine Bedingung oder Ressource erforderlich. Eine Ausnahme bilden rein-gedankliche Arbeitsprozesse bei denen nur der Verstand benötigt werden. Für solche Aufgaben sollte jedoch lieber ein Kontext @Brainstorming gebildet werden, um keinen zu allgemeinen Charakter zu haben.

Ansätze für Kontextestrukturen

Kontexte definieren benötigte Ressourcen, Rahmenbedingungen oder Voraussetzungen für eine Menge von Aufgaben. Kontexte können in folgende Gruppen untergliedert werden:

  • Orte: @Zuhause, @Büro, @Unterwegs
  • Dienste: @Telefonate, @Mail, @Mac, @Mobil
  • Aufgaben: @Planung, @Forschung, @Entwicklung, @Analyse
  • Personen(-gruppen): @Familie, @Freunde, @Kollegen
  • Status: @Wartet, @Überdenken, @Pausiert
  • Energie: @LowEnergy
  • Zeit- und Aufmerksamkeit: @Routine, @Fokus, @Kurz, @Lang, @Zwischendurch
  • Arbeitsfelder: @Design, @Programmierung, @Entwurf
  • Modus: @Freizeit, @Arbeit

Welche Probleme gibt es bei der Arbeit mit Kontexten?

In der Theorie klingt dies erst mal sehr gut und durchaus nachvollziehbar. In der Praxis ergeben sich jedoch für einige Probleme:

  • Überlappungen in Kontexten: Wenn ich mich im Kontext @Büro arbeite ich auch mit meinem @Mac, schreibe @Mails, erledige @Telefonate oder habe Meetings mit @Kollegen
  • Tiefe der Hierarchie: Tiefe Hierarchien innerhalb der Kontexte lösen das Problem der Überlappungen, aber führen zu unübersichtlichen Strukturen. z.B. Ist ein Kontext @Büro / Mac / Forschung wenig sinnvoll, da er keine simple Abarbeitung von Aufgaben ermöglicht.
  • Überschneidungen zwischen Rollen (Areas of Reponsibilities) und Kontexten: Kontexte und Rollen können sich leicht überschneiden, z.B. kann der Kontext @Freunde leicht mit einer Rolle verwechselt oder vermischt werden.

Bekommt man diese und andere Probleme nicht in den Griff kann dies dazu führen, dass man das GTD-Prinzip aufgibt. Es ist daher wichtig darauf zu achten die Probleme durch die genannten Strategien zu lösen.

Was sagen Kritiker zum Thema Kontexte?

Kontexte sind eines der mächtigsten Werkzeuge von GTD. Zugleich oder gerade deshalb sind Kontexte aber sehr umstritten und viel diskutiert.

Kritiker sagen, dass Kontexte bei den heutigen technischen Möglichkeiten überflüssigen geworden sind. Dies begründen sie damit, dass Tools durch die zunehmende Mobilität der Technik überall zur Verfügung stehen und Kontexte dadurch an Wichtigkeit und Wirksamkeit verlieren. Als David Allen das GTD-Prinzip entwickelte war zum Beispiel das Internet noch nicht überall verfügbar und die Aufgaben die zu erledigen waren mussten nach der jeweiligen Verfügbarkeit geplant werden. Heute da man nahezu immer Zugang zum Internet und damit diversen Tools hat ist die Notwendigkeit weitgehend verschwunden.

Meiner Meinung nach sind Kontexte dennoch sinnvoll, um große Listen von Aufgaben in kleinere besser zu überblickende Listen aufzuteilen. Gerade die verschiedenen Ansätze und Gruppen von Kontexten ermöglichen es eine sinnvolle Struktur zu schaffen. Zu dem finde ich es praktisch ähnliche Aufgaben durch Kontext-Listen zusammenhängend zu bearbeiten.

Referenzen zum Thema

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *