sâmbătă, 21 martie 2015

Product Management?

Unde am activat pana acum, pe parcursul carierei, echipa Product Management/Business Analysts/Project Management/Whatever_the_name (cei care dau specificatii si sunt clientii directi ai echipelor de dezvoltare) avea un rol specific companiei/workflowului in care activau. Adica, niciodata n-a fost un rol in workflowul de dezvoltare a platformelor/aplicatiilor care sa varieze mai mult decat rolul PM de la o companie la alta.





Din punctul meu de vedere si din experienta, path-ul de evolutie al unui rol tehnic este clar si general valabil. Adica, esti tehnic (dev/qa/sysadmin/etc) si evoluezi. La un anumit nivel al evolutiei in cariera tehnica, ai de luat o decizie - iar optiunile sunt :
- arhitect (de sistem, de aplicatie, etc)
- manager
- PM

Mergand pe ultima optiune, poti activa ca si PM in 2 feluri :
- PM tehnic - care proceseaza cerintele de la business si din prisma tehnica, iar rezultatul muncii lui (specificatiile) au si indicatii de implementare (mai mult sau mai putin) tehnice
- PM atehnic (acesta nu vine pe path-ul evolutiv descris mai sus) - care proceseaza cerintele de business fara sa-si puna probleme tehnice, iar rezultatul muncii lui (specificatiile) sunt doar "user stories", fara nici o farama de informatie tehnica

Cel mai bine/eficient am functionat in prima varianta.



Cel mai prost am functionat in varianta de mai jos :
- PM fara background tehnic care proceseaza cerintele de la business si scrie specificatii folosind termeni tehnici si (cateodata) adaugand si "putin tehnicus" prin cerintele de acceptanta
Adica, o ciorba dintr-o struto-camila. Cu varza.

De ce am functionat cel mai prost (fiind date ipotezele de mai sus):
- PM impune solutia tehnica propusa de el ca si criteriu de acceptanta; neavand expertiza tehnica, aceasta e de cele mai multe ori gresita (din punct de vedere tehnic); incercarea de impunere a unui path de rezolvare tehnic in cerinta de acceptanta face ca echipa de dezvoltare sa nu mai aiba (sau sa nu mai accepte) ownership tehnic
- PM isi limiteaza cerintele de business din specificatiile proiectului din cauza ca (,) crede ca intelege platforma si din perspectiva tehnica; adica, isi pune singur piedici tehnice (care in cele mai multe situatii nu exista si/sau exista, dar necunoscand solutia sau neavand destula expertiza tehnica, este considerat blocked)
- discutiile cu un PM care nu este tehnic (dar crede ca e) in specificatiile rolului sau din acea companie sunt interminabile/ineficiente si neconstructive
- specificand cu "artefacte" tehnice, un ticket poate fi refuzat in dezvoltare pentru ca solutia tehnica ceruta ca criteriu de acceptanta este gresita (desi cerinta de business poate fi valida!)
- aceasta tipologie de PM isi "permite" sa se implice chiar si in workflow-urile de dezvoltare - am observat unii PM dandu-si cu parerea in procesele de estimare si despre starea in care trebuie sa fie un ticket (de exemplu)
- PM care (cred ca) au cunostinte tehnice, dar rolul in companie si workflowurile in care activeaza nu sunt create pe acest criteriu sunt daunatori toate partilor implicate (business/dezvoltare), fie doar din perspectiva filtrarii cerintelor in functie de cunostintele lor tehnice, a delay-urilor de comunicare datorate unor ambiguitati in specificatii si a livrabilelor alterate de nivelul tehnic al specificatiilor



Dragi PM : incercati sa intelegeti in care setup activeaza echipa PM din acea companie si adaptati-va. Daca considerati ca nu este workflow-ul corect, sunteti pe jobul gresit (sau chiar compania gresita).
Puteti incepe evolutia pe partea tehnica, va incurajez chiar! Si cand ajungeti un membru tehnic intr-o echipa de dezvoltare, va doresc sa nu interactionati cu PM mini-tehnicus, pentru ca o sa-l... bateti.

Succes!

luni, 2 martie 2015

Zoo Bucuresti

Weekndul asta, fiind 1 Martie, mi-am invins lenea specifica weekendului si am vizitat Zoo din Bucuresti.

Fiind prima data cand am facut acest lucru, voi lista primele impresii :
- ca orice gradina zoologica si aceasta ma deprima (poate fi si vremea frumoasa, tot nu-mi place sa vad animale (mai ales din cele mai mari - vulturi, lei, tigri, pitoni) ingraditi intr-o arie (sau intr-un volum, in cazul pasarilor) mic)

- toate animalele par triste, fara energie si sedate (in afara pestilor din acvarii)
- e plin de copii (lucru bun), dar si de parintii lor (mai mult sau mai putin educati - tatii ma "ingrozesc" cel mai mult, mai ales cei care fumeaza cu o fata din aia "da ba, sunt un tata bun, mi-am dus odraslele la Zoo...")
- majoritatea parintilor fumeaza (poate din cauza ca m-am lasat de fumat remarc si aceste lucruri)

- exista camere accesibile online (poate vrei sa te deprimi si noaptea, daca se vede ceva...)
- exista si QR codes + aplicatie - care foloseste ca un fel de ghid virtual (nu am folosit-o pentru ca-l stiu pe autor, dar am vazut pe unii care o foloseau)

- leul ragea (foarte cool, mai ales ca se auzea din orice parte a gradinii, chiar si din afara ; din pacate, spre finalul vizitei orice raget de-al leului auzit ma facea sa inteleg ca nu era un semnal pozitiv -> ma intrista)
- 3 x tigri (cu aceata ocazie am aflat ca tigrii sunt mai mari ca leii - nu numai la Zoo Bucuresti)

Vizitatorii (oamenii) erau dubiosi (putin spus) iar animalele erau ori "lipsa" (din cauza iernii, sper) sau triste. Cireasa de pe tort a fost o blonda de 2m+, purtand pantaloni din piele (la Zoo :) ) , care incerca sa cheme un tigru intr-un cadru fotografic (adica, incerca sa pozeze un tigru cu telefonul :) ) astfel :
"Pis-pis-pis".
Trist.