De ce

Povestea unui trimestru fără cifre

Douăsprezece săptămâni, patru mii cinci sute de ore

Între 15 iunie și 8 septembrie 2026, echipa IT de la SOLO a avut 9 oameni și 62 de zile lucrătoare. Asta înseamnă 496 de ore per om și aproximativ 4.500 de ore în total.

Din aceste ore, aproximativ 1.400 au fost înregistrate pe proiecte cu estimare. Aproximativ 150 au fost concedii. Restul — aproximativ 2.900 de ore, două treimi din timpul echipei — nu au nicio cifră în spate. Pentru un sfert din timp nu există nici măcar un rând de text. Un coleg are 34 de ore consemnate din 496. Altul, 101.

Nu e o echipă slabă. A livrat 9 proiecte din 17, 5 dintre ele exact la termen. Dar nu putem spune ce a făcut cu două treimi din timp. Și nici ea nu poate.

Ce s-a întâmplat cu cele opt proiecte care nu au mers

Am citit motivele scrise de echipă la fiecare întârziere. Sunt oneste. Se repetă.

• CRM Marketing Campaigns, +169% peste estimare, anulat. Release-ul și concediile nu erau în plan. Prima mutare de termen a fost de 23 de zile.
• CAEN, +87%. 213 ore estimate, 398 consumate. Testarea cu primele 10 ANAF-uri a intrat în scop după estimare. Termenul s-a mutat de două ori, după ce întârzierea era deja vizibilă. Ultimele 11 zile nu au explicație scrisă.
• Mapare Design System, +80%. Prima deviere a apărut pe 18 iunie. Nimeni nu a discutat-o până la a patra.
• Padawan Admin. 22 din 32 de taskuri au fost scrise după ce erau gata.

Trei cauze, în toate cazurile. Estimarea s-a făcut fără definiție de „gata", fără release și fără buffer. Termenul s-a mutat după întârziere, nu înainte — un singur om, în tot trimestrul, l-a mutat înainte. Evidența s-a scris retroactiv, din memorie.

Cel mai lung blocaj a fost o așteptare

Cel mai lung blocaj din trimestru nu a fost o problemă tehnică. A fost o așteptare de opt zile lucrătoare la review. Cineva a terminat, a cerut o pereche de ochi, și nu a primit-o.

Datele din industrie pe 2026 spun același lucru. Faros, pe 10.000 de programatori: cu agenți AI, echipele fac cu 21% mai multe taskuri și cu 98% mai multe PR-uri, dar timpul de review crește cu 91%. Mai mult cod, același număr de ochi. Review-ul e blocajul numărul unu al echipelor care lucrează cu AI.

De ce contează pentru Bono

Bono nu are raportul acesta. Nu pentru că stăm mai bine, ci pentru că nu l-am făcut. Avem aceeași nevoie, cu un element în plus: patru programatori mid care trebuie să crească, și un CTO — Prodi — prin care trece azi aproape tot: arhitectura, review-ul, deploy-ul.

Vrem trei lucruri:

• Vizibilitate. În orice zi să știm ce se construiește, cât a costat până acum și cât mai e.
• Eficiență. Fiecare oră să aibă o categorie. Fiecare proiect să aibă o estimare validată și un scor de complexitate. Fiecare deviere să fie discutată la prima apariție, nu la a patra.
• Oameni care cresc. Cei patru mid să scrie arhitectură, să facă review unul altuia și să dea deploy. Dependența de Prodi să scadă, măsurat, lună de lună.

Ce nu e acest document

Nu e un sistem de supraveghere. Evidența pe care o cerem e a fiecărui om, despre propria muncă, confirmată de el. Nu comparăm oameni între ei în primul trimestru; cu 2–4 proiecte per om, diferențele mici sunt zgomot.

Nu e un set de formulare. Regula de bază e „omul confirmă, agentul scrie". Orice proces care cere completare manuală de formulare moare în două săptămâni. L-am respins din start.

Nu e o carte. Are 30–40 de pagini, cu aceeași structură la fiecare capitol, ca să poți sări direct la ce te privește.

Un singur desen

Tot documentul încape într-un desen.

Cum citești documentul

Dacă ai zece minute, citește Cine ce face și găsește-ți pagina de rol. Acolo scrie ce faci tu, ce decizi singur și ce cifră te privește.

Dacă ai o oră, citește capitolele în ordine. Fiecare are aceeași structură: rezumatul, principiul cu un exemplu din Q3, cum funcționează la Bono, instrumentul gata de copiat, ritualul cu ora și durata.

Dacă ești Prodi, Chris sau Alexandra, capitolele tale sunt marcate. Le rescrii unde nu se potrivesc. Un capitol e gata când owner-ul lui spune că îl poate ține.

The Bono Way · v0.1 · 9 septembrie 2026 · pregătit de Claude pentru Bogdan; capitolele se rescriu de owner-ii lor. Sursa: repo „Bono Waiy", Markdown.