F — Fairness
Percepția de echitate. În IT — prioritizări de scope, decizii de promovare, alocări de tasks „interesante” vs. „grunge work” — Fairness e cea mai puternică dimensiune când e încălcată.
- Înțelegi că Fairness e despre PERCEPȚIE, nu adevăr obiectiv
- Comunici criterii vizibile pentru orice decizie de prioritizare
- Recunoști când „eficiența” devine „inechitate” și inversezi
Studii (Tabibnia, 2008) arată că percepția de „nedreptate” activează zonele de durere fizică mai puternic decât oricare din celelalte 4 dimensiuni. În echipele de software, asta apare zilnic: cineva primește mereu task-urile „cool” (greenfield), altul mereu pe „bug fixes”. Cineva e invitat la architecture review, altul nu. Cineva primește credit la demo, altul nu.
Cum se manifestă Fairness în IT
Trei zone unde BA/PO/EM încalcă Fairness fără să-și dea seama: (1) Prioritizare scope — cererea cuiva intră, alta nu, fără criteriu vizibil. (2) Alocare task-uri — patternuri de „cine primește ce” care nu se discută. (3) Recunoaștere — la demo, în retro, la review-uri 1-1 — cine e menționat și cine nu.
Ce activează Fairness (toward)
- Reguli explicite, aplicate la fel pentru toți (inclusiv pentru tine).
- Transparență în decizii: „am ales A pentru că [criteriu specific]”.
- Recunoașterea contribuțiilor proporțional cu efortul real (nu cu vizibilitatea).
- Aplicarea regulilor și când te dezavantajează — fără excepții „politice”.
- Rotație explicită a task-urilor neplăcute (oncall, bug fixing, support).
- Documentarea publică a frameworks-urilor de prioritizare (RICE, MoSCoW).
Ce amenință Fairness (away)
- „Excepții” pentru anumiți stakeholders — chiar și mici, vizibile public.
- Decizii fără explicație („pentru că așa a zis CTO”).
- Recunoaștere disproporționată (cineva primește credit pentru munca altuia, sau cineva tăcut e invizibil).
- Procese diferite pentru oameni similari (ex: A a fost intervievat 1h pentru promovare, B 3h).
- Patternuri în alocarea de „greenfield” vs. „grunge work” care favorizează aceleași persoane.
- Schimbări de regulă retroactivă („de acum nu mai contează asta”) după ce cineva s-a calificat.
4 momente de Fairness în IT
Care din următoarele scenarii încalcă Fairness? Apasă răspunsul.
PO-ul anunță: „cererea echipei Marketing intră în sprintul ăsta, deși a venit ieri. Cea de la Sales (de săptămâna trecută) iese.”. Fără explicație.
EM-ul îi alocă lui Mihai task-ul de greenfield „re-architecture”. Tu, BA cu acelaș senioritate, primești backlog-ul de bug fixes. A 3-a săptămână la rând.
PM-ul îți spune: „nu putem avea standup la 9 dimineața — Mihai are copil de dus la grădiniță”. Tu ai aceeași situație, dar n-ai zis nimic. Acceptă pentru toți.
La demo, manager-ul spune: „Echipa A a făcut treabă excelentă!”. Echipa ta a livrat la fel, dar nimic. Tot trimestrul.
Redesign: anunț de prioritizare opac
Mai jos e un anunț pe care un PO l-a postat în channel-ul echipei despre re-prioritizare. E opac — și deja a generat 12 mesaje de DM. Rescrie-l ca să fie transparent fără să fie un email lung.
Scrie versiunea ta. Apoi vezi un hint și o variantă propusă.
Audit: ultimul „nu” pe care l-ai dat
Recall: ultima dată când ai spus „nu” unei cereri (de scope, de feature, de schimbare). Ai comunicat criteriul? L-ar fi putut argumenta cineva că e nedrept?
Notează: cui ai spus „nu”, contextul, ce ai zis. Apoi: ce criteriu folosit? Era vizibil pentru cealaltă parte?
- Cum ar fi reacționat dacă ai fi explicat criteriul? Ar fi schimbat ceva?
- Există un framework pe care îl poți folosi consistent (RICE, ICE, MoSCoW)? Dacă da, e public în echipă?
2 stakeholders îți cer feature-uri urgente. Decizi în favoarea unuia. Ce e cel mai important?