Principiile
Cinci propoziții pe care le ținem
1. Scriem înainte să construim
Niciun proiect nu începe fără o pagină care spune ce construim, pentru cine și ce înseamnă „gata". Nicio implementare nu începe fără un plan de două-trei pagini care spune cum. Codul vine după al treilea document, nu după primul mesaj pe Slack.
Cum arăta în Q3. Zero proiecte din 17 au avut specificație și plan aprobate înainte de prima oră de implementare. CAEN a primit definiția de „gata" — „documentele sunt acceptate de ANAF" — după estimare. Costul: 23 de zile la prima mutare.
Cum arată acum. Feature Lead-ul scrie Specify cu PM-ul. Prodi aprobă. Un mid scrie Plan-ul. Prodi pune întrebări și o notă, nu rescrie. Abia apoi există taskuri, și abia apoi cod. Un agent lucrează ore întregi cu un spec bun și minute cu unul prost. La fel un coleg.
2. Omul confirmă, agentul scrie
Evidența nu se scrie de mână. Un agent citește Slack, GitHub și SuperBono, deduce ce s-a lucrat și propune. Omul confirmă cu un ✅ sau corectează într-un rând. Orice proces care cere completare manuală de formulare e respins din start.
Cum arăta în Q3. Evidența s-a reconstruit din standup-uri, retroactiv, cu goluri. Padawan Admin: 22 din 32 de taskuri scrise după ce erau gata. Un task scris după fapt nu e evidență. E memorie.
Cum arată acum. Seara, fiecare primește un DM cu orele deduse pe categorii. Răspunde ✅ sau „nu, 3 h pe review, 2 h pe CAEN". Vineri dimineața, cele patru cifre per proiect sunt în canalul proiectului fără ca cineva să le fi calculat. Raportul lunar se scoate, nu se scrie.
3. Cunoașterea stă în fișiere
Ce știe Prodi și spune într-un thread se pierde. Ce știe Prodi și stă în CLAUDE.md sau într-un ADR rămâne și se citește — de oameni și de agenți. Decizia verbală se scrie în trei rânduri. Fiecare mid scrie lunar o secțiune.
Cum arăta în Q3. Cunoașterea arhitecturii stătea la un singur om. Coada la el era cel mai lung blocaj din trimestru.
Cum arată acum. Agentul propune rânduri pentru CLAUDE.md din răspunsurile lui Prodi. Prodi confirmă. CLAUDE.md e documentul de organizare al fiecărui repo: sub 300 de linii, citit de fiecare agent la fiecare task.
4. Ownership complet, de la idee la 30 de zile după release
Un proiect are un singur Feature Lead. El scrie Specify, ține Plan-ul, sparge taskurile, dă deploy și răspunde de ce se întâmplă în primele 30 de zile de producție. Nu predă la jumătate. Nu așteaptă să dea altcineva deploy.
Cum arăta în Q3. Release-ul nu era în estimare. Concediile nu erau în calendar. Monitorizarea post-release nu exista ca fază. Rezultatul: +169%, anulat.
Cum arată acum. Lista de taskuri include explicit review, testare, release, monitorizare 30 de zile și un buffer numit ca atare. Ore de rework în 30 de zile după livrare sunt o cifră a proiectului, nu o surpriză.
5. Ritm fix, cu cifre pe masă
Ne vedem în același moment al săptămânii, cu aceleași cifre în față. Discutăm doar unde cifrele nu merg împreună. Nu există ședință de status în care cineva povestește ce a făcut.
Cum arăta în Q3. Prima deviere la Mapare Design System a apărut pe 18 iunie. S-a discutat la a patra. NavSoft a avut patru zile de decalaj pe 21 august pe care nu le-a văzut nimeni la timp.
Cum arată acum. Vineri, 30 de minute, Prodi cu fiecare Feature Lead, patru cifre per proiect. 40% din ore consumate și 15% din taskuri închise înseamnă discuție pe loc: mutăm data, tăiem scopul sau adăugăm un om. Proiectele pe plan trec în două propoziții.
Cum se leagă
Principiul 1 produce documentele. Principiul 2 produce cifrele fără efort. Principiul 3 face ca ce învățăm să rămână. Principiul 4 face ca un proiect să aibă un răspuns la „cine?". Principiul 5 face ca devierea să se vadă la prima apariție.
Dacă unul lipsește, celelalte nu țin. Fără spec nu există estimare validată. Fără evidență automată nu există cifre de vineri. Fără ritm, cifrele există și nu le citește nimeni.
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.