Uvidi za rukovoditelje digitalne transformacije
Pročitajte naše blogove i praktične vodiče koji pomažu senior leadership timovima definirati jasnu digitalnu viziju, donositi pametnije investicijske odluke i uspješno voditi digitalne transformacije.
Zašto inicijative za developer experience platforme ne uspijevaju i što poduzeća mogu učiniti po tom pitanju?
Podijelite na društvenim mrežama
Zašto inicijative za developer experience platforme ne uspijevaju i što poduzeća mogu učiniti po tom pitanju?
Philip Papp
Published on 20. travnja 2026.
13 min čitanja
Philip Papp
Published on 20. travnja 2026.
13 min čitanja
Prijelaz na odjeljak
Prijelaz na odjeljak
Početak s alatima umjesto s developerima
Podcjenjivanje važnosti ljudi i procesa
Fragmentirano vlasništvo i nejasna odgovornost
Slaba integracija, loše planiranje migracije i složenost alata
Nedovoljna podrška menadžmenta i pogrešan model financiranja
Jaz u mjerenju: kada vrijednost postane nevidljiva
Što enterprise organizacije mogu učiniti
Prilika je stvarna, ali i složenost
Programi developer experience (DevEx) platformi obećavaju povećanje produktivnosti developera, smanjenje tehničkog duga i ubrzavanje izlaska proizvoda na tržište. Pa zašto onda toliko takvih inicijativa zapne, premaši budžet ili tiho nestane?
Developer experience (DevEx) postupno se popeo visoko na listi prioriteta enterprise organizacija. Uprave odobravaju višegodišnje transformacijske programe. Formiraju se platform engineering timovi. Interni developer platform sustavi (IDP-ovi) se dizajniraju, financiraju i implementiraju. Ipak, iznenađujuće velik broj tih inicijativa ne uspije ostvariti svoje izvorne ciljeve - ne zato što je ambicija bila pogrešna, već zato što se složenost njihove realizacije sustavno podcjenjuje.
DevEx nije samo osvježavanje alata ili nadogradnja CI/CD sustava. Radi se o temeljnom promišljanju načina na koji organizacija povezuje tehnologiju, ljude i procese kako bi promijenila poslovne rezultate. Tvrtke koje kreću na ovo višegodišnje putovanje istovremeno usvajaju nove tehnologije, automatiziraju ručne procese, poboljšavaju kvalitetu i sigurnost, smanjuju troškove i stvaraju diferenciranu vrijednost za korisnike. Ulog je velik. Značajno poboljšanje produktivnosti developera, čak i relativno skromnih pet posto u velikoj inženjerskoj organizaciji, može donijeti milijune eura vrijednosti. Jednako je velik i trošak pogrešaka, uključujući loše proizvode, odlazak developera, produženo vrijeme izlaska na tržište i rastući tehnički dug.
Pa što pođe po zlu? Kroz rad s enterprise organizacijama u svim fazama DevEx transformacije primijetili smo konzistentan skup obrazaca neuspjeha. Oni se rijetko pojavljuju izolirano. Češće se međusobno kombiniraju i pojačavaju, dodatno produbljujući početni problem. Evo što najčešće viđamo - i kako to izbjeći.
Početak s alatima umjesto s developerima
Najčešći obrazac neuspjeha koji susrećemo istovremeno je i najrazumljiviji: organizacije kreću od alata. Okupi se platform tim, evaluira se uži izbor tehnologija, a zatim slijedi nabava. Ono što često nedostaje jest ozbiljno ulaganje u razumijevanje developera kojima je platforma zapravo namijenjena.
Developer persone, workflowovi i problemi tijekom onboardinga rijetko se detaljno mapiraju prije donošenja odluka o platformi. End-to-end mapiranje korisničkog puta, ono koje otkriva prepreke kroz cijeli razvojni lifecycle i omogućuje timovima da prioritiziraju poboljšanja platforme prema stvarnim potrebama developera, više je iznimka nego pravilo. Rezultat je platforma koja rješava probleme koje je platform tim zamislio, a ne one s kojima se developeri svakodnevno suočavaju.
Loš service design dodatno pogoršava problem. Kada se developer portali i “golden path” workflowovi izrađuju bez developer-centric pristupa dizajnu, usvajanje self-service modela ostaje nisko. Ako platforma ne čini ispravan način rada najjednostavnijim načinom rada, developeri će pronaći zaobilazna rješenja, a ulaganje u platform engineering donijet će tek dio očekivane vrijednosti.
Podcjenjivanje važnosti ljudi i procesa
Tehnologija je rijetko najteži dio DevEx transformacije. Teži dio odnosi se na kulturu, organizaciju i ponašanje, i upravo se taj dio gotovo uvijek nedovoljno planira.
Platforme koje se predstavljaju kao obvezni standardi ili alati za provođenje usklađenosti, umjesto kao atraktivni i jednostavni “paved roads” pristupi, izazivaju otpor među developerskim zajednicama kojima bi trebale služiti. Percepcija gubitka autonomije snažan je demotivator. Kada developeri osjećaju da im se platforma nameće umjesto da se gradi zajedno s njima, stope usvajanja padaju, raste broj zaobilaznih rješenja, a poslovno opravdanje za daljnja ulaganja slabi.
Kros-funkcionalno usklađivanje potrebno za uspješan DevEx, između platform engineering timova, aplikacijskih timova, sigurnosti, HR-a i poslovnih odjela, sustavno se podcjenjuje. Promjene u kulturi, ulogama i ponašanju moraju biti jasno definirane i resursno podržane kao sastavni dio programa, a ne tretirane kao naknadna stavka uz tehničku implementaciju. Bez toga, čak i tehnički izvrsne platforme ne uspijevaju postići značajno usvajanje.
Fragmentirano vlasništvo i nejasna odgovornost
Inicijative vezane uz DevEx platforme imaju strukturnu ranjivost: obuhvaćaju više timova, budžeta i linija odgovornosti. Bez jasno definiranog vlasništva i stvarne product management funkcije, program gubi smjer. Odluke se odgađaju, prioriteti se fragmentiraju, a tempo isporuke usporava do brzine najneodlučnijeg dionika.
Workstreamovi vezani uz platformu, enablement i usvajanje, koje zahtijeva zreo DevEx program, često funkcioniraju u silosima, bez zajedničkog roadmapa ili jedinstvenog vlasnika odgovornog za integrirani rezultat. Privremena podrška za vođenje inženjerskih timova kroz tranziciju u velikom opsegu često izostaje. Posljedica je program koji izvana djeluje aktivno, ali zapravo ostvaruje spor ili nedosljedan napredak prema ciljevima koji su opravdali početno ulaganje.
Situaciju dodatno otežava činjenica da budžetska sredstva unutar poslovnih jedinica često nisu dovoljna ili uopće ne postoje. Platform engineering timovi ne mogu sami preuzeti puni trošak transformacije na razini cijele kompanije. Bez odgovarajućih ulaganja poslovnih jedinica koje od transformacije imaju najveću korist, tempo migracije i usvajanja ograničen je od samog početka.
Slaba integracija, loše planiranje migracije i složenost alata
Tehnička složenost izgradnje enterprise-grade interne developer platforme značajna je i često podcijenjena tijekom ranih faza planiranja. Integracija CI/CD pipelineova, cloud infrastrukture, observability alata, sigurnosnih kontrola i postojećih poslovnih sustava zahtijeva pažljivu arhitekturu i kontinuiran inženjerski angažman. Kada se ta složenost loše isplanira, integracija postaje dugi niz neriješenih ovisnosti koje ograničavaju korisnost platforme i odgađaju njezino usvajanje.
Fragmentacija alata dodatno pogoršava problem. Mnoge enterprise inženjerske organizacije godinama gomilaju različite alate, uključujući redundantne i preklapajuće tehnologije koje povećavaju kognitivno opterećenje i otežavaju integraciju. DevEx platform inicijativa koja izravno ne adresira ovu fragmentaciju riskira dodavanje još jednog sloja kompleksnosti na već kaotične temelje.
Jednako su važni onboarding i planiranje migracije. Ako usvajanje platforme nije demonstrativno jednostavnije od postojećeg načina rada, timovi neće migrirati. Jasno definiran i dobro podržan migracijski put, zajedno s modelom privremene podrške tijekom tranzicije, preduvjet je za usvajanje u velikom opsegu, a ne opcionalni dodatak.
Nedovoljna podrška menadžmenta i pogrešan model financiranja
DevEx inicijative zahtijevaju predanost i financiranje uprave, poslovnih jedinica, platform engineering timova i developerskih zajednica unutar tih poslovnih jedinica. Bez podrške na razini CIO-a i aktivnog uključivanja ključnih dionika, program ostaje nedovoljno financiran ili zapinje na prvoj ozbiljnijoj prepreci.
Posebno štetan obrazac jest tretiranje ulaganja u platformu kao projekta, a ne proizvoda. Projektni model financiranja stvara umjetne rokove, narušava kontinuitet i onemogućuje iterativna poboljšanja koja platformski proizvod prirodno zahtijeva. Kada financiranje prestane na kraju projektnog ciklusa, prije nego što usvajanje dosegne razinu potrebnu za dokazivanje ROI-ja, program se često gasi prije nego što dobije priliku ostvariti stvarnu vrijednost.
Ukupni trošak vlasništva (TCO) također se sustavno podcjenjuje. Troškovi rada, alata, cloud infrastrukture koja se naplaćuje prema potrošnji i kontinuirani operativni troškovi često nisu uključeni u business case, što dovodi do budžetskih manjkova i neugodnih iznenađenja tijekom programa. Bez sveobuhvatnog modela financiranja, razvijenog u bliskoj suradnji s financijama i CFO-om, čak i kvalitetno dizajnirane platforme mogu izgubiti financijsku podršku prije nego dosegnu zrelost.
Jaz u mjerenju: kada vrijednost postane nevidljiva
Najizbježniji obrazac neuspjeha istovremeno je i jedan od najčešćih: nedostatak metrika usmjerenih na poslovne rezultate. Inicijative koje ne mogu pokazati napredak kroz mjerljive poslovne pokazatelje, poput lead timea, frekvencije deploymenta, stope usvajanja, smanjenja troškova i zadovoljstva developera, teško uspijevaju zadržati podršku dionika potrebnu za dugoročan uspjeh programa.
Problem se dodatno pogoršava kada se mjerenje postavi prekasno, izvještavanje provodi prerijetko ili kada su rezultati predstavljeni isključivo tehničkim jezikom koji ne rezonira s financijskim timovima i C-level menadžmentom. Kvartalno izvještavanje kroz jasnu i poslovno usklađenu priču o vrijednosti nije “lijepo imati”. To je mehanizam kojim se opravdava nastavak ulaganja i održava momentum programa.
Upravljanje, sigurnost i policy kontrole koje nisu ugrađene u platformu kroz “platform-as-code” pristup stvaraju drugačiju vrstu problema s mjerenjem: ručne compliance procese koji uvode dodatno trenje, usporavaju isporuku i narušavaju developer experience koji bi platforma trebala unaprijediti. Kada su zaštitni mehanizmi (“guardrails”) ugrađeni od samog početka, compliance postaje pokretač, a ne prepreka.
Što enterprise organizacije mogu učiniti kako bi DevEx inicijative imale najveće šanse za uspjeh
Obrasci neuspjeha opisani iznad dobro su poznati. Poznata su i rješenja. Izazov nije u prepoznavanju onoga što treba napraviti, već u organizacijskoj odlučnosti da se to provodi dosljedno, od samog početka i tijekom cijelog trajanja višegodišnjeg programa.
Dodijelite jasno vlasništvo i tretirajte platformu kao proizvod
Imenujte dedicated product managera za internu developer platformu, definirajte metrike uspjeha povezane s poslovnim prioritetima i oduprite se iskušenju da program vodite kao projekt s unaprijed definiranim završnim datumom.
Uložite u razumijevanje developera prije ulaganja u platform engineering
Mapirajte developer persone, workflowove i probleme tijekom onboardinga. Koristite radionice, programe ranog usvajanja i kontinuirane feedback loopove kako biste osigurali da platforma rješava stvarne prepreke, a ne zamišljene probleme. Platformu predstavite kao “paved road”, nešto što developeri žele koristiti, a ne kao nametnuti standard.
Financirajte sveobuhvatno i dugoročno
Izradite business case koji uključuje troškove rada, alata, operativne troškove (OPEX) i troškove infrastrukture koji se naplaćuju prema potrošnji. Uključite financijski odjel i CFO-a u ranoj fazi. Zagovarajte product-block model financiranja koji odražava kontinuiranu i iterativnu prirodu ulaganja u platformu, umjesto projektnog financiranja s umjetno definiranim milestoneovima.
Osigurajte podršku na CIO razini i međufunkcionalno usklađivanje
DevEx obuhvaća platform engineering, sigurnost, HR, poslovne jedinice i produktne timove. Bez aktivnog sponzorstva na najvišoj razini, program će biti nedovoljno financiran, nedovoljno prioritetiziran i neće moći provesti međufunkcionalne promjene koje zahtijeva.
Ugradite governance i policy kontrole kao code od samog početka
Automatizirajte compliance i sigurnosne guardrailove unutar same platforme. Ručne kontrole stvaraju dodatno trenje, usporavaju isporuku i stvaraju uvjete u kojima developeri zaobilaze platformu.
Mjerite, izvještavajte i iterirajte kvartalno
Definirajte metrike uspjeha prije pokretanja programa. Redovito izvještavajte dionike o napretku kroz poslovno relevantne rezultate, a ne samo tehničke milestoneove. Koristite NPV i ROI alate kako biste vrijednost inicijative učinili jasnom financijskim timovima i C-level menadžmentu.
Prilika je stvarna, ali i složenost
DevEx platform inicijative ne propadaju zato što je vizija pogrešna, već zato što se složenost njezine realizacije sustavno podcjenjuje. Organizacije koje uspijevaju su one koje DevEx tretiraju kao istinsku enterprise transformaciju, s razinom financiranja, vlasništva, međufunkcionalne suradnje i discipline u mjerenju koju takva transformacija zahtijeva.
Konkurentski ulozi su jasni. Enterprise organizacije koje uspješno povećaju produktivnost developera, smanje tehnički dug i ubrzaju izlazak proizvoda na tržište nadmašit će one koje to ne uspiju. Obrasci neuspjeha su poznati. Rješenja postoje. Pitanje je samo hoće li vaša organizacija dosljedno primjenjivati ta rješenja, od uprave do developerske zajednice, tijekom višegodišnjeg transformacijskog puta.
Ako ste na početku tog puta ili usred programa koji ne ostvaruje planirane rezultate, rado ćemo razgovarati o konkretnim koracima koji DevEx transformaciju čine uspješnom te o tome kako Venue.sh, naša interna developer platforma, može pomoći organizacijama stvoriti vidljivost, zaštitne mehanizme i self-service iskustvo potrebno za pretvaranje dobrih namjera u mjerljive rezultate.
Istražite strategije za uspjeh vaše DevEx inicijative
Posjetite naš Developer Experience knowledge hub.
Napisao/la
Senior Strategic Advisor
Philip Papp je DevOps lider koji kombinira duboku tehničku stručnost sa strateškim vodstvom u područjima AWS-a i Kubernetesa. S više od 8 godina iskustva pomaže organizacijama u izgradnji sigurnih cloud platformi, vođenju visokoučinkovitih timova i modernizaciji njihove infrastrukture.