Impactul inteligenței artificiale asupra resurselor umane
septembrie 10, 2024Alexandru Franzen
,,Viața este ca mersul pe bicicletă. Pentru a-ți menține echilibrul trebuie să continui să mergi înainte.’’ – Albert Einstein
CITEȘTE MAI MULTÎntr-o lume în care schimbarea este frecventă și rapidă, ce putem face ca să rămânem în control?
Citește articolul“When the variety or complexity of the environment exceeds
the capacity of the system (natural or artificial)
the environment will dominate
and ultimately destroy the system.”
– Statement of “Ashby’s Law”, W. Ross Ashby
Care este asemănarea dintre implementarea unui proiect și urcatul pe munte?
Am folosit această întrebare pentru a deschide una dintre prezentările pe care le-am susținut pe tema managementului de proiecte. Căutam să atrag atenția publicului și să setez o relație deschisă și mai jucăușă înainte de a intra în „subiectele grele și serioase”. Cineva din public urma să întrebe „Care?”, eu să răspund „Mie-mi plac ambele.” continuând cu întrebarea „Dar care este diferența?” și răspunsul „Azi vom povesti doar despre implementarea proiectelor”. Însă știți ce se spune despre planurile făcute de acasă… cineva a ridicat mâna și a spus „Odată ajuns la final drumul pare diferit de cum arăta când erai la început.” Un răspuns neașteptat și excelent.
Reflectând, după prezentare, am reușit să găsesc chiar mai multe asemănări: există tot timpul diverse căi de a ajunge la destinație, iar unele sunt mai eficiente decât altele; trebuie să fii bine pregătit să înfrunți mediul care te va testa constant și în moduri neașteptate (și garantat dacă ești suficient de activ îți va preda lecții pe care nu le vei uita) și, poate cea mai importantă asemănare pentru scopul acestui text, atât urcatul pe munte cât și implementarea proiectelor dezvoltă abilități care sunt universal valoroase și care te pot ajuta mult în alte arii ale vieții de zi cu zi.
Și, la fel cum Everestul este foarte popular în rândul montaniarzilor, și în rândul managerilor de proiect există un munte atrăgător și cu provocări specifice de urcat. El se numește Agile Project Management. Așadar rândurile următoare se vor concentra în jurul a două idei principale:
Se cuvine însă să fac o ultimă precizare importantă. Lumea proiectelor este incredibil de largă și diversă, fiecare proiect fiind o experiență unică. În fața acestei multitudini de posibilități Agile este una dintre metodologiile care ne pot ajuta la implementarea proiectelor. De cele mai multe ori găsim termenul asociat în complementaritate cu metodologiile de management de proiect Tradiționale (sau Waterfall) .
Alegerea unei metodologii sau a celeilalte presupune o înțelegere aprofundată asupra industriei în care urmează să fie implementat proiectul, complexitatea mediului din acea industrie, dacă cunoaștem sau nu soluția pe care dorim să o implementăm, precum și care este nivelul de implicare pe care vrem să-l acordăm actorilor conecși proiectului : clienți sau alți terți.
Metodologiile Agile se potrivesc proiectelor care prin natura lor sunt expuse unui grad mare de incertitudine. Dacă dezvoltăm un proiect inovativ al cărei soluție finală o putem intui, dar nu estima 100%, dacă în acest proces avem nevoie să construim mai multe iterații ale soluției și dacă pentru aceste etape de dezvoltare trebuie să implicăm clienții, atunci cu siguranță vom favoriza Agile, nu Waterfall. Ar fi însă o greșeală să încercăm să lucrăm Agile pe un proiect în care ne dorim să montăm ferestre PVC cu geam termopan unei case. Acolo cunoaștem soluția, putem estima foarte clar perioada de proiect, cunoaștem procesele, și dacă ajungem la iterații înseamnă că am greșit ceva la prima montare.
Ce vreau să vă spun este că, deși acest articol va aduce o lumină foarte favorabilă metodologiilor Agile, nu trebuie să cădem în capcana în care să credem că aceste metodologii sunt răspunsul standard spre care ne îndreptăm în orice caz și pentru orice proiect. Ba mai mult, toate companiile, chiar și cele mai inovative dintre ele, vor tinde în mod natural să transforme în timp proiectele Agile în proiecte tradiționale de tip Waterfall. Se întâmplă asta datorită procesului de descoperire și învățare care are loc după fiecare proiect pe care-l executăm, și, executând proiecte similare, soluțiile, procesele și rezultatele finale ajung să ne fie din ce în ce mai clare. Deci și metodologiile de care avem nevoie sunt mai degrabă unele care gravitează spre standardizare și predictibilitate.
În realitate, de la caz la caz, companiile aleg să folosească fie abordări mai înclinate spre Waterfall fie abordări mai înclinate spre Agile, iar de cele mai multe ori regăsim îmbinări unice între cele două.
Agile – dincolo de buzz word
În contextul în care tehnologia evoluează rapid, ciclul de viață al produselor și serviciilor scade iar personalizarea pentru client joacă un rol foarte important, și mediul de dezvoltare și implementare al proiectelor se schimbă.
Metodologiile agile (en: agile methodologies) de abordare al proiectelor, originare în echipele de dezvoltare software, au devenit foarte atrăgătoare pentru o gamă largă de companii, echipe și proiecte. În mediul actual toată lumea, de la startup-uri la mari companii, de la ong-uri și instituții de stat, își dorește să lucreze Agile!
Însă experiența acumulată de mine în urma interacțiunilor cu diverse medii îmi semnalează o discrepanță între entitățile care-și doresc să lucreze Agile și cele care reușesc cu adevărat să facă asta. Și asta nu se întâmplă pentru că nu încearcă, pentru că nu folosesc metodologii agile, pentru că nu-și organizează munca în Sprint-uri sau nu au un Scrum Master. De cele mai multe ori le fac pe toate acestea, și nu devin Agile în ciuda eforturilor pe care le fac. De ce se întâmplă asta? Pentru a răspunde trebuie să înțelegem că Agile este mai mult decât suma metodologiilor folosite.
O broască pe care o aruncăm într-o oală cu apă care fierbe pe aragaz va sesiza pericolul și va sări afară. Dacă punem broasca în oală cât apa este încă rece, iar mai apoi aprindem focul sub oală broasca va rămâne acolo și până la urmă va muri. Ceea ce se întâmplă în cazul acesta ține de sistemul neuronal al broaștei. Modul în care se transmite informația de la pielea ei către sistemul central care ia deciziile, prin sinapse, funcționează corect în momentul în care sesizează diferențe mari de temperatură subite între mediul în care este înainte să fie în oala fierbinte și când intră în oală. El este însă ineficient în a detecta schimbările subtile și incrementale în temperatura apei. Cu alte cuvinte, broasca moare fără ca măcar să-și dea seama de pericol.
„Frumoasă poveste Vlad. Am învățat să facem supă de broaște, dar cu ce ne ajută asta când vorbim de Agile?” vă puteți gândi pe bună dreptate. Păi e simplu…de exemplu broasca este Nokia în 2007, iar apa care fierbe încet este piața care începe să popularizeze smartphone-urile. Un alt exemplu de la polul opus, când schimbările din mediu sunt rapide și sesizate de toți actorii care depun eforturi să se adapteze este criza Covid19. Pericolul a fost așa de evident încât fiecare companie de pe glob a luat măsuri pentru a se adapta și supraviețui contextului economic.
Așadar, ce este Agile?
Agile este în primul rând un mod de gândire și operare care trebuie educat și cultivat la nivel organizațional, de la cel mai înalt nivel decizional până la prima linie a interacțiunii cu mediul înconjurător (piața și clienții). Este înțelegerea ”adaptabilității rapide” ca o abilitate foarte valoroasă în contextul de schimbare rapidă a lumii din jurul nostru. Agile începe de la efortul conștient de a înțelege contextul de business al propriei companii în timp real, atât la nivel extern cât și la nivel intern, continuă cu educarea unui simț care recunoaște și comunică eficient schimbările mici și se finalizează cu selecția rațională a metodologiilor necesare pentru a gestiona eficient tot contextul. În mod evident construcția unui asemenea sistem cere eforturi strategice susținute din partea unei companii care este deja stabilită pe piață, și el pleacă tot timpul de la educația în acest spirit.
Principalele motive pentru care echipele, proiectele și companiile nu devin agile, deși își doresc sunt:
1. Implementează metodologii fără a înțelege „de ce-ul” din spate – văd că alte echipe sau companii lucreză în SPRINT-uri. Perfect, lucrăm și noi în SPRINT-uri fără să înțelegem dacă într-adevăr avem nevoie de asta.
2. Nivelurile de decizie și cel de execuție nu sunt armonizate – managerul gândește agil și construiește procese agile, însă echipa nu știe să le implementeze eficient pentru că nu e educată să lucreze așa, sau varianta în care echipele sunt cu adevărat Agile, însă informația pe care ele o transmit mai departe către nivelurile de decizie superioară nu este analizată corect. Cu alte cuvinte există o scindare între ”sistemul nervos central” al companiei și ”sistemul nervos periferic”. Cele două nu comunică eficient.
Așadar, putem concluziona că instrumentele și metodologiile agile folosite doar de dragul de a fi folosite vor fi tot timpul mai puțin eficiente decât instrumentele și metodologiile folosite cu sens în mâna echipelor care sunt educate să se adapteze în permanență condițiilor schimbătoare.
Un ultim gând aici: echipele agile sunt în general echipe mici ca număr de membri, însă dacă reușiți să construiți și să mențineți o astfel de echipă în interiorul business-ului vostru, veți avea ce poate valora mai mult decât întregi departamente.
”Bine Vlad, fumos până aici. Dar ce pot face eu mai concret ca să încep să lucrez mai agil?”
Să presupunem că ajungi luni dimineața la muncă și primul efort pe care-l faci, după tradiționalul small talk cu colegii și pregătirea ceștii de cafea, este să te întrebi „Eu ce am de făcut săptămâna aceasta?”
Un prim bun pas este să faci o listă de ”To Dos” care poate arăta în felul următor:
Observăm că această listă de ”To Dos” are câteva puncte pe ea, însă există posibilitatea ca aceste liste să adune foarte multe puncte în săptămânile aglomerate, în special în cazul în care ești cineva care are responsabilități și dincolo de propria-i persoană. Gestionezi o echipă la muncă? Ești părinte și ai copii? (Observăm că de multe ori sunt aproape echivalente). În aceste cazuri ai task-uri suplimentare sau cel puțin ai responsabilitate și față de task-uri pe care nu tu în mod direct ar trebui să le îndeplinești. E important să ne luăm timpul necesar ca această listă să fie una completă, cel puțin din perspectiva lucrurilor așa cum sunt ele luni dimineața.
Acum, avem opțiunea să ne apucăm direct de treabă și să începem să ne luptăm cu lista de To dos, item cu item, sau putem să facem un pas în spate și să ne întrebăm dacă nu ne putem îmbunătăți puțin perspectiva. Poate dorința de eficiență și organizare ne strecoară încă o întrebare în creier: ”Cu ce să încep?”. Și este una foarte bună. Cum am putea să organizăm multitudinea aceasta de task-uri într-o listă de priorități?
Pentru a răspunde la această întrebare ne este de foarte mare ajutor Matricea Eisenhower, care ne va organiza task-urile în cele 4 categorii: Importante și urgente, Importante dar nu urgente, Urgente dar nu importante și Neurgente și neimportante. Sugestia mea suplimentară este să le și organizăm pe Categorii (Personale / Profesionale) sau poate chiar pe proiecte dacă jonglăm cu mai multe.
În mod cert acum avem un nivel de claritate mai mare și știm de unde să începem. Cu toate acestea va mai apărea o provocare: cum putem monitoriza progresul și menține claritatea pe task-uri care nu sunt doar niște puncte de îndeplinit? Dacă ne uităm pe lista de mai sus, lucruri precum „Develop a new feature for the web application” cel mai probabil sunt mai complexe și se vor întinde pe o perioadă de timp mai mare decât săptămâna în curs. Și asta nu este ultima provocare pe care o vom întâmpina. Ce facem cu lucrurile noi care apar pe parcurs? Cu întârzierile? Cu lucrurile pe care trebuie să le facă alți oameni ca noi să le putem îndeplini pe ale noastre?
Acestea sunt lucruri de care invariabil te vei lovi, chiar și dacă nu lucrezi în Project Management. Pentru că ele fac parte din haosul care ne înconjoară în fiecare zi, iar să fi agil înseamnă să poți înfrunta haosul încrezător că vei fi în față de fiecare dată.
Ce m-a ajutat pe mine foarte mult, și ceea ce pot să recomand pentru că este un instrument foarte simplu de înțeles și folosit, care are și avantajele de a-ți oferi o mare doză de claritate și a te ajuta să înfrunți provocările descrise mai sus se numește Kanban Boards (tablourile Kanban).
În esentă, tablourile Kanban au două elemente:
-Liste
-Card-uri
Listele sunt coloanele tabloului, și ele reprezintă etapele unui procesului prin care trece un task de la stadiul de „avem asta de făcut” la stadiul de „am terminat de făcut asta”. Cel mai simplu process de descris este cel în 3 pași: To Do, In progress, Done.
Imaginea de mai jos exemplifică această organizare. Pentru acest articol am folosit ca demonstrație instrumentul Trello, fiind unul foarte simplu care se poate regăsi și în variantă gratuită online, însă aici sunt o multitudine de instrumente pe care le puteți folosi, important este să vă fie utile.
Desigur, în funcție de proiect și numărul de oameni implicați, procesul prin care trec task-urile poate fi mai complex, deci și numărul de liste și organizarea lor trebuie să reflecte asta.
De exemplu:
În acest caz, mă aștept ca în prima listă să regăsesc card-uri care să cuprindă informații importante despre proiect sau task-urile pe care le abordez. Documente de planificare, documente de buget, date de credențiale, link-uri și altele sunt doar câteva dintre exemplele posibile. Lista de „To Do” cuprinde task-urile pe care le-am identificat, dar nu le-am început încă, „In progress” pe cele aflate în desfășurare. „Ready for QA” sunt lucrurile finalizate care trebuie supusă unei verificări, iar „QA done” înseamnă că au trecut verificarea. Ce se întâmplă cu task-urile care nu trec de verificare însă? Simplu, ele se întorc în lista de „In progress”. În ultimul pas, task-urile trecut de verificare sunt semnalizate ca fiind încheiate prin mutarea lor în lista de ”Done”.
Acest proces pe care l-am descris poate fi unul foarte simplu care să creioneze flow-ul de lucru între o echipă de programare, o persoană care testează funcționalități și un manager de proiect, de exemplu, însă la fel de bine poate creiona flow-ul de lucru între părinți și copii când aceștia trebuie să-și facă temele, să se înscrie la ceva important, să ia o adeverință de la școală pentru bacalaureat…
Este foarte important să înțelegem că organizarea listelor este flexibilă și adaptabilă nevoilor noastre, însă are în spate un aspect esențial: PROCESUL. Procesul trebuie să fie fluid, să reflecte realitatea și să creeze claritate pentru părțile interesate care folosesc instrumentul. În crearea acestui proces, managerul de proiect folosește două abilități complementare: gândirea critică – care-i permite să se întrebe „Care este următoarea etapă cu acest task?” sau „Ce se poate îmtâmpla de aici?”, dar în același timp și empatia – abilitatea de a mă transpune în locul diferitelor persoane din echipa mea și a observa cum ar interacționează ele organic cu task-urile. Acestea două luate împreună îmi vor permite să creionez un proces eficient.
Card-urile sunt task-urile propriu-zise, însă în acest sistem sunt restructurate în așa fel încât să-mi ofere mai multe informații care mă ajută în îndeplinirea lor, dincolo de un simplu punct pe o listă de „To do”.
Începem simplu, prin transformarea fiecărei intrări din „To do”, într-un card care ajunge pe trello în Lista de „To do”, adică în etapa în care am identificat task-ul, dar nu am început să lucrez la el. Lucrurile vor arăta așa:
Acum, ce încep să fac este să „împodobesc” cardul cu informații. De exemplu, țin minte că am decis în urma filtrării prin Matricea Eisenhower o prioritate a task-urilor. Aceasta poate să se regăsească pe card-uri printr-un sistem de codare cu culori. Personal, folosesc Prio 0, Prio 1, Prio 2, pentru a evidenția primele 3 categorii de task-uri din Matricea Eisenhower. Cele nici urgente nici importante ar trebui eliminate.
Probabil după aplicarea codului de culori lucrurile vor arăta așa:
Acum, pentru eficientizare pot să le mut pe cele cu prioritate superioară în partea de sus a listei, față de celelalte. Obțin:
Acum, ce mai pot face este să lucrez la nivel de card ca să-l umplu cu informațiile potrivite. Pe card pot:
Ar trebui să folosesc aceste funcționalități astfel încât să-mi fac viața cât mai ușoară și mai clară pentru munca pe care urmează să o depun în continuare. Așa arată un card desfășurat pe care am început să pum informație:
Acum, după ce am făcut lista de „To Dos”, am prioritizat task-urile, am organizat procesul de liste prin metodologia de Kanban Boards, am încărcat cardurile și le-am detaliat cu toate informațiile relevante, pot spune că am o planificare bună pentru săptămâna care urmează. E încă luni dimineața și mă întreb dacă investiția de timp pe care am făcut-o în acest proces se merită? Răspunsul nu-l veți primi pe loc, ci în toate momentele în care:
Cu un ultim gând vă las: dacă vă atrage ce am descris în rândurile de mai sus, vi se pare interesant și vă doriți să aplicați, faceți asta. Dar faceți asta într-un mod asumat și disciplinat. Luați o săptămână de probă în care luni dimineața faceți procesul pe care l-am descris mai sus, iar mai apoi în fiecare început de zi de lucru a săptămânii vă luați 5 minute să deschideți Kanban Board-ul să vă întrebați „Ce trebuie făcut azi?”, iar la finalul zilei „Ce s-a făcut azi și trebuie actualizat?”. Dacă sunteți mulțumiți după prima săptămână mai încercați încă una, iar mai apoi poate ușor-ușor ajungeți la o lună de zile în care lucrați așa.
Cu timpul o să vedeți că simțiți procesul mai fluid, mai clar, lucrurile se așează armonios în zilele voastre de muncă, rezultatele sunt mai tangibile, atunci când haosul apare sunteți mai pregătiți să-i faceți față, iar în final veți putea concluziona singuri: „Am devenit puțin mai agili!”.