Ce este un manager de proiect tehnic?

Ce este un manager de proiect tehnic (TPM)? Răspunsul depinde de cine întrebi, spune Andi Blackwell, un consultant IT veteran și expert în operațiuni de afaceri. În calitate de director principal de management de proiect și produs al Toptal, Blackwell conduce echipa responsabilă de potrivirea managerilor de proiect cu înaltă calificare din rețeaua de independenți Toptal cu organizații care caută talent de top pentru inițiative specifice. În ultimii ani, ea a observat o creștere a cererii pentru TPM.

„Cu siguranță există o dezbatere în industria tehnologiei cu privire la ceea ce înseamnă de fapt acest termen”, spune Blackwell. „Există mulți oameni care se numesc manageri de proiect tehnici pentru că au lucrat foarte strâns cu o echipă de ingineri sau au condus o echipă tehnică din perspectiva managementului de proiect, dar nu asta căutăm.”

Definiția lui Toptal este mai specifică. Toți managerii de proiect din rețeaua Toptal sunt experți în abilități tradiționale de management de proiect, cum ar fi stabilirea scopului, bugetarea și gestionarea termenelor, precum și practicile de dezvoltare software Agile legate de livrarea iterativă și îmbunătățirea continuă. Ei au lucrat invariabil îndeaproape cu inginerii și ar putea, dacă li se cere, să antreneze și să ghideze o echipă Scrum.

Cu toate acestea, pentru a se califica ca TPM, aceștia trebuie să aibă un nivel suplimentar de experiență dincolo de gestionarea proceselor Agile și colaborarea cu dezvoltatorii: trebuie să fi fost ei înșiși dezvoltatori.

O combinație prețuită

Organizațiile mari și mici sunt din ce în ce mai interesate de această combinație specială de abilități. „Majoritatea startup-urilor nu pot angaja o persoană care poate face un singur lucru”, spune Blackwell, iar întreprinderile mai mari doresc să vadă „dezvoltator” sau „arhitect” în profilul unui candidat dacă angajează pentru un proiect de inginerie.

Chiar și în cazurile în care un client nu necesită în mod specific un manager de proiect cu experiență tehnică, bifarea casetei „dezvoltator” este un argument de vânzare major. Cineva care poate planifica și executa un proiect software, poate implementa și optimiza procese Agile și cod? Este o mare binefacere.

În realitate, totuși, nu se așteaptă ca TPM-urile să codifice - mulți nu au codificat de ani de zile. De ce, atunci, nevoia de experiență în programare?

TPM-urile sunt obligate să ia decizii tehnice, spune Blackwell: „Dacă nu aveți cel puțin o experiență practică relativ recentă cu o stivă tehnologică modernă, SDK (kit de dezvoltare software), arhitectură sau platformă de automatizare a testelor, atunci” potențial nu veți lua deciziile corecte. Nu vei avea credibilitate față de client pentru că nu ai mai folosit acele lucruri înainte.”

Lucrul cu echipe

Demonstrarea credibilității unui potențial client este un factor semnificativ în asigurarea angajamentelor, dar este doar primul obstacol. Odată atribuit unui proiect, un TPM trebuie să câștige rapid încrederea și respectul unei echipe tehnice.

Michael Poythress s-a apucat de programare când era adolescent. La 16 ani, a construit un site comercial pentru o afacere de publicitate imobiliară pe care a început-o împreună cu tatăl său. De atunci, este CEO și fondator al mai multor startup-uri. În 2018, s-a alăturat rețelei Toptal ca TPM și acum lucrează îndeaproape cu echipele de ingineri. „Dacă n-aș avea experiență cu codificarea, programatorii s-ar apuca de asta”, spune el. „Nu ar trage direct cu mine. Dar dacă îi provoc și le vorbesc ca un egal, există respect și un raport.”

Și experiența tehnologică este cea care contează mai mult decât titlul, spune Allen Takatsuka, un TPM Toptal cu sediul în Orange County, California: „Din ceea ce am văzut, „T” din TPM nu are nicio greutate pentru ingineri. Ei cred că este doar un alt manager de proiect care le va stabili întâlnirile și le va cere să completeze foi de calcul.”

Odată ce este stabilit un punct comun, însă, „aroma interacțiunii este foarte diferită. Este mai mult un parteneriat cu ingineria”, spune el.

Takatsuka a petrecut zeci de ani conducând echipe de inginerie mai devreme în viața sa profesională. El creditează această experiență pentru că și-a crescut abilitățile soft. „Este o abilitate de empatie puțin diferită”, spune el. „Trebuie să arăți că poți vorbi limba. Poți spune: „Întâlnesc de ce aveți aceste provocări pe baza lucrurilor tehnice care se întâmplă.”

Dan Allen, un consultant tehnologic din Vienna, Virginia, își descrie progresul în carieră drept „programator tip tip în cabină până la conducere tehnică la arhitect, director, VP, CTO, CIO”. De când s-a alăturat rețelei Toptal ca TPM în 2019, a fost ocupat, lucrând la 14 angajamente cu clienții.

„Rareori citesc cod. Aproape niciodată nu scriu cod”, spune el. „Dar au existat situații în care un dezvoltator rămâne blocat. Ei mă pot ghida prin arhitectură și pot vedea exact ce încearcă ei să facă și logica.”

El consideră că dinamica este utilă nu doar în cazurile marginale, ci și mai larg. „Echipa ta știe că pot veni la tine și vorbește, iar tu înțelegi cu adevărat ceea ce spun”, spune el. „Îi poți ajuta să ia în considerare toate complexitățile în cazul în care au omis ceva. Puteți fi o placă de sunet și puteți oferi feedback.”

Efectul multiplicator

Acest tip de feedback și înțelegere este important pentru mai mult decât pentru construirea unei relații. TPM-urile oferă o propunere de valoare diferită unei organizații. Ele servesc mai puțin ca canale pentru informații și mai mult ca surse de cunoștințe. Da, ei planifică, coordonează și comunică, dar ajută, de asemenea, clienții și echipele să lucreze prin decizii complexe de tehnologie.

„Aveți capacitatea de a fi obișnuit din punct de vedere tehnic”, spune Takatsuka. „Și asta adaugă valoare organizației, pentru că acum ai mai mult un efect multiplicator, decât doar organizarea și colaborarea.”

Takatsuka observă că TPM-urile trebuie să treacă prin mai puține cercuri pentru a rezolva probleme. În special, la organizațiile mai mari, un manager de program sau de proiect non-tehnic ar putea aborda o provocare tehnică prin identificarea jucătorilor relevanți și a părților interesate, oferind context, agregând informații și apoi analizând rezultatele pentru a lua o decizie. TPM-urile își pot aduce propriile cunoștințe.

„Puteți aborda riscurile mult mai eficient”, spune Oana Ciherean, un TPM cu sediul în Tokyo. „Și aceste riscuri pot veni din atât de multe locuri. Ele pot proveni din estimări greșite din partea echipei. Așa că poți spune: „Bine, sunt sigur că această bucată de cod nu va dura o săptămână să fie scrisă”, deoarece sunt într-adevăr două zile. Deci, puteți debloca oamenii. Pentru că ți-ai dat seama că sunt blocați și de aceea le ia cinci zile. Știi asta pentru că ai fost acolo și ai fost blocat.”

Găsirea echilibrului

Ciherean și-a început cariera ca dezvoltator, dar s-a mutat curând în managementul de proiect din dorința de a fi implicată în imaginea de ansamblu. În acele roluri, însă, ea a constatat că îi era dor de codare. Ea spune că Managementul Tehnic de Proiect oferă tot ce este mai bun din ambele lumi: „Îmi permite să fiu cu adevărat practic în tehnologie, dar și la nivel înalt, cu înțelegerea afacerii și a clienților și a ceea ce își doresc aceștia în funcții.”

Poythress, de asemenea, simte că și-a găsit locul potrivit. „Sunt un traducător sau o legătură între vizionarii care au o idee și talentul tehnic care știe să o construiască și să o realizeze”, spune el. „Vorbesc fluent ambele limbi. Vorbesc „persoană normală” și vorbesc „tehnică-ese”.

Mini CTO

TPM-urile care lucrează pentru startup-uri și întreprinderi mici ocupă un loc deosebit de important la intersecția dintre afaceri și tehnologie. În aceste angajamente, un TPM este adesea primul angajat care vine la bord la începutul unui proiect. El sau ea este apoi responsabil pentru evaluarea viabilității produsului, definirea domeniului și cerințele tehnice și ajutarea clientului (uneori un singur fondator cu o idee) să selecteze o stivă de tehnologie, să evalueze furnizorii pentru furnizarea de servicii, să implementeze cele mai bune practici DevOps, și adună echipa potrivită.

Takatsuka consideră aceste angajamente niște roluri de „mini CTO”, în care TPM-ul face o punte între tărâmurile de afaceri și cele tehnice pentru a demara lucrurile. Unii clienți nu știu aproape nimic despre dezvoltarea de software, spune el: „Cum îmi înființez magazinul? Am citit despre Agile. Cum să fac asta?"

Poythress vede cele două roluri ca fiind suprapuse, chiar imposibil de distins unul de celălalt în anumite cazuri. „Există multă polenizare încrucișată”, spune el. „Un CTO pentru o organizație mai mică s-ar putea muta cu ușurință într-un rol de PM tehnic senior într-o organizație mai mare și se poate simți ca acasă.”

Activarea Agilității

În timp ce mecanica Agile este în timonul oricărui manager de proiect cu experiență în dezvoltare de software, cineva cu aptitudini tehnice poate aduce o perspectivă mai nuanțată gestionării proceselor.

Ciherean constată că metodologiile Agile nu sunt niciodată implementate strict la carte; acestea trebuie să fie personalizate, combinate și adaptate nevoilor specifice ale unei echipe și ale unui proiect.

„Trebuie să vă asigurați că ceea ce proiectați ca proces nu interferează cu munca dezvoltatorilor și, de fapt, o face mai eficientă sau productivă”, spune ea. „Uneori, asta înseamnă să pătrundem în fluxul de lucru GitHub, de exemplu, pentru a vedea cum își fac commit-urile, a vedea cum creează ramuri pentru codul lor și a vedea dacă procesul tău se încadrează în fluxul lor de lucru. Și apoi fie corectați procesul, fie corectați fluxul de lucru.”

Expertiza unui TPM poate informa, de asemenea, artefacte și practici Agile specifice, cum ar fi stocul de produse și estimările de dimensiune relativă.

„Dacă înțelegi aspectele tehnice, știi complexitatea aproximativă a lucrurilor dintr-un stoc”, spune Takatsuka. „În caz contrar, tot ce ai este această listă și ți-ar fi greu să știi dacă numărul unu este un tricou de mărime mare în comparație cu numărul doi. S-ar putea să ai idee că unul este mai greu, dar nu știi cu adevărat ce se află în culise. Un TPM „extrem”, spune el, „ar putea dimensiona el însuși lucrurile, cu avertismentul că atunci când echipa vine la bord, ei vor avea propria viteză”.

Poythress își folosește înțelegerea estimării dimensiunii ca un indicator pentru a evalua conducătorii tehnologici și inginerii pe care îi ia în considerare pentru un proiect. Dacă se așteaptă ca ceva să fie o sarcină mică, dar altcineva o consideră uriaș, acesta este un semnal roșu: „O să-i aud să văd dacă există complexități despre care nu știu, dar dacă asta nu ține apă, Eu zic: „Bine, bine, asta nu se potrivește”. Avem nevoie de cineva care să înțeleagă foarte bine acest lucru și care să nu fie intimidat de ceea ce ar trebui să fie o caracteristică simplă.”

TPM-urile ajută, de asemenea, la educarea clienților cu privire la cerințele nefuncționale. Cum te descurci cu disponibilitatea ridicată? Cum te descurci cu recuperarea în caz de dezastru? „Fără înțelegerea tehnică, nu știu cum ai acea discuție”, spune Takatsuka. „Probabil o să te oprești la nivelul cerințelor Scrum și te vei chema la o zi până vor veni oamenii tehnici. Ei bine, atunci ai această prăpastie imensă.”

Menținerea curentului

Deși timpul petrecut la tastatură joacă un rol fundamental în ceea ce fac astăzi, TPM-urile nu se pot baza pe experiența trecută pentru a rămâne relevanți. Având în vedere ritmul cu care tehnologia se schimbă și se dezvoltă, este ușor să rămâneți în urmă.

Poythress a învățat acest lucru pe calea grea, într-o fereastră de cinci ani înainte de a se alătura Toptal, când s-a concentrat exclusiv pe conducerea propriei companii. „Cu siguranță am stagnat”, spune el. „Au apărut o mulțime de limbi diferite și au rezolvat probleme în acea perioadă de timp despre care nu știam nimic pentru că aveam stack-ul nostru de tehnologie și asta era tot ce ne trebuia.”

Astăzi își petrece până la 10% din timp citind documentație, urmărind YouTube și făcând sandbox „pentru a afla despre cele mai recente și mai bune lucruri”.

„Aproape întotdeauna sunt de părere cu o nouă limbă sau tehnologie, doar ca să rămân atent”, spune el. „Pentru că dacă nu o fac, industria va merge mai departe. Mi s-a mai întâmplat asta. Și este mult mai greu să te înghesui decât să fii la curent.”

Takatsuka este, de asemenea, proactiv în ceea ce privește completarea lacunelor sale de cunoștințe: „Google este grozav în aceste zile. YouTube este minunat. Trebuie să-ți faci temele. Dar această muncă se bazează pe ea însăși.”

De asemenea, se bazează pe o rețea largă de colegi consultanți pentru sprijin și schimb de cunoștințe. „Am fost în situații în care clientul dorește să folosească Google, dar se întâmplă să cunosc mai bine platforma AWS”, spune el. „Pot să sun prietenii și să spun: „Hei, vom folosi Firebase. Ai avut clienți care fac asta? Ce zici de scalabilitate?'”

Chiar și după mai bine de 30 de ani în afaceri și mai multe roluri la nivel executiv, Dan Allen nu se teme să-și murdărească mâinile. În ultimii trei ani, a învățat singur să implementeze de unul singur pe Amazon și Google Cloud. „Am făcut-o ca să înțeleg și să ajut un client Toptal”, spune el. „Nu aveau o echipă de tehnologie. Tot ce aveau eram pe mine. Așa că am fost la Universitatea YouTube și am terminat-o.”

S-au schimbat atât de multe de când Allen a început ca dezvoltator în 1985. Dar îi place provocările care vin cu fiecare nouă oportunitate. „Asta face parte din ceea ce îmi place la job”, spune el. „Întotdeauna există ceva ce nu ai făcut, ceva nou. Și mereu pleci cu o pană suplimentară în șapcă pe care o poți folosi la următoarea logodnă.”