Tim McKeoun: “Ako želimo da se developeri razvijaju, moramo se pomiriti da će nekad biti manje produktivni”

“Developerski advokati” nisu odvjetnici, već dobri komunikatori koji znaju kako pomoći developerima. Bez obzira na sve veću zastupljenost, njihova uloga nije svima jasna, niti su developeri advokati prisutni u svakoj firmi. Uz to, koliko je još manje prisutna ta uloga u hrvatskoj tech zajednici, pokazuje i taj nezgrapan prijevod. (op.e. poslužit ćemo se zato izrazom zagovaratelji)

Iako su u svijetu već prepoznati kao stručnjaci koji mogu donijeti vrijednost i promjene u developerske tvrtke, to nije uvijek slučaj. Sve je jasnije kako ova specifična uloga zahtijeva i specifične vještine koje treba razvijati.

Tim McKeoun koji trenutno radi kao Mainframe Professional i Developer Advocate u švicarskom IBM-u, na tim vještinama je počeo raditi još na svom prošlom radnom mjestu u osiguravajućoj kući – te je svoja iskustva odlučio podijeliti sa širom publikom. Njegove savjete imali smo priliku čuti na ovogodišnjem QED-u, biztech konferenciji koju već niz godina organizira hrvatski CROZ.

“Zašto radimo stvari na isti način kao prije 40 godina?”

Nakon završetka studija, Tim kaže kako je jedva dočekao raditi kao softver developer, ali onda mu je u ruke dan COBOL-ov udžbenik iz 1971. godine. Pomislio je tad kako će ipak morati tražiti drugi posao… Ostao je na kraju u techu, ali cijelo vrijeme gnjavilo ga je jedno pitanje:

Zašto radimo stvari na isti način kao prije 40 godina? Svijet se mnogo promijenio od prije 40 godina. Zar ne? Imali smo ljude koji su odbijali priznati tu činjenicu, pretpostavljam zato što im je bilo ugodno koristiti alate i procese koji se koriste desetljećima pa nisu bili spremni poduzeti taj korak naprijed.

Upravo iz ovog razloga Tim je na svom poslu kreirao poziciju Developer Advocate – znao je kako će firma imati velike probleme za 10 godina ako se nešto ne promijeni.

Kako bi developer mogao napredovati, prvo mora usporiti

Tim voli reći kako ne postoji točno određen tip osobe za ovu poziciju. Ne postoji striktno definiran skup vještina niti strukturirane upute kako se postaje developerski zagovaratelj. Usprkos tome, postoji nešto što svaki zagovaratelj mora imati:

Jedina stvar koju developerski zagovaratelj mora imati je goruća strast i moraju biti uzbuđeni da dijele tu strast s drugima, a to je nešto što se ne može naučiti. Mislim da svatko može biti developerski zagovaratelj, ali da biste bili istinski uspješni, ovo mora postati vaša strast i način kako želite pomoći ljudima.

A što uključuje posao developerskog zagovaratelja? Tim navodi kako je njegovo zaduženje da developeri budu što bolji u svome poslu, ali ovdje odmah dolazimo do problema. Kako to postići?

Najbolji način je uvođenjem novih alata i procesa koji će developerima olakšavati život, ali tu već govorimo o budućnosti. Kada bi me pitali koju ću vrijednost vidjeti sutra nakon uvođenja ovih alata, moram iskreno odgovoriti kako će se stvari zapravo usporiti.

Ako želimo da se developeri razvijaju, onda će biti manje produktivni jer ipak smo promijenili način na koji rade stvari. To je očito bila pilula za menadžment koju je teško progutati.

Usprkos činjenici što bi Tim trebao biti developerov najbolji prijatelj, iskreno kaže kako ga nisu uvijek voljeli jer htio mijenjati stvari, ali upravo u tome vidi i zadaću sebe kao developerskog zagovaratelja.

Developer Advocate kao graditelj mostova

Poučen iskustvima iz prakse, Tim je shvatio kako developerski zagovaratelj može biti graditelj mostova, a jedan od tih primjera je upravo odnos developera i osoba s kojima moraju pričati, a to je menadžment:

Mislim kako menadžment uvijek vidi sebe kao nekog tko razmišlja o potrebama developera. S druge strane, developeri vole misliti kako je menadžment uvijek u krivu. Ovdje se nalazi ta rupa u odnosu gdje obje strane krive jedna drugu, a nikada ne pričaju. Developerski zagovaratelj trebao bi započinjati te teške razgovore.

Drugi primjer je manjak komunikacije između IT-ja i prodaje. Dok je Tim radio u osiguravajućoj kući, bio je zaprepašten da developeri ne pričaju sa svojim krajnjim korisnicima. Zapravo, to je bilo zabranjeno:

Rečeno nam je da to ne smijemo, a jedini put kada smo se čuli s našim prodajnim timovima bilo je putem bug reporta. S njima smo pričali samo kada smo imali problem. Tako odmah zavolite ljude s kojima pričate, zar ne…

Zato sam počeo inzistirati da pričamo s krajnjim korisnicima – jer trebamo iskrenu povratnu informaciju na naš rad.

Ipak, ljudi nisu spremni započeti ovakve razgovore i zato je to savršena primjer situacije u kojoj su potrebne vještine developerskih zagovaratelja.

“Uspio sam jer sam imao povjerenje menadžera koji je prihvatio da će njegov tim na dva tjedna biti sporiji”

Tim je za kraj podijelio priču koja obilježava trenutak kada je postao developerski zagovaratelj u pravom smislu te riječi.

Developeri u mojoj prošloj firmi koristili su stare terminalne s malim ekranima i pritom nisu koristili ni miš. Praktički govorimo o tehnologiji iz 70ih godina s koje se nisu htjeli maknuti. Koristili su stari IMB-ov ISPF mainframe, a ja sam htio da prijeđu na IBM Z jer bismo tada barem mogli koristiti miš. Šalu na stranu, to je moderno sučelje temeljeno na Eclipseu koje omogućuje ljudima da pišu i razvijaju mainframe kod.

Manageru tog tima, objasnio je kako će biti sporiji neko vrijeme, ali da će u konačnici postati kvalitetniji tim. Rad s novim alatom objasnio im je kroz razgovor, s konkretnim primjerima kako mogu brže i bolje napraviti svoje zadatke pomoću njega.

Najgore bi bilo da sam im dao alat i upute te rekao doviđenja. Nakon toga sam ih često obilazio i ispitivao ih kako napreduju.

Kada su developeri primijetili da imaju manje bugova i kako su zadatke izvršavali brže, svi su vidjeli vrijednost njegove uloge. Tako je Tim uspio modernizirati 80% tima kojeg čini 40 ljudi, a neki su čak imali i preko 65 godina:

Uspio sam jer sam imao povjerenje menadžera koji je prihvatio da će njegov tim na dva tjedna biti sporiji. Moj je posao bio pomoći tim ljudima i da im budem podrška kako ne se ne bi vratili na staro.