Zašto razvijati in-house rješenja

[bozoou]

Ova tema prikazuje zašto se gotovo uvijek isplati ulagati vrijeme u razvoj in-house rješenja, spram korištenja gotovih sustava.

Kod in-house sustava imamo tu mogućnost da puno fleksibilnije nadograđujemo sistem po osobnim potrebama, što svakodnevno doprinosi našoj produktivnosti. No zbog potrebe razvoja inhouse rješenja, u startu nam je produktivnost praktički nula i vrlo sporo raste.
Dok kod gotovih rješenja dobivamo u startu jednu veliku produktivnost, koja je više manje konstantna ukoliko nemamo mogućnost da taj sustav prilagođavamo osobnim potrebama koje putem naiđu.

Ta dva odnosa se mogu prikazati sljedećim grafom:

Kao što se vidi na grafu, u startu produktivnost dosta brže raste ako idemo sa gotovim rješenjima …no taj rast je poprilično lineran jer mi nemamo puno opcija utjecati na to gotovo rješenje. (Doduše nije uvijek tako)

Dok kod razvoj inhouse rješenja nam produktivnost u startu praktički stoji na mjestu i nema pomaka jer većina energije odlazi na razvoj rješenja. No kada se taj vlak lagano pokrene…te kako konstanto možemo boostati naše inhouse rješenje, tako produktivnost svakog dana se povećava. A to kreira jedan eksponencijalni graf koji prije ili kasnije prestiže linerani graf gotovih rješenja.

Naravno, imamo tu jedan kritični moment na osi t, to je moment kada produktivnost in-house rješenja prestiže produktivnost gotovih rješenja.
Kada se u startu odlučujemo na inhouse rješenje ili gotovo rješenje, moramo razmisliti upravo o tom kritičnom momentu t. Trebamo si postaviti sljedeće pitanje:

Da li ćemo preživjeti do kritičnog t momenta sa inhouse rješenjem? Ako nećemo, onda nam inhouse rješenje nije logična opcija. No ako smo sigurni da ćemo preživjeti moment t, onda praktički nema nikakvog rizika ići tim putem. To i dalje ne mora biti najbrži put, ali na duže staze, ovaj put teži biti ekvivalentan sa svim ostalim najbržim putevima. Znači, on je best-buy, pogotovo još ako volimo razvijati svoja rješenja.

Drugo bitno pitanje o kojem moramo razmisliti:

• koliko smo fleksibilni sa gotovim rješenjem? Jer ako jesmo, onda i njega konstatno možemo razvijati i ostvariti benefite i brzog starta i razvoja po eksponencijalnoj liniji.

Najidealnije bi znači bilo pametno odabirati gotova rješenja sa kojima smo fleksibilni da ih dovedemo na eksponencijalni graf. To je teoretski najbrži put, ali kao što rekoh…to uopće nije puno brži put od onoga kada propustimo prepoznati neko gotovo rješenje (i malo zaostanemo u startu), ali kasnije sve nadoknadimo jer zajašemo tu eksponencijalnu liniju.

Dok s druge strane ako odaberemo super odlično gotovo rješenje koje je produktivno i nudi fleksibilnost dodatnog razvoja, a nemamo nikakav poriv da ga usitinu dalje i razvijamo, te da sa njime zajašemo eksponencijalni graf…onda i nismo zapravo napravili neki jak posao gledano na duže staze.
Tako da ima tu još jedna bitna stvar.
Primjetio sam da mnogi iako imaju priliku nešto boostati/unaprijediti, oni to ne rade jer im to stvara privid gubitka vremena. Radije biraju u startu krenuti “bržim” grafom.

A svaki puta kada ulažemo svoje vrijeme da si nešto unaprijedimo, postavljamo se na taj eksponencijalni graf…koj je u startu sporiji zbog ulaganja dodatnog napora u razvoj, ali kasnije neminovno prestiže onaj graf koji nam se u startu činio “bržim”. Ali nikako nije brži…brži je samo neko ograničeno vrijeme i kasnije njegovo kašnjenje teži u beskonačnost, pošto i vrijeme t teži u beskonačnost.

Stoga, nerazboritim i lošim strateškim odlukama u startu…možemo baciti tone i tone naše potencijalne produktivnosti u vjetar.

[jorgovan]

Ovo je na mjestu. To govorim iz iskustva.

Kad si ovisan o nekome onda se pojavljuje hrpa problema. Ili se kasni sa implementacijom, ili se ne napravi po zeljama, ili ako imas pristup code-u, dokumentacija je ili nikakva, ili je code los.

Jedino sto nikada ne bi razvijao od 0 u firmi je knjigovodstveni/financijski program , ne isplati se fiskalna blagajna te evidencija radnog vremena.

Ostalo se isplati, erp, crm i ostali poslovni sw.

@bozoou
Tvoje misljenje za vlastiti mvc framework u php-u, vlastiti cms na tom vlastitom frameworki i vlastiti web shop,također na vlastitom frameworku.
Što misliš?

[bozoou]

@jorgovan

Tvoje misljenje za vlastiti mvc framework u php-u, vlastiti cms na tom vlastitom frameworki i vlastiti web shop,također na vlastitom frameworku.
Što misliš?

Zašto ne.
No ne mogu se takve odluke generalizirati za svakoga. Kod takvih odluka puno znači koliko se netko s nečim planira baviti. Tipa, ako se radi neki usputni web-shop, onda je očito najbolje rješenje neka gotova platforma.
A ako se planira od toga praviti core-biznis i želi postati novi “e-bay”, onda su bolje šanse da će se dalje doći sa in-house rješenjem. (Ali nije svatko ni u prilici praviti in-house rješenja, tako da onaj tko je…trebao bi jako cijeniti tu mogućnost, a ne pljuvati po njoj. )

Isto za PHP framework, sigurno ga neće razvijati netko tko ide “iz hobija” napraviti jednu web stranicu.
No kome je core biznis izrada weba, moglo bi mu dosta značit imat i svoj framework.

Iako framework se ne mora nužno praviti iz nule da bi se zasjelo na eksponencijalni graf, ali potrebno je raditi onda na tome da se neki postojeći podredi sebi, da se preuzmu kontrole nad svim bitnim eventima frameworka i da code koji nastaje u tim točkama, da se lako reciklira na svaki idući projekt.

Pod lako recikliranje ne smatram pristup:

1. treba nešto ovdje iz prethodnog projekta…pa kopaj gdje je to bilo pa copy-paste
2. pa treba nešto ovdje iz prethodnog projekta…pa opet kopaj gdje je to bilo…pa copy-paste
3. pa treba nešto ovdje iz prethodnog projekta…pa opet kopaj gdje je to bilo…pa copy-paste

Što si više takvih točki uglavimo, usporavamo progress/potencijal eksponencijalnog grafa. (Takvim pristupom težimo da se jednog dana bavimo samo time…copy-pastom bitnih segmenata. xd. Ne želimo to.)

Dobro recikliranje znači da startanje novog projekta u sebi već ima sve feature iz prethodnog projekta koji su po svojoj prirodi korisni za svaki projekt.

Slična stvar je i sa tuđim libriry-ima, treba ih provući kroz svoj “central” point, putem kojega ćemo lako reciklirat sve naše dodatke tom libriry-u. Meni su se wraperi tu pokazali najjednostavniji i najkorisniji.
Wraperi su uvijek dio mog library-a koji vučem uvijek sa sobom, a tuđi libriry u moj code ulazi samo tako da ih ugnjezdim u wraper u svoj libriry. Tako da samnom u mom libraryu ostaju sve korisne nadogradnje nad tuđim libriry-ima.

Jer ponavljam, raditi na nadogradnjama i raditi in-hose rješenja …i jedno i drugo nas pozicionira na eksponencijalni graf. Jedino gdje smo “mrtvi”, ako ništa ne radimo po tom pitanju unaprijeđivanja…jer onda smo izgubili jedan stupanj derivacije.

[belmin]

@bozoou

Ova tema prikazuje zašto se gotovo uvijek isplati ulagati vrijeme u razvoj in-house rješenja, spram korištenja gotovih sustava.

Uopste ne mora znaciti da je ovako.Sta ti to garantuje da ce graf izgledati ovako kako si ga ti predstavio ?

Da bi znao da li trebas neko vlastito rijesenje ili nesto gotovo moze posluziti, moras jako dobro procesljati (i poznavati) ostala opce prihvacena rjesenja za tvoj problem i tek onda mozes odluciti u kom smjeru ici.

Logicno da neces pogledati ovaj tvoj graf i na osnovu njega reci, super idem raditi sve od nule
Volio bih bas vidjeti tu primjenu na frontendu i koliko bi pokrio sa svojim rjesenjem, ono sto danas pokrivaju popularni FW

Da ne bude zabune, nisam protiv in-house rijesenja.Nekad je stvarno neizbjezno raditi nesto svoje

[bozoou]

@belmin

Uopste ne mora znaciti da je ovako.Sta ti to garantuje da ce graf izgledati ovako kako si ga ti predstavio ?

Objašnjeno je gore što uvjetuje oblik grafa da će jedan biti linearan drugi eksponencijalan. Nebih se trudio isponova to objašnjavati, pa da opet nakon godinu dana truda objašnjavanja … nakon što shvatiš …pljuneš na mene kako sam idiot i neznam objašnjavati. Sve piše, čitaj više puta.

Valja svakako primjetiti da točan nagib linearnog grafa i eksponent eksponencijalnog grafa zavise od raznih faktora, no njihov oblik ne.

Za shvaćanje zašto su takvi oblici grafa, može pomoći i lekcija o derivacijama/integralima. Ovaj post:
Kad Anđeli slože puzzle :) - #50 od bozoou …i još par postova nakon toga.

Priroda ne mari “što to ubrzava”, kada to prikazuje grafom. Stoga napredak po putu (ostvaren brzinom / akceleracijom) su elementi koji postoje i kod produktivnosti. Jer i produktivnost je sposobnost napredka na nekakvom putu.

[bozoou]

@belmin

Nemoj propustiti niti značenje boldanih djelova i shvaćati rečeno prekruto:

@bozoou

Ova tema prikazuje zašto se gotovo uvijek isplati ulagati vrijeme u razvoj in-house rješenja

@bozoou

…no taj rast je poprilično lineran jer mi nemamo puno opcija utjecati na to gotovo rješenje. (Doduše nije uvijek tako)

[belmin]

Da, ali ovdje pricamo o software developmentu (valjda?), i tu zakoni fizike ajmo reci ne vaze
Tvoj graf opisuje neko idealno okruzenje i situacije, a iz mog iskustva idealno okruzenje u software developmentu ne postoji

Ako ne pricamo o razvoju nekog softverskog rijesenja, onda ne znam i ne bih se upustao u dalju raspravu.

@bozoou

nakon što shvatiš …pljuneš na mene kako sam idiot i neznam objašnjavati

Pronadji mi gdje sam ja rekao da si ti idiot i gdje sam pljunuo na tebe ? To da ne znas na jednostavan nacin objasniti neke stvari, bez upliva filozofije i nekih analogija sa evolucijom covjecanstva i dalje smatram.

Sto se fizike tice, i game developmenta tu ti skidam kapu (u objasnjavanju toga).

[bozoou]

@belmin

Da, ali ovdje pricamo o software developmentu (valjda?), i tu zakoni fizike ajmo reci ne vaze

Krivo.
Zašto je generalno graf razvoja tehnologije kroz ljudsku prošlost eksponencijalan?
Zato jer tehnologija ima tu karakteristiku da sa razvojem sebe omogućava daljnji lakši razvoj same sebe. Ta karakteristika čini eksponencijalni graf.

Uzmimo za primjer koliko god naprednu tehnologiju iz bilo kojega segmenta proizvodnje. (Ne mora biti programiranje)
Evo, neka ta tehnologija proizvodi “gumene bombone”.
Ako imaš tenologiju za uber brzu proizvodnju gumenih bombona, imat ćeš linearan graf i dalje. Doduše, ako stvarno jako brzo proizvodiš te bombone…graf će biti strm prema gore…ali i dalje linearan.

S druge strane, ako imaš neku relativno primitivnu tehnologiju za proizvodnju gumenih bombona, koju si sposoban unaprijeđivati…tako da sa protokom vremena možeš svaki puta proizvesti nešto više bombona u istom vremenskom periodu nego što si mogao prošli mjesec … onda ćeš imati eksponencijalni graf.

(Ok, zaboravio sam ranije spomenuti i da eksponencijalni graf može ući u svoje zasićenje, ili točku kraha … zbog čega nemamo baš 100% garanciju da će svaki eksponencijalni graf nužno prestići linearni)

@belmin

Pronadji mi gdje sam ja rekao da si ti idiot i gdje sam pljunuo na tebe ?

Znaš i sam na koji način si se počeo obraćati prema meni. Neću ulaziti u to što te točno frustira, ali smatam da nije uredu. I ne trebam ti ja da ti dokazujem na koji način i kako si počeo “komuncirati”. Poštedi me takvoga natezanja.

@belmin

o da ne znas na jednostavan nacin objasniti neke stvari, bez upliva filozofije i nekih analogija sa evolucijom covjecanstva i dalje smatram.

Onda je opet bolje da ti neobjašnjavam, ako ti se ne dopada moj način objašnjavanja.
Svatko bira svog učitelja …ne bira učitelj svoje učenike.

[trnac]

Na koji broj ljudi / zaposlenih bi se to trebalo odnositi?
Firme s minimalno 10 zaposlenih, 20, 50, 100…?

[sjekira]

@bozoou

Znaš i sam na koji način si se počeo obraćati prema meni. Neću ulaziti u to što te točno frustira, ali smatam da nije uredu. I ne trebam ti ja da ti dokazujem na koji način i kako si počeo “komuncirati”. Poštedi me takvoga natezanja.

Jbt pusti malo gas.
Sve ti je najnormalnije rekao, ali izgleda da nisi bas sve najbolje shvatio i da si ti taj koji bi trebao citati vise puta da shvati a ne belmin.

Na kraju ce jos bit: eh koliko su mi samo zla nanijeli @belmin @c3po i sjekira

[bozoou]

@sjekira

Jbt pusti malo gas.
Sve ti je najnormalnije rekao

Ne ovdje. Ja dobro znam na kakav ton je Belmin prešao prilikom obraćanja meni. I nakon nekog vremena što sam istrpio takvu komunikaciju, rekao sam mu da više neće ići tako i poželio mu dobrodošlicu među “probrane”. Ne kužim zašto uopće ima obraza nakon toga tražiti pojašnjenja.

Malo njegovog načina izražavanja, koji mu je postao standard kada se meni obraća:

@belmin

Jos jedan doprinos temi, ali vjerujem da je i ovo za autora teme previse verbose

Inače mi je belmin bio (i ostao) iznimno drag momak na ovom forumu, tim više me pogodilo što se počeo razgovarati kao kakav mangup i namjerno pokazivati da nema poštivanja. Gdje mi je očito da mu je svaka druga napisana sa namjerom da uvrijedi, a ne da konstruktivno sudjeluje u temi.

Toliko o tome i neću više odgovarati na tu temu. Belmin kada se upristoji, ja ću biti opet dobre volje odgovarati mu na svako pitanje.

[bozoou]

Svaki slučaj je indivudualan kada se procjenjuje koliko će trajati period do kritičnog momenta t.

Ne ovisi to samo o broju ljudi, nego i o sustavu/komponenti oko koje se važe hoće li se razviti inhouse. Nekada je to ogroman sustav, a nekada je to samo neka metoda koja se razvije za 15min …ili se odabere 2 min googlanja da se koristi nečija tuđa.

15min i 2min su karikirane brojke. Može biti neka komponenta koja se razvija sat vremena…ili 10 sati.
Treba znati procjeniti jel to vrijeme bačeno ili nije.

@trnac

Firme s minimalno 10 zaposlenih, 20, 50, 100…?

Veća ekipa svakako ima veće kapacitete da pregazi veće kritične momente t, i da na kraju zbog toga fino profitira. Drugim riječima, veće ekipe mogu veće sustave podrediti pod svoju kontrolu. Kao što vidimo iz priloženoga kakve sustave recimo Google podređuje sebi i razvija. Sigurno ne zato jer im je dosadno, nego zato jer znaju da su nakon nekoga vremena u plusu sa takvim ulozima. (Čak i ako dosta projekata propadne, ostali donose dovoljnu produktivnost da se sve skupa takva strategija fino isplati)

Što misliš zašto je Google razvijao npr. Google Documents? Sigurno ne da ga pokloni narodu

…nego zato jer im je trebalo za internu komunikaciju i za povećanje vlastite produktivnosti.
Ako uz to uspiju i prodati alat koji si razviju, plus može biti i puno veći.

[petarcro]

Za manje firme ovo moze biti dvosjekli mac koji moze cak i ugroziti poslovanje firme ukoliko se previse vremena/novaca ulaze u inhouse rjesnje.

[bozoou]

Naravno, kritični moment t se mora znati procjeniti.
No za neke komponente ga nije teško procjeniti ako su “malene”, a dio bitnog sustava. Ja tu ne razmišljam “preveć”.

A valja spomenuti (što nije ukalkulirano do sad) …da svaki razvoj donosi i bitna iskustva i znanje. Tako da još jedan fini plus za “zasukati rukave” i raditi.

[trnac]

Potpuno promašena teza.

Ne znam kakve bi to firme trebale razvijati in-house rješenja?
Računovodstveni servisi?
Maloprodaje / veleprodaje svega i svačega?
Putničke agencije?
Web shopovi?

Slučajno radim za dvije firme koje imaju ino vlasnike. Nisu programerske firme, ali su tehnološki potkovane. Međutim, ne pada im na pamet trošiti resurse (a pogotovo ne razvijati in-house rješenja) na ništa što se kosi s njihovim core businessom.

Kada sam nekad davno radio u Getrou (ZG), morali smo raditi svoje rješenje za maloprodajne kase. Razlog je bio taj da tadašnje kase nisu radile dobro, a firma koja je prodala rješenje nije mogla/htjela napraviti ništa bolje. Ispitivanjem tržišta se nije našlo prikladno rješenje (uz adekvatan poček od par mjeseci) i odluka je bila - in-house rješenje.

Bilo smo svjesni da je sve bolje od razvijanja vlastitog rješenja koje će i tako biti zamjenjeno čim se nađe adekvatna vanjska zamjena.

[bozoou]

Platiti vanjsku firmu da razvija custom rješenje je skoro pa isti vrag kao i platiti svoje ljude da razvijaju custom rješenje. (U ovom gore kontekstu gdje ističem inhouse rješenja zbog fleksibilnosti koja se tu nudi)

Opet smatram da je bolje kad se može iznutra razviti, jer se ne može završiti u situaciji da ta vanjska firma odustane od daljnjeg razvijanja.

Tvoj primjer tako pokazuje prednost inhouse rješenja, jer inače nebi izvisili kako ste izvisili. Nije moj problem što ta firma nije naučila nešto iz te greške i opet tražila isti put…gdje postoji šansa da poljubi nosom vrata opet na isti način. Ali i to je bolje nego imat gotov sustav sa kojim nisi fleksibilan, a o tome je u uvodu teme riječ.

[trnac]

Već sam napisao podulju argumentaciju, ali sam odustao…

[bozoou]

Ne znam…nije ti dobar primjer Googla, kao vodećeg igrača…a vodio bi se primjerom propalog Getroa.

Meni se osim teorijskog obrazloženja, to full pokazalo točnim i u praksi da to tako funkcionira. Zato bi stvarno morao čuti dosta jak dokaz kao kontru, koji bi usto morao razjasaniti praktično iskustvo koje imam.

Nekada tamo prije 10g. sam imao djelomični strah da mi je teorija kriva, ali kako sam tada pravio planove i za 10g unaprijed (sve do jednog su se obesitnili i potvrdili teoriju) … tako i sada kada planiram, planiram puno unaprijed…ali sada imam puno veću vjeru da će sve ići očekivanim tokom.

Upravo danas mi stigla “alatka”, koja će biti jako vrijedan asortiman “oružja” za sljedeća in-house rješenja.

Guess who is here:

Da ne govorim da već sada proučavam teoriju za razvoje jedne (in-house) komponente, koju ću valjda moći realizirati tek nakon 3-5. godina.

Ali pošto mi ništa ne visi za vratom da će zbog toga propasti u tih 5g. to će se sve vratiti višestruko.

Bitno je strateški usmjeriti razvoj unaprijed, tako da se ne gase stalno “požari”.

[jorgovan]

Isplati se razvijati proizvodnim firmama od erpa nadalje, osim knjigovostvenog/financijskog, pod uvjetom da imaju odredjeni broj ljudi.

Ne isplati se ako je firma od 50 ljudi, ali ako je 250-300, svakako se isplati.

Gotovo rjesenje - mogucnost prilagodbe kako ti hoces je ravno nula, jer ako firma koja nudi erp i ima x klijenata, sad zamisli da svakome klijentu prilagodjavaju. Mogu ti eventualno prilagoditi reporte.
Isto tako te ne mogu onda ucjenjivati da im moras platiti 300-500 k kn za api.

Ima druga strana, da ne treba razvijati sve ispocetka?
Dosta se prosirio oddo erp, jer se lako nadogradjuje, uzme se neku firmu da implementira i napravi se obuka za 2-3 programera i vozi. A firma koja je radila implementaciju odrzava knjigovodstveni/financijski dio.

Ima hrpa modula, od voznog parka, imovine, crm-a itd.

Ako ti nesto ne odgovara, ili prilagodis ili sam napravis kako ti odgovara.

I imas jedan sustav koji pokriva financije, hr, crm, erp, skladiste, vozni park itd…

Jedan sustav, jedna baza, sve na jednom mjestu.

Moduli se lako i brzo razvijaju.

Erp, crm, hr i sl. , isplati se razvijati od nule, ako firma nema nista.

A puno brze je onda uzeti firmu da implementira oddo da se moze raditi.

Da oddo nije tako fleksibilan ili ne bi postojao takav sw, onda se svakako isplati razvijati ispocetka nekima.

Treba sve odvagati.

[bozoou]

@jorgovan

Treba sve odvagati.

Tako je, to su stvari koje se trebaju odvagati i ne mogu se promatrati crno-bijelo. Moj uvodni post to također ne tumači crno-bijelo, nego čisto ukazuje na model “regulacije” koji tu postoji. …kako bi se možda netko osvjestio problematike i ako hoće, neka kalkulira sa istim.

Mi ljudi prirodno imamo ugrađenu regulaciju da želimo samo što prije ispraviti grešku.
To funkcionira dobro u većini slučajeva. Npr…kada ti je vruće, prirodno bježiš od izvora topline. (Ispravljajući tako grešku, koja je u ovom primjeru razlika trenutne topline okoline od željene topline)

No tricky part je kada te požar zarobi u zgradi koji se širi odozdo. Intuitivno tko bježi od topline, bježat će na gornje katove i možda će tako privremeno ublažit posljedice vrućine, ali vrlo vjerovatno mu je na kraju pogibelj suđena nakon što ostane zarobljen u još većem požaru.

Zato nekada regulacija traži da idemo prvo u susret problemu. U ovom slučaju, treba prihvatiti veću količinu topline i ispeći se malo ako treba…da bi se probilo na niže katove ispod požara i tako se spasilo.

Ista stvar postoji u modelu koji sam opisao uvodnim postom.
Onaj tko je u grču od nedostatka vremena …on prirodno bježi ka “quick-and-dirty” rješenjima. Misleći tako da ako spašava neko vrijeme “ovdje i sada” da generalno spašava vrijeme na duže staze. A zapravo se zakopava samo još dublje.
Da bi zaista spasili svoje vrijeme, treba upravo prvo žrtvovati to vrijeme, kako bi se kasnije ono višestruko vratilo.

To je inače najzaebaniji model regulacije u automatici…i teško ga je opisati regulatorima.
Ljudi unutar sebe isto imaju regulatore, te u ovakvom slučaju ponašanja modela vrlo lako padaju u zamku. Što ne znači da se ne može odreagirati optimizirano ukoliko se razumije ponašanje modela.