Razgovarali smo s četiri domaća razvojna programera, Marinom Bulatovićem, Lukom Kladarićem, Matijom Matečićem i Antunom Tomaševićem, kako bismo jednom zauvijek dobili odgovor na dvojbu - je li bolje pisati računalni kod za sebe ili za druge.
Marin Bulatović iz Photomatha iskustvo razvoja softvera za klijente stekao je radeći kao Android developer za tvrtku Decode, agenciju specijaliziranu za razvoj softverskih rješenja za startupe.
Isprva sam bio fokusiran na projekt uniGluko, koji pomaže dijabetičarima u osobnoj kontroli dijabetesa. S vremenom pristizali su i drugi projekti, poput turističke aplikacije za Šibensko-kninsku županiju, ili pomoći pri razvoju većih projekata poput društvene mreže Fling.
Danas je Android developer u Photomathu, svjetski poznatom kamera kalkulatoru koji koristi više od osam milijuna ljudi mjesečno.
U većini slučajeva, ističe Marin, razvoj vlastitog proizvoda imat će homogeniju strukturu nego projekti koje se razvija za klijente. Firmama koje razvijaju vlastiti proizvod korisno je držati cjeline poput dizajna, menadžmenta, backenda, frontenda i drugih in-house, dok u tvrtkama koje razvijaju softver za klijente to često nije slučaj jer obično rade na jednom dijelu projekta.
Što je heterogenija struktura, to je više problema u komunikaciji. Ako ideja o realizaciji proizvoda mora proći kroz više tvrtki, veće su šanse za njenu pogrešnu interpretaciju. Komunikacija u tvrtkama koje razvijaju vlastiti proizvod lakša je jer je probleme moguće rješavati trenutno bez konzultacija s trećim stranama.
Kratak put od zahtjeva do konačnog proizvoda
Kada ste sam svoj majstor, objašnjava dalje Marin, sami birate razvojne alate i tehnologije koje ćete koristiti. Ponekad će vas problemi gurnuti u određenom smjeru, ali uglavnom možete sami odabrati način rješavanja koji smatrate najpogodnijim. Taj izbor odredit će s kime ćete surađivati.
Kod razvoja klijentskih aplikacija prednost je brzo i efikasno pretvaranje zahtjeva u konačne proizvode. Iskustvom stečenim tijekom razvoja možete usavršiti razvojni proces i lakše predvidjeti probleme u komunikaciji. Kod razvoja vlastitog proizvoda taj je proces često je jako krivudav i nerijetko se kreće ispočetka.
Agencije obično već imaju uigrani tim stručnjaka, zbog čega klijenti mogu biti sigurniji da će dobiti finalni proizvod u dogovorenom roku. Za razvoj vlastitog proizvoda trebate sami oformiti tim. Idealno je kad tim dijeli vašu viziju i motivaciju, ali realnost je obično drukčija.
Kad razvijate puno aplikacija, što je u agencijama čest slučaj, možete temeljem ustaljenih obrazaca rješavanja problema stvoriti framework kojeg potom možete adaptirati za svaku aplikaciju uz minimalno truda. Tijekom razvijanja vlastitog proizvoda češće ćete istraživati i implementirati nove komponente.
Koristan “prazan hod”
Razvojni proces u agenciji uvelike ovisi o klijentu. Često klijenti nisu tehnički potkovani u razvoju softvera te nemaju osjećaj za složenost i vrijeme potrebno za razvoj određenog zahtjeva, što često dovodi do nesporazuma. Kod razvoja vlastitog proizvoda rizici za to su gotovo nepostojeći ili barem uvelike smanjeni.

U Photomathu je tržište to koje određuje rokove. Kako je riječ o edukacijskoj aplikaciji, počeci polugodišta tj. semestara su ciljani datumi za ažuriranje.
Dobra organizacija vremena i ljudskih resursa u agencijama može dovesti do “praznog hoda” između projekata, tijekom kojeg možete proučavati modernije tehnologije. Kad razvijate vlastiti proizvod često nemate takav luksuz. Marin kaže:
Razvoj vlastitog proizvoda kudikamo je riskantniji i složeniji put. No, odličan je za razvoj tehnološki složenog proizvoda, kao i kad je potrebna veća količina vremena za razvoj zbog istraživanja ili uvođenja novih tehnologija.
U praksi se često koristi hibridni model. Ljudi s idejom u startu unajme agenciju da napravi prvotni oblik produkta. Ako se produkt pokaže uspješnim i bude zahtijevao dodatne nadogradnje, tvorci ideje postepeno okupljaju in-house developere koji će preuzeti razvoj i održavanje na sebe. Agencije tijekom te tranzicijske faze i dalje sudjeluju u razvoju, no krajnji cilj je prebaciti što više komponenata ispod istog krova zbog lakše organizacije posla i komunikacije.
Zanima vas više kako spajati tehnologije računalnog vida i strojnog učenja s mobilnim aplikacijama? Posjetite Microblinkov i Photomathov štand na JobFAIRu te pratite Netokracijin specijal posvećen sajmovima poslova za studente!
Rad za sebe i klijenta nije usporediv

“Za sebe sam uglavnom razvijao stvari koje rješavaju moje probleme i potrebe”, kaže Luka Kladarić, stariji softverski inženjer u tvrtki Noom, u kojoj razvijaju mobilne aplikacije koje pomažu poboljšanju zdravlja korisnika.
Kao osnovnoškolac Luka je tako razvio program koji mu je javljao kad je kojim prijateljima rođendan, a u srednjoj web aplikacije (TV raspored) i web stranicu koja mu je prikazivala omiljene dnevne web stripove po danu.
U radu s klijentima specijalizirao se za CMS rješenja po mjeri, sustave koji im omogućavaju održavanje web stranica i njihovo punjenje sadržajem. Desetak godina vodio je web studio u kojem su razvijali CMS rješenja. Danas uglavnom razvija softver koji koriste drugi developeri.
Ta dva načina rada uopće nisu usporediva, tvrdi Luka, jer su procesi, metode i ciljevi potpuno različiti.
Klijenti imaju problem i znaju razaznati rješenja koja ih zadovoljavaju, a koja ne. Dizajn i korisničko sučelje bitne su stavke. Često ne razumiju ideju i vrijednost “čistoće” tehnološkog rješenja, ili ne mare za njega.
Kad je dizajn manje bitan
Softver koji razvija za sebe često ima vrlo funkcionalnu svrhu. Dizajn je manje bitan, a i lakše mu je odustati od kompleksnijih zahtjeva i završiti s nečime sto više liči na MVP (minimum viable product, minimalno održivi proizvod). Kod takvog softvera često su prisutni ili ekstremna uređenost i čistoća ili apsolutni krš i anarhija.
Neki dijelovi procesa razvoja softvera su nedostižni hobi-developerima. Luka objašnjava:
Rijetko tko ima luksuz ulupati godinu dana pune satnice na nešto sto je čisti pet project, dok i nije toliko teško naći projekt u kojem će vas netko plaćati godinu dana za rješavanje naoko nemogućih problema.
U razvoju softvera za vlastite potrebe su prioriteti – pa stoga i rezultat – drastično drukčiji.
Nekad ćete zaglibiti na problemu kojeg bi klijent proglasio nevažnim i na njega potrošiti dane vremena da postignete savršenstvo, nekad ćete zaključiti da je nešto prekompleksno i nije vrijedno truda, a klijent bi tu baš inzistirao.
Klijenti ponekad imaju čudne ideje

Matija Matečić svoj je internetski servis Solo isprva razvijao sam za sebe kako bi si olakšao poslovanje i ubrzao proces izrade računa.
Na tržištu nije postojalo adekvatno i jednostavno rješenje, a birokracija je užasna i nepotrebno komplicirana, pa sam iskoristio znanje u dizajnu i programiranju i u par mjeseci napravio servis prijeko potreban tržištu, ponajviše malim i mladim poduzetnicima.
Dotad je za klijente razvijao web servise poput internet trgovina i administracije, kombinirajući skriptne jezike i popularne frameworke.
Razvoj softvera za vlastite potrebe je fleksibilniji jer nema rokova i fiksnih ideja, zanimljiviji jer se radi na vlastitom usavršavanju i zadavanju izazova, ali i rizičniji jer nema informacija o povratu investicije (vremena koje je moglo biti utrošeno za agencijski rad). Prednost rada za druge su novac i networking, a nedostaci rokovi i moguća ograničenja vlastite kreativnosti. Matija uz osmijeh dodaje:
Svi znamo da klijenti ponekad imaju čudne ideje.
Kod rada za sebe je obrnuto. Razvoj vlastitog softvera ima i dodatnu prednost u odabiru alata, lokacije za rad i atmosfere. “Nužno je da u barem jednom periodu poslovnog života stječe iskustva, radne navike i poslovne kontakte radom za druge”, uvjeren je Matija.
Milijarda malih stvari
Antun Tomašević u agenciji Degordian radi s različitim klijentima, u pravilu na zahtjev: od malih aplikacija za Facebook (nagradni natječaji), do mikro-sajtova sa sustavom za plaćanje, prezentacijskih webova, pa i interaktivnih kioska s kamerama, raznim senzorima i POS printerima.
Osobni projekti, kao i kod prethodnih sugovornika, dosad su mu uvijek bili vezani uz neki problem koji je mučio njega ili njegove prijatelje, poput stranice koja pokazuje što sve mogu skuhati od stvari koje imaju u hladnjaku i stranice na kojoj gitaristi mogu pronaći savjete i upute.
Rad na Mediatoolkitu je sličan radu za sebe jer radimo na softveru koji nema završnu fazu i jednog klijenta, nego se prilagođava potrebama tisuću korisnika.
Kad radim za klijenta dobijem uputu i mogu se posvetiti onom što najbolje znam, a da pritom ne moram razmišljati o naplati, vođenju projekta i komunikaciji s klijentima.
Na osobnim projektima uz samo programiranje radim i još malu milijardu malih stvari: smišljam što se može napraviti, tražim klijente, učim nove stvari jer ih nema tko drugi napraviti ili delegiram pa onda pazim na kvalitetu i poštivanje rokova.
Nedostatak rada za klijente? To što zna biti trom zbog svih uključenih razina koje moraju odobriti dijelove posla.
Vanjski pritisak nije uvijek loša stvar
Kod rada na svojim projektima sam ste sebi i klijent i voditelj projekta gdje su rokovi fleksibilni (gotovo nepostojeći) pa si možete dopustiti konstantno mijenjanje projekta. No to je ujedno i nedostatak jer vas ništa ne pritišće da projekt ugleda svjetlo dana pa tako većina osobnih projekata ne razvije potencijal do kraja. Antun savjetuje:
Ako imate projekt u kojem točno znate što će biti krajnji cilj i riječ je o nečemu što dobro poznajete, onda je bolji pristup u kojem se sve vodi kao da radite za klijenta, odnosno unaprijed odredite što će se raditi i kada i strogo se toga držite.
Iako će vas inicijalno koštati nešto novca, uzmite nekog tko je specijaliziran za određeni dio posla u kojem “niste na ti” – značajno ćete uštedjeti vrijeme i živce.
Kod kreativnih zadataka u kojima ne postoji zadano rješenje i klijent želi samo da stvar dobro radi, bolji je pristup kao da sami razvijate svoj softver, zaključuje Antun.
Sukladno članku 94. Zakona o elektroničkim medijima, komentiranje članaka na Netokraciji dopušteno je samo korisnicima koji ostave svoje ime i prezime te mail adresu i prihvate pravila ponašanja.
Pravila ponašanja
Na Netokraciji za vas stvaramo kvalitetan, autorski potpisan sadržaj i zaista se veselimo vašim kvalitetnim, kontruktivnim komentarima. Poštujmo stoga jedni druge prilikom komentiranja, kao i Zakon, držeći se sljedećih pravila ponašanja:
Kako koristimo podatke koje ostavljate? Bacite oko na našu izjavu o privatnosti.
Sve ostale komentare ćemo s guštom spaliti, jer ne zaslužuju svoje mjesto na internetu.
Komentari
goran
17. 05. 2017. u 1:06 pm
Najteže je raditi in-house zato jer kvaliteta ili nekvaliteta rada “ubrzo” ispliva na površinu.
Crno na bijelo se vidi kod nadogradnje ili zamjene dijela softwara, dali je kod reusable i modularan, mislim da je to danas osnovni cilj kvalitetnog programiranja.
Kod agencijskog razvoja troškovi nastali radom se ipak na kraju dana svale na klijenta tako da pritisak poslodavca u pogledu kvalitete ipak nije toliko velik, već je prisak na brzini rada.
Idealno za primjenu stečenog iskustva su vlastiti projekti jer imate vremena radi najbolje što znate što je nemoguče u agencijskom radu, a u in-house radu uvijek morate raditi kompromise između kvalitete i brzine rada.
Damir
18. 05. 2017. u 11:09 am
Mislim da je taj kompromis umjetan pa i zbog prirodne selekcije. Vrlo mali postotak programera posjeduje kreativnost i poslovnost za uspjeti u današnjem užasno konkurentskom startup ekosustavu. Neki bi rekli da su programeri većinom ‘fah-idioti’ (bez negativnih konotacija) – stručni u jednom segmentu ali netalentirani za ostalo. Zato im je puno bolje raditi za agenciju i biti natprosječno dobro plaćen.
Sa druge strane kreativci moraju jako riskirati i za ozbiljan projekat potrošiti puno neplaćenog vremna ili platiti (vrlo skupi) razvoj nekoj agenciji, sa realno malim šansama za uspjeh. Znači nijedna strana nije u pretjeranoj prednosti. Od tisuća domaćih projekata samo nekoliko njih ima relativni uspjeh, poražavajuća statistika.
Da je spoj dobrog programerstva i kreativnosti jako rijedak dokazuju i osnivači najpoznatijih startupa. Zanemarivo mali bropj njih su bili dobri programeri.
Tako je poznato je da je npr Larry Page za prvi Google search isprogramirao kod toliko loše da je morao zamoiliti frenda programera da ga popravi. No kod je bio toliko loš i bugovit da je frend odustao od popravljanja i morao je isporgramirati from scratch