Našli ste mali tim koji Vam se dopada. Procena deluje razumno, a cena je samo deo onoga što traži velika agencija. Onda stigne ugovor na potpis i negde u pozadini se javi tiho pitanje koje retko ko izgovori naglas: šta ako taj programer ode?
Kratak odgovor glasi da projekat ne treba da stane kad programer ode, razboli se ili je na godišnjem odmoru. Važno je samo da razlog za to možete da proverite, a ne da poverujete obećanju. Naš razlog je način na koji slažemo tim. Ja sam na svakom projektu od prvog dana, kao CTO, arhitekta i menadžer projekta. Trudimo se da svaku izmenu u kodu pre ulaska u projekat pregleda drugi programer. Svaki projekat ima dokumentaciju od koje novi čovek može da krene, a većina naših ugovora navodi imena ljudi koji rade na projektu.
Ono što ne nudimo jeste zamena programera za 48 sati. Mislim da onaj ko to nudi prodaje pogrešnu stvar, a u nastavku objašnjavam zašto.
Zašto je „šta ako programer ode“ pravo pitanje
Za ovaj rizik postoji i naziv. Bus faktor je broj ljudi koji bi morali da nestanu sa projekta da bi projekat stao. Mračna verzija priče kaže da ih je udario autobus, ali u stvarnosti ih mnogo češće jednostavno zaposli neko drugi. Bus faktor 1 znači da sve zavisi od jednog čoveka.
Avelino i saradnici su 2016. godine izmerili bus faktor na 133 popularna projekta otvorenog koda na platformi GitHub, dakle na projektima čiji je kod javno dostupan. Čak 34% tih projekata imalo je bus faktor 1, a 65% bus faktor 2 ili manji. Na internetu se za prvi podatak često navodi 46%, ali to nije tačno, jer u samom radu piše 34%. Kasnija studija istog prvog autora iz 2019. godine pratila je 315 projekata u kojima su otišli svi ključni programeri. Od tih 315 projekata preživelo je samo 41%, a preživeli su samo zato što su posao preuzeli novi ljudi.
Istraživači iz firme JetBrains i sa Univerziteta Bilkent anketirali su 2022. godine 269 inženjera. Njih 63% je u prethodnoj godini radilo na bar jednom projektu za koji su osećali da mu bus faktor ozbiljno preti da padne na nulu, dok je samo 19% ikada radilo na projektu na kome im je neko rekao koliki mu je bus faktor. Treba reći da se ovi brojevi odnose na otvoreni kod i velike firme. Timove male kao naš niko nije proučavao. Mehanizam je ipak isti na svakoj veličini tima, a trenutak pred potpisivanje ugovora je upravo trenutak kada treba pitati.
Kako slažemo tim za projekat
Nas je petoro, računajući i mene: 2 backend programera koji rade serverski deo aplikacije, 1 frontend programer koji radi deo koji korisnik vidi, 1 QA inženjer koji testira sve što isporučujemo i 1 dizajner. Na svakom projektu sam u isto vreme CTO, arhitekta i menadžer projekta, a kao tim radimo na najviše 3 projekta istovremeno. Na najmanjem projektu radi 1 programer. Na prvi pogled to liči na bus faktor 1, kao da je taj programer sam. Nije, jer je na projektu i čovek koji je sistem projektovao, a to sam ja.
Za probleme koji izlaze iz okvira svakodnevnog posla, kao što su složena podešavanja plaćanja preko servisa Stripe ili složeni sistemi poziva i poruka preko servisa Twilio, angažujemo spoljne saradnike. To su uvek isti ljudi s kojima dugo radimo, a ne onaj ko je tog dana slobodan.
Gde je znanje kad čoveka nema
Kod nas znanje o projektu stoji na pet mesta.
Pregled koda. Trudimo se da svaku izmenu pregleda drugi programer pre nego što uđe u projekat. Alberto Bacchelli i Christian Bird iz Microsofta objavili su 2013. godine istraživanje koje je pokazalo da pregled koda manje služi za hvatanje grešaka nego što se očekivalo, a više za prenos znanja. Programer koji pregleda tuđu izmenu razume i kod koji nije sam napisao, a upravo to Vam treba onog dana kada neko iznenada nije tu.
Repozitorijum. Repozitorijum je mesto gde se čuva sav kod projekta. U njemu držimo detaljan README, odnosno fajl koji programeru objašnjava kako da instalira i pokrene projekat, zatim spisak zadataka koji tek treba uraditi i pisani zapis o zadacima koji su u toku i onima koji su završeni. Novi programer tako vidi šta je urađeno i šta je ostalo, a da ne mora da pita onoga ko je odsutan.
Sam kod. Frontend nema drugog programera, pa se tu oslanjamo na strukturu koda. Pišemo po SOLID principima, to jest po pet pravila dizajna po kojima svaki deo koda ima jedan posao, tako da jedan deo možete da promenite bez rušenja ostatka. Takav kod nepoznat čovek mnogo lakše preuzme. Ipak, struktura koda nije drugi čovek. Na to se vraćam kasnije u tekstu.
Ugovor. Većina naših ugovora navodi imena ljudi koji rade na projektu. Ne svi, jer to zavisi od toga šta klijent traži. Ako želite imena u ugovoru, samo to tražite.
Nalozi. Više volimo da kod, serveri i nalozi za servise budu na ime klijenta, a da klijent nama da pristup. U praksi mnogi klijenti nemaju nikoga ko bi podesio hosting (zakup servera na kome aplikacija radi), repozitorijume i servise trećih strana, pa se sve to često vodi na ime naše firme. To je zgodno, ali znači da zavisite od nas i to treba da znate od prvog dana. Moj savet je sledeći: bez obzira na to na čije su ime nalozi, tražite pisani spisak svih naloga na kojima Vaš proizvod radi.
Odmor, bolest i otkaz: tri različita odgovora
Planirani godišnji odmor
Po Zakonu o radu svaki zaposleni u Srbiji ima pravo na najmanje 20 radnih dana godišnjeg odmora, a prvi deo odmora traje najmanje dve uzastopne nedelje. Takvo odsustvo je sigurno i predvidivo, pa ga planiramo unutar tima. To je naš problem sa rasporedom, a ne nešto čime Vi treba da se bavite.
Ako ste klijent iz Zapadne Evrope, imajte u vidu da su naši praznici drugačiji od Vaših. Pravoslavni Uskrs 2027. godine pada 2. maja, pet nedelja posle zapadnog Uskrsa (28. marta 2027.), pa se spaja sa praznicima 1. i 2. maja.
Iznenadno odsustvo
Do sada se nijedan naš programer nije ozbiljno razboleo usred projekta. Najbliže tome je situacija u kojoj klijent traži da jedan naš programer odmah prestane da radi na njegovom projektu, bez otkaznog roka i bez nedelje za primopredaju posla. Svaki put kada nam se to desilo, ja sam preuzeo odgovornost i nastavio posao. Zato i postoji arhitekta na svakom projektu: ko god uskoči, ne uči sistem od nule, jer sam taj sistem ja projektovao.
Otkaz
Niko još nije napustio Conimex IT usred projekta. Još. Kada se to desi, novom programeru će trebati vremena. Po našem iskustvu programeru treba oko 3 meseca da potpuno savlada projekat srednje veličine. Istraživanja daju sličan raspon: Minghui Zhou i Audris Mockus su 2010. godine pokazali da se produktivnost novog programera ustali za nekoliko meseci na malim i srednjim projektima, a na velikim tek za godinu dana.
Zašto ne premeštamo programere i zašto je obećanje od 48 sati pogrešno
Tu se ne slažem sa velikim delom industrije. Velike agencije stalno premeštaju programere s projekta na projekat, a cenu toga plaćaju mali i srednji klijenti. Od njih slušamo istu priču: tokom jednog projekta smenjivao se programer za programerom, svaka smena je usporila posao, a gotov proizvod je na kraju bio lošiji.
Zato me zamena programera za 48 sati ne impresionira. Zamena stigne za 2 dana, a razumevanje projekta dođe za oko 3 meseca.
Fred Brooks je to 1975. godine sažeo u pravilo koje se danas zove Bruksov zakon: „Adding manpower to a late software project makes it later.“ Kad se dodaju ljudi softverskom projektu koji kasni, on kasni još više. Projekat koji stalno menja ljude nikada ne izađe iz faze uvođenja u projekat.
Šta tim naše veličine ne može
Bus faktor našeg frontenda je 1. SOLID principi i arhitekta na projektu skraćuju preuzimanje, ali ako frontend programer nije tu, posao na frontendu usporava dok se on ne vrati ili dok neko drugi ne savlada njegov kod.
Nemamo ni stalno dežurstvo 24/7, odnosno inženjera koji je u svakom trenutku spreman da reaguje kada sistem padne. Google u svojoj SRE knjizi, priručniku o održavanju sistema koje korisnici svakodnevno koriste, navodi da je za održivo dežurstvo na jednoj lokaciji potrebno najmanje 8 inženjera. To je više od celog našeg tima od 5 ljudi. Ako Vam trebaju upozorenja koja neko rešava u 3 ujutru svake noći, treba Vam veći tim ili firma koja se bavi samo održavanjem sistema.
Ne možemo ni da udvostručimo tim do sledećeg meseca. Ako Vam treba 10 programera do prvog u mesecu, mi smo pogrešan izbor, a o tome bismo uopšte razmišljali samo ako se klijent obaveže na dužu saradnju. I na kraju, dok se otkaz zaista ne desi, naš odgovor na njega je plan, a ne iskustvo.
Sedam pitanja koja treba postaviti svakom timu pre potpisivanja
Postavite ova pitanja svakom timu s kojim razgovarate. Uz svako pitanje je i naš odgovor.
- Ko još poznaje moj kod? Ja, jer sam na svakom projektu kao arhitekta. Backend poznaju 2 programera. Frontend poznaje 1 programer i to je naša slaba tačka.
- Da li svaku izmenu pregleda još neko? Trudimo se da to bude svaka izmena.
- Gde su kod, serveri i nalozi? Najbolje je da budu na Vaše ime. Ako više volite da ih mi podesimo, biće na naše ime. U oba slučaja treba da znate na čije su ime.
- Da li su ljudi navedeni u ugovoru? Obično jesu. Ako želite da budu navedeni, biće.
- Koliko često premeštate programere s projekta na projekat? Što ređe možemo. Premeštanje programera je upravo ono protiv čega se zalažemo.
- Koliko traje da novi programer preuzme projekat? Oko 3 meseca da potpuno savlada projekat srednje veličine.
- Šta ne možete da pokrijete? Stalno dežurstvo 24/7 i udvostručavanje tima u kratkom roku.
Kakav tim odgovara Vašem projektu
Ako Vam treba danonoćno dežurstvo ili 10 programera već sledećeg meseca, izaberite većeg dobavljača. Mi bismo Vam to rekli već na prvom razgovoru.
Ako gradite jedan proizvod i želite da na njemu rade isti ljudi od prve linije koda do lansiranja, mali tim sa arhitektom na svakom projektu nije rizičniji izbor. Po mom mišljenju je sigurniji.
Ako ste banka, osiguravajuće društvo ili druga finansijska firma, Vaša obaveza je već propisana. Uredba Evropske unije o digitalnoj operativnoj otpornosti (Digital Operational Resilience Act, skraćeno DORA), koja važi od 17. januara 2025., traži izlaznu strategiju za svakog IT dobavljača koji podržava kritične funkcije, dakle plan kako da nastavite bez tog dobavljača. Tražite takav plan bez obzira na to koliko je tim veliki.
Pre potpisa znate ko radi na Vašem projektu
Conimex IT iz Beograda razvija web i mobilne proizvode po meri u Laravelu, Reactu i React Nativeu. Radimo u istom radnom vremenu kao veći deo Evrope.
Pre nego što potpišete ugovor, reći ćemo Vam ko bi po ulogama radio na Vašem projektu, ko bi pregledao njihov kod i na čije bi ime bili vođeni Vaši nalozi. Ako želite te odgovore pre nego što donesete odluku, pišite nam na [email protected].