boBYTE CONSULTING

De ce intampinam rezistenta la schimbare?
Rezultatul schimbarii nu este intotdeauna perceput ca ceva benefic de catre nimeni. De ce sa schimb cand merge si asa? O schimbare in procesul de lucru poate afecta rezultatele acestui trimestru! Acestea sunt numai cateva din cele mai des utilizate formulari in momentul in care intervin schimbari. Psihologic vorbind, schimbarea determina modificarea unor automatisme din viata de zi cu zi, ceea ce poate produce fie un sentiment de teama, fie un sentiment de reticenta. Cel mai grav este sentimentul de nepasare, ceea ce poate indica o lipsa totala de interes a subiectului in ceea ce priveste efortul depus pentru schimbarea in mai bine
Schimbarea intr-un proiect software poate surveni din mai multe directii: beneficiarii proiectului realizeaza ca cerintele initiale nu se mai potrivesc cu nevoile actuale; echipa de dezvoltare trebuie sa faca fata unei schimbari majore in aplicatie; cei care vor utiliza aplicatia nu doresc inlocuirea celei existente cu aceasta. Sarcina echipei de proiect este sa orchestreze totusi schimbarea. Ce este de facut in astfel de situatii?
Ce este de facut?

Sa analizam putin prima situatie: intervine o cerere de schimbare in arhitectura / intefata / continutul aplicatiei cu impact major in livrarea proiectului in parametrii stabiliti initial. Situatie concreta: clientul realizeaza ca modulul de CRM dezvoltat contine gestionarea unui flux informational inconsistent cu realitatea din firma, drept pentru care lanseaza o cerere de schimbare in aplicatie.

Managerul de Proiect instiintat trebuie in primul rand sa identifice motivatia cererii de schimbare: este vorba despre un proces care, desi a fost modelat corect, a fost gresit implementat? Sau este vorba despre o analiza gresita de la inceput? Sau pur si simplu schimbarea din firma a generat o noua nevoie care trebuie acoperita cat mai urgent?

Oricare ar fi motivul trebuie livrata o solutie documentata si care trebuie acceptata de client, si abia dupa ce documentul poarta semnatura clientului se poate continua cu dezvoltarea solutiilor care sa corespunda schimbarii. In toate cazurile recomandam ca documentul propus clientului sa contina descrierea cat mai clara a problemei raportate, a solutiilor propuse (daca exista mai multe variante), si a impactului asupra proiectului (exprimat in cost financiar si de timp). Sugeram oferta de solutii multiple (in general trei ar trebui sa fie suficiente) astfel incat sa se ofere clientului posibilitatea de a decide, functie de buget sau timp, care este solutia ideala din punctul lui de vedere. In niciun caz nu propuneti solutii gen "nu se poate". Clientul multumit este clientul care primeste ceea ce si-a dorit pentru banii pe care i-a platit. In marea majoritate a cazurilor acestia se vor axa pe aspectul financiar al solutiei, si vor alege, in general, modalitatea de rezolvare a problemei care costa cel mai putin (doar si-au facut deja un buget si nu il pot suplimenta oricand si oricum). Nu cedati presiunilor de genul "am discutat la inceput costul proiectului, asa ca nu vreau sa aud de costuri suplimentare". Sunteti perfect indreptatiti sa cereti modificare de buget in cazul in care aveti o dovada a acceptantei planului initial de catre client. Schimbarea odata acceptata trebuie mai apoi comunicata echipei de dezolvoltare, ceea ce ne conduce la situatia a doua

Echipa de proiect este reticenta schimbarii in aplicatia deja dezvoltata. Este o problema cu care firmele de outsourcing se confrunta destul de des: ce facem cu programatorii care sunt in pragul unei revolte cauzate de desele schimbari care au loc in directia de dezvoltare? In general Managerul de Proiect trebuie sa inteleaga faptul ca programatorul se "ataseaza" de rezultatul muncii sale, iar schimbarea acestuia este perceputa, uneori, ca o lovitura luata personal (exista cazuri extreme de acest gen). Alti programatori isi motiveaza rezervarea fata de schimbarea cerintelor prin temerea de a nu fi trasi la raspundere pentru intarzierea pe care o pot genera proiectului implementand schimbarile cerute. Oricare ar fi motivele, rezultatul este aproape acelasi: incep sa apara frictiuni intre programatori si persoana care comunica nevoia de schimbare, frictiuni ce pot degenera in conflicte sau demisii.

Este imperativ necesar ca Managerul de Proiect sa se implice in dezamorsarea conflictelor aparute in echipa de dezvoltatori. Demisia unei persoane insarcinate cu dezvoltarea unei parti din aplicatie poate genera costuri mult mai mari decat cele anticipate, la pierderea credibilitatii Managerului de Proiect in fata echipei si, in cel mai rau caz, chiar la concedierea acestuia. Managerul de Proiect trebuie sa comunice echipei de dezvoltarea schimbarea, si mai ales motivatia acesteia. Evident ca in enuntarea propunerii de solutii ale schimbarii au fost deja implicate persoane tehnice din proiect (arhitectul sistemului, team-lead developeri, etc), deci exista sanse ca acestia sa fi comunicat deja echipei, corect sau distorsionat, posibilele schimbari ce pot fi aduse proiectului, caz in care puteti folosi acest lucru in avantajul vostru.: recomandam o discutie anterioara purtata cu acestea prin care sa incercati sa-i convingeti de faptul ca ati analizat in detaliu impactul asupra proiectului si ca noul plan de proiect contine modificarile necesare astfel incat sa-i castigati de partea voastra. Avand deja cativa aliati in schimbare, va va fi mult mai usor sa convingeti si restul echipei.

Ultima situatie este cea a Managerului de Proiect de implementare a solutiei software dezvoltata, cel care are "ingrata" misiune de a comunica viitorilor utilizatori ai sistemului ca au un nou tool de care trebuie sa se foloseasca in activitatea zilnica. Revenind la o situatie concreta: compania X tocmai a primit in folosinta sistemul A care va inlocui sitemul B existent de ceva vreme in firma; majoritatea angajatilor au deja experienta in utilizarea sistemului B, drept pentru care incearca orice in a-si convinge superiorii ca investitia nu a rentat.

Unul din motivele cel mai des invocate este acomodarea cu noul sistem: "Noul sistem informatic mi se pare mult mai complicat, din cauza noilor facilitati introduse". Afirmatia poate fi demontata de echipa de traineri aducand urmatoarele motive: sistemul nou este menit sa reduca timpul petrecut inainte cu introducerea informatiei in sistemul exitent (si ar face bine sa faca asta:) deoarece am analizat fluxul de informatie din cadrul companiei si am eliminat toate bottleneck-urile descoperite, sau evidentiati ergonomia noii interfete comparativ cu cea veche (presupunand ca aveti in echipa de dezvoltare un GUI guru), sau precizati faptul ca orice noutate dureaza pana devine automatism.

Un alt motiv invocat este "Aplicatia asta noua nu stie sa faca ... asa cum stiam eu ca se face in sistemul vechi". Da, intr-adevar, poate ca procedura de lucru s-a schimbat, insa trainerii trebuie sa demonstreze ca noua procedura de lucru este mult mai eficienta (sperand ca respectiva functionalitate nu a disparut cu desavarsire in noua versiune :). Formarea operatorilor sistemului poate fi un proces de durata, dar odata incheiat astfel de obiectii ar trebui sa dispara de la sine.

Oricum ar sta lucrurile incercati sa dati dovada de tact. Implementarea nu inseamna numai castigarea utilizatorilor de partea voastra, ci si a echipei de maintenanta (IT Helpdesk, Sysadmin, etc). Pregatiti programele de training adecvat pentru fiecare tip de utilizator. Si mai ales pregatiti perfect tema de acasa (procedura de import date, use-case-uri adecvate fiecarui utilizator, etc) pentru a nu fi pusi in situatia jenanta de a explica o functionalitate si a fi intrerupti de o eroare a sistemului care nu a fost tratata si duce la inchiderea completa a aplicatiei.