Skip to content

Latest commit

 

History

History
186 lines (105 loc) · 24.2 KB

konzept.de.md

File metadata and controls

186 lines (105 loc) · 24.2 KB

FlowgencyTM – Konzept einer neuartigen Zeit- und Aufgabenmanagementsoftware

  1. Vorüberlegungen
  2. Welche Größen der Dringlichkeit kennt FlowgencyTM?
  3. Was verbirgt sich hinter dem Zeitfortschritt?
  4. Wie wird der Erledigungsfortschritt berechnet?
  5. Weitere Kernfunktionen
  6. Risiken
  7. Vergleich mit anderen Tools

In der Büroarbeit anfallende Aufgaben müssen oft quasi-parallel im Kopf behalten und erledigt werden. Obendrein sind sie sehr verschieden, und zwar nicht nur in Bezug auf ihre inhaltlichen Aspekte. Noch dazu sind die einen Aufgaben dringlicher als die anderen, und es gibt auch wichtigere und weniger wichtige, und mal komplexere, mal simplere Sachen zu tun. Das alles ballt sich leicht zu einem Chaos im Kopf zusammen. Hier den Überblick zu behalten, erfordert eigentlich eine Assistenz, damit man den Kopf freihat für die Aufgaben selbst statt mit ständigen Abwägungen, welche Aufgabe aktuell am ehesten bearbeitet werden sollte.

Als wäre das noch nicht genug, kommt schon wieder eine Mail mit einem »EILT«-Vermerk im Betreff in den Posteingang, ein Telefonanruf geht ein oder jemand schneit persönlich ins Büro und möchte »mal schnell« irgendwas von einem. Und dieser Zustand soll auch noch der Sollzustand sein, »Multitaskingfähigkeit« im Wahn einer sich immer schneller um sich selbst drehenden Arbeitswelt? In Studien wurde ermittelt, dass es nach einer Unterbrechung viele Minuten braucht, bis die Konzentration wieder annähernd die alte Tiefe wie davor erreicht hat und dass dies mit jeder Unterbrechung immer schlechter geht, dass die Konzentrationsfähigkeit sozusagen verschleißt und konzentriertes Arbeiten immer mehr zu einer Utopie verkommt.

FlowgencyTM soll eine Open-Source-Software werden, die dabei unterstützt, mit dieser Situation besser umzugehen. Sie soll die Konzentrationsfähigkeit erhalten und die Resilienz gegen Unterbrechungen verbessern. Bei der Entwicklung des Programms sind zwei eigentlich widersprüchliche Herausforderungen zu vereinbaren: Einfachheit in der Anwendung zum einen und Flexibilität zum anderen, so dass es sich so gut wie möglich an die Arbeitsweise des Anwenders anpasst.

Das Programm soll im Wesentlichen:

  • die sogenannte Refokussierungsphase nach Unterbrechungen bei der Arbeit verkürzen. Damit ist die Zeit gemeint, die benötigt wird, bis man wieder so tief »drin« ist wie vor einer Unterbrechung.
  • zwischen dem im Büro herrschenden Multitaskingwahn und dem menschlichen Gehirn vermitteln. Gut machen kann es bekanntlich nur eines nach dem anderen. Dass es hier einen Unterschied zwischen den Geschlechtern gäbe, ist übrigens wissenschaftlich nicht belegt. Jedenfalls müsste es in der Redewendung »auf mehreren Hochzeiten gleichzeitig tanzen« ehrlicherweise torkeln heißen.
  • der Verschmelzung von Arbeits- und Freizeit entgegenwirken, indem sie den Dringlichkeitsanstieg von eingetragenen Aufgaben rechnerisch aus der Freizeit in die Arbeitszeit verlagert. Damit setzt das Programm die Bereitschaft des Anwenders voraus bzw. soll ihn in erster Linie dazu motivieren, hinreichend genau vorauszuplanen.

Der Sinn und Zweck des Projekts ist, Flowerlebnisse bei der Büroarbeit zu begünstigen – daher der Name – und das private Leben freizuhalten von Arbeitssorgen. Das Programm zählt sich zu den Zeit- und Aufgabenmanagementsystemen. Andere Vertreter dieser Softwaregattung sind oft entweder zu einfach gestrickt sind oder zu komplex – die Mitte ist noch zu wenig vertreten. FlowgencyTM ist weder ein einfaches Todolistenprogramm, noch eine professionelle Projektmanagementsoftware. Es ist für Vorhaben kleiner und mittlerer Größe geeignet, die für sich genommen vom Einzelnen überschaut werden können. Das Augenmerk liegt bei der Entwicklung eines Prototyps auch nicht darauf, sich gut in bestehende Groupwarelösungen einzufügen. Vielmehr sei die Entnetzung zum Prinzip erhoben. Wo keine Netze, da keine Abhängigkeiten, da Freiheit – da ist konzentriertes Arbeiten möglich.

FlowgencyTM wird – ist übrigens bereits zu essentiellen Teilen – in der Programmiersprache Perl realisiert. Es handelt sich um freie und offene Software unter den Bedingungen der GNU General Public License, Version 3.

FlowgencyTM ist mit dem Webframework Mojolicious realisiert. Dadurch kann die Benutzeroberfläche über den bevorzugten Webbrowser des Anwenders laufen und mittels HTML5 und Javascript realisiert werden. Der Serverseite kann entweder eine Maschine im Inter-/Intranet sein oder ein Programm, das abgeschottet von der Außenwelt direkt auf dem lokalen System läuft. Weil letztere Betriebsart weniger datenschutzrechtliche und Sicherheitsprobleme macht, soll sie bei der Entwicklung bevorzugt werden.

Der folgende Screenshot zeigt einen Entwurf der Hauptansicht von FlowgencyTM. Links ist die Navigation, rechts werden die aktuell dringlichsten Aufgaben aufgelistet.

Hauptseite von FlowgencyTM: Aufgabenliste – Prototyp

Technische Konzeption

Nur fünf verschiedene Größen scheinen mir derzeit sinnvoll. Sie spiegeln verschiedene Begriffe von Dringlichkeit wieder. Weitere Dimensionen können dazukommen. Sie werden unabhängig voneinander berechnet, anschließend über eine gedachte kontinuierliche, lineare und einheitslose Skala normiert. Die resultierenden Werte im Bereich von 0 (Minimum) bis 1 (Maximum) werden jeweils mit einem Wichtungsfaktor multipliziert, den der User jeweils seinem Gefühl entsprechend für alle Aufgaben bestimmen kann (voreingestellt ist neutralerweise 1 bei allen). Alle aktuell anstehenden Aufgaben werden schließlich in absteigender Ordnung nach der schlichten Summe dieser Produkte, ihrem sogenannten »FlowRank« angezeigt.

  1. Priorität

Konventionelle Stufen wie »normal«, »dringlich« und »gelegentlich erledigen« sind in FlowgencyTM lediglich informativ. Eigentlich gerechnet wird mit einer positiven Ganzzahl, die beliebig hoch sein kann. Hat zum Beispiel eine Aufgabe A Priorität 5 und eine weitere Aufgabe bekommt Priorität 3000, dann wird automatisch A, vormals vielleicht »dringend«, ganz bestimmt zurückgestuft auf »gelegentlich erledigen«, zumindest solange B diese hohe Priorität hat und nicht erledigt ist.

  1. Zeitliche Nähe zum Fristende

Je näher die Frist rückt, umso dringlicher ist eine Aufgabe. Grundsätzlich sollte jede Aufgabe mit einem Fristende belegt werden. Aufgaben, für die man sich nicht einmal eine provisorische Frist »ausdenken« kann, sind nach gängiger Lehrmeinung des Zeitmanagements beiseite zu legen.

  1. Diskrepanz zwischen zeitlichem und Erledigungsfortschritt

Je weiter der Erledigungsfortschritt dem zeitlichen Fortschritt zwischen Beginn und Fristende hinterherhinkt, als umso dringlicher gilt die Aufgabe.

In der Liste wird dieses Kriterium auch farblich visualisiert.

  1. Zeit, wie lange eine Aufgabe schon offen ist

Werden die Details einer Aufgabe eingeblendet, gilt sie als offen, bis sie erledigt ist oder wieder geschlossen wird. Offene Aufgaben, aber auch geschlossene, die gemäß der anderen Größen dringlicher sind, werden auf der »Schreibtisch«-Ansicht gelistet, der Rest in den Ansichten »Ablage« bzw. die begonnenen, aber pausierenden Aufgaben in »Schublade«.

Durch diese Größe ist bei entsprechender Gewichtung gewährleistet, dass nur ein paar wenige offene Aufgaben tatsächlich auf dem virtuellen Schreibtisch liegen und der Anwender den ganzen Rest mental ausblenden kann.

  1. voraussichtlicher relativer Bruttozeitbedarf

Diese Größe richtet sich nach dem aktuellen Erledigungsfortschritt der Aufgabe, der bisherigen Bearbeitungsgeschwindigkeit und danach, wie viele und wie lange Arbeits- und Freizeitphasen vor bzw. nach ihrer Frist liegen.

Folgendes bezieht sich auf die obigen Größen 2 bis 5.

Nur die laufende geplante Arbeitszeit ist für die Dringlichkeitsberechnung relevant. In FlowgencyTM-Terminologie unterscheiden wir diese sogenannte »Nettozeit« von der realen, der »Bruttozeit«, die auch die Freiphasen umfasst. Während der geplanten Freiphasen sind Aufgaben quasi eingefroren: Ihre zeitbezogenen Dringlichkeitswerte ändern sich nicht. Dafür steigen sie in den Arbeitsphasen entsprechend steiler an. Alle Sekunden einer Freiphase gelten gewissermaßen als identisch mit der nächsten Nettosekunde, bildlich gesprochen pendelt der Sekundenzeiger gewissermaßen zwischen zwei Strichen des Ziffernblatts.

Welche Sekunde der Realzeit in einer Arbeits- oder einer Freiphase liegt, ergibt sich aus dem Zeitmodell, das der Anwender definiert, bevor er die erste Aufgabe einträgt. Ob Feierabend, Wochenende, Urlaub oder andere Schichten/Jobs – regelmäßige wie einmalige Abwesenheiten werden unterstützt.

Auf technischer Ebene besteht ein Zeitmodell aus einer oder – bei Bedarf – mehreren Schienen. Eine Zeitschiene hat einen festen Grundrhythmus von Arbeits- und Freiphasen. Er richtet sich danach, an welchen Wochentagen der Anwender wann mit der Arbeit beginnt, wann er in die Pause(n) geht und wann in den Feierabend. Und: Sie kann Variationen eingelagert bekommen, also andere Rhythmen, die von dann bis dann anstelle des Grundrhythmus' gelten sollen. Diese Variationen können explizit für eine Schiene definiert sein oder implizit von anderen Schienen übernommen werden. Letztere Möglichkeit ist dabei experimentell, ihre Zukunft noch ungewiss.

Aufgaben sind bei Eintragung mit einer Zeitschiene zu verknüpfen, und natürlich mit einem Startdatum (voreingestellt auf den Zeitpunkt der Eintragung) und einem Fristende. Ob eine Frist »hart« ist oder »weich«, das spielt für FlowgencyTM keine Rolle. Sowohl Aufgaben als auch die Zeitschienen selbst können zu definierten Zeitpunkten auf eine andere Schiene wechseln. In Bezug auf Aufgaben sprechen wir dann von Zeitsegmentierung. Die Benutzeroberfläche sollte so gestaltet werden, dass Zeitsegmente und -schienen nur für die Zukunft eingeführt und geändert werden können, nicht rückwirkend. Das würde die Dringlichkeitsberechnung verfälschen.

Nun sorgt bekanntlich Komplexität für alles andere als Stressreduktion. Sie muss also vor dem Anwender soweit verborgen und einzelne Funktionen von ihm erst manuell freigeschaltet werden. Dies erfordert eine Benutzeroberfläche, die mit seinen Ansprüchen »wächst«. Grundsätzlich sollte das Zeitmodell ganz pragmatisch nach der Devise So fein wie nötig, aber so grob wie möglich definiert sein.

Beispiele

Im Folgenden werden die Notationen für Grundrhythmen unterschiedlicher Komplexität erläutert. In dieser Notation wird ein Grundrhythmus in der Datenbank hinterlegt. Dem weniger bedarften Anwender muss er über ein intelligentes, intuitiv zu bedienendes kleines Formular zugänglich gemacht werden, das im Hintergrund diese Notation erzeugen und wiederum interpretieren kann.

  • Mo-Fr@9-16: Arbeitswoche mit fünf Werktagen. Die Nettozeit läuft an diesen Tagen ab neun durchgängig bis … nein, genau genommen nicht bis um vier, sondern bis 16:59:59. Eine feste Mittagspause ist nicht definiert, sollte dennnoch im Rahmen der stets gebotenen Pufferzeit gemacht werden. Nun nehmen wir an, der Anwender hat mit dieser Zeitschiene eine Aufgabe verknüpft, die gestartet wird am Freitag um zwölf und bis Dienstag der Woche darauf um 15 Uhr erledigt sein muss. Ohne die beschriebene Unterscheidung zwischen Arbeits- und Freiphasen müsste FlowgencyTM am Montag früh davon ausgehen, dass das Aufwandäquivalent zur verstrichenen Echtzeit, nämlich 12 + 24 + 24 + 9 = 69 von 99 Stunden => ca. 70% erledigt ist. Aber wer kann schon 69 Stunden auf die zwei restlichen Arbeitsstunden am Freitag verdichten, zumal vor Feierabend. Dank der Logik weiß FlowgencyTM, dass er Montag um neun, quasi seit Freitag abend nur 23,6%, entsprechend fünf von 19 Nettostunden geschafft haben sollte.

  • Mo-Do@9-16,!12,Fr@9-12,!13-16: mit regelmäßiger Mittagspause von zwölf bis eine Sekunde vor eins, außer am Freitag, da macht der Anwender regelmäßig schon um eins Feierabend und verzichtet dafür auf die Mittagspause. Das Ausrufezeichen markiert Freizeiten.

  • 2n+1:Mo,Di,Do,Fr@9-16,Mi@8-11:30;Mo,Di,Do,Fr@9-16,Mi@11:30-15:00: Nicht selten müssen sich auch Büroarbeiter an Dienstpläne halten, die nach Kalenderwochen alternieren. In diesem Beispiel arbeitet der Anwender mittwochs von acht bis halb zwölf in ungeraden Kalenderwochen, in geraden dagegen hat er die folgende Schicht bis um drei. An allen anderen Tagen geht seine Arbeitszeit durchgängig von neun bis fünf. »2n+1« spezifiziert die Kalenderwochennummern im Bereich von 1 bis 53 nach ISO-Zählung an, für die der anschließend notierte Rhythmus (bis zum folgenden Semikolon oder bis zum Schluss) gilt. Statt 2 und +1 können beliebige Ganzzahlen angegeben werden, letztere auch im negativen Bereich. Ob ein Rhythmus mit »xn±y:«-Einschränkung für eine gegebene Kalenderwoche anzuwenden ist, prüft das System über (w-y)/x = n bei n∈ℤ und n≥0.

Danach muss man sich dann haargenau richten?

Abweichungen von derartigen Vorausplanungen sind realiter unvermeidlich und auch nicht weiter schlimm, solange sie sich in Grenzen halten und einander ausgleichen. Je enger sich der User an die definierte Zeiteinteilung hält, umso weniger gleiten ihm die Aufgaben während seiner Freizeit ins Rote, sorgen für umso weniger Überraschung, wenn er wieder im Büro ist und FlowgencyTM aufruft. Die Zeitlogik funktioniert für ihn also nur so gut, wie sich die geplanten und die tatsächlichen Arbeits- und Freiphasen decken.

All das ist bereits implementiert und von automatisierten Tests abgedeckt.

Normalerweise haben Zeitmanagementtools ein Modul, dass dem konventionellen Timer aus Papier nachempfunden ist. Es geht bei dieser klassischen Terminsicht vor allem darum, zeitliche Konflikte zu vermeiden. FlowgencyTM soll das Konzept weiterentwickeln und sauber in das Ganze integrieren. Hierzu habe ich schon erste Ideen.

Viele Aufgaben haben die Eigenschaft, dass sie die Arbeit an anderen Aufgaben ausschließen, mal in der ganzen, mal in einem Teil der zugeteilten Zeit. Ein Beispiel sind Vorträge oder Messepräsenzen: Bei der Vorbereitung dieser Sachen im Büro können sich noch andere Aufgaben vordrängeln, erst zum Schluss ist man ausschließlich mit ihnen befasst und dass sollte bei der Dringlichkeitsberechnung anderer anstehenden Aufgaben berücksichtigt werden. So kann der Anwender in FlowgencyTM für einzelne Aufgaben Arbeitszeitspannen reservieren, während derselben für alle anderen Aufgaben automatisch Freizeit gilt. Meist möchte man von »jetzt«, manchmal ab einem bestimmten Zeitpunkt in der Zukunft, bis Fristende der jeweiligen Aufgabe reservieren.

Auch auf Zeitschienenebene könnten Reservierungen möglich sein. Solche Reservierungen gelten nur im Verhältnis zu Aufgaben anderer Zeitschienen, das heißt, um die so reservierte Zeit konkurrieren alle Aufgaben derselben Zeitschiene.

Aufgaben zu erledigen ist die beste Möglichkeit, die Dringlichkeit einer Aufgabe zu reduzieren und sie im blauen Bereich zu halten. Der Anwender wird nicht daran gehindert, ständig an den Erledigungsfristen oder am Zeitmodell zu schrauben, um Aufgaben zu »entröten«, das ist jedoch keine zweckmäßige Verwendung des Programms.

Kleine Aufgaben bekommen einfach ein Erledigungshäkchen und verschwinden ins Archiv. Größere Vorhaben dagegen, auf jeden Fall Projekte, an denen auch Kollegen mitarbeiten, sollten in Schritten und ggf. Unterschritten/-aufgaben gegliedert werden.

Einzelne Schritte können bei Bedarf eine Reihe von Kästchen zum Abhaken bekommen, etwa wenn sie mehrmals in Folge abgearbeitet werden müssen, oder wenn sie dem Wesen nach in Phasen eingeteilt sind, die selbstverständlich sind oder sich aus der Beschreibung des Schrittes ergeben.

Schritte auf allen Ebenen können zudem in ihrem Aufwand geschätzt werden. Die Schätzung erfolgt jeweils im Verhältnis zu allen Schritten, denen sie hierarchisch über-, unter- oder beigeordnet sind. Anhand dieser Schätzungen berechnet FlowgencyTM, wie weit ein bestimmtes Erledigthäkchen den Gesamtfortschritt der Aufgabe treibt. Dieser sachliche Gesamtfortschritt ist relevant für die Berechnung der Dringlichkeitsdimensionen 3 und 5 (siehe oben).

Warum könnte man nicht einfach eingeben, wieviel Prozent von der gesamten Aufgabe man schätzungsweise erledigt hat und das gar nicht weiter von der inneren Struktur der Aufgabe abhängig machen? Das würde mich als Anwender bestimmt über kurz oder lang ans Schummeln gewöhnen. Durch die beschriebene Kopplung zwischen direkt verwandten Schritten lohnt sich eine spontane Manipulation dagegen nicht mehr, denn sie würde erneut sorgfältiges Austarieren anderer Schritte notwendig machen. Ich würde damit Zeit verschwenden, die ich besser hätte in die Erledigung der Aufgaben hätte stecken können. Die Kopplung hat natürlich vor allem den Vorteil, dass später auf tiefere Ebenen hinzugefügte Schritte sich auf den höheren Ebenen nicht mehr auf die Aufwandstruktur auswirken.

Beispiel 1

  • Aufgabentitel: "Kalkulation Auftrag Müller 25.5.2011"; Start: 30.5.11 11:30; Ende: 30. 18:00; Priorität: mittel; Zeitschiene: buero; Häkchen: 1; Erledigt: 0

Beispiel 2

  • Aufgabentitel: "Migration Excel-Kundentabelle nach SQL-Datenbank und Webapp"; Start: 21.7.2012 9:00; Ende: 15.10. 17:00; Zeitschiene: buero; Priorität: hoch; Aufwand: 1; Häkchen: 1; Erledigt: 0

    • Schritttitel: "Export nach CSV-Format"; Position: 1; Aufwand: 1; Häkchen: 1; Erledigt: 1

    • Schritttitel: "Konzeption der Datenbank, Entitäten und Relationen"; Position: 2; Aufwand: 3;Häkchen: 1; Erledigt: 0

      • Unterschritttitel: "Erstellung des SQL-Codes"; Position: 1; Aufwand: 3; Häkchen: 3; Erledigt: 2

      • Unterschritttitel: "Logik auf niedriger Ebene mittels Datenbank-Wrapper implementieren"; Position: 1; Aufwand: 2; Häkchen: 3; Erledigt: 1;

    • Schritttitel: "CSV-Daten mittels Datenbank-API verarbeiten"; Position: 3; Aufwand: 2; Häkchen: 1; Erledigt: 0;

    • Schritttitel: "Webapp erstellen unter Rückgriff auf Datenbankschnittstelle"; Position: 4; Aufwand: 6; Häkchen: 2; Erledigt: 0

      • Schritttitel: "Datensicherheits-Audit v. extern"; Position: 1; Aufwand: 2; Häkchen: 2; Erledigt: 0

Beachte die Einstellung der beiden Unterschritte der Datenbankkonzeption. Beide stehen auf Position 1. Das heißt, sie werden beide angezeigt, bis einer erledigt ist. Ersterer hat drei Aufwandsanteile, und zwei von drei Häkchen ist gesetzt. Beim zweiten Unterschritt ist es schon schwieriger: Hier ist nur eines von drei Häkchen gesetzt, aber es sind nur 2 Aufwandsanteile. Der ganze Schritt umfasst also 3+3+2 Aufwandsanteile, wovon 2 plus 2*(1/3) = 2,66 erledigt sind. Der Hauptschritt umfasst einen Aufwandspunkt, der erste Schritt ebenfalls und der vorletzte Schritt zwei Punkte, insgesamt also 4. 8 plus 4 plus die sechs vom letzten Schritt sind 18 Aufwandsanteile, von denen unsere erledigten 2,66 ca. 14,7% im Gesamtfortschritt ausmachen.

  • Schritte samt untergeordneten können nachträglich in eine (Unter-)Aufgabe mit eigener Priorität, Von/Bis-Datierung und Zeitschiene überführt werden.
  • Abhängigkeiten zwischen Aufgaben und Einzelschritten. Abhängigkeiten können wiederum Unterschritte im Kontext der abhängigen Aufgabe haben, die Aufwandschätzung wird ebenfalls noch mal gesondert vorgenommen.
  • Aufgaben können sich wiederholen. Die Zwischenzeit bis zur nächsten Wiederholung kann an den Fristbeginn, an das Fristende oder an die vollständige Erledigung des aktuellen Durchlaufs gekoppelt werden.
  • der Anwender soll voraussehen können, wie die Dringlichkeiten zu einem angegebenen Zeitpunkt sein werden in der Annahme, dass er erst dann wieder seine Arbeit aufnimmt. Wer möchte, kann sich also einfach ein 24/7er Modell definieren (Mo-So@0-23) und vor dem Start in den Feierabend der Überraschung zuvorkommen, wie rot am nächsten Morgen alles sein wird. Aber dann könnte man FlowgencyTM im Prinzip gleich vergessen. Diese Möglichkeit gibt es vor allem für den Umgang mit ungeplanten Abwesenheiten.

Rein technisch ist es egal, ob das definierte Zeitmodell von der selbstbestimmten Lebensgestaltung des Users herrührt oder er es von seinem Vorgesetzten aufoktroyiert bekommen hat. Das heißt, diktiert nicht der User der Maschine seinen Arbeitstakt, sondern hat er vielmehr das Gefühl, dass es umgekehrt läuft, so wird auch der Vorteil zum Nachteil, und FlowgencyTM nachgerade kontraproduktiv. Aus diesem Grund sollte FlowgencyTM nur freiwillig verwendet werden und es dürfen keine Nachteile durch die Nichtanwendung entstehen. Aufgaben- und Zeitmanagement muss Privatsache bleiben, egal ob FlowgencyTM oder andere Tools/Methoden verwendet werden oder gar nichts dergleichen.

Überhaupt lässt sich FlowgencyTM durch sein Funktionsprinzip als Instrument missbrauchen, um die Leistungsmessung von Angestellten zu überwachen. Das Open-Source-Prinzip – so viele ethische Vorteile es haben mag – macht es unmöglich, solche unethischen, schädlichen Bestrebungen effektiv zu verhindern. Durch ein Manifest können wir uns allenfalls davon distanzieren. Weder wird das Entwickler-Kernteam an Funktionen arbeiten, die eindeutig auf Leistungsmessung abzielen, noch die Entwicklung und die Installation entsprechender Erweiterungen irgendwie unterstützen. Sollte es je Firmen geben, die Support, Betreuung, Betrieb oder Installation von FlowgencyTM anbieten, so sei ihnen empfohlen, vorrangig Betriebsräte und Gewerkschaften als Kunden zu akzeptieren.

Nicht zuletzt gibt es ein gewisses Risiko einer zwar nicht seelischen, aber einer mentalen Abhängigkeit von FlowgencyTM. Die Software ist abstrakt gesehen eine Art von Prothese, die das Zeitdringlichkeitsgefühl ersetzt und zu einem gewissen Grad auch die Fähigkeit, Dringlichkeit und Wichtigkeit abzuwägen. Dass es dieses Gefühl überhaupt gibt und es im engeren Sinne natürlich ist, steht infrage: Zumindest wurde es erst mit der Uhr für den Einzelnen relevant, also der Zeitmessung im Alltag, mit dem Beginn des relativ jungen industriellen Zeitalters.

taskwarrior

Taskwarrior ist über Textbefehle zu bedienen. Verschiedene Kriterien und Einstellungen unterstützt, um Aufgaben übersichtlich zusammenzustellen. Dringlichkeit wird durch mehrere Größen bestimmt, die mittels Koeffizienten gewichtet werden. Urlaube können eingetragen werden. Aufgaben können im Lieblingseditor betrachtet und bearbeitet werden. Aufgaben gelten entweder als erledigt oder nicht, ein kontinuierlicher Fortschritt wird nicht erfasst.

Horde Groupware, Aufgaben-Modul

Läuft im Browser. Über ein Formular wird eine Aufgabe erstellt und bearbeitet. Aufgaben können nur nach einem Kriterium angeordnet werden, also entweder nach Priorität (5 Stufen) oder nach Stichdatum. Die geschätzte Zeit (Bedarf) einer Aufgabe ist ein Freitextfeld, wohl zur reinen Information. Es gibt keine Möglichkeit, den Erledigungsfortschritt anzugeben.