by Inca de pe bancile scolii suntem invatati ce este bine si ce este rau, ca trebuie sa respectam legile, standardele, regulamentele, regulile scrise sau nescrise. Totusi, nu de putine ori intalnim situatii iesite din tipare pe care fiecare dintre noi le vede diferit, situatii neclare, neacoperite de nimic din ceea ce am invatat. Primul impuls al fiecaruia dintre noi este de a incerca sa le incadram in unul din tiparele stiute. Dar suntem siguri ca le incadram bine? In aceasta scurta povestire va provoc la evaluarea unei astfel de situatii, as spune, putin controversata…
Am un prieten care conduce mai multe proiecte de dezvoltare si testare software din cadrul unui program de dezvoltare a unui produs IT. Acest program este coordonat de catre client si cuprinde atat echipe ale clientului din Franta, cat si pe cele din firma romaneasca unde este project manager prietenul meu. In Franta se face dezvoltarea unor module software care se integreaza cu modulele dezvoltate in Romania iar totul este testat de catre echipa romanesca.
Cu mici poticniri la inceput datorate procesului de stabilire a canalelor de comunicare, proiectele din Romania erau, in general, “pe verde”. Curand, performantele echipei de testare au fost dovedite prin descoperirea a din ce in ce mai multe bug-uri reale, multe din ele provenind de la modulele dezvoltate in Franta. Toate erau logate intr-un sistem automat de issue tracking, analizate, rezolvate,
testate. Cu alte cuvinte, era un proces bine definit care se respecta.
La un moment dat, Program Managerul i-a cerut prietenului meu sa nu mai logeze chiar toate bug-urile pentru ca asta nu “dadea bine” in rapoartele pe care le prezenta superiorilor. Prin urmare, conform noilor cerinte ale reprezentantului clientului, echipele din Romania au inceput sa rezolve si probleme care nu apareau in sistemul de issue tracking.
A urmat un audit extern in care, pana la un moment dat, auditorul fost incantat de modul in care sunt urmate procesele in proiectele din Romania, considerandu-le ca “best practice” in domeniu. Intamplator, a mai descoperit ca un dezvoltator lucra la un bug care nu avea corespondent in acel sistem, urmand apoi sa descopere faptul ca aceasta era o practica folosita in mod curent. Prietenul meu a explicat ca este vorba de o cerinta expresa a clientului, aratandu-i auditorului chiar un email de la Program Manager. Cu toate acestea, auditorul nu a putut fi convins, considerand aceasta o neconformitate.
In concluzie, chiar daca nu era inclusa in contract, o nerespectare a acestei cerinte a clientului ar fi putut insemna un scor slab la KPI-ul de satisfactie a clientului putand duce pana la incetarea contractului. Respectarea ei a insemnat un audit ratat. Stim ca toate standardele de maturitate procesuala ne spun ca trebuie sa avem dovezi pentru orice activitate pe care o desfasuram, deci ar fi trebuit ca acele bug-uri sa fie inregistrate oricum. Pe de alta parte, tot aceste standarde ne spun ca trebuie sa respectam cerintele clientului si in acest caz, ar putea aparea o “derogare” de la proces. Ar fi mult mai multe de spus aici, pro si contra.
Prietenul meu era intr-o foarte mare dilema. A gresit sau nu a gresit? Ce trebuia sa faca pentru a respecta si cerinta clientului dar in acelasi timp si procesul definit?
P.S.: Am apreciat foarte mult solutia sugerata de o colega (CAPM) pe care am de gand sa o fac publica dupa ce obtin acordul ei.
Sunt (evident) mai multe aspecte de discutat aici :
– In primul rind daca (in cadrul metodologiei utilizate – probabil AGILE) , comunicarea agreata este de tip formal sau informal – pentru a putea stabili relevanta “discutiei prin e-mail” in privinta schimbarii / modificarii unor proceduri / procese (care ulterior au fost auditate) ;
– In al doilea rind, nu ai mentionat daca, integrarea modulelor dezvoltate in Franta necesita doar interfatarea (proiectarea interfetei cu modulele dezvoltate in Romania si cu aplicatia)sau exista un ACORD privind posibilitatea interventiei in structura modulelor respective (daca DA, cred ca acel acord trebuie FORMAL solicitat + acceptat). Tot aici, interventia in structura unui modul necesita cunoasterea specificatiilor (pt. modul si pt. aplicatie)
Auditorul a descoperit ca “un dezvoltator lucra la un bug care nu avea corespondent in acel sistem” deci “lucra neautorizat” cu alte cuvinte. In acest caz Program Managerul va trebui sa reevalueze situatia, respectiv sa decida startarea unui “control” asupra modulelor procesate (pentru a verifica daca acestea corespund cu specificatiile si daca nu au nicic nici in plus si nici in minus …) si un “audit” de nivel superior (ca sa poata localiza actiunea neautorizata).
In functie de modul in care vor fi interpretate rezultatele actiunilor de control si audit, poate rezulta o REZOLVARE …
Salut,
– cred trebuia discutat mai clar cu PgM impreuna cu dev+test lead aceasta problema si apoi luata o decizie (nu doar pe email);
– in general, testarea ar trebui sa aiba grija ca munca lor sa fie reflectata prin: buguri valide logate, buguri fixate inchise (poate conta si timpul de raspuns), test case-uri create corect dupa specificatii, test caseuri executate si progres, in sistemele folosite (de bug tracking, test case tracking, requirements etc.).
– dezvoltatorii daca gasesc o problema ei insisi in cod, trebuie sa ridice oficial problema, sa se vada ca lucreaza la ea; dupa ce e fixata problema, poate fi verificata chiar si de testeri.
In general, toate rapoartele ar trebui sa reflecte realiatea: daca sunt multe probleme asta inseamna calitate slaba si trebuie analizat cum se poate imbunatati.
Cum altfel se poate imbunatati calitatea daca nu avem o idee clara a tuturor problemelor? In plus o sa se ajunga sa se lucreze la taskuri care nici nu sunt stiute, dat fiind ca nu sunt raportate (cam acolo se ajunge)…iar de aici, va imaginati ce poate iesi.
Un lucru e cert: acest articol a fost incadrat bine la ‘Greseli in PM’ iar auditorul are dreptate 🙂
Numai bine.
@Marius Gaitan:
Procesele erau agreate formal cu clientul. Managerul de Program din Franta a cerut informal acea “derogare” pentru ca rapoartele sa arate “ceva mai bine”.
Din cate stiu, conform contractului, modulele dezvoltate in Franta puteau fi modificate daca nu erau conform cu specificatiile.
Managerul de Program a fost cel care a initiat “lucrul neautorizat”, ceea ce a creat problemele respective. Sunt de acord cu faptul ca el ar trebui sa initieze si rezolvarea situatiei prin inlaturararea cauzei.
@Bogdan Postelnicu:
Si eu am fost si sunt de acord cu faptul ca auditorul a avut dreptate.
Prietenul meu, Project Manager, ar fi trebuit sa incerce sa convinga Program Managerul de faptul ca aceasta cerinta nu era benefica proiectelor, chiar dimpotriva. Daca totusi, nu reusea, ar fi putut incerca sa gaseasca o cale de a inregistra acele bug-uri care nu erau acceptate in sistemul comun de issue tracking.
Cea mai simpla metoda a fost cea sugerata de o colega CAPM, aceea de a le inregistra si mentine intr-un fisier xls accesibil tuturor membrilor proiectelor din Romania. Bineinteles ca si aici ar fi aparut anumite probleme de protectie a informatiei inregistrate, de acces neautorizat etc dar care puteau fi rezolvate usor.
Ca sa clarific putin, si eu cred ca mai mult a ‘gresit’ PgM sa propuna asa ceva. Cat despre prietenul tau PMm probabil ca a fost mai mult intimidat de el si s-a gandit ca e mai bine sa-i faca pe plac pentru a mentine relatiile bune.
Referitor la a tine un fisier separat xls as spune ca e munca in plus, inca ceva de avut pe cap … exact ce ai mentionat si tu.
As mentiona ca daca totusi PgM, ca reprezentant al clientului, insista pe asta se putea merge banuiesc si pe un change request la contract in care sa apara oficial ca se cere asa ceva (stiu ca ar suna ciudat, dar tocmai si de asta poate asa il punea pe ganduri si pe PgM vazand implicarile). Eu unul nu as face ceva are ar putea avea impact asa important daca nu apare oficial.
Dar poate au mai fost si alti factori, nu as vrea sa intru prea mult in detalii.
Oricum, bafta multa in continuare.
Numai bine.
Asta e ! , PgM trebuia sa introduca un Change Request si numai dupa aprobarea de CCB ( Change Control Board) sa se deschida procedura acceptata pentru implementarea schimbarii (cf. Integrated Change Control) … dar, DACA este AGILE (eventual cu SCRUM) asta nu mai este chiar valabil, deoarece schimbarile se fac “on the fly” , deci PgM este responsabil de ceea ce a cerut in mail (deoarece, acceptanta lui tacita ulterioara arata ca A AGREAT noua procedura si A VALIDAT-o !!! (cu alte cuvinte a acceptat sa suporte consecintele aplicarii procedurii agreate … ca “asa e viata in Agile !)
“Marius Gaitan says: September 24, 2012 at 10:47 am
Asta e ! , PgM trebuia sa introduca un Change Request si numai dupa aprobarea de CCB ( Change Control Board) sa se deschida procedura acceptata pentru implementarea schimbarii (cf. Integrated Change Control) … dar, DACA este AGILE (eventual cu SCRUM) asta nu mai este chiar valabil, deoarece schimbarile se fac “on the fly” , deci PgM este responsabil de ceea ce a cerut in mail (deoarece, acceptanta lui tacita ulterioara arata ca A AGREAT noua procedura si A VALIDAT-o !!! (cu alte cuvinte a acceptat sa suporte consecintele aplicarii procedurii agreate … ca “asa e viata in Agile !)”
Marius, un CR pentru ce ? nimic nu s-a schimbat in proces. Dar acceptand ca asta ar fi fost solutia, un Change Request l-ar fi aratat cu degetul mult mai evident pe PrM decat o intelegere informala. Luand in considerare zicala “clientul nostru, stapanul nostru”, eu as fi aplicat urmatoarea strategie: pentru ca logarea in JIRA a erorilor incarca raportarea, o parte dintre ele conform intelegerii informale nu le-as fi logat dar le-as fi inregistrat in planul intern de proiect alocand resursa necesara pentru rezolvare. As fi aplicat o conventie de atribuire nume task sau si mai bine as fi bagat un cod suplimentar pe un camp nefolist in Project Plan si in felul asta in orice moment as fi putut obtine efortul facut de membrii echipei pentru rezolvarea erorilor neinregistrate in JIRA.
In toata activitatea mea de peste 10 ani ca PM, am incercat sa iau in seama doleantele clientului chiar daca uneori aceste doleante excedeau cadrul contractual. Parerea mea este ca pentru un PM, modul cum interactioneaza, abilitatile de comunicare si negociere a situatiilor aparute in proiect, de multe ori sunt mai importante decat bagajul sau de cunstinte tehnice.
@ Cornel ,
Daca “procesele erau agreate formal cu clientul” inseamna ca exista un formular (cu structura si continut agreat) in comunicarea intre client si PgM.
Ref. la specificatii, o intrebare ar fi legata de “daca tu cunosteai TOATE specificatiile (incl. cele pentru modulele dezvoltate in Franta) deoarece ai intervenit in structura lor (la nivel de cod) pentru eliminarea bugurilor. Problema care se deschide este : ridicarea bugurilor a pastrat consistenta produsului, corespunzatoare specificatiilor ? (de aici se pune problema cunoasterii complete a specificatiilor … )
De aceea am spus si repet : (cred) ca firma va starta o procedura de audit amanuntita (cu niste Check-Listuri punctuale) si o procedura de control.
Cornel nu cumva se lega de faptul ca auditul a descoperit ca se lucra la un bug care nu era in sistem, nu ca era un bug logat aiurea, necorespunzator specificatiilor produsuli/modului? sau poate gresesc eu…
Cat despre faptul ca ar fi Agile, dupa cum am zis ‘poate mai erau si alti factori de luat in considerare’, dar intr-adevar asta cam schimba lucrurile 🙂 .. totusi si acolo sunt niste meetinguri, dar nu as vrea sa intru in detalii pentru ca nu e OK o asemenea ‘decizie’ luata de PgM nici macar intr-un sistem Agile.
Numai bine.
Eu nu stiu de ce PgM se ocupa de integrarea produsului. Asta face in general SgM (senior) deoarece se ocupa de integrarea unui portofoliu de proiecte (considerind ca fiecare modul este un proiect). PgM trebuie sa se ocupe de optimizarea unei componente care este utilizata in mai multe portofolii (ex. un anumit modul … ?)
In acest caz, legatura PgM cu dezvoltatorul trebuie facuta prin SgM … chiar si in Agile.
@All
Scuze pentru raspunsul intarziat.
PgM nu avea niciun interes sa ridice un Change Request pentru modificarea procesului. Oficial, procesul trebuia sa fie acelasi ca si inainte. Singura diferenta era ca in felul acesta nu se respecta “pe alocuri”, “la mica intelegere”. Din punctul meu de vedere, aceasta incalca etica profesionala.
De asemenea, am uitat sa precizez ca nu era vorba de vreo metodologie Agile.
@Marius
[“Problema care se deschide este : ridicarea bugurilor a pastrat consistenta produsului, corespunzatoare specificatiilor ?”]
Din cate stiu, bugurile erau ridicate conform specificatiilor. Singura problema era ca nu erau logate chiar toate.
[“Eu nu stiu de ce PgM se ocupa de integrarea produsului.”]
PgM conduce programul care are ca misiune dezvoltarea unui anumit produs si care include mai multe proiecte (legate intre ele, evident). Bineinteles ca nu se ocupa in mod direct de integrarea componentelor produsului dar este foarte interesat ca ea sa iasa bine.
@Bogdan
[“auditul a descoperit ca se lucra la un bug care nu era in sistem, nu ca era un bug logat aiurea, necorespunzator specificatiilor produsuli/modului?”]
Auditul extern a descoperit un bug care nu era logat nicaieri si, dupa aceea, faptul ca nu era un caz singular.
@ Cornel
De unde poti sa FII SIGUR ca bugurile erau ridicate cf. specificatiilor ? AI avut acces la Cerinte ? si la toate specificatiile produsului final ?
Chestia cu “nu erau logate ” poate afecta integritatea unui segment sin produsul final ?
Pe de alta parte , toata “povestea” asta care a plecat de la o comunicare defectuasa (PgM a agreat o discutie si a tolerat o stare de fapt ce incalca regulile de baza – Ground Rules). Vrea nu vrea, tacit este implicat, deoarece a APROBAT TACIT (si tacerea este un raspuns) acest mod de lucru, mai mult decit atit, acoperind niste probleme care clar ERAU ALE LUI !!!
Sunt curios : cum arata matricea RACI ??? cine trebuia sa faca … si pe cine a acoperit PgM cind a cerut sa nu fie logate toate bugurile ??? Este o persoana (sau mai multe) care erau acoperite / tolerate de PgM … de ce oare ???
Concluzionind, matricea RACI trebuie sa ne arate cine si ce trebuia sa faca. Daca a fost o greseala privind modul in care ai actionat : raspunsul meu este DA. Dar vina este share-uita cu PgM si cei care lucrau la modulele cu bug-uri. Iar vina nr. 1 este a PgM deoarece STIA ! (El a solicitat, a vazut , a tolerat … deci a aprobat tacit !). Organigrama proiectului si Raci poate spune si sustine exact spusele de mai sus.
@Marius
Neavand legatura cu vreunul dintre proiecte, nu am cum sa stiu cum arata specificatiile dar ma bazez pe ceea ce mi-a spus prietenul meu. A primit neconformitate pentru buguri ne-logate (nerespectare proces). Nu am auzit sa fi fost probleme din alte cauze. Nu stiu cat de relevant ar fi, in cazul problemei prezentate, faptul ca ne-logarea unor bug-uri afecteaza sau nu niste module sau intregul produs.
In alta ordine de idei, asa cum am scris mai sus, PgM nu a agreat sau tolerat, ci el a creat aceasta situatie (cu ajutorul Project Managerului 🙂 Este primul vinovat nu pentru ca “stia”, ci pentru ca a initiat “ilegalitatea”. Intr-adevar, vazand matricea RACI, am putea sa ne dam seama si pe cine a vrut sa acopere. Pe de alta parte, prietenul meu (PM) are si el o mare parte din vina pentru ca transmis mai departe mesajul si a tolerat incalcarea eticii profesionale.
@Cornel: asta ma gandeam si eu, ca aici este vorba de faptul ca PgM a facut un ‘silent request’ sa nu se mai logheze bugurile in sistemul oficial.
@Marius: si eu sunt de acord cu ce spui, dar cred ca asta este o discutie separata… Referitor la bugurile care nu respecta specificatiile.
Dupa cum spuneam, eu vad treaba clara, dat fiind ca nici Agile nu e: PgM nu a procedat corect cerand acest lucru neoficial (adica nu printr-un change request) si atunci nu prea trebuia acceptat de PM asa usor 🙂
Normal ca PgM nu cred ca ar fi acceptat un change request si tocmai de aceea ca PM poate insistam pe asta ca sa vada cat de ‘serioasa’ e treaba: asta ar fi aratat ca ce cere el oficial e o incalcare a mai multor reguli: de etica, profesionale si probabil si contractuale.
Daca era dispus sa ‘plateasca’ el pentru asta, atunci OK dar numai in mod oficial.
Numai bine
Ca PgM a gresit cred ca este evident. Project managerul insa a gresit si el, acceptand prea usor aceasta cerinta. Cateva posibilitati (nu neaparat ideale) pe care le vad eu:
1. o discutie cu PgM in in care ii putea explica ca el ca ProjM va trimite din Romania rapoartele reale, dupa care PgM le poate prezenta cui si cum vrea.
2. sugestia de a folosi un alt tool de bug tracking in paralel, chiar si un excel (evident ca ideea de a rezolva buguri nelogate nicaieri poate duce usor la scapare proiectului de sub control), evident insa cu o crestere a costurilor, duratei etc. In functie de contractul sau starea in care era proiectul poate ca un delay nu ar fi reprezentat o problema asa mare
3. o discutie deschisa pentru a incerca sa gaseasca o rezolvare de comun acord. De exemplu daca respectivul client isi dorea doar sa apara mai putine buguri in rapoarte, s-ar fi putut de exemplu grupa bugurile asemanatoare in buguri mai complexe.
@ Liviu,
Mi-a placut ideea cu gruparea bug-urilor 🙂 … poate sa se initieze un proiect pentru asta 🙂
Eu in continuare cred ca rezolvarea este una singura : rezultatul auditului va fi corectarea procedurii si (poate) adaugarea a citeva procese suplimentare (de “etanseizare” … pt. “cicatrizare” + un checklist nou) care sa elimine pe viitor probleme similare. Procedura completata va face obiectul unui Change Request pt. acest contract, astfel ca pe viitor nu se va mai intimpla.
PS Un nou AUDIT si un CONTROL … cred ca sunt maxim posibile !