Toewijzing aan personen

Derde functie-idee na v0.8: taken horen bij een persoon, projecten hebben een eigenaar, en een taak kan worden doorgeschoven naar iemand anders.

Van impliciet naar expliciet

Vandaag is de toewijzing er wel, maar nergens vastgelegd: elke taak is van degene die het bord gebruikt. In het prototype is dat zelfs letterlijk niemand, want fase A kent geen inlog (Fase A — het lokale prototype). Zolang je alleen werkt, valt dat niet op. Zodra er een tweede persoon bij komt, gaat het meteen mis: je kunt niet zien van wie een taak is, niet zien wat je aan iemand hebt gegeven, en niet zien wat er op jouw naam is gezet.

Er zit bovendien een gat in het model dat er vanaf het begin in zit. Kwadrant III heet Delegeren/afhandelen (De twee dimensies), maar er is niets om mee te delegeren — je kunt een taak in dat kwadrant zetten en er vervolgens niets mee. Dit hoofdstuk vult dat in.

Wat "persoonlijk" voortaan betekent. Visie noemt Management Board een persoonlijk takenbord, en dat blijft zo — maar preciezer geformuleerd: elk bord heeft één eigenaar en toont diens taken. Het is geen teamboard waar iedereen naar hetzelfde scherm kijkt. Taken kunnen wél van hand tot hand gaan, en dan verhuizen ze van het ene persoonlijke bord naar het andere.

Persoon als eigen entiteit

Een persoon wordt een eigen tabel, geen Joomla-gebruiker. Twee redenen:

• Het prototype kent geen gebruikers. Fase A heeft bewust geen inlog (Fase A — het lokale prototype). Met een eigen tabel kun je toewijzing nu al bouwen en beproeven: er is één persoon die "ik" is (ingesteld in config.php), en daarnaast maak je de anderen gewoon aan.
• Niet iedereen aan wie je iets geeft, is een gebruiker. Een collega die het systeem niet gebruikt, een partner, een externe — die moeten een taak kunnen krijgen zonder account. Dat is dezelfde afweging als in Ontwerpkeuzes en aandachtspunten: eigen tabellen, expliciet en volledig uit dit document te lezen.

Voor fase B krijgt de persoon een optionele koppeling naar een Joomla-gebruiker (joomla_user_id). Wie is ingelogd, bepaalt dan welke persoon je bent; personen zonder koppeling blijven bestaan als iemand aan wie je taken kunt toewijzen zonder dat hij kan inloggen.

Een persoon heeft een naam, een e-mailadres, een kleur of initialen voor de weergave, en een status actief/inactief uit de bestaande statuslijst (Entiteiten en relaties). Inactief betekent: verdwijnt uit de keuzelijsten, maar blijft staan bij alles wat al aan hem is toegewezen.

Twee rollen: uitvoerder en eigenaar

Rol	Waar	Verplicht	Betekenis
Uitvoerder	Taak (task.assignee_id)	Ja	Wie de taak gaat doen. Op wiens bord de kaart staat
Eigenaar	Project (project.owner_id)	Ja	Wie verantwoordelijk is voor het geheel, ook als de losse taken bij anderen liggen

Beide zijn verplicht, en één taak heeft altijd precies één uitvoerder. Meerdere uitvoerders per taak zijn bewust uitgesloten (Bewust buiten scope): een taak met twee namen erop is een taak waar niemand zich verantwoordelijk voor voelt, en bovendien zou de kaart dan op twee borden staan met twee verschillende scores.

Standaardwaarden bij het aanmaken. Een nieuwe taak wordt toegewezen aan jezelf, ook in een project van iemand anders — je maakt tenslotte een taak omdat jij iets ziet dat moet gebeuren. De projecteigenaar staat er wel zichtbaar bij, zodat duidelijk is in wiens straatje je werkt. Een nieuw project krijgt jou als eigenaar. Taken die per e-mail binnenkomen (hoofdstuk 9) worden toegewezen aan degene op wiens adres ze binnenkomen.

Doorschuiven naar iemand anders

Doorschuiven is één handeling op de taak: kies een persoon, eventueel met een toelichting, en de taak verhuist. De taak verdwijnt van jouw bord en verschijnt op dat van de ander, gemarkeerd als nieuw binnengekomen totdat hij hem heeft gezien.

Direct, niet in overleg. Er is geen accepteren-stap: de taak ligt meteen bij de ander, met de mogelijkheid om hem terug te leggen bij degene die hem stuurde. Een aanbieden-en-accepteren-flow zoals bij binnenkomende e-mail (Concept-flow) is hier bewust niet overgenomen: die bestaat omdat e-mail van buiten komt en niet te vertrouwen is, terwijl doorschuiven gebeurt tussen mensen die elkaar kennen. Terugleggen is de correctie, en die is één klik. Of dat in de praktijk volstaat, is een open punt (Doorschuiven: direct of met accepteren?).

Wat er met de scores gebeurt. Dit is de subtiliteit van dit hoofdstuk. Belangrijkheid en urgentie zijn persoonlijke oordelen — er zit zelfs een factor Persoonlijk belang in het model (Alle factoren op een rij) — en die oordelen zijn niet zonder meer van de volgende persoon. Tegelijk is alles weggooien onzin: jouw inschatting is het beste startpunt dat er is. De afspraak:

• De factor-subscores gaan mee, maar worden gemarkeerd als overgenomen (task_factor_score.source = 'inherited'), met de naam van degene van wie ze komen.
• De ontvanger ziet op de kaart dat de score nog niet van hem is, en bevestigt of corrigeert hem — dat laatste kan met één sleepbeweging (Kaarten verslepen).
• De handmatige bijstelling uit Van doelscore naar factoren: de bijstelfactor vervalt bij overdracht. Die duw was het oordeel van de vorige uitvoerder over zijn eigen bord; hem meenemen zou betekenen dat een vreemde correctie stilzwijgend blijft doorwerken.
• De deadline-factor verandert niet: die is een feit, geen mening.

Geschiedenis. Elke overdracht wordt vastgelegd — van wie, naar wie, wanneer, met welke toelichting. Zo is achteraf te zien waar een taak allemaal is geweest, en wordt zichtbaar of er taken zijn die rondgaan zonder ooit gedaan te worden.

Wat het bord toont

Het bord toont standaard jouw taken. Daarnaast zijn er twee extra weergaven, als filter naast gebied, categorie en project:

• Uitstaand bij anderen — taken die jij hebt doorgeschoven en die nog niet af zijn. Dit is de weergave die kwadrant III bruikbaar maakt: delegeren is pas delegeren als je het ook kunt volgen.
• Alles — het bord van de hele installatie, met de persoon als filter.

Op de kaart zelf komt alleen een persoon te staan wanneer die afwijkt: is de taak van jou, dan geen label. Dat is dezelfde afweging als in De kaart op het bord — een druk bord moet scanbaar blijven, en een naam die overal hetzelfde is, is geen informatie. Bij een afwijking verschijnt een klein rondje met de initialen in de kleur van de persoon.

Doorwerking naar advies, agenda en e-mail

• AI-advies (AI-advies) wordt per persoon opgesteld: het gaat over jouw taken, en het ochtendbericht gaat naar jouw adres. Het advies krijgt er één taak bij: melden wat er nieuw op je bord is gezet door een ander, en wat er te lang uitstaat bij iemand anders.
• Notificaties bij overdracht lopen bewust via dat ochtendbericht en niet via een losse mail per gebeurtenis. Een persoonlijk werkbord dat de hele dag mailt, is precies het soort systeem dat dit product niet wil zijn.
• Agenda (Agenda-overzicht) wordt eveneens persoonlijk: de drukte-indicatie (Drukte zichtbaar maken) slaat op jouw dag. Een gecombineerde weergave over meerdere personen is buiten scope (Bewust buiten scope).
• E-mail naar taak (E-mailverwerking) wint aan betekenis: de whitelist van vertrouwde afzenders (E-mail naar taak) kan worden gekoppeld aan de personenlijst, zodat bekend is wie de taak heeft ingestuurd. Wie de taak vervolgens moet doen, blijft de ontvanger — de afzender vastleggen als opdrachtgever is een derde rol, en die valt buiten dit hoofdstuk (Aanvrager als derde rol).

Rechten: wat dit hoofdstuk niet regelt

Toewijzing is geen beveiliging. In fase A is een persoon niet meer dan een label: er is geen inlog, dus iedereen die het prototype opent, kan alles zien en wijzigen — precies zoals Fase A — het lokale prototype het beschrijft, en om dezelfde reden acceptabel, want het draait alleen lokaal.

Pas in fase B, met Joomla-gebruikers en ACL, wordt de vraag echt: mag je elkaars taken zien, en mag je ze wijzigen? Voorstel is om dan te beginnen met volledige zichtbaarheid binnen één installatie — het gaat om een klein, vertrouwd gezelschap, en een bord waarop je de helft niet ziet is een slecht bord. Afscherming per gebied of per persoon is een latere verfijning. Zie Zichtbaarheid tussen personen in fase B.

Gevolgen voor het datamodel

Één nieuwe tabel voor de persoon, één voor de overdrachtsgeschiedenis, en drie verwijzingen in bestaande tabellen:

Tabel	Wijziging
task	assignee_id (FK naar person, verplicht)
project	owner_id (FK naar person, verplicht)
advice	person_id (FK naar person, verplicht) — advies is per persoon
task_factor_score	source krijgt de waarde inherited erbij (zie Doorschuiven naar iemand anders)

task_transfer heeft twee verwijzingen naar person; in het diagram is dat als één relatie getekend omdat mermaid er niet meer van maakt. from_person_id is leeg bij de allereerste toewijzing.

Bij het aanzetten wordt één persoon aangemaakt — jij — en krijgen alle bestaande taken en projecten die persoon als uitvoerder respectievelijk eigenaar. Daarmee zijn de verplichte velden meteen gevuld en verandert er aan een bestaand bord niets zichtbaars.

Bewust buiten scope

• Meerdere uitvoerders per taak. Zie Twee rollen: uitvoerder en eigenaar: één taak, één naam.
• Een derde rol (aanvrager/opdrachtgever). Wie het heeft gevraagd is iets anders dan wie het doet, en soms nuttig om te weten — maar het is een zelfstandige uitbreiding met eigen schermen. Zie Aanvrager als derde rol.
• Een teamweergave. Alle borden naast elkaar, capaciteit per persoon, wie heeft het druk: dat is een ander product. Dit blijft een persoonlijk bord dat toevallig weet van andere mensen.
• Notificaties per gebeurtenis. Zie Doorwerking naar advies, agenda en e-mail.

Plaats in de fasering

Toegevoegd als fase A6, maar met een kanttekening die de andere twee ideeën niet hebben: dit is het enige van de drie dat het datamodel wezenlijk verandert, met twee verplichte velden op tabellen die dan al gevuld zijn. Verwacht je dat er echt meerdere personen komen, dan is het verstandiger om dit vóór A4 en A5 te doen — agenda en advies worden er persoonlijk door, en dat achteraf inbouwen is meer werk dan het meteen goed zetten.