Anforderungen an die Aufgaben-Mimik:

Generelle Anforderungen:

• Es muss möglich sein, die Planung mit beliebigem, flexibel anpassbarem Detailgrad zu gestalten.

• Die Aufgabenplanung muss sich mit minimalem Aufwand bearbeiten lassen.

• Der Stand einer Aufgabenplanung muss anschaulich und übersichtlich darstellbar sein.

• Bei Änderungen der Parameter oder Randbedingungen muss eine sofortige aktualisierte Anordnung der Aufgaben erfolgen

• Die Abhängigkeiten einer Aufgabe von anderen Aufgaben, Akteuren, Orten oder Ressourcen sowie weiteren Randbedingungen muss einfach, flexibel und automatisierbar gestaltet werden können.

• Die Terminierung von Aufgaben sollte auf Basis von Prioritäten, Zeitpunkten, Orten oder anderen Anlässen möglich sein. Formal soll nicht zwischen "Termin" und "Aufgabe" unterschieden werden - das ergibt sich aufgrund der Aufgaben-Parameter.

• Es müssen mehrere ("konkurrierende") Aufgabenbereiche mit jeweils eigenen Prioritäten nebeneinander verwaltet werden können. Beispielsweise Beruf, Freizeit, Sport, Verein, etc. . Benötigte Ressourcen erfolgen über die Zuordnungen zu den Aufgaben bereichsübergreifend.

• Parameter wie beispielsweise die voraussichtlich benötigte Zeit und Mittel oder die erwarteten Erträge sollen mit "Toleranzen" (fuzzy) angegeben werden können.

• Ein "Belegungskalender" für Akteure und Resources soll (für den nächsten überschaubaren Zeitraum automatisch aktualisiert werden. Dabei sind die "weichen" (fuzzy) Angaben für diverse Steuerungsparameter einzurechnen.

• Aufgaben sollen andere Aufgaben unterbrechen können. Beispielsweise termingebundene Aufgaben mit höherer Prio, Aufgaben eines anderen Aufgabenbereichs mit ausreichend hoher Prio und Termindruck, ...

Anforderungen zu Einzelaspekten:

• Jede Aufgabe muss mindestens mit Titel, Zuordnung zum Aufgabenbereich (per [Projekt und] Rubrik?), Priorität im Aufgabenbereich, voraussichtliche Dauer, ggf. voraussichtliche Kosten versehen sein.

• Die Abhängigkeiten von Aufgaben /Zielsetzungen ist stets zu berücksichtigen. Benennung "abhängige" Aufgaben und Teilaufgaben.

• Eine Teilaufgabe kann mehreren abhängigen Aufgaben zugeordnet sein.

• Die subjektive Wichtigkeit der Aufgaben richten sich nach den MoSCoW-Regeln und werden in Prioritäten von 0.75 bis 1, 0.5 bis <0.75, 0.25 bis <0.5, 0 bis<0.25 deklariert. Die Priorität kann zeitabhängig variieren. Die Teilaufgaben werden mit der Angabe der subjektiven Wichtigkeit bei einer Aufgabe verlinkt. Die Widmung der Rückverlinkung ist derzeit noch nicht festgelegt.

• Eine "objektivierte" Wichtigkeit kann anhand der Parameter (Kosten, Erträge, ...) berechnet und beim Bearbeiten vorgeschlagen werden.

• Erledigte Aufgaben werden mit einer Wichtigkeit von (nahe) Null verlinkt.

• Die Zeitpunkte können als konkreter einzelner Zeitpunkt oder als Zeitraum mit verschiedenen Gewichtungen /Prioritäten zu verschiedenen Zeitpunkten innerhalb des Gesamtzeitraums definiert werden.

• Zeitpunkte und Zeitspannen sollen auch mit Varianzwerten versehen werden können. Damit können u.a. "weiche" (fuzzy) Termine /Erinnerungen realisiert werden. Dazu auch einige Mustervarianz-Arten zur schnellen Auswahl bereitstellen; beispielsweise [__/^], [_/^^], ...

• Aufgaben können die Durchführung anderer Aufgaben unterbrechen. Beispielsweise termingebundene Aufgaben  mit höherer Prio, Aufgaben eines anderen Aufgabenbereichs mit ausreichend hoher Prio und Termindruck, Erreichen einer Örtlichkeit, usw. .

• Aufgaben können mit Orten verknüpft werden. Beispielsweise "Kaufhaus Schneider". Neben der Liste der Aufgaben und der Zeitachsen-Darstellung sollte es auch eine Landkartendarstellung mit den eingetragenen Aufgaben-Triggern geben.

• Örtlichkeiten können klassifiziert sein. Beispielsweise "Baumärkte", Discounter, ALDI, Fahrradwerkstätten, Tankstellen, ...

• Geografische Bereiche können fix (beispielsweise Läden) oder variabel (beispielsweise Aufenthaltsorte von Personen, Fahrzeugen, Tools, ...) sein.

• Aufgaben können nicht nur zu bestimmten Zeitpunkten gestartet werden, sondern auch bei Erreichen eines geografisch definierten Bereichs.

• Anhand eines voraussichtlichen Aufenthaltspfades könnten ortsabhängige Aufgaben zeitig in den Terminkalender eingebaut werden. Zum Aufenthaltspfad sollte als Fortbewegungskategorie die Art des Verkehrsmittels (zu Fuß, Roller, Fahrrad, Bus, Bahn, Auto, ...) eingetragen sein

• Aufgabenbereiche unterliegen Randbedingungen. Beispielsweise minimaler bis maximaler Zeitanteil pro Tag, Woche, Monat, Jahr; Einschränkungen der Zeitbereiche am Tag, Wochentag, in der Woche, ...;

• Aufgaben können auch auf Zeitbereiche eingeschränkt werden. Beispielsweise wochentäglich 9 bis 17 Uhr, nur am Wochenende tagsüber, nur bei Tageslicht, nur am Anfang eines Monats, etc.

• Aufgaben können mit Randbedingungen während der Durchführung versehen werden. Beispielsweise alle max. 2 Stunden eine (Rast- /Tank) Pause bei einer längeren Autofahrt.

• Aufgaben können ggf. an weitere Randbedingungen gebunden werden. Beispielsweise Wettererscheinungen, Mindest- oder Höchsttemperatur, ...

• Aufgaben können Einzelaktionen oder wiederholte /mehrfache Aufgaben sein. Beispielsweise zu jedem Ersten des Monats.

• Aufgaben oder eine Auswahl von ihnen können auf verschiedene Arten visualisiert werden

• Eine Liste der Aufgaben nach voraussichtlichem Aufgaben-Beginn (siehe unten). Sowohl pro Aufgabenbereich als auch bereichsübergreifend.

• Neben einer Listen-Darstellung auch eine Darstellung mit Zeitachse anbieten.

• Das Eintragen, Ändern und Entfernen von Aufgaben sowie Änderungen der Parameter muss mit mit geringstem Aufwand komfortabel durchführbar sei

• Bei den Listen- oder Zeitachsen-Darstellungen sollen die Prioritäten, Zeiten und Zeitspannen schnell und einfach änderbar sein. Die Darstellungen werden sofort aktualisiert.

• Eine unerwartete /ungeplante /spontane Aufgaben soll jederzeit kurzfristig nachgetragen werden können.

• Der (Termin-) Belegungskalender eines Akteurs oder Ressource wird bei Betroffenheit jederzeit bei irgendwelchen Änderungen aktuell gehalten. Wenn es bei der Zuordnung irgendeinen nicht automatisch lösbaren Konflikt gib, wird dieses dem "Bearbeiter" der Parameter-Änderung sofort mitgeteilt.

• Wenn Aufgaben mit einem fixen Zeitpunkt oder einer Deadline spätestens zu einem bestimmten Zeitpunkt gestartet werden müssten, aber aufgrund mangelnder Priorität nicht zum Zuge kommen, werden sie als "gestrichen" eingetragen. Falls machbar, sollte bereits zeitig vor der drohenden Streichung eine Warnung dargestellt werden.

• Ebenso wie die Aufgaben(-Dokumente) werden Akteure und Ressourcen durch Dokumente repräsentiert, die entsprechend gewidmeten Rubriken (Klassifizierungen) zugeordnet sind. Die Akteur- und Ressource-Dokumente besitzen art-typische weitere Parameter - genauso wie die Aufgaben-Dokumente. Auch Ressourcen können in Teil-Ressourcen unterteilt sein(?).

• Akteure können als "Rollen" eines Individuums verstanden werden und können auf "Unter-Rollen" verweisen.

• Akteuren/Rollen können Verantwortungen für Aufgaben zugewiesen werden. Aus diesen Rollen leitet sich der "Aufgabenkalender" eines Akteurs ab. Gleichzeitig kann ein Akteur aber auch "buchbare Ressource" für eine Aufgabe eines anderen Verantwortlichen sein, die dann im Aufgabenkalender ebenfalls berücksichtigt werden - dabei ist aber die Gesamt-Belegung aller Rollen eines Akteurs zu beachten.

Beispiel für eine Aktions- und Termine-Liste:

{ Nach Beginn der Aktion bzw. des Termins sortiert. Die Aufgabenliste soll im Wesentlichen eine "Orientierungshilfe" sein, die die konkreten Entscheidungen über die tatsächlich durchzuführenden Aktionen unterstützt - aber nicht "erzwingt"! }

1. Tag:
1. 🕘 🚧 Biz-Aktion 1 <Zeitraum🕥>
   {steht ganz vorne, weil aktuell die höchste Biz-Prio; voraussichtlich keine Unterbrechung; Dauer ca. 90Min}
2. 🕥 ⏸🚧 Biz-Aktion 2 <Zeiträume>
   {Hier trotz eingetragener mäßiger Priorität platziert, weil sie Voraussetzung für Biz-Aktion 3 ist; wird voraussichtlich durch Biz-Termin 1 unterbrochen}
3. 🕦..🕧 ⏰ Biz-Termin 1 <Zeitraum>
   {fällt in den Zeitraum von Biz-Aktion 2, mit etwas variablem Beginn; mit ausreichender Prio;}
4. 🕞 ⏸🚧 Biz-Aktion 3 <Zeitraum>
   (hier platziert, weil sie abhängig von Biz-Aktion 2 sowie Voraussetzung für Biz-Aktion 4 ist; wird voraussichtlich von Soc-Aktion 1 unterbrochen}
5. 🕔 ⏰👨🏼‍🤝‍👨🏼 Soc-Aktion 1 <Zeitraum>
   {unterbricht Biz-Aktion 3 weil Biz-Aktion 3 nicht mehr innerhalb des erlaubten Tageszeitraum-Fensters fortgeführt werden darf: "Feierabend!"}
2. Tag:
1. 🕘 ⏸🚧 Fortsetzung von  Biz-Aktion 3 <Zeitraum>
   (hier platziert, weil sie abhängig von Biz-Aktion 2 sowie Voraussetzung für Biz-Aktion 4 ist; wird voraussichtlich von Soc-Aktion 1 unterbrochen}
2. 🕜 ⏸🚧 Biz-Aktion 4.
   {hier platziert wegen zweithöchster Biz-Prio; ist abhängig von der Biz-Aktion 3; wird voraussichtlich von Biz-Termin 2 und Soc-Termin 1 unterbrochen; }
3. 🕐 ⏰ Biz-Termin 2 <Zeitraum>
   {hier platziert, weil voraussichtlich während des Zeitraums der Biz-Aktion 4 fällig}
4. 🕙 ⏰ 👨🏼‍🤝‍👨🏼 Soc-Termin 1 
   {hier platziert, weil sehr hohe Priorität; unterbricht ggf. Biz-Aktion 4 }
3. Tag:
1. 🕘 🚧 Biz-Aktion 5:
   {hier platziert, weil dritthöchste Biz-Prio; ohne vorausgesetzte andere Aktion; eventuell noch durch Biz-Termin 3 unterbrochen}
2. 🕜..🕟 ⏰ Biz-Termin 3 mit verschiebbarer Anfangszeit und mäßiger Priorität
   {könnte eventuell noch gestrichen /abgesagt werden, wenn die Priorität nicht hoch genug ist}
3.  . . .

Möglicher Datensatz:

• Standard: Titel der Aktion und was sonst noch zu jedem Dokument möglich ist.
• fieldfActivity: Zuordnung zu einem Aufgabenbereich
• prio: Priorität beim Aufgabenbereich
• startAt, deadline: Beginnzeitpunkt und Endzeitpunkt  oder
• + duration: Entweder Beginnzeitpunkt oder Endzeitpunkt mit Zeitdauer oder
• duration: Nur die (geplante oder geschätzte) Zeitdauer
• costs(?): Weitere Aufwände für die Aktion (beispielsweise Kosten)
• place: Orts- Pfad- oder Bereichsangabe
• responsible: Verantwortliche(r) Akteur
• participants: Beteiligte /Mitwirkende
• contact: Kontaktadresse
• (dependencies?) Abhängige Aktionen
• (preliminaries?) Vorausgesetzte Aktionen
• (?) Adressat der Fertigmeldung
• ----------------------- neuer:
• bookingList: Belegungsliste (Sortierte Liste mit Reservierungs-Einträgen)
• located: Optionale Liste möglicher Lokationen, an denen die Aufgabe durchgeführt werden kann
• requiredResources: Liste benötigter Ressources (wer/was & wieviel davon)