Waarom we het takenbeheer opnieuw ontwierpen
Lijst én kanban, workload per teamlid en deadlines die zichzelf bewaken. Een kijkje achter de schermen bij de nieuwe takenmodule.
Twee views, één datamodel
De grootste fout in versie één was dat de kanban zijn eigen state hield en de lijst zijn eigen. Verplaats een taak in kanban en de lijst wist even van niks; refresh je pagina en de kanban gaf een oude kolom. In de herstart is elk kaartje één record met één status; kanban en lijst zijn twee lezers van dezelfde tabel. Geen sync, geen webhook, gewoon dezelfde bron.
Workload per teamlid, direct in de header
Handmatig taken evenwichtig verdelen werkt tot je vier teamleden hebt; daarna raakt iemand overspoeld en merkt niemand het. Bovenin de takenmodule staat nu per teamlid een strook met "open deze week / open volgende week / doorschuivend". De cijfers zijn deterministisch uit dueDate en status — geen aparte kolom in de database, gewoon een groupBy op elk request.
Deadlines die zichzelf bewaken
Vroeger was een deadline een tekst-veldje; er gebeurde niets als je 'm miste. Nu is elke taak met dueDate meteen ingeschreven in de dagelijkse checkcron. Overschrijding = een activity-log entry (voor het historiek) en een chip op de kaart. Nooit een e-mail zonder dat de gebruiker het aangaf — een chip vraagt aandacht zonder je inbox vol te lopen.
Wat we bewust wegleefden
Er is geen sub-taken-niveau. Er is geen tag-systeem. Er zijn geen custom-status-kolommen. Elke feature die we oversloegen kwam terug in de eerste feedback-ronde — en we lieten 'm er nog steeds af. De reden: workflows kunnen taken aanmaken, dus de meeste "sub-taak"-verzoeken zijn beter opgelost als een workflow-recept dan als een dieper takenmodel. Simpelheid is hier de feature.