Fiecare oră evidențiată

Majoritatea colaborărilor software facturează în ore și raportează în totaluri. Un client primește un număr la finalul lunii și îl acceptă pe încredere, pentru că n-are altceva de făcut cu el.

Un număr gol nu poate fi auditat. Nu poate fi întrebat, verificat sau conectat la nimic livrat. E o cifră care fie se potrivește cu așteptările, fie declanșează o conversație incomodă, și niciunul din rezultate nu implică pe cineva care învață ceva.

Așa că nu livrăm cifre goale. Fiecare colaborare ForkTex include analitice de muncă la granularitate orară: timp înregistrat per proiect și per persoană, cu fiecare intrare descriind ce s-a făcut. Nu doar cât a durat.

Ăsta e un angajament luat față de clienți, nu o comoditate internă de raportare.

O oră fără activitate nu e o intrare

Constrângerea centrală e că orele și activitățile călătoresc împreună. O intrare cu o durată și fără descrierea muncii e incompletă, iar sistemul n-o acceptă.

Regula asta există pentru că alternativa se degradează previzibil. Când descrierea e opțională, e furnizată sub presiunea termenului limită aproape niciodată, iar în două luni jurnalul devine iar o coloană de cifre. Valoarea n-a fost niciodată în urmărire. a fost în descriere, iar a o face opțională e ca și cum ai elimina-o.

Forma unei intrări e neremarcabilă:

{
  "projectId": "…",
  "date": "2026-08-14",
  "hours": 6.5,
  "activities": [
    { "info": "Stock ledger: FEFO consumption across partial lots" },
    { "info": "Fixed receipt totals diverging from line sums on VAT rounding" }
  ],
  "links": [{ "url": "…", "label": "PR 412", "kind": "review" }]
}

Linkurile contează mai mult decât par. Ele conectează o oră pretinsă la ceva verificabil extern. Un pull request, un deployment, un document. Un client care vrea să verifice nu trebuie să ne întrebe pe noi.

Totalurile sunt calculate, niciodată stocate

Cifrele săptămânale, lunare, trimestriale și anuale sunt agregări peste intrări. Niciun total de perioadă nu e scris ca valoare proprie.

Asta e o decizie de design de bază de date cu o consecință directă pentru client. Un total stocat încetează să corespundă intrărilor lui din momentul în care una e corectată. Și intrările chiar se corectează, pentru că oamenii nu-și amintesc bine o zi sau înregistrează pe proiectul greșit. În clipa în care o cifră lunară stocată și suma zilelor ei nu sunt de acord, clientul se uită la două cifre, fără nimic care să spună care e adevărată.

Recalcularea costă o interogare. Stocarea costă credibilitate, o dată, într-o conversație pe care n-o poți câștiga.

Inclus, niciodată opțional

Analiticele de muncă vin cu fiecare colaborare. Nu e un add-on, nu e un nivel premium, și nu e ceva oferit la cerere.

A-l face condiționat ar transforma un diferențiator într-o negociere. Și, mai important, ar face din colaborarea *implicită* cea opacă. Un client care nu știe să ceară ar primi mai puțină vizibilitate decât unul care știe, ceea ce e exact invers cum ar trebui.

Partea de raportare e decuplată deliberat: dintr-un payload și o configurare, produce un document. Nu accesează o bază de date și nu ține o sesiune, așa că aceeași cale de cod servește un request API, un raport lunar programat, sau un export unic dintr-un fișier JSON. Un raport e o vedere peste date, niciodată o înregistrare separată a lor.

De ce „jurnal"

Am redenumit asta din „work logs". Cuvântul contează mai mult decât pare.

Un jurnal e o înregistrare cronologică, doar-adăugare, în formă de audit. E termenul pe care contabilitatea l-a folosit secole întregi pentru exact această structură, și stabilește așteptarea corectă despre ce este: nu notele private ale unui dezvoltator, ci o înregistrare pe care un auditor ar putea-o citi.

Această încadrare rezolvă și dispute de design. Poate fi editată retroactiv o intrare? Un jurnal spune că corecțiile sunt intrări, nu suprascrieri. Ar trebui stocate totalurile? Un jurnal spune că intrările sunt adevărul, iar tot restul e derivat.

Pentru ce e de fapt

Utilizarea evidentă e transparența facturării, și e reală. Dar utilizarea mai valoroasă e că face posibilă o conversație anume.

Când un client întreabă de ce ceva a durat trei săptămâni, răspunsul nu e un rezumat defensiv scris din memorie. E înregistrarea: astea au fost zilele, la asta s-a lucrat, iată pull request-urile. Uneori asta confirmă estimarea. Uneori arată că estimarea a fost greșită, și de ce. o integrare subspecificată, o dependință care s-a comportat diferit de ce era documentat.

Ambele rezultate sunt utile. Niciunul nu e disponibil unei echipe care raportează un total.