Așa cum am mai afirmat, în articolele noastre de blog ne propunem, pe lângă subiectele tehnice, să prezentăm și rolurile-cheie din echipa Arctic Stream și modul în care fiecare contribuie la succesul proiectelor. Articolul de astăzi, scris de Mihai Dumitru, Chief Architect, este continuarea celui publicat cu ceva timp în urmă, despre rolul unui arhitect IT și oferă o perspectivă autentică asupra parcursului profesional al unui arhitect de sistem, de la curiozitate și expunere, la comunicare, anticipare și leadership tehnic. Este un text autentic, plin de experiență acumulată în proiecte complexe și o lectură perfectă pentru cei care vor să înțeleagă ce înseamnă cu adevărat rolul și evoluția profesională a unui arhitect IT. Alături, avem o fotografie cu Mihai, surprins exact așa cum îl știm: calm, atent și mereu pregătit să construiască arhitecturi bine gândite, ancorate în realitatea proiectelor și aliniate nevoilor reale ale organizațiilor care le folosesc.
Scriam acum un an și ceva despre ce face un arhitect de sistem (https://www.arcticstream.ro/blog/role-of-an-architect-in-complex-projects). Între timp, după o altă conversație din postura de mentor wanna be, m-am gândit să scriu și cum poți ajunge unul. Acum, că Anca* v-a pus link-ul, prima poveste era ceva cu Harry Potter și pălăria vorbitoare. Unii ingineri ajung manageri, alții vânzători de tehnologie sau… așa se nimerește și în cele din urmă ajung arhitecți. Acum serios, cred că pentru a ajunge arhitect îți trebuie cel puțin două lucruri: expunere și leadership. Iar acestea, pentru mine, au plecat de la două trăsături din copilărie: curiozitatea și plăcerea de a explica. Plus o grămadă de alegeri norocoase. Să vedem.
Primul drum e de la curiozitate la expunere. Trebuie să îți placă să descoperi, să ai ocazia de a rezolva o problemă, să înveți teoria aplicabilă (cărți, certificări?) și să o aplici. Nu prea poți să îți alegi ce să înveți la început (faci ce ești pus să faci), dar e important să începi de undeva și să o faci bine. După care se va ivi ocazia să înveți și altceva bine și încă altceva care se leagă, întocmai ca straturile de ceapă. Dacă vrei și nu se întâmplă, poate că nu ești în locul potrivit (nu, nu e cazul la noi, ca să fie clar). La începuturi, strategia mea era să schimb dacă nu mai am ce să învăț și de la cine. Unde se termină învățatul? Niciodată n-o să știi tot, dar un nucleu de cunoștințe solide aduce încredere și respect. Oricum n-o să poți face ceva grandios de unul singur (dacă nu ești cumva un geniu), e vorba de a avea ce oferi în schimb într-un întreg mai mare. Nope, AI n-o să îți înlocuiască expertiza, tot trebuie să știi ce să îl întrebi și cum să îl verifici – altfel AI e drumul sigur spre mediocritate.
Dar expertiza și experiența tehnică nu e suficientă. De aici, peste câțiva ani, trebuie să îți faci ocazia să te extinzi lateral, pentru a căpăta context. În cariera de arhitect, contextul este esențial, vei face permanent zoom in și zoom out și trebuie să înțelegi ce este relevant pentru ceilalți. Prima extensie naturală e către managementul de proiect. Sistemul nu e o chestie statică: pleacă de undeva, evoluează în timp și în timpul transformării are constrângeri de personal, de timp și de buget – și managementul are și el teoria lui. Apoi următorul stop e la colegii de la vânzări (yup, trebuie să înțelegi de ce există proiectul și ce interes are fiecare în el). Nu strică nici cyber security (ok, ăsta e deja un alt mindset, dar ajută să îl înțelegi). Ideal, ar trebui să vezi mulți clienți și din domenii diferite (o să observi asemănări și deosebiri) și să participi în proiecte mari sau complicate (e ușor să reduci ceva mare atunci când înțelegi complexitatea și ratările, să crești optim ceva mic nu e deloc la fel de ușor). Bonus: contextul bate cunoștințele specializate în noua lume AI – orice problemă are un context pe care trebuie să îl înțelegi (iar AI nu are cum, nici dacă îi explici tu).
Unde ai putea acumula expunere? Nu la utilizatorul final, din cauza lipsei de varietate. La un ISP (Internet Service Provider) e mai greu în ziua de azi, din cauza hiperspecializării rolurilor. Poate la un MSP (Managed Service Provider), dar acolo riscul este mindset-ul de operațiuni (munca prea fragmentată, pe tichete). Tot la un integrator cred că încă apar ocaziile cele mai bune. Am zis de mindset: da, sunt mai multe: de cyber security, de operațiuni (orientat spre proces), de proiect. În caz că te întrebai de ce companiile din grup nu fuzionează: nu ar fi la fel de bune dacă ar face-o. Arhitectura presupune un mindset de proiect, mai puțin de proces, adică orientat spre integrare și înțelegerea întregului.
În cele din urmă, expunerea aduce experiență, iar experiența îmbunătățește anticiparea (deja știi în câte feluri ceva poate să crape și cât de mult ajunge să coste un lucru prost făcut sau neprevăzut la timp – sau, vorba lui Florin**, două greșeli bine plasate). Mă repet: sistemele nu sunt ceva static, ci pleacă de undeva (un sistem existent, niște cerințe de business), evoluează și posibil eșuează sau nu îndeplinesc așteptările în timp.
Al doilea drum paralel duce de la plăcerea de a explica, la comunicare și leadership (eu am fost un timid în copilărie, dar îmi plăcea să explic). Pe măsură ce știi, capeți încredere și preiei inițiativa. În meeting-uri, trebuie să poți să comunici așteptări și intenții (ca peste tot în parteneriate), să nu ai neclarități neexprimate (nu presupune, întreabă) și să asculți (nu vei afla chestii dacă te crezi mai deștept). Trebuie să poți sintetiza, să elimini sau să adaugi detalii după caz. În scris, trebuie să poți să spui esențialul cu cât mai puține cuvinte și cu o structură clară (aici, multora le-ar trebui un dezvăț de la beția cuvintelor pe care o învățăm la școală). Cum să faci asta? Cu mult exercițiu, recitind și urmărind structura și interesul destinatarului. Ce informații sunt așteptate? Unde se schimbă ideea? Ce vrem de la interlocutor? În ziua de azi suferim cu toții de atenție scăzută, iar mult text (mai ales generat de AI) nu ajută. Într-un text mai larg (documentație), de obicei structura este dată de prezentarea contextului (ce se dă și ce se cere), apoi de ordinea în care configurăm lucruri. Aici, multe desene clare ajută enorm.
Mai târziu, din postura de leader tehnic, trebuie să te asiguri că toți membrii proiectului au aceeași înțelegere (nu neapărat de acord cu tine, dar asta e și ideea, să afli ce e în dezacord și de ce). Comunicarea, scrisul și explicatul (ajută să fi fost trainer) aduc și structură în ideile și cunoștințele proprii.
Leadership-ul nu înseamnă nimic mai mult decât a prelua inițiativa (pentru că ai încredere, pentru că vrei să te apropii de rezultatul final, pentru că vrei ca lucrurile să fie făcute corect), așa că ce ai de făcut pentru început este să fii stăpân pe cunoștințele tale, să preiei inițiativa și, în general, să nu îți fie frică să greșești, să îți testezi ideile explicând și să recunoști atunci când greșești (yup, toți seniorii au făcut niște boacăne mari până au ajuns acolo).
În concluzie, experiența, anticiparea (unii îi spun viziune), structura, contextul, comunicarea și leadership-ul fac un arhitect bun, așa cum îl percep eu. Care este valoarea pe care o aduce? Face ca lucrurile să fie făcute temeinic (ce client nu apreciază asta?) și reduce riscurile (ceea ce crește marginea de profit). La sfârșitul zilei, îmi place să cred că am redus riscurile.
Iar dacă aceste perspective v-au făcut curioși despre cum abordăm noi proiectele și cum putem contribui la dezvoltarea infrastructurii dumneavoastră de date, echipa Arctic Stream vă stă la dispoziție. Ne puteți scrie oricând la [email protected].
* Anca Burgovszky – Marketing Manager, Arctic Stream
** Florin Mărginean – Director General, Arctic Stream