Za novo izdanje .debuga donosimo novu seriju intervjua s gostima iz partnerskih kompanija, u kojima ćemo najaviti njihove nastupe na najvećoj tehnološkoj konferenciji u regiji. Prvi gost u našem TV studiju u ovoj je sezoni bio Nikola Buhiniček, Engineering manager u tvrtki Productive.

Predstavio je značajne iskorake koje je ova kompanija ostvarila u proteklih godinu dana. Naglasak je stavljen na rast tima koji sada broji preko 130 zaposlenika te na uspješnu implementaciju novih korisničkih iskustava koja su rezultirala privlačenjem najvećih klijenata u povijesti tvrtke. Fokus na UX i performanse postao je temelj za daljnji razvoj, a tvrtka nastavlja s intenzivnim planovima zapošljavanja.

O tome što će donijeti Productive 5.0, koja će zanimljiva predavanja njihovi stručnjaci održati te kakav profil ljudi trenutačno zapošljavaju – pogledajte u kratkom intervjuu u nastavku, a potom nabavite u svoju ulaznicu za .debug.

Objava Productive stiže na .debug: Kako integriraju AI i što novoga “kuhaju”? pojavila se prvi puta na .debug.

Danas vam iz TV studija .debuga donosimo intervju s Karlom Radmanićem iz Productivea, tvrtke koja nudi SaaS alat za upravljanje projektima, zadacima, praćenje vremena, financijske rezultate i raspoređivanje resursa. Klijenti su im agencije, konzultantske kuće, IT usluge i tvrtke za razvoj softvera diljem svijeta, s jakim naglaskom na tržišta poput SAD-a, Ujedinjenog Kraljevstva, Australije i Nizozemske.

Tvrtka trenutno zapošljava preko 110 ljudi i nedavno je dobila SOC 2 certifikat. Kontinuirano rade na novim alatima, uvode AI tehnologije, a trenutačno rade i na lokalizaciji svojih alata za tržišta izvan engleskog govornog područja. U videu ćete doznati više o njima, ali i o predavanjima koja nam pripremaju za .debug, gdje će njihova Jana Šimon govoriti o pretvaranju korisničkih kritika u prilike, a Stjepan Hadjić o neobičnom pristupu otvaranju baze podataka korisnicima.

Ne propustite zanimljiva predavanja – dođite na .debug i upoznajte se s ekipom Productivea uživo.

Objava VIDEO: Predstavljamo Productive, partnera .debuga pojavila se prvi puta na .debug.

Napomena: U članku je izostavljeno većinu internih detalja o proizvodu. Nekoliko puta sam koristio pojednostavljena objašnjenja za MySQL indekse, pogotovo ako za isti koncept već postoji detaljnije objašnjenje online. Poveznice sam koristio gdje je prikladno. 

U prvom dijelu teksta sam dao kontekst o tome kako radimo određene stvari u Productiveu. Zatim sam ukratko pojasnio deadlockove, te na kraju prikazao pristup koji smo upotrijebili da ih riješimo.

Asinkroni jobovi u Productiveu

U Productiveu koristimo Sidekiq za schedulanje asinkronih jobova. Neki od tih jobova su slanje emailova korisnicima kada zaborave evidentirati radno vrijeme. Drugi su batch jobovi koji trebaju ažurirati financijske podatke, kopirati određene objekte tako da je transakcija valjana, itd. Prije nekoliko mjeseci počeli smo primjećivati nagli porast deadlockova u aplikaciji. Konkretno, ti deadlockovi su se počeli pojavljivati kod batch Sidekiq jobova koji obrađuju velik broj relativno teških transakcija na našoj bazi podataka.

Što su deadlockovi?

Deadlockovi u bazama podataka se događaju kada se dvije transakcije ne mogu provesti jer jedna sadrži lock koji drugoj treba. Deadlockovi nisu problem sami po sebi, sve dok ne utječu na bazu podataka tako da u potpunosti zaustave određene transakcije. Međutim, potrebno je imati mehanizam za ponavljanje deadlockanih transakcija. Obično je dovoljno ponoviti samo drugu transakciju (onu koja je izazvala deadlock), jer MySQL upravo nju zaustavi kako bi oslobodio lock i omogućio da se nastavi prva transakcija.

Otkrivanje uzroka deadlockova u produkciji je teško. Teško ih je reproducirati, jer često ovise o opterećenju baze u određenom trenutku. Uključivanje dodatnog logiranja specifično za deadlockove je isto izazovno jer ti logovi mogu biti vrlo veliki. Čak i kad pronađete transakcije i njihove lockove, nije uvijek odmah jasno kako bi ih bilo najbolje riješiti.

Eksperiment

Priprema

Budući da je broj deadlockova u aplikaciji rastao iz mjeseca u mjesec, morali smo nešto poduzeti kako bismo spriječili ozbiljnije probleme. Napravili smo odvojenu testnu okolinu koja je vrlo slična produkcijskoj. Također smo promijenili dio produktnog koda kako bismo mogli lakše simulirati problematične Sidekiq jobove. Okruženje smo povezali s našim sustavom za nadzor kako bismo mogli bilježiti logove. Čim smo počeli masovno pokretati jobove, odmah smo primijetili deadlockove.

Otkrivanje deadlockova

Postoji više načina za otkrivanje deadlockova. Mi smo koristili dva. Prvi je innodb status, koji prikazuje operativne informacije o mehanizmu za pohranu, uključujući zadnji zabilježeni deadlock. Ovako izgleda ispis iz innodb statusa:

Ispis prikazuje samo jedan, zadnji otkriveni deadlock, s ispisom detalja o tablici u kojoj se deadlock dogodio, kao i lockane zapise i tip korištenih lockova. Ove se informacije bilježe za obje transakcije koje su sudjelovale u deadlocku.

Drugi način je baza podataka performance_schema koja sadrži podatke o svim trenutno aktivnim lockovima. Evo primjer kako izgleda ispis tablice data_locks, koja prikazuje sve trenutačno aktivne lockove (podatci u ovoj tablici su „živi”, što znači da se lockovi pojavljuju i nestaju u stvarnom vremenu, kako se SQL upiti izvršavaju):

Iz ovog ispisa možete vidjeti imaju li neki SQL upiti previše lockanih redova, što ponekad može dovesti do deadlockova (u našem slučaju je).

Analiza deadlockova

Analiza deadlockanih upita i njihovih lockova nije nam pomogla da identificiramo konkretne dijelova koda koji su uključeni u njihovo izvršavanje. A čak i da je, trebalo bi osigurati da sve transakcije izvršavaju upite istim redoslijedom kako bismo izbjegli deadlockove.

Proučavanjem innodb statusa otkrili smo koji se indeksi koriste i u kojim tablicama. Ispis jasno prikazuje koja je SQL transakcija bila uključena u deadlock, te koji je indeks i tip locka korišten. Svaki novi deadlock prebriše innodb status, tako da refreshanjem statusa možete analizirati koji se deadlockovi pojavljuju.

Iz ispisa smo uočili da MySQL ponekad koristi dva različita indeksa u istoj tablici u različito vrijeme. U oba slučaja su indeksi indeksirali jedan stupac (jednostavni indeks). Potrebno je istaknuti da će se različiti zapisi lockati ovisno o tome koji je indeks korišten, budući da tako MySQL osigurava integritet podataka.

Kada smo saznali o kojim se indeksima i tipovima lockova radi, daljnje smo analizirali performance_schemu, točnije njezinu data_locks tablicu. Ova se tablica sastoji od „živih” podataka o svim aktivnim lockovima. U njoj smo pronašli problematične lockove i zapise indeksa koje su zalockali (treba imati na umu da MySQL zaključava indeksne zapise, a ne same retke).

Optimizacija indeksa

Ova tablica nam je pomogla da shvatimo sljedeće: kada su dva indeksa korištena pojedinačno, MySQL mora lockati širi raspon indeksnih zapisa nego što je stvarno potrebno. Na primjer, naš je job trebao ažurirati jedan zapis D, ali je MySQL zalockao sve zapise između B i F, jer je to bio najmanji indeksni zapis koji je mogao zalockati. Dakle, zalockano je više redaka nego što je bilo potrebno, opterećenje Sidekiq jobova je bilo veliko, i ovo je dovelo do značajnog broja deadlockova.

Kao rezultat analize smo zaključili da trebamo optimizirati ta dva indeksa. Kako su problematični SQL upiti koristili oba indeksirana stupca u WHERE uvjetima, odlučili smo ukloniti te indekse. Umjesto njih, stavili smo složeni (kompozitni) indeks koji u sebi sadrži oba stupca. Naša hipoteza je bila da će manje redova biti zalockano ako su indeksni zapisi precizniji.

Kombiniranje dva stupca znači da MySQL može lakše pronaći zapise koje je potrebno ažurirati, što posljedično znači da će manje redaka biti zalockano. Kada smo proveli eksperiment u testnom okruženju, broj deadlockova je pao s 50,000 na 0.

Drugi eksperiment

Novi deadlockovi

Nakon ponovnog pokretanja eksperimenta s novim složenim indeksom, ponovno su se pojavili deadlockovi, ali sada u drugoj tablici. Simptomi su bili slični kao i oni od prije, pa smo opet pogledali innodb status i lockove i pokušali zamijeniti jednostavne indekse složenim. No, kada smo ponovili eksperiment vidjeli smo da se broj deadlockova zapravo udvostručio (s oko 300 na oko 600) s novim složenim indeksom, pa smo ga odlučili ne koristiti.

Zbunjeni ovakvim rezultatom, odlučili smo problem pogledati detaljnije. Tek kada smo pregledali shemu baze podataka, primjetili smo BEFORE INSERT trigger. Unutar njega se nalazio upit s dva stupca uvjeta u WHERE uvjetu. Jedan od tih stupaca imao je uzorak čija je tipizirana vrijednost za većinu kupaca bila „{n}“.

Ponovni pokušaj sa složenim indeksima

Za razliku od prvog eksperimenta gdje je kompozitni indeks riješio problem, isti pristup nam nije pomogao u ovoj situaciji. Problem je bio manjak varijabilnosti u stupcu s uzorkom (>98% uzorka je bilo {n}), zbog čega MySQL nije mogao suziti pretragu i zalockati manje zapisa. Rezultat toga je bio da je zalockao gotovu cijelu tablicu, što je značilo da su deadlockovi bili neizbježni. Nismo mogli pronaći druge stupce da oblikujemo prikladniji indeks, niti promijeniti trigger. Budući da je broj deadlockova u drugoj tablici bio relativno nizak, odlučili smo ne mijenjati ništa.

Zaključak

Na kraju smo odlučili živjeti s ponekim deadlockom. Shvatili smo da nam se na produkciji dogodi oko 50 deadlockova u periodima najvećeg opterećenja, ali često i manje. Točnije, zadnjih mjeseci ih promatramo, i tjedno ih imamo 16 u prosjeku. Važno je naglasiti i da optimizacija indeksa nije uvijek prikladno rješenje za deadlockove. Kao što smo pokazali u članku, sve ovisi o konkretnoj situaciji.

Također, deadlockovi nisu nužno loši, dokle god postoji strategija za ponovno pokretanje transakcija i baza radi normalno. Sve u svemu, više od 50,000 deadlockova smo riješili jednom jednostavnom promjenom indeksa.

Zaključno, našli smo način da se nosimo s deadlockovima izvan onoga što predlaže službena MySQL dokumentacija. Optimizacija indeksa se pokazala kao jednostavno, ali učinkovito rješenje. Međutim, promišljeno dodavanje indeksa isplati se i više nego da se kasnije uklanjaju zbog problema koje mogu prouzročiti.

Objava Kako smo riješili MySQL deadlockove u Productiveu pojavila se prvi puta na .debug.

Kako se pripremiti za vaše prvo javno predavanje?

Ove godine sam dobio priliku da prezentiram na .debug konferenciji. To mi je bio big deal – moje prvo javno predavanje. Htio sam to napraviti “kak spada” pa sam se primio posla. Pošto sam developer, pristupio sam tome developerski i kroz ovaj post ću vam opisati taj proces. Važno za napomenuti je da je prezentiranje vještina kao i svaka druga – s praksom i s vremenom ćete to raditi sve bolje i bolje.

Za temu sam odabrao feature koji je mene kao developera i leada, kao i moj cijeli tim, jako challengeao. Kako sada sve što smo naučili u dvije godine razvoja plus uvod i zaključak stavit na prezentaciju koja traje 30 minuta? Kako dati najveći mogući value ljudima koji će doći slušati moje predavanje?

Kao i početak svakog featurea na kome radimo, treba početi pisati specifikaciju. Tako sam i ja ovdje krenuo s outlineom predavanja.

No, razmišljao sam onda, kako znam da to što ja mislim da je bitno i to što želim prenijet publici i njima bitno? Okej, trebam feedback, kako doći do njega?

Za predavanje na .debugu treba napisati kratki opis teme koji se može naći na rasporedu predavanja. To je jedini sadržaj na temelju koga možete zainteresirati ljude da dođu na vaše predavanje.

Upravo taj opis sam odlučio poslati par frendova na različitim pozicijama u developmentu. Uz to, poslao sam im: “meni bi puno značilo kada bi mi rekao što bi ti očekivao od takve prezentacije? Koji bi bio value kom bi se nadao?” Isto to sam pitao i par kolega na poslu koji nisu bili toliko upoznati s ovom tematikom da mi ne bi dali biased komentare. Kolege s više iskustva oko prezentiranja sam pitao za općenite smjernice.

Iz toga sam izvukao dosta informacija o tome na koja pitanja bi trebao dati odgovor. To mi je pomoglo da popravim outline, da ga učinim konkretnijim i da po tome napravim prvu verziju prezentacije. To je bio moj “PoC” i sad je uslijedila faza prvog testiranja.

Prilikom traženja inicijalnog feedbacka mi je jedan od prijatelja rekao da mu se javim kada ću imati spremnu prezentaciju, da se nađemo i prođemo sto sam smislio. Tako je i bilo – javio sam mu se i evo nas na kavi u Atriumu jedan ponedjeljak nakon posla. Nisam mu isprezentirao predavanje kako bi na .debugu već smo prolazili po slajdovima kako bi probao shvatiti moju priču, njene glavne i ne toliko glavne dijelove.

To je potrajalo više od pola sata i tu mi je već ukazao da sam previše toga stavio na slajdove. Zatim smo opet prolazili deck i micali sadržaj koji nije bio toliko bitan za samu poantu predavanja. Također kao i u developmentu – imaš puno ideja za feature no vrijeme je najčešće ograničeno, moraš vidjet što je must-have, a što nice-to-have. Najbolji savjet koji mi je dao je bio: “ljudi su došli slušati tebe i tvoju priču. Nitko iz publike neće znati više o toj temi od tebe, nema razloga za brigu i stres. To je tvoja tema, ti si to prošao, znaš sve o njoj.” Bilo je tu još savjeta:

• nemoj se oslanjati na presenter notes jer u trenu predavanja nećeš stići pratiti publiku, slajdove i te bilješke
• presenter notes neka budu natuknice, ne rečenice
• što manje teksta na slajdovima da fokus publike bude na tebi i tvom pričanju
• ako je slot 30 minuta, ciljaj na 20-25 minuta
• ostani na razini detalja koja je dovoljna slušateljima da shvate poantu, a da s druge strane ne ulaziš u detalje koji nisu toliko bitni
• dobro je svesti predavanje na relatable razinu s publikom
• ne koristiti interne pojmove
• jako je bitna intonacija i stil pričanja – ne smiješ pričati monotono
• snimi se kako prolaziš prezentaciju i poslušaj da vidiš što je višak, a što ne
• …

Kao što vidite ima tu dosta savjeta, puno toga što bi trebali imati u glavi. Zvučalo je overwhellming u tom trenu. Idućih dana sam razmišljao o tome i doradio prezentaciju. Tada sam organizirao još jedno probno predavanje. Ovaj puta pred većom publikom – petero kolega iz firme. Do tog trena sam prošao prezentaciju 10ak puta, ali ovo je prvi put da ću je for real prezentirati pred drugim ljudima.

Proba je prošla solidno no vremenski gledano je opet bilo na knap. Što je bio i jedan od komentara kolega: “jako brzo pričaš pa te je u trenucima teško pratiti. Uspori malo kako bi sve skupa lakše leglo ljudima.” Znači i dalje je previše sadržaja. Rekli su da ima višaka, a da ima i pojmova koje bi bilo dobro proširiti ili ubaciti. Npr. u uvodnom djelu prezentacije sam mislio da moram objasniti prijašnje ponašanje sustava.

Na tom djelu sam trošio oko 3 minute predavanja dok je to zapravo bilo nešto što bi se moglo svesti na 30ak sekundi. Također, previše sam otišao u product-related rasprave, manje u tehničke. Trebao bi više prilagoditi sadržaj za publiku koju očekujem. Kako je ovo developerska konferencija, trebalo bi podebljati tehničke detalje i odluke. Komentirali smo također memove koje sam ubacio – zanimalo me kuži li se poanta, jesu li smiješni, je li to too much za predavanje. Uglavnom, dobio sam dosta kvalitetan feedback s kojim sam još jednom došao do nove verzije decka.

Taj deck sam prošao još 5-10 puta i usput napravio par sitnih tweakova – najviše u pogledu daljnjeg rezanja sadržaja.

And that’s a wrap.

Predavanje je prošlo odlično! Bio sam jako sretan količinom ljudi koja je došla čuti što im imam za reći, s raspravama nakon predavanja i sa svojom izvedbom. Sve skupa sam uložio nekih 50-60 sati pripreme i drago mi je da se je taj trud prepoznao od strane publike – što kroz pohvale narednih dana, što kroz rezultate ankete za .debug predavače.

Objava Developer savjetuje: Kako pripremiti predavanje za .debug? pojavila se prvi puta na .debug.

Pisanje dokumentacije je važno, ali i naporno. Vjerujem da smo svi svjesni da je potrebno voditi dokumentaciju tijekom razvoja produkta. Ne znam kako se vi osjećate, ali kada ja pišem dokumentaciju, automatski dobijem glavobolju.

Nije niti stvar u tome da je toliko teško (većinu vremena), nego je problem to što cijeli proces može biti zamoran. Volim pisati, ali čak se i ja moram nagovarati da napišem nekoliko rečenica o tome što sam napravio. But you gotta do it, baby!

Objasnit ću vam načine koje smo uveli kako bismo poboljšali proces vođenja dokumentacije. Ako je to nešto s čim se mučite, siguran sam da ćete moći izvući neke korisne ideje iz ovog članka.

Problemi s dokumentacijom

Neću trošiti previše vremena u pojašnjavanju koncepta dokumentacija, zašto je bitna i kome, jer sam siguran da nas većina to već zna. Prijeći ću odmah na konkretne probleme koji mogu nastati kod pisanja dokumentacije.

Kada sam počeo raditi u Productiveu, već je postojala povelika količina dokumentacije. Dosta stvari i procesa je bilo zapisano, od postavljanja računala do detalja o korištenju specifične komponente. Bilo mi je uzbudljivo što ću saznati sve o svemu, ali sam ubrzo došao do slučajeva i značajki koji nisu bili dovoljno detaljni ili koji nisu uopće bili zapisani. Ovo me nije toliko iznenadilo budući da se radi o velikom proizvodu u kojem stvarno ima svačeg. Ostao sam optimističan — ovo je značilo samo da ću se trebati češće javljati kolegama i neke stvari zaključiti sam.

Nakon nekoliko mjeseci, došlo je vrijeme da ja nešto dokumentiram. Sve do tog trenutka mi je bilo uzbudljivo da ću napisati sve što sam napravio. Međutim, kada je došlo vrijeme da nešto stvarno napišem, pojavio mi se mučan osjećaj. Znao sam da moram to napraviti, ali sada sam morao razmišljati o tome zašto i kako je nešto napravljeno, koliko detaljno trebam nešto objasniti, gdje napisati dokumentaciju, itd. Još je gore kada se radi o sustavu koji ne razumiješ u potpunosti i počneš preispitivati jesi li ti uopće prava osoba za to.

Toliko problema — a nisam još napisao nijednu riječ.

Naše rješenje

Malo dramatiziram, ali sve ove misli su mi prolazile kroz glavu u nekom trenutku. U Productiveu smo osmislili nekoliko ideja kako bismo riješili ove izazove. Kada bismo imali jednostavni proces za pisanje dokumentacije, svima bi ostalo više snage i vremena sjesti i zapravo ju napisati.

Dogovorili smo se da:

• Svi trebamo pisati dokumentaciju
• Ne mora biti savršeno isprva
• Treba biti zapisano sve što iziskuje javljanje kolegama ili dublje istraživanje
• Dokumentaciju treba voditi u kontinuitetu
• Zastarjele dokumente treba pobrisati
• Razvoj treba biti vođen dokumentacijom

Pogledajmo što svaka od ovih točaka predstavlja.

Svi trebamo pisati dokumentaciju

Na ovo sam se morao naviknuti, kao što možda možete iščitati iz mojeg prvog iskustva rada u Productiveu. To ne znači da svatko treba dokumentirati samo nove značajke na kojima je radio, nego i stare koje možda i ne razumije u potpunosti. Uvijek je moguće tražiti pomoć od nekog s više iskustva. Čak i ako nije 100 % točno, drugoj osobi će biti lakše nešto ispraviti nego pronaći vremena i raspisati cijeli dokument. Međutim, bitno je potaknuti iskusnije kolege u pisanju kompliciranijih ili težih dijelova dokumenta jer neke stvari mogu stvarno biti prekomplicirane za shvatiti samostalno.

Ne mora biti savršeno isprva

Ovo se nastavlja na moj prethodni savjet. S obzirom na to da je dokumentaciju potrebno stalno držati ažurnom, u redu je napisati natuknice bez da se previše pazi na gramatiku, strukturu, i cjelovitost teksta. Najbitnije je razviti neometani proces koji će povećati angažman kod članova tima. Uvijek je moguće popraviti tekst kasnije. Također, drugi ljudi mogu lako ostaviti povratnu informaciju na dokumentaciju jer ne moraju u potpunosti razumjeti značajku o kojoj se radi.

Treba zapisati sve što iziskuje javljanje kolegama ili dublje istraživanje

Iako je važno zapisati nove značajke i održavati dokumentaciju o starijima, nemojte zaboraviti na nepotpunu dokumentaciju. Često naiđemo na neki problem koji je dokumentiran, ali nam nedostaje neki specifičan slučaj. To može značiti da nešto krivo radite, ali je svejedno bitno dokumentirati što se dogodilo. Vjerojatno će se nekom dogoditi ista situacija, a tih desetak minuta koje odvojite za zapisivanje im može sačuvati sate istraživanja.

Ovo možemo smatrati procesom „odozdo prema gore”. Umjesto da dokumentiramo cijeli proces ili feature, zapiše se jedan slučaj. Ovo može malo „olakšati” proces jer nije potrebno znati i razumjeti sve detalje o featureu. Zapamtite: bez obzira da li se radi o nekoj temi iz onboardinga ili o nečemu tehničkom, kandidat za dokumentaciju je bilo što može smanjiti zbunjenost na projektu!

Dokumentaciju treba voditi u kontinuitetu

Po mom mišljenju, ovaj korak je najteži. Jednako kao što je CI/CD proces (continuous integration/ continuous deployment) bitan, dokumentacija se treba pisati i voditi iz dana u dan. Ako su proces ili značajka dovoljno bitni, dobar trenutak za dokumentaciju je kada proces ili značajka postanu stabilni. Još bolji trenutak je prije nego što kodiranje započne, ako je to moguće. Pisanje dokumentacije dok su informacije svježe pomaže izgraditi čitavu priču uz širi kontekst, ne samo nepovezane djeliće. Kada se dokumentacija radi nekoliko tjedana kasnije, neki bitni detalji i nijanse iz razvoja se često propuste. To u nekim slučajevima može voditi do nepotpune dokumentacije pa je najbolje riješiti taj problem u korijenu!

Zastarjele dokumente treba obrisati

Zastarjela dokumentacija je gora od dokumentacije koja ne postoji. Kada netko otkrije da nešto ne radi onako kako je navedeno u dokumentaciji, to može dovesti do nedoumica i problema. Ako naiđete na dokumente za koje ste sigurni da su zastarjeli, izbrišite ih da ne zbunjuju druge.

Razvoj treba biti vođen dokumentacijom

Kao što sam već spomenuo, jedan pristup koji razmatramo je pisanje dokumentacije prije nego što kodiranje krene. U praksi smo shvatili da razmatranje featurea prije razvoja može olakšati proces razvoja. To je i dobar način da se uključe članovi tima koji nemaju tehničku podlogu, ali mogu istaknuti probleme i odstupanja prije nego što se ona pretvore u kod.

Zaključak je…

Dokumentacija je vrlo bitna za sve, čak i one koji imaju jako puno iskustva. Bez obzira na to, ponekad nije lako potaknuti sebe ili druge da jednostavno krenete pisati dokumentaciju.

Jedno rješenje je pojednostaviti proces. Možete započeti tako da definirate vrijeme i mjesto za pisanje dokumentacije i uključite čitav tim.

Dok istražujete alate koji mogu biti korisni, nemojte zaboraviti na Productive i naš feature, Docs!

Može biti korisno dodati dokumentaciju kao jedan korak u svakodnevnim procesima, npr. uključivanje dokumentacije u procjenu vremena ili traženje izmjena u dokumentaciji prije pull requesta. Možete tretirati vođenje dokumentacije kao pisanje testova, budući da upotpunjuju jedno drugo. Ovakav proces će sigurno povećati vrijeme da se značajke dovrše, ali dokumentacija je jednako važna kao bilo koji drugi dio razvoja.

Ovakav pristup dokumentaciji je nama izrazito pomogao i pokazao se kao dobra podloga za suradnju i nadograđivanje dokumentacije. Nadam se da će vam ovi mali koraci pomoći da provedete značajna poboljšanja na projektima i u svakodnevnom radu.

Predstavnici Productivea nastupit će i na .debugu 2024, a ulaznice su u prodaji:

Kupi ulaznicu

Objava Jesu li vam procesi dobro definirani? pojavila se prvi puta na .debug.

Jedan od dugogodišnjih partnera .debuga je domaća SaaS tvrtka Productive, koji će se i ove godine predstaviti svojim zanimljivim predavanjima. Trenutačno se približavaju broju zaposlenih od 100, rasli su i tijekom prošle godine, a koliko i zašto – pogledajte u video razgovoru u kojem je gostovao Marko Krištić iz Productivea.

Čut ćete i kakve developere trenutačno zapošljavaju, kako se kod njih radi, koliko se koriste umjetnom inteligencijom i, naravno, nešto više o tome što nam pripremaju za ovogodišnje izdanje konferencije.

Najveći .debug ikada održava se 6. i 7. lipnja, a ulaznice su u prodaji.

Kupi ulaznicu

Objava VIDEO: Predstavljamo partnera .debuga, Productive pojavila se prvi puta na .debug.

Uvijek nastojim sagledati širu sliku projekta na kojem radim.

Vrlo je lako izgubiti se u detaljima, pogotovo na velikim projektima. Zato je ključno sve što radimo staviti u perspektivu.

To se često odnosi na poslovnu logiku ili domenu, ali jednako je bitno uzeti u obzir i tehničku implementaciju projekta. To običavamo zanemariti pa ću pokušati objasniti zašto bismo morali obratiti veću pažnju na cjelokupnu sliku.

Novi početak

Svaki put kad počnem raditi na novom projektu, dobijem osjećaj da na njemu ima puno suvišnih i neefikasnih stvari. Volio bih stvari napraviti po svome. U nekim slučajevima stvarno ima mjesta za poboljšanje, no u većini slučajeva priroda projekta zakomplicira nešto jednostavno. Ovo se ne odnosi samo na kod, nego i na libraryje, arhitekturu projekta i ostalo.

Najgora stvar koju možeš čuti u ovoj situaciji je „ovako to oduvijek radimo” ili „ma samo pusti”.

Dobro, možda nije baš najgora stvar, ali ne ostavlja baš najbolji osjećaj.

To može značiti da se nalazite u središtu legacy koda koji će postati sve kompliciraniji i kompliciraniji. Sada, dodajte tim ljudi koji radi isto što i vi, i vidjet ćete koliko se brzo situacija može oteti kontroli.

Tračak nade

Srećom, u Productiveu ne radimo stvari tako. Jako mi je drago što sam napokon pronašao ljude sa sličnim načinom razmišljanja, koji imaju želju stvarno poboljšati procese. Ideja je da svaki član tima može i treba doprinijeti radu na projektu. Mogu, na primjer:

• Ažurirati dokumentaciju
• Poboljšati ili uvesti novi proces, npr. automatizacija ažuriranja libraryja
• Pojednostaviti kompleksnu komponentu ili radni proces
• Napisati skriptu za repetitivni zadatak
• Doraditi testove i proces testiranja
• itd.

Vjerojatno vam padaju na pamet i drugi primjeri. Neke od ovih stvari su jednostavnije za napraviti, neke su teže, ali sve su važne. Kao što sam već rekao, ovo nije nešto što se preporučuje napraviti na vlastitu ruku. Bitno je surađivati s timom kako bi se osmislila najbolja moguća rješenja. Možda nećete doći do njih isprve, ali bitan je napraviti korak u pravom smjeru. Kada drugi ljudi vide da se nešto pokrenulo, to ih obično i motivira da sami krenu razmišljati i eksperimentirati.

Česta prepreka je ideja da moramo imati puno iskustva kako bismo mogli uvesti promjene. Uvijek sam se zamarao time da netko drugi bolji odabir za uvođenje promjena. Netko tko ima više iskustva ili znanja. To možda i je istina. Ali ako imamo ideju i vrijeme, to može biti odlična prilika da naučimo nešto novo i postanemo taj „bolji” odabir za uvođenje promjena. Čak i ako smo sasvim novi na nekom poslu, visoke su šanse da smo najbolji odabir u nekim situacijama — npr. za ažuriranje onboarding dokumentacije, jer nam je lakše procijeniti što nije bilo najjasnije objašnjeno.

Kako organizirati želju za poboljšanjem

• U većini slučajeva, nije dovoljno dogovoriti se usmeno
  • Pokušajte zapisati bitne stvari za određenu inicijativu
• Istaknite specifične probleme i zapišite na čemu točno treba raditi
  • Ljudima je lakše raditi prema krajnjem cilju kada je isti dobro definiran
• Odredite tko je odgovorna osoba (ili osobe) za inicijativu
  • Ta osoba ne mora nužno raditi na inicijativi (iako može), ali mora pratiti koji dio posla je dovršen i što je još preostalo
  • Uloga je ekvivalentna projektnom menadžeru, ali za specifičnu inicijativu
• Ako je moguće, rotirajte odgovorne ljude na inicijativi
  • To je prilika da svatko nauči više o sustavu i da se potakne razmišljanje o novim rješenjima
• Sve ključne osobe trebaju biti svjesne aktivnih inicijativa
  • Često nije moguće potrošiti cijeli tjedan na inicijativu, ali kraći i konzistentni rad bi trebao biti dovoljan za napredak
  • U Productiveu pokušavamo uložiti 15 % do 20 % vremena svaki tjedan, ako je moguće
• Organizirajte vrijeme i prioritete prema svakodnevnom poslu i inicijativama

U ovo dodajte suradnju sa svim članovima tima, dobru komunikaciju i imate recept za uspjeh! I dalje ćete imati vremena za razvoj funkcionalnosti i za popravke, ali ćete, uz to, podići kvalitetu koda i poboljšati radne procese za developere. Ovakav postepen pristup također može pomoći pri rješavanju složenih problema koji bi inače bili zanemareni zbog količine posla na njima.

Prepreke na putu

Iako je naše iskustvo s uvođenjem inicijativa bilo pozitivno, nije sve bilo savršeno od početka. Neke značajne inicijative jednostavno nisu zaživjele.

Nakon razgovora s članovima tima, shvatili smo da je opseg nekih inicijativa bio preširok. Sama ideja je bila dobra, ali ljudi nisu znali gdje i kako bi započeli.

Jedno od rješenja je raščlaniti i suziti problematične inicijative koliko je moguće. Kako bi to bilo izvedivo, potrebno je razgovarati s članovima tima i dobiti stvarne povratne informacije, pogotovo ako primijetite nešto neuobičajeno.

Ako niste sigurni u kojem smjeru biste mogli krenuti, možda vam neki od ovih prijedloga mogu pomoći:

• Release / deployment inicijativa
  • Popravljanje čitavog procesa, od generiranja buildova, do automatizacije i objavljivanja popisa promjena na Slacku
• Praćenje i rješavanje bugova
  • Povećanje broja riješenih bugova i smanjivanje vremena za rješavanje istih
• Refaktoriranje
  • Komponente i dijelovi sustava trebaju biti pojednostavljeni koliko god je to moguće
  • Poboljšavanje developerskog iskustva (DX)
• Praćenje projekta
  • Poboljšanje monitoringa i alertinga na projektima
• Alat za upravljanje paketima
  • Automatiziranje procesa praćenja i ažuriranja paketa na svim projektima
• Modernizacija
  • Identifikacija i modernizacija neefikasnih praksi
• Migracija sheme baze podataka
  • Istraživanje i smanjivanje rizika kod migracija baza podataka
• Onboarding
  • Poboljšanje procesa s fokusom na najkompliciranije dijelove
• UI framework
  • Povezivanje dizajn sustava i kreiranje libraryja iz raštrkanih komponenti

Siguran sam da bi sve išlo puno sporije kada bismo radili poboljšanja u hodu i bez ljudi koji ih nadgledaju. Drago mi je što smo krenuli s ovim jer je jako nadahnjujuće vidjeti kako se ljudi trude poboljšati procese u domenama koje nisu razrađene koliko bi mogle biti.

Kada su svi počeli prepoznavati prednosti neke inicijative, razno razne ideje su se počele pojavljivati. Nevjerojatno je koliko se brzo možemo naviknuti na ustaljene procese, ali dovoljna je mala promjena kako bi započela lančana reakcija nakon koje se zapitaš: „Kako se ovoga nisam sjetio ranije?”.

Nadam se da će vam ovo pomoći i potaknuti vas da isprobate nešto slično u vašem radu!

Predstavnici Productivea nastupit će i na .debugu 2024, a ulaznice su u prodaji:

Kupi ulaznicu

Objava Kako postupno uvoditi poboljšanja na projektu? pojavila se prvi puta na .debug.

Na svečanosti održanoj u Hotelu Zonar u Zagrebu, portal MojPosao proglasio je Najbolje poslodavce u Hrvatskoj, temeljem rezultata Pulser – Istraživanja zadovoljstva zaposlenika.

Najbolji od najboljih

Tvrtke su svrstane u 3 kategorije ovisno o veličini prema broju zaposlenika: male (20 do 50 zaposlenika), srednje (51 do 250 zaposlenika) te velike (251 ili više zaposlenika). Tvrtke s manje od 20 zaposlenika mogu provesti istraživanje, ali ne ulaze u izbor najboljih.

Najbolji poslodavci u 2023. u kategoriji velikih tvrtki su:

1. Infinum d.o.o.
2. ZUBAK GRUPA d.o.o.
3. Rimac Technology d.o.o.

U kategoriji srednjih tvrtki najbolji poslodavci su:

1. The Productive Company d.o.o.
2. Ars Futura d.o.o.
3. Porsche Digital Croatia d.o.o.

Najbolji poslodavci u kategoriji malih tvrtki za 2023. godinu su:

1. Kodilion d.o.o.
2. Netgen d.o.o.
3. Pontis Technology d.o.o.

Također, sve tvrtke koje prvi put sudjeluju u istraživanju ulaze u konkurenciju za priznanje Best new entry, a ovogodišnji dobitnik je tvrtka Pontis Technology d.o.o.

Osim po veličini tvrtke se promatraju i unutar djelatnosti u kojoj posluju. U djelatnosti Informacijskih tehnologija najiznimniji rezultat ostvarila je tvrtka The Productive Company d.o.o., u proizvodnji MICRO-LINK d.o.o., dok je u djelatnosti trgovine najbolji rezultat postigla tvrtka ZUBAK GRUPA d.o.o.

O istraživanju

Ove godine je u istraživanju sudjelovalo 39% srednjih, 35% malih, 21% velikih i 5% mikro tvrtki te više od 7.100 zaposlenika, što predstavlja značajan udio od ukupno 10.000 radnika koliko zapošljavaju tvrtke sudionice istraživanja.

Prosječna ocjena svih tvrtki koje su sudjelovale u istraživanju iznosi 3,29 (od mogućih 4), što predstavlja blagi pad u odnosu na prošlu godinu kada je prosječna ocjena bila 3,35. Zaposlenici su i ove godine najvišim ocjenama ‘nagradili’ Radne uvjete i Izazovnost radnih zadataka, dok najviše prostora za napredak poslodavci imaju u području Osobnog rasta i razvoja zaposlenika te Organizacije rada.

S druge strane, upravo su kategorije Organizacija rada i Osobni rast i razvoj te Uključenost u donošenje odluka ono što najbolje poslodavce čini iznimnim, odvajajući ih od konkurencije.

Koliko radnika je angažirano?

Dio upitnika obuhvaća i mjerenje angažiranosti zaposlenika, odnosno njihove motivacije da dodatno doprinose razvoju i rastu tvrtke u kojoj rade. Sveukupno gledano, 39% zaposlenih je angažirano, dok 58% radnika ne pokazuje izražen interes za davanje dodatnog doprinosa razvoju tvrtke. Dozu prijeko potrebnog optimizma pronalazimo u podatku kako je svega 2% radnika nemotivirano.

Postotak angažiranih radnika kod Najboljih poslodavaca, odnosno u tvrtkama dobitnicama nagrada, je kudikamo veći te iznosi visokih 73%.

Jesmo li lojalni i skloni preporučiti našeg poslodavca drugima?

Istražena je i lojalnost radnika u Hrvatskoj, provjeravajući jesu li spremni preporučiti svoje radno mjesto ili tvrtku obitelji i prijateljima.

Osobe koje su entuzijastične u preporuci svog poslodavca smatramo “promotorima”, one koje su neodlučne označavamo kao “pasivne”, dok su radnici s izraženim neprijateljskim stavom prema preporuci svog poslodavca klasificirani kao “kritičari tvrtke”. Među sudionicima istraživanja, otkriveno je 52% promotora i 34% pasivnih radnika, dok 14% zaposlenih izražava kritički stav prema svom poslodavcu. Kao i ranije, Najbolji poslodavci zapošljavaju veći broj promotora u odnosu na prosjek istraživanja.

Usporedno s ovim istraživanjem, tijekom godine provedeno je i nacionalno istraživanje s istim pitanjem, na oko 2.000 ispitanika, a rezultati su gotovo dijametralno suprotni – na nacionalnoj razini imamo samo 12% promotora, 23% pasivnih radnika te čak 65% kritičara.

Objava Najbolji poslodavci u 2023. su Infinum, Productive i Kodilion pojavila se prvi puta na .debug.

Neovisno o tome radi li se o agenciji za odnose s javnošću, kreativnoj, digitalnoj, event ili tech agenciji, izazovi su često vrlo slični. Rast, produktivnost i učinkovitost, profitabilnost, ljudski resursi, nove tehnologije i trendovi…

Stručnjaci iz domaće tech kompanije Productive, koji se u posljednjih 9 godina bave isključivo agencijama i njihovim potrebama, odlučili su stvoriti Bold, zajednicu koja će okupljati iskusne stručnjake iz agencija svih vrsta i veličina u svijetu. Bold je zamišljen kao mjesto gdje će se razmjenjivati savjeti i ideje o svemu što u praksi i svakodnevici čini život agencijskih stručnjaka, bez obzira na to u kojoj industriji radili.

Na svakodnevnoj bazi u Productiveu se bavimo načinom rada agencijskih stručnjaka i njihovim suočavanjem s izazovima na svim razinama. Primijetili smo da većina zapravo ima vrlo slične probleme i izazove u radu. Bold smo odlučili pokrenuti jer želimo okupiti i spojiti ljude koji si međusobno mogu pomoći znanjem i iskustvom – rekao je Stjepan Šandor, product marketing specialist u Productiveu.

Praktično, Bold je online zajednica u kojoj ćete moći razmjenjivati ideje, savjete i izazove s kolegama iz globalnih agencija, dijeliti materijale, raspitati se o novim načinima poslovanja… Komunikacija će se isprva odvijati na pojedinim kanalima na Slacku, a u planu su i webinari, kao i druženja uživo.

Ideja o ovakvoj zajednici razvija se već gotovo dvije godine, a naziv Bold (eng. odvažan) smo izabrali jer znamo koliko hrabrosti i stava treba da biste vodili uspješnu agenciju i ostvarili zadane ciljeve, a posebno da biste vodili svoje zaposlenike. Bold je trenutno potpuno besplatan na globalnoj razini i nadamo se da će postati središnje mjesto razmjene ideja agencijskih stručnjaka – rekla je Marija Kata Vlašić, koja na poziciji content marketing specialist kreira sadržaj koji informira, educira i inspirira agencijske stručnjake.

Productive je globalna SaaS kompanija koja se bavi razvijanjem softvera za agencije koji im omogućuje praćenje i konsolidiranje svih poslovnih procesa. Proizvod se razvija i raste uz svakodnevno osluškivanje realnih potreba agencija i njihovih lidera. Productive tako koristi više od 1.000 agencija diljem svijeta, a najviše iz SAD-a, Ujedinjenog Kraljevstva i Nizozemske.

Objava Bold, zajednica koja okuplja globalne agencijske stručnjake pojavila se prvi puta na .debug.

Domaća tvrtka Productive, izdvojena kao produkt kompanija iz Infinuma, ove će godine ponovno sudjelovati na .debugu kao zaseban partner. Njihov nastup na najvećem developerskom spektaklu u regiji najavio je Stjepan Petruša, koji je u .debug TV studiju i predstavio što Productive jest i čime se bavi.

Trenutačno Productive zapošljava oko 60 ljudi, od čega je oko polovica developera. No, zapošljavaju i dalje, prošle su se godine brojčano udvostručili, a ambiciozni su planovi i za ovu godinu. Stjepan je naglasio kakve ljude traže u inženjeringu, ali je najavio i o čemu će biti govora na njihovim predavanjima.

Pogledajte video, pa nastavite na naslovnicu debug.hr po ulaznice, kojih već ponestaje…

Objava VIDEO: predstavljamo Productive, partnera .debuga pojavila se prvi puta na .debug.