Workflow van taken
Vierde functie-idee na v0.8: één expliciete toestandsmachine voor de taak, in plaats van drie statussen zonder regels plus een handvol velden die feitelijk ook een toestand zijn.
Waarom de status niet volstaat
De taak kent nu drie statussen: open, in behandeling en afgerond (Taakbeheer). Daarnaast zijn er in de loop van dit document allerlei toestanden bij gekomen die géén status heten maar het wel zijn:
- Concept — een taak uit e-mail die nog bevestigd moet worden (Concept-flow).
- Uitgesteld — een taak met een
snoozed_untilin de toekomst (Overige attributen), die tijdelijk niet op het bord hoort. - Doorgeschoven — sinds Toewijzing aan personen kan een taak bij een ander liggen, en dan wacht jij ergens op.
Zolang die toestanden in losse velden zitten, moet elk scherm ze opnieuw uitrekenen ("wel status open, maar snoozed_until ligt in de toekomst, dus tóch niet op het bord"), en kunnen ze elkaar tegenspreken. Eén veld met een vaste waardenlijst en vastgelegde overgangen maakt daar een einde aan: een taak is altijd precies één ding, en per toestand staat vast waar hij verschijnt.
De winst zit niet in de administratie maar in het overzicht: taken die wegzakken doen dat meestal niet omdat ze vergeten zijn, maar omdat ze in een tussenstand hangen waar niemand naar kijkt — wachtend op antwoord, half begonnen, doorgeschoven en nooit teruggekomen. Een expliciete workflow maakt die tussenstand zichtbaar en bewaakbaar (Bewaking: de tussenstanden zichtbaar houden).
De toestanden
| Sleutel | Op het scherm | Betekenis | Op het bord? |
|---|---|---|---|
draft | Concept | Uit e-mail binnengekomen, nog niet bevestigd (Concept-flow) | Nee, in de inbox-weergave |
open | Open | Klaar om opgepakt te worden | Ja |
in_progress | In behandeling | Je bent er mee bezig | Ja, met markering |
waiting | In afwachting | Je kunt niet verder: ligt bij een ander of je wacht op antwoord | Ja, gedempt |
snoozed | Uitgesteld | Bewust even weg tot een datum | Nee, wel in de agenda |
completed | Afgerond | Klaar; completed_at gevuld | Nee |
cancelled | Vervallen | Bewust niet gedaan | Nee |
Twee toestanden verdienen toelichting.
In afwachting is de belangrijkste toevoeging. Een taak die bij iemand anders ligt of waarop je antwoord afwacht, is niet open (je kunt er niets aan doen) en niet uitgesteld (je hebt er niet voor gekozen). In afwachting heeft daarom twee extra gegevens: waarop of op wie je wacht, en vanaf wanneer. Bij doorschuiven naar een ander (Doorschuiven naar iemand anders) mag de afzender de taak desgewenst als wachtpost op zijn eigen bord houden — dan staat het origineel bij de ander en heeft de afzender een gedempte kaart met "ligt bij [naam]".
Vervallen is bewust géén synoniem van afgerond. Voor de terugblik is het verschil tussen "gedaan" en "besloten om niet te doen" het interessantste gegeven dat het bord kan opleveren — zeker in kwadrant IV, dat Elimineren heet (De twee dimensies). Wie alles wat hij niet doet afvinkt als afgerond, gooit precies die informatie weg.
Wat er al gebouwd is
Van deze lijst bestaat waiting inmiddels wel: In afwachting is als
gewone taakstatus toegevoegd, naast open, in behandeling, afgerond, niet
uitgevoerd en concept. Hij telt mee als open status, zodat een taak waarop je
wacht op het bord blijft staan en in Overzicht > Projecttaken een eigen kolom
krijgt om naartoe te slepen.
Op het bord staan die taken niet tussen de rest. Kwadrant III heet Afhandelen / In afwachting, en leest sindsdien als twee lijsten in één: boven een dunne streep wat je zelf afhandelt, daaronder waar je op wacht — dezelfde opzet als de voorraad-items onderaan kwadrant IV (Voorraadlijst). Zo blijft zichtbaar dat er iets ligt, zonder dat het je werklijst vult. In de andere drie kwadranten is er geen scheiding: daar is een wachtende taak zeldzaam genoeg om geen eigen lijst te verdienen.
De rest van deze pagina is nog plan: de vastgelegde overgangen, waiting_for
en waiting_since, de bewaking van tussenstanden en de gedempte weergave.
Wat er nu is, is één extra waarde in dezelfde vrije statuslijst — geen
toestandsmachine. Let ook op het verschil in naamgeving: waar deze pagina
cancelled (Vervallen) noemt, heet de bestaande status not_done (Niet
uitgevoerd).
Toegestane overgangen
Wat opvalt aan dit plaatje is vooral wat er niet in staat: elke weg naar
completed loopt via een toestand waarin iemand er werkelijk mee bezig is
geweest, en draft is de enige toestand waar je nooit naar terug kunt. Een
concept dat je hebt bevestigd, is een gewone taak — het bewijsstuk van de
binnenkomst blijft in de e-mailinbox (Entiteiten en relaties) bewaard.
Automatische overgangen
Drie overgangen gebeuren zonder dat iemand iets aanklikt, en alle drie via de cronjob die het ochtendadvies al draait (AI-advies):
| Overgang | Wanneer |
|---|---|
snoozed → open | De terugkomdatum is bereikt |
waiting → open | De ander schuift de taak terug (Doorschuiven naar iemand anders) |
open/in_progress → geen | Een verstreken deadline verandert de toestand niet, alleen de urgentiescore (De deadline is geen statisch getal) |
Die laatste regel is een keuze: een taak die over de datum gaat, is niet ineens een ander soort taak. Het model heeft daar al een mechanisme voor — de deadline-factor loopt vanzelf op — en een extra toestand "te laat" zou hetzelfde nog eens zeggen, maar dan zonder gradatie.
Wat elke toestand betekent voor de schermen
| Toestand | Bord (h. 3) | Agenda (h. 13) | AI-advies (AI-advies) |
|---|---|---|---|
draft | Niet | Niet | Alleen als telling: "3 concepten wachten" |
open | Ja | Ja | Volledig meegewogen |
in_progress | Ja, gemarkeerd | Ja | Voorrang: eerst afmaken wat loopt |
waiting | Gedempt | Alleen op de opvolgdatum | Alleen als bewaking (Bewaking: de tussenstanden zichtbaar houden) |
snoozed | Niet | Als terugkeermarkering (Wanneer is een taak "actief in een periode") | Niet |
completed | Niet | Alleen met "toon afgeronde" | Als terugblik |
cancelled | Niet | Niet | Niet |
Voor de drukte-indicatie in de agenda (Drukte zichtbaar maken) tellen alleen open en
in_progress mee: een dag vol wachtposten is geen drukke dag.
Bewaking: de tussenstanden zichtbaar houden
Een expliciete toestand is pas nuttig als iemand ernaar kijkt. Daarom krijgt het ochtendadvies er een vast onderdeel bij:
- Taken die langer dan een ingestelde termijn
waitingstaan — je wacht al drie weken op dat antwoord. - Taken die langer dan een ingestelde termijn
in_progressstaan — half begonnen en blijven liggen. Dit is de tegenhanger van "taken die wegzakken" uit AI-advies, maar dan voor taken die juist wél zijn aangeraakt. - Doorgeschoven taken die bij een ander blijven hangen (Doorwerking naar advies, agenda en e-mail).
De termijnen zijn instellingen, geen vaste getallen in de code; welke waarden en of ze per taak instelbaar moeten zijn, is een open punt (Bewakingstermijnen).
Overwogen en afgevallen: maar één taak tegelijk in behandeling. Dat dwingt focus af en is in kanban-systemen gebruikelijk, maar het is een regel over hoe je hoort te werken, en dit bord bemoeit zich met wat belangrijk is, niet met hoe je je dag indeelt. De bewaking hierboven doet hetzelfde werk zonder je iets te verbieden.
Gevolgen voor het datamodel
De workflow zit vrijwel geheel in bestaande velden: task.task_status krijgt
de vaste waardenlijst uit De toestanden — Engelse sleutels in de database, Nederlandse
labels op het scherm, conform de afspraak in Fase A — het lokale prototype. Verder:
| Tabel | Wijziging |
|---|---|
task | waiting_for (tekst, nullable) en waiting_since (datum, nullable) voor de wachtstand |
task | snoozed_until blijft, maar is voortaan alleen gevuld bij status snoozed |
task_status_log | Nieuwe tabel: task_id, from_status, to_status, person_id, occurred_at, note |
waiting_for is vrije tekst en geen verwijzing naar een persoon: je wacht net
zo vaak op een leverancier, een besluit of een levering als op een collega.
Wacht je op iemand die wél in het systeem staat, dan is dat een doorgeschoven
taak en legt task_transfer (Gevolgen voor het datamodel) het vast.
Drie logboeken. Er zijn er nu drie in wording: scorewijzigingen (Taakbeheer),
overdrachten (Gevolgen voor het datamodel) en statuswijzigingen (hierboven). Inhoudelijk zijn dat
drie soorten van hetzelfde — "er is iets met deze taak gebeurd, door wie en
wanneer" — en ze zouden samen kunnen in één task_event-tabel met een
type-kolom. Dat is aantrekkelijk en het is niet gedaan: drie smalle tabellen
met betekenisvolle kolommen zijn eenvoudiger te bevragen dan één brede tabel
met een payload-veld. Wel iets om opnieuw te bekijken zodra er een vierde
soort gebeurtenis bij komt.
Bewust buiten scope
- Zelf statussen kunnen aanmaken. De lijst uit De toestanden staat vast in de code, net als de paginasleutels voor helpteksten (Helpteksten in de rechterkolom). Een beheerscherm voor statussen betekent dat de code niet meer op een vaste verzameling kan rekenen, en dat is een grote prijs voor een lijst die zelden verandert.
- Goedkeuringsstappen. Een taak die pas afgerond is als iemand anders het goedkeurt: dat is projectmatig werken, en daarvoor is dit bord niet.
- Doorlooptijden en statistiek. Het logboek maakt het mogelijk (hoe lang staat een taak gemiddeld te wachten), maar rapportage is een eigen onderwerp.
Plaats in de fasering
Toegevoegd als fase A7, direct na de toewijzing uit Toewijzing aan personen, omdat de wachtstand daarop leunt: "ligt bij een ander" veronderstelt dat er anderen zijn. Zonder Toewijzing aan personen is het alsnog bruikbaar — je wacht dan op dingen in plaats van op mensen — maar dan mist de helft van de reden om het te bouwen.
Versie 0.11 voegt twee samenhangende hoofdstukken toe: toewijzing aan personen (15) en de workflow van taken (16). Samen maken ze expliciet wie een taak doet, wie verantwoordelijk is voor het project, en in welke toestand een taak verkeert — inclusief de tussenstanden waarin werk gewoonlijk blijft liggen. Toewijzing aan personen is het eerste idee dat verplichte velden aan bestaande tabellen toevoegt; de eerstvolgende stap blijft niettemin fase A3: het AI-advies, zodat de derde basisfunctie uit Visie lokaal beproefd kan worden.