ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 147
Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 131
Abonament PDF

A fi Product Owner – necesitate sau moft?

Loredana Vigu
Proxy Product Owner @ CodeCrafters by BT



MANAGEMENT


Câți dintre voi vă mai amintiți, din perioada în care erați copii, ce vă doreați să deveniți când veți fi mari? Când mamele noastre sau profesorii noștri ne întrebau: "Ce vrei să te faci când vei fi mare?" Poate unii dintre noi și-au dorit să devină piloți și să zboare peste tot în lume. Alții visam să fim bucătari și să pregătim mâncare pentru cei dragi. Sau poate ne doream să fim ca Neil Armstrong și să ajungem pe Lună. Cu siguranță, fetele și-au dorit să devină balerine, dansatoare, actrițe, exploratoare, visând să devină celebre. Ce vremuri, nu-i așa? Câți dintre voi ați dorit să deveniți QA, programatori, arhitecți software, BA sau PO?

Eram în clasa a 8-a, mă pregăteam pentru examenul de admitere și i-am spus mamei: "Vreau să devin make-up artist sau coafeză", iar ea mi-a spus: "Cum? Tu știi ce greu este să stai în picioare toată ziua și să te doară picioarele? Nu! Trebuie să mergi la Liceul de Informatică și să faci o muncă de birou, trebuie să te gândești la sănătatea ta…" Da, mulțumesc, mamă ... nu e ca și cum azi nu ne-am plânge mulți dintre noi de dureri de spate sau alte probleme de sănătate. Dar acesta ar fi un alt subiect de discuție.
Când eram copii, aceste meserii nu erau comune: QA, Programator, Arhitect Software. Ce să mai vorbim de Business Analyst sau Product Owner (PO)!

Câți dintre noi au avut BA sau PO în echipă acum cinci sau zece ani? Câți dintre noi au un BA sau un PO în echipă azi? Cu siguranță, acum, numărul acestor roluri este mult mai mare decât acum cinci sau zece ani.

Să facem un exercițiu de imaginație! Ce se întâmplă dacă nu ai un BA sau un PO care să scrie US (user stories) în echipă? Cine scrie criteriile de acceptabilitate? Cine documentează toate solicitările de a modifica aplicația? Cine vorbește cu clientul sau cu factorii decizionali?
În trecut (2000-2010), modul în care se dezvolta și se lucra la un produs era următorul. Cineva venea cu o idee. De obicei, ideea venea din partea managementului sau de la client sub forma câtorva propoziții, apoi toți membrii echipei contribuiau la acea construcție de idei. Programatorii trebuiau să decidă dacă ideea este fezabilă și să vină cu o soluție tehnică. Cei din rolurile de QA trebuiau să facă mai multe drumuri între programatori și manageri pentru a înțelege ce trebuia testat, dacă sistemul funcționa, dacă ceea ce s-a implementat este exact ceea ce își dorise managerul. Unele lucruri nu erau chiar clare. Trebuia prezentată implementarea persoanei care avusese ideea, ulterior solicitat feedback, pentru ca mai apoi să se ajungă tot la programatori cu noi solicitări de a schimba implementarea, care nu era completă sau, și mai rău, era ceea ce își imaginase managerul ...
Dar aveam timp să le facem pe toate. Aceste idei (care nu erau atât de mari) se implementau în 3, 6 sau chiar 9 luni. Proiectele mari aveau nevoie de câțiva ani. Se făcea release o dată sau de două ori pe an.
De ce nu facem același lucru și azi? Pentru că totul s-a schimbat, de la tehnologie la modul în care gândim, la răbdarea pe care o avem. Totul se desfășoară pe repede înainte. De câte ori nu am fost frustrați că aplicația este prea lentă, că pagina web nu răspunde suficient de repede? De câte ori apăsăm butonul Refresh în speranța că totul se va rezolva. 

Toate acestea au avut consecințe și asupra mediului de business. Dacă nu ne mișcăm suficient de repede, pierdem trenul. Dacă nu implementăm ideea suficient de repede, cineva cu aceeași idee o va face disponibilă pe piață înaintea ta.

Așadar, ce s-a întâmplat mai precis? A apărut rolul de PO. ( Să fim sinceri, cine știa de rolul de PO acum cinci sau șase ani?) A apărut o nevoie, nevoia de a mișca lucrurile într-un ritm mai alert, de a da echipei informația de care are nevoie mai repede pentru ca echipa să finalizeze, bineînțeles, munca mai repede.
Rolul de PO sau cel de BA (deoarece uneori aceste roluri se suprapun) este ocupat de persoana care vorbește cu clientul, pregătește specificațiile în mai mult de două propoziții, scrie condițiile de acceptabilitate, stabilește priorități, monitorizează modul în care se efectuează modificările care au impact asupra planului inițial. Este mediatorul dintre client și echipă. Dacă acum zece ani, acest rol era împărțit printre sarcinile de lucru ale altor membri ai echipei sau era asumat de client, acum acesta aparține unei singure persoane din echipă.

De cele mai multe ori, clientul vine cu ideea, întrucât cunoaște care este obiectivul pe care dorește să îl atingă, dar nu știe cum poate să îl materializeze. Responsabilitatea unui PO este de a clarifica și de a înțelege ce dorește clientul și care sunt lucrurile de care are nevoie. Apoi, un PO trebuie să ghideze clientul, să îl consilieze, să îi ofere opțiuni, să prezinte argumente pro și contra. Bineînțeles, clientul va avea ultimul cuvânt și va face alegerile care i se potrivesc, dar sarcina unui PO este de a ajuta clientul și de a-l asista în deciziile sale.

Pentru a face toate acestea, un PO are nevoie de ajutor. Dar să fim realiști, un PO nu este un zeu, nu știe totul și mai mult nu el este cel care implementează proiectul. Un PO colaborează îndeaproape cu UI/UX, dar și cu arhitectul sau coordonatorul tehnic. Rolul UI/UX este de a crea o experiență de utilizare cât mai plăcută. Arhitectul va spune ce e fezabil și va veni cu soluția tehnica. În paralel, se va alcătui backlogul pentru echipa de dezvoltare, astfel încât să existe cât mai puține neclarități, iar programatorii să aibă user stories pregătite la începutul sprintului pentru a-l putea implementa.

Așadar, este rolul PO o necesitate? Cu siguranță, da.

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects