Acest text nu e scris cu AI și nici inspirat de ce au avut de zis alții pe Internet. E o poveste personală și imperfectă.

Ideea seriei de articole care urmează a apărut într-o zi când povesteam Ancăi, noua noastră colegă Marketing Manager, cum am ajuns să fac ce fac, și în general ce ne aseamănă și ce ne adună pe toți colegii în același loc, astfel încât să ne facem atât de bine treaba ca un întreg. Poate că și clienții ar vrea să știe, a revenit Anca mai târziu. Poate că e și ceva de învățat din atâta experiență colectivă.

Cariera în IT

Atunci când mi-am început cariera în IT, inginerii intrau în meserie din curiozitate și pasiune. Tot pasiunea împreună cu contextul au făcut ca fiecare să apuce pe câte o cale, de parcă Sorting Hat din Harry Potter își spusese cuvântul. În contextul unei firme de IT, unii și-au dorit adrenalina depanării, alții structura planificării și proiectării – sau pur și simplu ambiția din vânzări. Pe alții corporația i-a făcut șefi. Eu am avut șansa de a îmi pune pălăria de mai multe ori, și prin urmare de a mă dezvolta lateral. Așa mi-am format mai degrabă o gândire de consultant, decât de management de linie. 

Un lucru important a fost că atât eu, cât și majoritatea colegilor actuali nu am lucrat niciodată direct pentru utilizatorul final al tehnologiei, și asta mi-a permis să văd frecvent o altă stivă tehnologică și mod de a face lucrurile. Tot la fel ca și majoritatea colegilor, am trecut printr-o firmă de telecomunicații, și astfel am văzut tehnologia aplicată la scară mare. Pe scurt: un drum cu deschidere, schimbare frecventă de context, și cu structură și gândit la scară mare.

Pe de altă parte, clienții noștri sunt utilizatori finali ai tehnologiei. Un arhitect sau un expert IT competent nu ar avea de lucru constant la întreaga capacitate, iar pentru client nu ar avea sens economic. Cu alte cuvinte, dacă pentru un integrator de sisteme are sens să aibă experți în toate stadiile din ciclul de viață IT, pentru clienți nu are sens.

Ciclul de viață al unui sistem

Pentru a înțelege diversele roluri de care un integrator IT are nevoie, este necesară perspectiva ciclului de viață al unui sistem. Cisco îl vede ca: pregătire (identificare obiective), planificare (evaluarea stării inițiale versus cerințe), proiectare (în funcție de obiectivele de business și cerințele tehnice), implementare, operare și optimizare. Un arhitect este implicat în tot ciclul de viață (plan, build, manage). Deși percepția generală este că un arhitect doar proiectează, rolul său e de a elimina presupunerile și de a aduce focus și claritate în proiect pe întreaga sa durată (ce este important și corect de făcut și cât de fezabil este), atât către business, cât și către tehnic. De asemenea, un arhitect trebuie să își cunoască opțiunile și să fi avut experiență cu ele.

Un arhitect lucrează cu o organizație temporară de proiect, dar pe de altă are în vedere evoluția infrastructurii pe termen lung, și se asigură că derapajele sunt ținute sub control (cu alte cuvinte, se poziționează într-un sfătuitor de încredere pentru client). Pe de altă parte, nu orice proiect are nevoie de un arhitect. Deseori, acolo unde proiectul e bazat pe o singură tehnologie și cerințele sunt clare, un inginer expert poate prelua acest rol. La rândul său, arhitectul a fost și încă mai este expert în unul sau mai multe domenii (pentru că altfel nu și-ar putea argumenta opiniile tehnice), iar acolo unde nu este se bazează pe munca altor experți, atât dintre colegii săi cât și de la parteneri, dar tot trebuie să poată evalua opțiunile.

Interacțiunea arhitectului cu alte roluri

De-a lungul ciclului de viață al sistemului, arhitectul interacționează cu alți colegi ce au diferite roluri, dintre cea mai lungă bucată de drum cu managerul de proiect. Deși uneori rolurile se pot confunda, acesta este o altă persoană decât arhitectul. Arhitectul este liderul tehnic al proiectului, pe când managerul urmărește încadrarea în timp, buget și resurse (cu alte cuvinte, ține ritmul). Totuși, este răspunderea arhitectului să prevadă riscurile, să estimeze inițial costurile și resursele și să îi fie clară ordinea operațiilor și dependențele, pentru ca managerul de proiect să știe să le urmărească. În faza de operare, un service delivery manager va prelua rolul managerului de proiect, pentru că proiectul se va fi transformat în proces.

Arhitectul interacționează cu sponsorii proiectului pentru a înțelege obiectivele și constrângerile economice, în special în faza de planificare. Un sponsor este persoana din management (atât de la executant, cât și de la client) care este cea mai interesată de buna execuție a proiectului și care ia deciziile de business importante, legate de bani și riscuri. Apoi, începând cu proiectarea, arhitectul interacționează cu experții tehnici. În faza de implementare, arhitectul coordonează munca tehnică, înțelege logistica și poate participa la rândul sau în execuție cu partea sa de expertiză. Nu în ultimul rând, îndrumă corecțiile necesare în faza de operare și optimizare, pe baza feedback-ului primit de la client și de la colegii săi. Foarte important, bucla de feedback nu există numai în faza de operare, ci pornește de la planificare! Un proiect reușit va fi consumat multe discuții încă înainte de implementare, iar documentația trebuie începută tot înainte.

Un arhitect ar trebui să poată să pună întrebările relevante, să testeze, să sintetizeze, să prezinte și să scrie. În această capacitate, poate ajuta activitatea de pre-vânzări, de marketing sau de vânzări, acolo unde este nevoie.

Un arhitect nu este manager operațional. Echipa tehnică face parte dintr-o organizație permanentă, care împrumută experții sau inginerii de implementare proiectului, spre deosebire de echipa de proiect care este o organizație temporară. De aceea, există un rol de management separat pentru echipa de implementare. De asemenea, managerii de proiect au și ei propria organizare permanentă (PMO), la fel cum și arhitecții pot să o aibă (AMO), în funcție de mărimea organizației, diversitatea tehnologiilor acoperite, respectiv ponderea activităților de proiectare versus implementare și operațional. Nici organizația de pre-vânzări nu acoperă complet arhitectura, pentru ca ea nu urmărește tot ciclul de viață a unui sistem, și este concentrată mai degrabă pe activitatea de livrare de echipamente fără a fi parte dintr-un proiect.

În loc de concluzii

Dacă ar fi să dau câteva sfaturi în urma experienței câștigate, iată câteva care mi se par foarte importante:

• Nu presupune, întreabă.
• Fii deschis, nu ignora informația care nu se potrivește sau care contrazice ce știi.
• Păstrează tot timpul contextul în minte în timp ce te uiți la detalii, pentru că altfel te pierzi în detalii. A propos, orice generație de ingineri iubește contextul.
• Pune întrebări cu candoare, nu cu grija la ce pot crede ceilalți.
• Nu îți pune singur limite.
• Teoria (cursurile despre cum funcționează tehnologia), testarea, o gândire structurată și ordinea operațiilor sunt importante.
• Imaginează-ți proiectul în dinamica sa și du raționamentul până la capăt.
• Planifică mult și culege feedback.
• Nu te complica (KISS*), cunoaște-ți opțiunile, urmărește cele mai bune practici. În primul rând, infrastructura trebuie să fie ușor de depanat și de extins. Daca e ceva exotic (corner case), vei deschide un caz de lungă durată la TAC**, cel mai probabil.
• Deleagă! N-o să poți face totul singur și trebuie să își păstrezi mintea liberă pentru chestiunile importante, nu micro-management.
• Bazează-te pe experiența echipei, dar continuă să fii expert în aria ta. A propos, e valabil și pentru juniori: trebuie să te concentrezi să excelezi într-un anumit lucru, înainte de a adăuga următorul strat de cunoștințe.
• Nu ignora juniorii, păstrează ușa deschisă și investește timp să îi cunoști. Îți va păstra gândirea proaspătă.

* acronim pentru Keep It Simple, Stupid

** Technical Assistance Center