Proiect principal
Platformă web și mobilă pentru planificarea turelor și pontaj, făcută pentru organizațiile care lucrează în schimburi. În spate stă un motor de optimizare pe Google OR-Tools CP-SAT, cu regulile din legislația muncii din România: sărbători legale, normă lunară, ture de 12 și 24 de ore, echilibrarea orelor și a weekendurilor. Am validat-o pe date reale dintr-o secție de cardiologie.
Proiectată și scrisă integral de mine
Despre proiect
În spitale, clinici sau firme de curățenie, planificarea lunii se face de mână. Trec zile întregi cu potrivitul normelor, al regulilor și al preferințelor, iar la final tot rămân nemulțumiri: nopți împărțite inegal, weekenduri sacrificate, pontaje refăcute de la zero.
Planova tratează planificarea ca pe o problemă de optimizare cu constrângeri. Modelul matematic e rezolvat de Google OR-Tools CP-SAT, care caută soluția ce respectă legislația muncii din România și împarte echitabil orele și weekendurile între angajați.
Am validat platforma pe date reale dintr-o secție de cardiologie. Managerul lucrează din browser, iar angajații își trec preferințele și își văd programul din aplicația de telefon, pe Android.
Demo video
Prin aplicație
Grila lunii pentru toată echipa, generată de motorul CP-SAT cu toate condițiile respectate. Contoare live pe fiecare zi, pornire din preferințele angajaților, import și export, plus editare manuală celulă cu celulă peste soluția generată.
Pontajul iese direct din planificare: ore lunare, ore de weekend și numărul fiecărui tip de tură pentru fiecare angajat, gata de export.
Fiecare angajat își vede luna lui: turele colorate, orele totale, cele de weekend și zilele lucrate. Aceleași culori pe web și pe telefon, ca un simbol să însemne același lucru peste tot.
Sub capotă
Fiecare zi a fiecărui angajat devine o variabilă de decizie. Constrângerile hard, adică legislația, dependențele între ture și cererile aprobate, se respectă întotdeauna. Acoperirea posturilor intră ca penalizare cu pondere foarte mare, iar echilibrul orelor și al weekendurilor se optimizează cât permite restul. CP-SAT trece prin milioane de combinații și întoarce în câteva secunde o soluție pe care un om ar căuta-o zile întregi. La secția de cardiologie, cu 25 de asistenți și 12 infirmieri, generarea durează câteva secunde pe post. În testele de scalare, motorul ajunge la soluția optimă până la 120 de oameni pe un singur post. La 200 găsește o soluție validă, dar nu întotdeauna optimă, iar acolo algoritmul mai are loc de îmbunătățit.
Arhitectura: API în ASP.NET Core cu SQL Server, interfață web în Angular pentru manageri, aplicație de telefon în .NET MAUI pentru angajați. Un singur backend, web și telefon.
Decizii tehnice
Solverul lucrează în două faze. Regulile care nu se negociază sunt constrângeri hard: o singură tură pe zi, zilele permise, interdicțiile, limitele de zile consecutive, dependențele între ture și cererile aprobate. Acoperirea posturilor și excesul săptămânal intră în prima fază ca penalizări cu ponderi foarte mari. Echitatea orelor și a weekendurilor se optimizează separat, în faza a doua, cu rezultatul primei faze înghețat. Puse la un loc, penalizările mari ar fi oprit solverul înainte să ajungă la echitate.
Am introdus 510 cereri reale ale secției pentru octombrie 2026, transcrise din bilete scrise de mână, iar planificarea generată le respectă pe toate. Pe drum au ieșit două bug-uri la granița dintre luni: ziua liberă de după o noapte cădea cu o zi mai târziu, iar o cerere aprobată pe 1 a lunii făcea modelul imposibil de rezolvat. Le-am reparat și le-am acoperit cu teste de regresie. Am mai găsit condiții care cereau imposibilul, ca oameni pe tura de dimineață în weekend, și care încurcau regula de oprire a solverului.
Backendul e în C#, pe ASP.NET Core cu ABP Framework și SQL Server. Motorul CP-SAT stă în stratul de domeniu și nu atinge baza de date, așa că poate fi rulat în teste de regresie. Managerii lucrează într-o interfață web în Angular. Aplicația de telefon e în .NET MAUI, tot C#, și e doar un client: folosește același API și nu are logică proprie. Regulile stau într-un singur loc, deci web-ul și telefonul nu pot ajunge să calculeze diferit.
Vezi Planova în acțiune