I jednorozi imaju tehničke probleme, kako Infobip rješava svoje?

Baš zato je i prvi dan Dev Daysa otvoren s predavanjima domaćeg dvojca stručnjaka i jednog stranog stručnjaka.

U Engineering Powerhouse is not just a buzzword predavanju Infobipovi Damir Prusac, VP of Engineering i Mihovil Mađer, Group Product Manager, pokazali su nam koji to principi vode njihove inženjerske timove i kakva kultura usmjerava tvrtku. Kako primjenjuju te principe i kulturu? Odnosno, na koji način zaobilaze lokaliziranu optimizaciju i uspijevaju osigurati visoko zadovoljstvo klijenata? Odličan nastavak na to uslijedio je gostujućim predavanjem samog Craiga Larmana, su-pokretača Large Scale Scrum metodološkog okvira, a koji primjenjuje i sam Infobip.

Sve funkcionira do jednog trenutka – a onda slijedi skaliranje

Kao i u mnogim drugim tehnološkim tvrtkama, inženjeri i voditelji razvoja proizvoda tijesno rade kako bi se na tržište izbacili novi proizvodi usmjereni na potrebe klijenata. No, za prvog hrvatskog jednoroga razvojni procesi su se tijekom proteklih godina morali mijenjati kako je kompanija ubrzano rasla, objašnjava Damir:

Infobipu je trebalo 7 godina da dođe do 100 milijuna dolara godišnjih prihoda, što je manje-više u rangu Zendeska, Salesforcea i Slacka kad su bili startupi. A kako znate Infobip je startao 2006. da bi 2013. evoluirao. Jedan od tri faktora te evolucije jest da smo počeli raditi agilno. U to vrijeme, interes za metodologije je rastao i Scrum je već bio jedna od popularnijih metodologija. Infobip je tada svoje inženjerske timove počeo organizirati po Scrum načinu rada te smo tako u prethodnim godinama došli do 70 i više Scrum timova.

Svi ti timovi imali su timski backlog, a ako ste donekle upoznati sa Scrumom, znate i kako ti backlogovi izgledaju: sadrže sve važne sastavnice razvoja rješenja, diktiraju prioritete i slično. Za sve te backlogove u Infobipu imali su i oko 40-ak dediciranih product ownera koji su za njih bili odgovorni. Oni su timovima davali resurse koji su im bili potrebni da razvijaju nove funkcionalnosti (feature). Prva razina evolucije trajala je do 2013. dok nisu ovladali time kako učinkovito dostaviti promjene komponenata neke funkcionalnosti.

Međutim, kako su rasli, sva operativa se morala skalirati, a i oni su se morali organizirati drugačije. Počeli su drugačije grupirati Scrum timove, a tako su se i posve okrenuli metodološkom okviru poznatom i kao LeSS odnosno Large Scale Scrum, ili kako to kaže Damir:

Tehnički smo se de-skalirali, jer je u konačnici potrebno manje ljudi kojima bi “hranili” timove. Ti ljudi su sad dovoljno slobodni da se čak mogu i posvetiti strani korisnika i istražiti što zapravo korisnik treba.

I tako su zapravo od dostavljanja komponenata došli do toga da učinkovito razvijaju čitave funkcionalnosti.

Što je sljedeći korak? Business Agility!

U 2021. Damir kaže kako planiraju otići i korak dalje kako bi se proces dodatno ispolirao:

Znate, ako ste tvrtka koja se natječe na vrlo dinamičnom tržištu na kojem postoji velika konsolidacija i velika konkurencija, vrlo raspršena vrsta etera, tada pokušavamo izgraditi jedan backlog tvrtke, a onda, na temelju procjene strateškog rizika, vremena do izlaska na tržište i potrebnog truda pokušavamo shvatiti koja je najvrjednija funkcionalnost koju ljudi žele predstaviti svojim kupcima? To zovemo – Učinkovita isporuka najvrjednijih funkcionalnosti za kupca. Dakle, ono što pokušavamo učiniti je maksimizirati stvari koje se neće napraviti u ovoj godini, u pogledu isporuke.

O detaljima kako su organizirani razvojni timovi, više nam je rekao Mihovil. Princip kojem su se okrenuli jest BAPO odnosno Business Architecture Process Organization, a gdje doslovno, u razvoju – počinjete od poslovne strane, jer je na kraju to i ono što želite postići, ističe.

Infobipovi principi razvoja proizvoda

Ono što su se vjerojatni mnogi u široj javnosti pitali jest – a što točno radi tvrtka vrijedna milijardu dolara? Iako je ovaj isječak prezentacije možda najbliže da objasni to nekome, raznolikost i specifičnost ovih rješenja možda neće svima biti razumljivi na prvi pogled.

Ukratko, Infobip danas ureduje nekoliko rješenja u segmentu SaaS-a, odnosno softvera kao usluge (low i no-code alata za enterprise tvrtke) te cPaaS-a (na razini kanala i API-ja, za developere); u segmentima telekoma i sigurnosti (enterprise proizvodi u tim područjima) te Growtha koji uključuje okvire, alate i okruženja za onboarding no/low-touch kupaca.

Svi ti proizvodi izašli su iz Infobipove mašinerije koja danas funkcionira na temelju nekoliko važnih principa koje su nam Mihovil i Damir predstavili u tančine, a ja ću ih ovdje sažeti na ono najbitnije. Ti principi se odnose na ustrojstvo rada među inženjerima i voditeljima proizvodnog razvoja.

• Nije moj posao – svi mi imamo neki opis posla i ideju toga što bi trebali raditi, Mihovil ističe da su Infobipovci 80% vremena u toj ulozi, ali za onih 20% moraju razmišljati kako riješiti rupe koje će postojati u brzorastućoj tvrtki.

Svi mi nekad trebamo ići izvan svoje uloge i napraviti ono što je potrebno kako bi se posao zaključio.

• Autonomni timovi – važno je postaviti ih na dobrim temeljima timskog rada i osvijestiti da jedino zajedničkim snagama možete izvesti rješenja koja će donijeti značajne promjene, uostalom, dvije su glave pametnije od jedne.
• Kontinuirani napredak – uvijek je važno prepoznati potrebe kupaca na vrijeme, najbolji način za to jest direktan kontakt nakon kojeg se opetovano prolazi kroz ciklus koji počinje od inoviranja, eksperimentiranja, mjerenja i revizije da bi se opet vratio na početak.
• Preispituj s poštovanjem – iliti, preispituj uvriježena mišljenja i razloge iza određenih odluka, kako svojih tako i tuđih kako bi međusobno nadogradili ideje u nešto veće. No, kako ističe Damir, ovo je jedan od težih principa:

Svi smo mi ljudi koji imaju vlastiti ego, pristrani smo, i svi želimo obraniti svoje rješenje, no bitno je da se ne vežemo nužno za jednu stvar, već za traženje pravih odgovora, da poštujemo tuđe mišljenje i argumente koje su dali i da razvijamo rješenje na temelju toga.

• Fokusirajte se na kupca, razmišljajte o rješenju iz perspektive kupca – što on ima od toga i da li njemu to rješenje rješava problem?
• “Always deliver” – prvo napravite nešto, a onda napravite to još bolje, uvijek postoji mjesta za napredak, ali, dodaje Damir, nije cilj da izmišljate toplu vodu, ako već resursi unutar tvrtke postoje za nešto, nećete krenuti raditi isto ispočetka.
• Ugradite kvalitetu i sigurnost u sve što radite – sada, ne kasnije. Kad je tu, o kvaliteti se puno ne govori, ali kad je nema, svi će “plakati” kako ništa ne valja.
• Budite transparentni – uvijek je bolje prepričati se i prenijeti i više nego je potrebno, nego kada informacija nedostaje, zaključuje Damir:

Kako mi to volimo reći u Infobipu, važno je biti “radikalno transparentan” makar to bilo i bolno, nekada će i boljeti, ali i to je bolje nego zadržati informaciju pa da nitko ne može zapravo doći do stvarne slike.

Uzročnost i korelacije s Craigom Larmanom

Ono što za tvrtku na početku može značiti njezinu snagu i nešto zbog čega je uspješna, može postati njezina slabost ako se toga predugo drži. I zato Craig Larman ističe važnost prilagodbe unutar organizacije. Što bi to značilo? Za početak, Craig je istaknuo zanimljiv primjer lokalne vs globalne optimizacije, odnosno kako se prioriteti u radu postavljaju na lokalnoj razini, da li osobe, tima ili odjela, a kako na globalnoj, na razini CEO-a primjerice.

Kako se može dogoditi da je nekom timu određena stavka prva na listi prioriteta, a CEO-u na 201. mjestu? Odgovor je ovaj: zato što svatko ima svoje liste prioriteta. Ako ovo ekstrapoliramo, ne samo da svaki tim ima svoju listu, već i svaka osoba ima svoje liste. Zamislite onda da imate 500 ljudi s različitim listama prioriteta… Vrlo je vjerojatno da će neki pojedinac na svojoj listi imati nešto što je na lokalnoj razini na prvom mjestu, ali je na globalnom – na tisuću i nekom mjestu … A sad i vidimo da – što je veći broj lista, to je vjerojatnije da je neki prioritet nevažan s globalnog stajališta.

Iliti što je veća organizacija, to je teže uskladiti uistinu bitne prioritete. No, to ne znači da su “lokalne liste” loše. Dapače, no Craig objašnjava koje probleme donosi takav proces u velikim tvrtkama i kako oni dovode do tromosti sustava i ne isporučivanja dobrih rješenja.

Naime, sljedeći prethodni primjer, brzo dolazimo do situacije gdje će CEO zamoliti jedan tim da prestane raditi na nečemu što je nevažno iz njegove perspektive, kako bi se radilo na, primjerice, zadatku drugog tima koji ima prioritete koji odgovaraju listi CEO-a. U tom trenutku pita Craig retorički – da li to znači da CEO samo treba uputiti prvi tim da radi na zadatku drugog tima:

Odgovor je – vjerojatno ne. Zašto? Stvar je u tome da prvi tim vjerojatno ne zna tehničke detalje liste koju drugi tim ima. Stoga bi značilo da se prvi tim mora prebaciti/priučiti prije nego mogu implementirati nešto s tuđe liste. Tu dolazimo do troška prijelaza, a koji je ključan element prilagodbe organizacije. Ako organizacija ima niske troškove prijelaza, bit će konzistentnija i prilagodljivija i obrnuto.

Postavlja se onda i pitanje, a zašto neki tim ima velike troškove prijelaza. Odgovor je isti, ističe Craig:

Zato što imaju odvojene liste. Dakle, ovdje vidimo kako čim je u igri više lista dolazi do smanjene vjerojatnosti da će se na globalnoj razini raditi na stvaranju vrijednosti. I tu dolazi do značajnog pada prilagodljivosti, pada sposobnosti timova da promijene smjer i u ovom slučaju, da preusmjere smjer prema stvarima koje su zapravo najveće vrijednosti.

Dotaknuo se Craig mnogočega još, no za kraj ću vas samo ostaviti s porukom za kraj:

Budite oprezni kad ljudi koriste riječi poput “dobro”, “brzo”, “učinkovito” jer najčešće gledaju na to s lokalne perspektive, a ne poslovne, na razini tvrtke, gledajući cjelinu i razmišljajući dugoročno o faktorima kao što su povrat ulaganja.

Zanima vas više? Snimke Dev Days predavanja još možete uhvatiti ako se registrirate na službenoj stranici.