Zašto razvijati in-house rješenja

@belmin

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

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

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

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).

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)

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.

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

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

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

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:

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.

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.

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 :wink:

…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.

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

1 Like

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ć”. :slight_smile:

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.

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.

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č.

Već sam napisao podulju argumentaciju, ali sam odustao…

1 Like

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

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. :smiley: :smiley:

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”.

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.

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.

1 Like

Nisam procitao bas sve postove od rijeci do rijeci pa se nadam da netko vec nije spomenio.

Ali @bozoou sto je sa kasnijim odrzavanjem sustava? Sto kada ljudi koji su kreirali sve iz nule odu?

Upravo glavni benefit popularnih frameworka je community i to da ces vjerojatno odgovor naci unutar istog, a koristenjem vlastitog rijesenja se upravo svjesno odrices toga.

Upravo sa frameworkom si olaksava zaposljavanje kasnije, jer ces uglavnom traziti ljude koji vec imaju iskustva u odredenom fw i lakse ce se prilagoditi.

Vjeruj mi prije sam bio veliki pobornik vlastitih rijesenje i uvijek sam govorio pa taj kod mora imati problema i sa sigurnosti svi imaju sourcecode dostupan negdje na git-u ja mogu napraviti nesto sto nitko nece znati, i upravo taj dio “sto nitko nece” znati je zapravo i najveci problem.

Ok, to je dobra opaska.

REZIME:
Da, inhouse pristup ima tu manu da drugi ne poznaju tvoj sustav. (Kako si i sam rekao, nije to uvijek ni mana)
Ali svaki pristup ima svoje prednosti / mane i treba se znati nositi sa time.



WHOLE POST:

…ali uvodni post se ne odnosi generalno samo na frameworke, tj. sustave koji su podliježni znanju nekih velikih dokumentacija. Tako da je i to za odvagati.

Uvodni post se u suštini ne odnosi niti samo na inhouse rješenja, nego je poanta u ulaganju vremena u razvoj i unaprijeđenje sebe. To čini eksponencijalni graf.

Hoće li se taj razvoj vidjeti kroz razvoj inhouse komponenti, ili kroz unaprijeđenje tuđih komponenti, dođe na isto. No inhouse je istaknut, jer vrlo često nemamo priliku na isti način unaprijeđivati gotova rješenja, kao što možemo inhouse rješenja.

No budimo realni, nema tu linije koja to dvoje razdvaja. Uvijek moramo koristiti neka gotova rješenja…osim ako ne mislimo uzeti kamenu sjekiru i krenuti od klesanja kamena…

Tako je recimo smješno i da Rimac tvrdi da rade sve inhouse i ekipa koja mu to pokušava demantirati. A niti jedna ni druga strana ne mogu biti u pravu. Iako se on nespretno izražava, druga strana bi trebala shvatiti što je time htio reći…i fokusirati ono što zaista prave. Jer bakar je logično da ne proizvode, heh.

A konkretno što se tiče frameworka i razvoja “takvih” sustava.
Pa nije ni to bauk imati takav neki svoj sustav. Treba “samo” imati razvijenu i asimilaciju novih ljudi u sustav.
Kako je toniperic stavio u svoj oglas da niti PHP nije obavezan, da je bitna logika razmišljanja, a da se jezik lako nauči.
Tim istim pristupom ja nikada nebi tražio ljude po uvjetu da se poznaje framework i generalno da se poznaju sustavi sa kojima firma radi. Čovjek ako ima iskustva sa sličnim alatima i ako zna razmišljati, on će se lako asimilirati. Firma mu treba svakako pomoći u tom procesu sa svojom dokumentacijom i sa intro tečajem.
Ne kažem da nije lijepo kada dolazi čovjek koji “sve već zna” …ali i to je samo kratkoročni “gain” koji se neće akumuliati u vrijednost beskonačno kako vremenska os teži u beskonačno.
Dok s druge strane spomenute prednosti se akumuliraju u beskonačno kako vremenska os teži u beskonačno. Dugoročno je tu znači veća dobit.

Svakako ako je prevelika cirkulacija ljudi kroz firmu problem, onda treba razmišljati i o drugim elementima da se ta cirkulacija što više smanji.
Jer realno da nema cirkulacije ljudi kroz firmu, tvoj spomenuti problem niti ne postoji. A uspješna firma, nebi trebala imati problem sa cirkulacijom ljudi.
A ako su inhouse rješenja recept za uspješno poslovanje…onda taj problem nije uzrokovan in-house pristupom, nego nečim drugim.

To je prednost popularnog frameworka vs onog nepopularnog.
Ali ako se radi o tvom sustavu, onda lakše pronalaziš riješenje unutar sebe, nego traganjem da ti netko iz community-a pomogne.

I nije mi baš jasno zašto ste uvodni post uglavnom shvatili da se tu radi o nekakvim velikim sustavima razvijenim in-house.

Puno malih nadogradnji nas također postavlja na eksponencijalni graf.

Evo jednog banalnog primjera, čisto jedna mala nadogradnja, a korisna. (Tiče se web-developmenta)

Možete ugraditi u vašu radnu okolinu da svaka stranica u dev modu ima mali pop-up prozor koji se nalazi pozicioniran npr. u donjem-lijevom kutu. Prelaskom miša preko tog prozora, on se otvara (iskače jel).
Što se nudi na tom popup prozoru?

Pa samo postojanje takvog prozorčića je već fina podloga da se na njega s vremenom nakaleme razne korisne funkcije koje ćemo imati potrebu ugraditi u našu radnu okolinu.

Evo jedne sitničice koja se može ugraditi:
svaki puta kada kliknete mišem na ekran da se na tom popup-u ispiše razlika x i y koordinata od zadnjeg klika. Time ćete postići da kada napravite double click na ekran, da se ispiše dx:0 dy:0, pošto je drugi klik u nizu očito forsirao razliku po x i po y da su nula.
No nakon tog double-klika, gdje god da kliknete na ekran, dobit ćete izmjeru duljine po x i y osi od pozicije gdje ste napravili double-click.

Huh, koliko puta je samo trebalo saznati koliko je nešto udaljeno međusobno na stranici? Ova metoda je inače precizna u px i svakako korisna.

Poanta je znači i u tako malim nadogradnjama…da se redovito ulaže vrijeme u razvoj vlastite okoline i da nas to pozicionira na eksponencijalni graf.

Kada ulagati vrijeme?

Pa svaki puta kada smo primjetili da smo i makar 10 sekundi potrošili na nešto što se moglo relativno lako automatizirati. Jeste, otići će na automatizaciju možda nekoliko sati posla, ali na duže staze je ovih 10 sekundi skuplje. Pogotovo kada se sve te sitne nadogradnje akumuliraju…pa smo uštedili 10 sekundi simo, 10 tamo…itd. I to je jako puno, kada se svo to vrijeme oslobodi da ta energija bude uložena u nešto drugo…da opet bude slobodna da ide u daljnji razvoj samog sebe.

U suprotnom, ako se tih 10 sekundi nakupi simo-tamo, tako da više nemamo vremena da pomišljamo o razvoju sebe, onda smo onaj koji je usred požara otrčao na vrh zgrade i više mu nema jednostavnog spasa.
Jer cijelo vrijeme smo tada podređeni da se bavimo tim neophodnim sitnicama, što nas dovodi u manjak vremena da ih unaprijeđujemo. Zatrpamo se tako glupostima i sudbina nam je da samo “gasimo požare”.

A poanta uvodnog posta je da grafom ukaže zašto je isplativo izdvojiti i nekoliko sati posla, da se uštedi 10 sec na svakodnevnoj bazi.

Možemo to staviti i u matematičku kalkulaciju:
Recimo da neka sitničica uzima dnevno tri puta po 10 sec. Ili ti ga dnevno pola minute vremena.
To je mjesečno 15min vremena, godišnje 3 sata, a u sljedećih 5 godina to je bačeno 15 sati našeg vremena.

Znači ako uložimo sada 15 sati posla da automatiziramo taj proces koji dnevno uzima 3x10 sec, to je isplativ povrat investicije u 5 godina. A povrat investicije u 5g je više nego odličan deal.

A osim što smo nakon tih sljedećih 5g sa vremenskom potrošnjom na nuli, te kasnije imamo samo čisti plus … valjda primjetiti da takvim pristupom stvaramo vrijedan asortiman raznih alata, skupljamo vrijedna znanja i iskustva, te je ugodnije raditi razvijajući okolinu, nego biti rob takvih sitničica po 10sekundi. Ko nekakva čimpanza koja bi takve poslove mogla obavljati.

Znači odabir je između:

  • potrošiti 15 sati svog vremena na razvoj okoline, znanja i iskustva i biti zauvijek u plusu sa vremenskom bilancom

ili

  • tih 15 sati (i puno više) potratiti obavljajući stupidni task od 10 sekundi, svakodnevno po nekoliko puta…

Igrom slučaja me danas zove jedan stari kolega i iskreno mi kaže da njemu nije jasno kako sam ja tek sada uspio …te da je on očekivao da će to biti puno ranije.
(haha, jesam li uopće xd …iz njegovih usta u Božje uši. Smatram da je put ka uspjehu vječna pustolovina bez svoga kraja.)

A ja si mislim…da mu objašnjavam ovaj graf ili ne, haha. Jer upravo je u tome fora…kada godinama ranije nije mnogima bilo jasno što ja radim, ja sam svjesno (vjerujem i lukavo) ulagao svoje vrijeme za svoju budućnost. Smatram da to nije neki startan način ka uspjehu (kao što prikazuje graf) …ali isto tako smatram da je to poprilično siguran put ka željenoj destinaciji.

Jer ono što je sigurno, znanje koje se steče putem nam ne može ama baš nitko uzeti. Postoji evenutalno rizik od kakve ozljede glave ili tako neke neuračunate nezgode…ali više manje su tim putem sve karte otvorene na stolu. Treba samo vjerovati i voliti ono što radimo…što će rezultirati da budemo ustrajni na tom putu.

A onda na koncu svega, iako to nije bio možda startan način…on se u jednom momentu pretvara u popriličnu agilno “bićence”, koje lako prestiže ono drugo “biće” koje je bilo startnije u startu.