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!
Niciun comentariu:
Trimiteți un comentariu