Project manager

Mosotti, on 10 aprilie 2022 - 08:59, said:

Multe proiecte au un   astfel mod de lucru. Se suspecteaza faptul ca astfel de proiecte care in mod normal intr-o economie normala (bazata pe performanta) nu ar mai trebui sa exista sunt tinute  in viata fie pt ca se spala bani negri prin bugetele echipelor fie  doar existenta acelei echipe sustine in viata un  lant de manageri din topul management care fac politica(adica in realitate sunt politicieni ,si locul lor de munca este garantat de partid)

Quote

Daca este senior si isi stie valoarea, ii prezinta  "fisa postului de lucru" unde sunt in scris atributiile pentru care este platit.
Daca el accepta sa faca unele chestii care nu sunt in fisa postului de lucru, este strict raspunderea lui.
Evident din moment ce acele taskuri nu sunt in fisa postului de lucru , nu poate sa ceara legal bani pt acele taskuri si nici ore suplimentare pentru acele taskuri.
Deci o face gratis,  din "altruism" colegial.

Quote

Aici e rolul BPO/PO  + PL sa protejeze echipa fie de incursiunile clientului (se razgandeste in timp ce acel feature este in curs de implementare) sau de alte incursiuni
ale altor echipe in "bucataria" lor interna.

Quote

Agile-ul la romani este complet diferit de Agile-ul asa cum a fost proiectat din carti. Agile-ul din carti ar merge corect si in lumea reala daca toti membrii echipei ar fi fost
alesi in mod meritocrat, si asta pornind de la managerii de sus.

Problema e ca la noii romanii se aplica stilul balcanic de cumetrii si asta ajunge intr-o mare masursa sa influenteze implementarea Agile.
De mult ori la noi Agile seamana cu "Waterfall in sprinturi" ceea ce nu ar trebui sa fie deloc asa.

Quote

Unele cerinte de post specifica sa stii design patterns tocmai ca sa nu se intample acest lucru. Ce nu specifica este ca de multe ori vei mosteni un proiect al carui cod
sursa nu respecta de la incepetul  principiile SOLID. Si degeaba o arde devul cu design patternuri. Nimic nu va fi stabil daca fundatia nu este stabila.

Daca le ceri buget pt refactorizare, n-o sa se aprobe desi echipa ar avea buget suficient pt asa ceva, din urmatorul motiv. Buget pt refactorizare inseamna ca cineva acolo sus din management nu si-a facut datoria si a dat OK -GO la o echipa care nu a fost pregatita tehnic sa implementeze complexitatea reala a proiectului
=> acel manager daca semneaza buget de refactorizare => papa prima de performanta care pt top management este destul de insemnata(bani seriosi)

RedDev, on 09 aprilie 2022 - 23:20, said:

Este specificul balcanic sa ne dam cu parerile in domenii in care nu suntem calificati.
Daca mecanicul ala decide ca trebuie sa desfaca blocul motor. inseamna ca are el un motiv.Tu n-ai nici o calificare sa te bagi .

Daca dupa reparatie suspectezi ca a fost inselat fie la pret fie la calitatea executiei poti solicita o contraexpertiza. Si daca contraexpertiza confirma
banuielile tale , primul service sunt buni de plata si ii dai judecata pt dauna materiale de isi inchid aia firma la cat trebuie sa-ti plateasca.

neagu_laurentiu, on 08 aprilie 2022 - 14:29, said:

Nici pomeneala. O buna prietena a fost Project Manager vreo 15 ani la Fundatia Copiii Nostri.  Nu stie nici o programare. In schimb stia cum se puna la dipozitie si sa coordoneze resursele de care dispunea in diversele proiecte desfasurate. Plus raportari semestriale, bi-anuale, anuale, sa fie pe faza cand vine auditul si altele asemenea.

Eu ma retrag din discutie. Am inteles mai bine care e ecosistemul Project Managerului si toata partea abstracta dar prea se intra in atacuri la persoana.

Exista companii si companii. Eu sunt multumit unde lucrez, programul de lucru e o superb, 100% remote, salariul e excelent si vine mereu la timp si oamenii sunt seriosi si vor sa ne dezvoltam. Da, firma nu are know-how pentru proiecte software, nu avem bani sa angajam o serie de oameni, dar mergem inainte si poate la un moment dat o sa avem o organigrama ce ne va permite sa facem doar un lucru fiecare.

Edited by RedDev, 10 April 2022 - 15:18.

AlaDinCopac, on 08 aprilie 2022 - 19:08, said:

Pai si cum apreciezi riscu daca nu stii sa cantaresti cat stie fiecare si cam in cat timp va termina o functionalitate? adica nu ai o latura tehnica sa intelegi ce face proiectul.
Te lasi pe estimarea dezvoltatorului? Ok, daca nu ii iesa extimarea ce faci? il bagi in sedinta si il faci cu ou si otet ca el e vinovat?

Ce doresc sa zic e ca un  manager isi asuma riscul  pentru subordoantii lui in fata clientului.
In programare managerul nu trebuie sa programeze, trebuie sa delege pe cine e potrivit  si sa deblocheze unde e nevoie de resurse sau informatii; astfel daca nu stii sa apreciezi complexitattea unui proiect sau  cat stie/livreaza fiecare angajat  e cam dificil sa faci estimari si  sa apreciezi riscuri.
Dar in Romania se poarta orice, estimari fac toti si managerul doar imparte taskuri, daca e buget  se iau oameni si se acopera munca cu altii mai buni si pt cei slabi.

Sa faci management pe un domeniu care nu il intelegi macar pe jumatate cred ca e cam imposibil de estimat si bugetat.

Edited by MarianG, 10 April 2022 - 18:49.

Estimările le face dezvoltatorul iar PM - ul nu trebuie neapărat să ia de bun, poate să ceară să detalieze cum a ajuns la acea estimare. Trebuie să înțeleagă ce se livrează, însă nu trebuie să știe cod, pentru că nu este verificator de cod.

Dacă au mai lucrat împreună în acea formulă și pe alte proiecte în trecut și exista în continuare probleme cu estimările, atunci dezvoltatorul ăla are o problema iar PM-ul trebuie să semnaleze acest lucru celui care sponsorizează proiectul.

PM-ul dubleaza minim estimarea

Contingency

AlaDinCopac, on 09 aprilie 2022 - 22:57, said:

Ideal asa e ... in realitate insa pe multe proiecte nu e asa din motive de costuri. Si atunci tech lead-ul, project managerul si scrum masterul sunt una si aceeasi persoana. Daca e proiect intern e si product owner de multe ori.

Eu am intalnit multe modele de proiecte, la unele clientul intra in sprint planning si facea el taskurile si propunea ce sa intre in sprint (dar echipa putea sa nu accepte tot), project managerul era atehnic si doar urmarea indeplinirea targetului/sarcinilor, technical managerul lua decizii de arhitectura/facea reiew-uri la PR-uri si scria si cod ... pe alte proiecte insa era un singur om care facea si taskurile, lua decizii de arhitectura, facea review-uri la cod, era scrum master si mai scria si cod cat mai apuca.

Zyx, on 10 aprilie 2022 - 18:09, said:

Dar nu-l apreciaza PM-ul , ci programatorul ci prin metodologia Agile. Programatorul isi estimeaza complexitatea fiecarui task in story-points( daca lucreaza pe Sprinturi) .
Story-Points(SP) se dau  conform sirului lui Fibonnacci .De asmeeni aici mai intra DoR si DoD pt fiecare task.
Mai multe detalii aici https://www.mountain...re-story-points
si aici [ https://www.youtube-nocookie.com/embed/jaqiXSp-D8E?feature=oembed - Pentru incarcare in pagina (embed) Click aici ]

Poti avea Agile Sprint, Agile Kanban, Agile Scrumban. Un programator  senior care lucreaza in mediul Agile de obicei a cam trecut de-a lungul carierei sale prin toate.

La sfarsit de Sprint se face retrospectiva si frameworul JIRA , iti face raportul de performanta intre ceea ce ai declarat ca faci si ceea ce ai facut.
Acel grafic se anexeaza la performanta ta trimestriala. SI odata la 3 luni se scot graficile si pe baza lor esti evaluat.  (ca la scoala cu sistemeul de teze)

Quote

Daca nu are alte motive tehnice din cauza caruia nu i-a iesit  + daca nu a cerut ajutor la o chestie care s-a blocat (si a stat asa sa treaca timpul) desi stia ca se aproprie sfarsitul sprintului si mai are si alte taskuri de facut), cam da, isi ia warninguri .(Nu a livrat ceea ce a promis, nu stie inca sa se evalueze , nu stie sa comunice cu echipa problemele importante, pune mai presus orgoliul sau personal decat imaginea echipei, nu este conform
cu graficul de performanta a obiectivelor individuale pe care l-a semnat la inceput de an).

Quote

Nu chiar asa.Riscul unei echipe fata de client este impartit astfel: BPO +PO +PL(PM)
Clientul nu ia legatura cu programtorul sub nici o forma. Echipa  tehnica nici macar nu stie cine este clientul.La echipa tehnica ajung problemele clientului filtratre insa
prin sita BPO+PO+PL.

Quote

Nicidecum , nu doar ca este posbil dar daca este implementat ca ala carte  merge ceas. Managerul trebuie sa evalueze riscuri indiferent de originea lor .
Pt asta de obicei exista un curs numit MBA(Master Business Administration)

utopium, on 10 aprilie 2022 - 21:31, said:

Dupa pararea mea, asta e stil haotic si as sta departe de o astfel de echipa.

Quote

Probabil ca la firmele  mici se intampla, nu cunosc.Oriunde am lucrat pana acum, clientul nici macar nu avea accessul al boardul echipei, doarece nu are voie sa aiba access.

RedDev, on 10 aprilie 2022 - 15:16, said:

Categoric,  iar Agile nu este singurul sistem de project management pe lumea asta si nu este obligatoriu ca toata lumea sa-l implementeze.
Pe de alta parte  o metodologie Agile care este implementata gresit poate face mai mult rau decat bine.

Apropos:acum la moda in lumea managementului mai toti PM o ard pe SAFe Scalled Agile.
https://www.scaledagileframework.com/
Din cat am inteles de la altii, o certificare in SAFe poate aduce un boost de bani la salariu sau la negociera salariului la un interviu.(Daca esti PL/PM)

Mosotti, on 10 aprilie 2022 - 19:25, said:

Depinde daca are curajul.

george_alexandru, on 10 aprilie 2022 - 20:27, said:

Doar daca are destul experienta sa-si sustina in fata clientului dead-line-ul(in cazul in care clientul face mutre)

AlaDinCopac, on 10 aprilie 2022 - 23:53, said:

Daca n-are curaj atunci tripleaza estimarea, ca sa fie sigur ca ajunge si dupa taieri

Mosotti, on 10 aprilie 2022 - 19:25, said:

In realitate PM cam trebuie sa faca pe dracu'n patru sa se incadreze in deadline-ul clientului.

La mine, chiar daca nu sunt PM, uneori mai fac estimari. Peste ce scot de la dezvoltatori, dupa ce trecem impreuna in detaliu prin ce avem de livrat (adica nu cer o cifra si aia e), mai pun de la mine o marja, in functie de cat de complex e proiectul si care sunt riscurile. 10-30% de regula. Peste asta e ala care se ocupa de partea de vanzare si care pune cat are chef, sau mai bine zis cat vrea sa-i ia clientului.

CptPix, on 08 aprilie 2022 - 14:26, said:

ai citit PMBOK® guide?

george_alexandru, on 11 aprilie 2022 - 13:04, said:

Estimarile le fac cei care sunt specialisti pe bucata lor si se duc cu ele mai departe catre PM, nu le face PM-ul.

PM-ul poate sa le challenge-uiasca (eu mai fac asta) apoi le impacheteaza si adauga si partea ce tine de alte activitati. Activatile de PM si PMO, de exemplu, trebuie si ele bugetate, iar alea nu le ofera dezvoltatorii.

Edited by george_alexandru, 11 April 2022 - 13:58.

Da, asta ar trebui sa fie rolul unui PM.

AlexEn, on 11 aprilie 2022 - 12:58, said:

Deadline-ul se determina in functie de niste estimari, nu vine clientul si zice "vreau un program, joia viitoare" si atunci toti zic "OK, se face, no problemo". Daca se intimpla asta esti inconjurat de dobitoci si oricum n-o sa iasa nimic pina la deadline sau o sa iasa un kktzoi. Nu ma indoiesc ca in realitate se intimpla asa de multe ori, de-aia dau gherla 70% din proiecte. Clienti cu asteptari ireale si oameni slabi care nu-s in stare sa spuna NU. De-aia fac aia in industria de jocuri crunch-uri pina se sinucid sau se dilesc. Toti vor repede, ieftin si bun, da cumva asa ceva nu se poate.

Mosotti, on 11 aprilie 2022 - 14:49, said:

La unul dintre service-urile auto la care mergeam acum ceva ani scria asa:
"In acest service prestam lucrari ieftine, bune si rapide.
Lucrarile ieftine si bune nu sunt rapide.
Lucrarile ieftine si rapide nu sunt bune.
Lucrarile rapide si bune nu sunt ieftine."

Edited by utopium, 11 April 2022 - 16:34.