Un proiect, unsprezece faze

Patru porți de aprobare: Nevoia · PRD · Plan · Taskuri

CAEN, reconstruit

CAEN e proiectul cu cea mai mare depășire livrată din Q3 SOLO: 213 ore estimate, 398 consumate, termen mutat de două ori, de pe 8 iulie pe 24 august. Motivele au fost scrise onest. Sunt exact cele pe care fazele de mai jos le previn.

Definiția de „gata" — „documentele generate sunt acceptate de ANAF" — nu a existat înainte de estimare. Testarea cu primele 10 ANAF-uri a intrat în scop după. Prima mutare: 23 de zile. Riscul ca ANAF să întârzie răspunsurile D700 era cunoscut, dar nu era scris și nu avea buffer. A doua mutare: 7 zile. Între ultima dată mutată și livrare au trecut 11 zile lucrătoare fără explicație.

Cu Nevoia scrisă, definiția de „gata" era prima propoziție. Cu Planul scris, riscul ANAF avea un plan B și un buffer. Cu taskurile scrise, a treia mutare ar fi fost obligatorie, cu motiv. Nu e o metodă nouă. Thoughtworks o numește Spec-Driven Development. E practica standard a echipelor care lucrează cu agenți AI în 2026.

De unde vine un proiect

Din prioritățile trimestrului. Fiecare prioritate are un owner din Product, o cifră, un Feature Lead (un mid) și un reviewer (alt mid). Fără prioritate nu există proiect.

Fazele 1–4: până la PRD aprobat

Faza 1 — Analiza: situația actuală și nevoia

Ce există azi: documente, date, prototipuri, cod. Ce lipsește. Pentru cine. De ce acum. Se încheie cu Nevoia: o pagină, fără tehnologie, cu definiția de „gata" scrisă ca o propoziție pe care o verifică altcineva.

• Cine scrie: Feature Lead, cu PM-ul (Chris sau Teo). Product dă nevoia; nu scrie el pagina.
• Poarta 1 — Nevoia aprobată: Prodi, în 24 de ore. Bogdan nu aprobă. Proiectele lui trec prin aceeași poartă.
• Timp: estimat la deschidere, 1–2 zile; real la aprobare.
• Agent: Bruce pregătește draftul din discuția din canalul proiectului; skill-ul bono-planificare rulează pașii „situație actuală" și „discovery".
• Formular: F1 · Nevoia

Faza 2 — Research: soluții, concurență, experți

Cum rezolvă alții problema. Ce împrumutăm, ce construim, ce sărim la MVP. Un expert consultat, când e cazul (Cristi pe logică contabilă, un avocat pe legal). Se încheie cu o pagină de decizii de research.

• Cine: Feature Lead, cu Bruce (skill-ul bono-research).
• Timp: 1–3 zile. La un proiect care are deja research din trimestrul trecut, faza e o jumătate de zi: ce s-a schimbat.

Faza 3 — Prototip și design

Ecranele, când proiectul are UI. Octav le face în Edge-38, cu Feature Lead-ul alături, și le validează cu owner-ul înainte de PRD. Un prototip validat schimbă PRD-ul; un PRD scris înainte de prototip se rescrie.

• Cine: Octav. Validează: owner-ul din Product.
• Timp: 2–5 zile, după mărime.

Faza 4 — PRD

Ce construim, exact: comportamentul vizibil pas cu pas, cazurile limită, ce nu facem, definiția de „gata" verificată pe prototip. Fără tehnologie. Una-două pagini. La un proiect mic, Nevoia și PRD-ul sunt același document, aprobat de două ori.

• Cine scrie: Feature Lead, cu PM-ul.
• Poarta 2 — PRD aprobat: Prodi. De aici proiectul poate fi estimat.
• Formular: F1 · Nevoia, secțiunea PRD.

Fazele 5–6: Plan și taskuri

Faza 5 — Proiectare tehnică și arhitectură

Cum construim. Componente atinse, modele de date, integrări externe și ce se întâmplă dacă ele întârzie, riscuri, ce nu se atinge. Două-trei pagini.

• Cine scrie: Feature Lead-ul. Un mid, nu Prodi. Aici cresc oamenii.
• Cine revizuiește: Prodi, cu o notă de simplitate de la 1 la 3, un rând de motiv și întrebări în thread. Nu rescrie.
• Poarta 3 — Plan aprobat. Dacă Planul trece de dublul estimării lui, problema nu e clară și proiectul se oprește aici.
• Formular: F2 · Plan

Estimarea în trei surse. Apare aici, nu mai devreme. Feature Lead-ul estimează din propriul plan. Claude estimează independent, din Nevoie, PRD și Plan, fără să vadă prima cifră. Prodi validează după ce vede ambele. Cifra lui e referința. Estimarea proprie se păstrează ca dată: diferența constantă e un semnal, nu o vină. Formular: F3 · Fișa de estimare.

Scorul de complexitate. Prodi dă un scor de la 1 la 5 înainte de start, independent de cine execută și de cât s-a estimat. Nu se schimbă pe parcurs. E baza output-ului ponderat, singura cifră prin care doi oameni cu proiecte diferite devin comparabili.

Faza 6 — Spargere în taskuri

Planul se sparge în taskuri de sub o zi, fiecare cu un criteriu de verificare pe care îl confirmă altcineva. Lista include explicit fazele care lipsesc de obicei: review, testare, release, monitorizare 30 de zile și un buffer numit ca atare. Concediile din interval se scot din calendar înainte de a pune data.

• Cine scrie: Feature Lead. Agentul de planificare produce prima listă din Plan; Feature Lead-ul o ajustează. Reviewer-ul e numit aici.
• Poarta 4 — Taskurile în tracker: toate, înainte de prima oră de implementare. Data asumată intră în Predictibilitate acum. Nu mai devreme, nu mai târziu.
• Formular: F5 · Task

Un task terminat retroactiv se numără ca nealocat, nu ca livrat.

Fazele 7–9: execuție, testare, release

Faza 7 — Execuție

Feature Lead-ul execută sau deleagă către agent — Jimmy, Claude Code, SuperNicu — task cu task, cu Nevoia, PRD-ul și Planul în context. PR-uri sub 200 de linii. Review în trei trepte, continuu, nu la final. Termenul se mută înainte de întârziere, cu motiv scris. Detalii în Review și deploy.

Faza 8 — Testare

Reviewer-ul verifică definiția de „gata" din PRD, punct cu punct. Când proiectul are logică contabilă sau fiscală, Cristi verifică cifrele. Bug-urile găsite se rezolvă sau se închid în cinci zile.

Faza 9 — Release

Deploy automatizat, făcut de Feature Lead, cu rolul „responsabil deploy" al lunii alături prima dată. Anunț în canalul proiectului cu definiția de „gata" bifată. Data reală intră în tracker.

Fazele 10–11: după release

Faza 10 — Monitorizare 30 de zile

Feature Lead-ul rămâne pe proiect. Orele de rework în aceste 30 de zile sunt o cifră a proiectului și intră în „Calitatea soluției". Un proiect nu se predă la release; se predă la 30 de zile după.

Faza 11 — Review final cu owner-ul, review de proces și lecții

Două întrebări, o oră, la retrospectiva lunii sau separat: cifra prioritității a fost atinsă? — cu owner-ul din Product; ce a mers și ce nu în proces? — cu Alexandra. Ies două-trei lecții, scrise: în CLAUDE.md-ul repo-ului sau ca ADR. Așa un proiect lasă ceva în urmă și pentru următorul.

Checklist-ul pe faze în tracker

Tracker-ul de pe superbono.ro ține, pe fiecare proiect, fazele cu taskuri de sign-off ca porți. Pentru fiecare fază: data deschiderii, timp estimat, timp real, data aprobării, cine a aprobat. Faza următoare nu se deschide fără aprobarea celei anterioare. Tracker-ul devine sursa unică pentru KPI 4, 5, 9 și 10.

Azi tracker-ul are fazele 1–8 ca tabel și estimat/real doar pe taskuri, nu pe faze. Ce lipsește e în SuperBono: nevoia și drumul. Formular: F4 · Checklist pe faze.

Reguli transversale

• Fiecare om are zilnic orele pe categorii: proiect pe fază, operațional, review pentru alții, ședințe, concediu. Agentul le deduce, omul le confirmă.
• Munca operațională recurentă e un proiect permanent cu ore alocate. Nu mai apare ca surpriză în alte proiecte.
• Fără backlog de bug-uri. Un bug se rezolvă sau se închide în cinci zile lucrătoare.
• Concediul se anunță cu taskurile în curs predate nominal unui coleg, scris în tracker.
• Bogdan nu implementează în locul cuiva când e coadă la Prodi. Coada e o cifră; se rezolvă prin proces, nu prin Bogdan.

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.