Prioritering

Het bord ordent werk op twee dimensies: belangrijkheid en urgentie (Het bord). Geen van beide is een getal dat je invult. Het zijn uitkomsten — het gewogen gemiddelde van een handvol factoren die er samen een oordeel van maken.

Dat onderscheid is het hele idee. Een taak "een 7" geven zegt niets terug: je weet volgende week niet meer waarom het een 7 was, en je kunt er niet met jezelf over van mening verschillen. Een taak die hoog scoort omdat hij weinig kost, weinig tijd vraagt en over vier dagen af moet, is een taak waarover je een gesprek kunt voeren.

Deze pagina beschrijft het rekenwerk dat beide dimensies delen. Waar de twee inhoudelijk uit bestaan, staat op de twee pagina's ernaast.

De onderdelen

• Belangrijkheid — wat een taak oplevert, wat hij voorkomt, en wat hij kost aan geld en inzet.
• Urgentie — hoeveel haast het heeft, en waarom die dimensie nog het minst is uitgewerkt.

De formule

Elke factor krijgt een subscore van 1 t/m 10 — per taak, en met dezelfde factorenlijst ook per project (Attributen van gebied, categorie, project en taak). Elke factor telt mee volgens een gewicht dat je zelf instelt:

dimensiescore = Σ (gewicht_i × effectieve_subscore_i) / Σ (gewicht_i)

Zolang alle subscores tussen 1 en 10 liggen en alle gewichten niet-negatief zijn, valt de uitkomst automatisch ook weer tussen 1 en 10 — ongeacht hoeveel factoren er zijn. Je kunt dus factoren toevoegen, verwijderen of van gewicht laten veranderen zonder dat de schaal ooit aangepast hoeft te worden. De volledige achtergrond bij die eigenschap staat in Ranking.

Een factor die de andere kant op werkt — hoge kosten maken een taak niet belangrijker — gaat geïnverteerd de formule in:

effectieve_subscore = inverteren ? (11 − subscore) : subscore

Dat is de reden dat inverteren via 11 − subscore gaat en niet via een negatief gewicht: een negatief gewicht breekt de 1–10-garantie, deze omkering niet.

Alle factoren op een rij

Dimensie	Factor	Richting	Subscore uit
Belangrijkheid	Toegevoegde waarde	Normaal	Schuif
	Risico-mitigatie	Normaal	Schuif
	Kosten	Geïnverteerd	Trap op de geschatte kosten
	Gevraagde inzet	Geïnverteerd	Trap op de geschatte uren
Urgentie	Persoonlijk belang	Normaal	Schuif
	Verplichting richting klant	Normaal	Schuif
	Deadline	Normaal	Trap op de dagen tot de datum

Dit is nadrukkelijk een startset — de lijst is bedoeld om aan te vullen en bij te schaven zodra je in de praktijk merkt dat iets ontbreekt of niet klopt. Vanaf fase 1 kan dat zonder codewijziging (zie Fasering).

Geoordeelde en afgeleide factoren

De laatste kolom hierboven verdeelt de factoren in twee soorten, en dat verschil is belangrijker dan het lijkt.

Een geoordeelde factor vul je zelf in, met een schuif van 1 tot 10. Of een taak veel toevoegt is een mening, en een mening hoort met de hand ingevoerd te worden.

Een afgeleide factor vul je niet in. Die leest een getal dat de taak toch al heeft — het bedrag dat hij naar verwachting kost, het aantal uren dat hij vraagt, het aantal dagen tot zijn einddatum — en rekent dat om naar dezelfde 1–10-schaal. Je vult het getal in; de subscore volgt.

Dat scheelt niet alleen invoerwerk. Het maakt de score reproduceerbaar: twee taken van € 2.500 krijgen dezelfde kostenscore, altijd, ook als je ze een half jaar uit elkaar hebt opgevoerd en er die dag anders in zat.

De trap

De omrekening gebeurt met een trap: een lijstje treden dat zegt tot welke waarde welke subscore hoort. Eén leesregel, voor alle afgeleide factoren:

De treden lopen van laag naar hoog. De eerste trede die de waarde niet overschrijdt bepaalt de subscore. Is de waarde hoger dan elke trede, dan geldt de score die onderaan staat.

Een trap van drie treden voor de geschatte kosten leest dus zo:

Bedrag	Subscore
t/m € 500	2
t/m € 2.500	5
t/m € 10.000	8
daarboven	10

Een taak van € 2.500 valt op de tweede trede en krijgt een 5; € 2.500,01 valt op de derde en krijgt een 8.

Een taak zonder ingevuld getal krijgt de neutrale subscore 5 — niet de laagste. Niets ingevuld is geen oordeel, en een lege schatting mag geen oordeel voorwenden. Dat is dezelfde regel als voor een taak zonder einddatum, en hij is niet zonder gevolgen: zie Wat aan de deadline-trap nog wringt.

Waarom een trap en geen formule

Een vloeiende formule zou soepeler lopen: geen sprongen, elke euro telt een beetje mee. Toch is het een trap geworden, en dat is een bewuste ruil.

Bij een trap kun je aanwijzen waarom een kaart bewoog. "Deze taak ging over de grens van veertien dagen" is een zin die je kunt navertellen. Bij een curve kun je alleen zeggen dat de uitkomst nu eenmaal iets anders is. Dat is precies wat Kaarten verslepen van het model vraagt: een bord waarvan de bewegingen te verantwoorden zijn.

De prijs is dat de waarde binnen een trede stilstaat en op de overgang in één keer een heel punt springt. Dat valt mee in de uitkomst — een dimensiescore is het gemiddelde van meerdere factoren, dus één punt op één factor van drie verschuift de dimensie met ⅓ punt.

Instelbaar per factor

Bron én trap zijn per factor in te stellen, bij Beheer › Factoren en gewichten. Per factor kies je:

• de bron: handmatig (een schuif), of een van de getallen die een taak kent — dagen tot de einddatum, geschatte kosten, geschatte uren;
• de treden: zoveel als je zinvol uit elkaar kunt houden, met een bovengrens en een subscore per trede;
• de score daarboven: wat er geldt als de waarde hoger is dan elke trede;
• het gewicht en of de factor geïnverteerd meetelt.

De richting van een trap kies je zelf, en dat is de plek waar je jezelf kunt verrassen. Bij Deadline geeft wéinig dagen een hoge score, want dichtbij is urgent. Bij Kosten geeft véél geld een hoge score, en zorgt het vinkje geïnverteerd ervoor dat het alsnog omlaag telt. Zo dekt één leesregel alle factoren, maar staat de richting op twee plekken: in de trap en in het vinkje.

Na het opslaan worden alle taken en projecten opnieuw doorgerekend.

Vastgestelde ontwerpkeuzes

Gewichten zijn globaal. Eén set gewichten voor het hele bord, niet per gebied. Dat houdt het model uitlegbaar en voorkomt dat een taak van gebied wisselt en daardoor spontaan van positie verspringt. Gewichten per gebied zijn hiermee als wens vervallen; mocht het ooit terugkomen, dan is het een kolom op de factor-tabel met een gebied-koppeling.

Geoordeelde subscores vul je in eerste instantie zelf in. Handmatig per factor, zodat je gevoel voor het model krijgt en kunt zien of de uitkomst klopt. Pas in de fase waarin taken per e-mail binnenkomen (fase 4) doet de AI een voorstel per factor, dat je in de concept-flow corrigeert voordat de taak op het bord komt. Het veld task_factor_score.source legt vast of een subscore handmatig, door AI of automatisch is bepaald.

Een nieuwe factor krijgt een neutrale subscore. Voeg je een factor toe nadat er al taken op het bord staan, dan hebben die taken nog geen subscore voor die nieuwe factor. Ze krijgen standaard een 5 totdat de factor alsnog wordt ingevuld, zodat de dimensiescore niet abrupt verspringt.

Een nieuwe taak begint op de scores van zijn project. Een project wordt op dezelfde factoren gerangschikt als een taak (Attributen van gebied, categorie, project en taak), en de taken eronder lijken doorgaans op het project waar ze bij horen. De schuiven van een nieuwe taak staan daarom niet neutraal maar op de subscores van het gekozen project; je verzet alleen wat voor deze taak afwijkt. Er wordt niets overgeërfd of gekoppeld, alleen een beginstand overgenomen. Wat daarna in de taak staat is van de taak.

Drie afspraken houden dat voorspelbaar:

• Alleen bij een nieuwe taak. Een bestaande taak houdt zijn eigen subscores; die zijn ooit ingevuld en worden nooit door het project overschreven.
• Kies je in het formulier een ander project, dan volgen de schuiven die je nog niet hebt aangeraakt. Een schuif die je zelf hebt verzet blijft staan: die zegt iets over déze taak en weegt zwaarder dan de standaard van een project.
• Afgeleide factoren doen niet mee. Die volgen uit de getallen van de taak zelf — zijn eigen einddatum, zijn eigen begroting — niet uit die van het project.

Doet de AI een voorstel voor een taak, dan winnen de scores uit dat voorstel: het model heeft naar deze taak gekeken. Factoren waar het voorstel niets over zegt vallen terug op het project.

Wanneer er herberekend wordt

Een trap zegt wat de subscore zou moeten zijn; hij wordt pas werkelijkheid als er herberekend wordt. Dat gebeurt op vier momenten:

• bij het opslaan van een taak of project;
• bij het wijzigen van een factor — een ander gewicht of een andere trap verschuift alle scores tegelijk, dus dan gaat het hele bord langs;
• met de knop Herberekenen in het beheer, voor als je het niet wilt afwachten;
• dagelijks, via een cronjob.

Die laatste doet er maar voor één factor werkelijk toe: de deadline. De andere drie momenten hebben een aanleiding, en het verstrijken van een dag heeft dat niet — een bedrag verandert niet vanzelf, een aantal dagen wel. In het prototype is dat bin/recalculate.php, bedoeld om 's nachts te draaien. Het script is idempotent: twee keer draaien op dezelfde dag verandert niets, en een overgeslagen dag wordt bij de eerstvolgende run vanzelf ingehaald, omdat de subscore uit de datum van vandaag volgt en niet uit hoe vaak er gerekend is.

Draait die cronjob niet, dan staat de deadline-factor stil op de waarde van de dag waarop de taak voor het laatst is aangeraakt. Het bord ziet er dan ogenschijnlijk normaal uit, maar het veroudert stilletjes — precies het soort fout dat je niet opmerkt.