Senior developer ili tech lead: tko je zapravo odgovoran za kvalitetu koda u timu?

Situacija koja se u ovom ili onom obliku događa u mnogim razvojnim timovima. Aplikacija se kvari na mjestima koja nitko nije dirao. Voditelj primijeti da neki developeri pišu testove, a neki ne, i okrene se najiskusnijoj osobi u prostoriji: “Ti si senior. Pobrini se da svi pišu testove.”

Senior odgovori da će rado pomoći, ali da nije na njemu odlučivati što kolege moraju raditi. Voditelj čuje “to nije moj posao”. Senior čuje “sad si odgovoran za tuđi rad, a nad njim nemaš nikakve ovlasti”. Oboje izađu iz razgovora frustrirani i ništa se ne promijeni.

Problem su rijetko ljudi. Problem je uloga koju nitko nije definirao. Ovaj članak je za osobu koja je može definirati: vlasnika, direktora, CTO-a ili voditelja razvoja.

Dva različita posla sa sličnim nazivima

Senior developer (iskusni programer) definiran je tehničkom dubinom: rješava teške probleme, donosi dobre odluke o dizajnu, pregledava kod i pomaže kolegama da napreduju. Njegov utjecaj dolazi iz znanja. Može predložiti, objasniti i pokazati, ali kolege ga nisu dužne poslušati.

Tech lead (tehnički voditelj) definiran je odgovornošću za to kako tim radi softver: koji standardi vrijede, kako se pregledava kod, koji se tehnički dug otplaćuje i što se događa kad netko zanemari dogovoreno pravilo. Njegov utjecaj dolazi iz ovlasti koje mu je dala uprava.

Ista osoba može raditi oba posla i često ih radi. Ali drugi posao ne dolazi automatski s prvim. Netko ga mora dodijeliti, a tim mora znati da je dodijeljen.

Pitanje koje otkriva rupu

Za bilo koji standard u vašem timu postavite jedno pitanje: što se događa kad ga neki developer ne poštuje?

• Ako je odgovor “tech lead to otvori, a ako treba, ide do uprave”, standard ima vlasnika.
• Ako je odgovor “senior bi trebao razgovarati s njim”, pitajte što senior zapravo može učiniti ako kolega kaže ne. Obično ništa, osim da eskalira, a time od kolege postaje nadređeni kojeg nitko nije imenovao.
• Ako je odgovor slijeganje ramenima, standard je samo želja.

Tko što radi

Jednostavan način da to postane jasno: za svaku vrstu odluke zapišite tko predlaže, tko odlučuje, tko provodi i tko reagira kad se odluka zanemari.

Odluka	Predlaže	Odlučuje	Provodi	Kad se zanemari
“Novi kod mora imati automatske testove”	Senior ili tech lead	Tech lead, uz podršku uprave	Cijeli tim, uz pomoć seniora	Tech lead, zatim uprava
Kako izgleda code review (pregled koda)	Tech lead	Tech lead	Svi	Tech lead
Arhitektura nove funkcionalnosti	Senior developer	Tech lead	Developeri na toj funkcionalnosti	Tech lead
Koji tehnički dug otplaćujemo ovaj kvartal	Tech lead	Uprava, na savjet tech leada	Tim	Uprava
Prioriteti među funkcionalnostima	Product owner ili uprava	Uprava	Tim	Uprava
Pomoć kolegi koji je zapeo	Bilo tko	Ne treba odluka	Senior	Ne primjenjuje se

Ako u stupcu “odlučuje” piše “senior” za stvari koje utječu na tuđi rad, a nitko iz uprave to nije naglas rekao, tu je izvor trzavica.

Što je razumno očekivati od seniora bez ovlasti

Situacija	Razumno je očekivati	Nije razumno očekivati
Nedostaju testovi	Da to istakne i predloži rješenje	Da natjera kolege da ih napišu
Kolega pita kako napisati test	Da mu pokaže	Da svaki dan provjerava svačiji rad
Timu treba standard	Da ga napiše i objasni	Da ga odredi u ime svih
Netko zanemaruje standard	Da to spomene, jednom	Da ga disciplinira
Radi se rizičan dizajn	Da iznese zabrinutost s argumentima	Da ga sam blokira

Dobar senior podiže kvalitetu tima primjerom, pregledom koda i pomoći. Ako od njega tražite da kolegama nameće pravila, a nitko nije rekao da to smije, narušavate upravo one odnose na kojima taj utjecaj počiva.

Znakovi da uloga nedostaje

Ne treba vam revizija da biste to vidjeli. Ako vam zvuče poznato tri ili više ovih točaka, za tehničku kvalitetu u vašem timu zapravo nitko ne odgovara:

• Svaki developer ima svoju ideju o tome što znači “gotovo”.
• Code review se radi kad netko ima vremena, a odobravanje je uglavnom formalnost.
• Ista rasprava o testovima ili strukturi vraća se svakih nekoliko mjeseci i završava bez odluke.
• Vaš najiskusniji developer je frustriran, a niste sigurni zašto.
• O greškama koje dođu do kupaca govori se kao o lošoj sreći, a ne kao o rupi u procesu.
• Kad za neki tehnički izbor pitate “tko je to odlučio?”, odgovor je “jednostavno se dogodilo”.

Nijedna od ovih stvari sama po sebi nije katastrofa. Zajedno znače da tim svaki dan plaća za odluku koju nitko nije donio: tko postavlja pravila.

Ovlasti na jednoj stranici

Ako želite da netko odgovara za tehničku kvalitetu, zapišite to. Ne mora biti dugo. Ovakva stranica, dogovorena s tom osobom i objavljena timu, uklanja većinu zabune:

Zadnja dva retka su najvažnija. Bez puta za eskalaciju voditelj ima odgovornost bez ovlasti. Bez vremena uloga postaje neplaćeni prekovremeni rad, a vaš najbolji developer polako prestaje to biti.

Tri načina da to postavite

• Imenujte tech leada unutar tima. Obično pravi odgovor za uhodan tim s iskusnim seniorom koji tu ulogu želi. Dajte mu ovlasti i vrijeme i objavite to timu.
• Neka to bude zajednički dogovor tima. U malim timovima standardi se mogu dogovoriti zajedno i zapisati, a uprava rješava iznimke. Nitko nikoga ne nadzire; pravilo pripada svima.
• Dovedite vanjskog seniora na određeno vrijeme. Kad nitko iznutra ne želi tu ulogu ili je tim mlad, iskusna osoba izvana može postaviti standarde, testove i proces pregleda koda, s ovlastima od uprave, i zatim sve predati nekome u timu. Kako to izgleda u svakodnevnom radu, pišemo u članku o tome što raditi dok tražite senior .NET developera.

Razgovor, bez nesporazuma

Za voditelje, bolji početak od “pobrini se da svi pišu testove”:

“Želim da automatski testovi postanu standard za novi kod. Možeš li napisati pravila i pomoći timu da ih usvoji? Ja ću objaviti da vrijede za sve i ja ću reagirati ako ih netko ne poštuje.”

Za seniore, bolji odgovor od “to nije moj posao”:

“Rado ću definirati standard i pomoći svima da ga usvoje. Možemo li se dogovoriti da je to službeno pravilo tima i tko reagira kad se ne poštuje?”

Obje verzije govore isto što i izvorni razgovor. Razlika je u tome što odgovornost i ovlasti završe na istom mjestu.

Zašto je to važno za poslovanje

Kvaliteta koda nije hobi developera. Testovi koji nedostaju i neujednačeni standardi pokazuju se kao greške u produkciji, kao funkcionalnosti koje svake godine traju dulje i kao sustavi koje se usuđuje dirati samo jedna osoba. U članku o tehničkom dugu i sporom razvoju pokazujemo kako se to nakuplja.

Većina toga može se spriječiti, ali samo kad je netko jasno odgovoran za to i kad mu je to netko i rekao.

To je ujedno i jedan od najčešćih razloga zbog kojih dobri ljudi odlaze: odgovornost bez ovlasti ih iscrpi. Više o tome u članku zašto odlaze dobri programeri.

Pitanja koja najčešće čujemo

Očekuje li se da svaki senior developer postane tech lead?

Ne. Mnogi izvrsni seniori radije idu u tehničku dubinu i ne zanima ih vođenje. Oba puta su vrijedna. Ako nekome nametnete ovo drugo, obično izgubite dobrog developera i dobijete nevoljkog voditelja.

Naš tim ima pet developera. Treba li nam uopće tech lead?

Treba vam netko tko odgovara za tehničke standarde, makar to bilo nekoliko sati tjedno. U malim timovima često je dovoljan zajednički dogovor i voditelj koji iza njega stoji.

Treba li tech lead imati veću plaću?

Ako uloga traži stvarno vrijeme i stvarnu odgovornost, da, kroz plaću ili kroz jasno manje drugih zaduženja. Ovlasti bez vremena i priznanja ne traju dugo.

Može li vanjski developer imati tu ulogu?

Na određeno vrijeme da, i to često dobro funkcionira: osoba izvana nema povijest u internoj politici tima. Ovlasti moraju doći od uprave, a cilj treba biti da se uloga preda nekome u timu.

Kako mi radimo

ProCoding je .NET studio iz Splita. Osim razvoja, timovima često pomažemo postaviti tehničku stranu zajedničkog rada: standarde pisanja koda, automatske testove, code review i prijenos znanja, uvijek s jasnim ovlastima od uprave i s ciljem da sve ostane vašem timu. Kao mjesečni blok dana ili kroz freelance .NET developera unutar vašeg tima. Prvi korak je besplatan razgovor od 30 minuta.

Izvori

• The standard of code review, Google Engineering Practices