Najveća greška koju osnivači prave pri izgradnji operativnih platformi
• 7 min read
Nakon rada sa desetinama osnivača koji grade softver za građevinarstvo, terenski servis, logistiku i druge operativno zahtevne industrije, primetili smo jasan obrazac u onome što uzrokuje da platforme u ranoj fazi stagniraju, kasne sa isporukom ili budu izgrađene ponovo od početka.
Nije problem loš inženjering. Nije pogrešan tehnološki stack. Nije čak ni to da se gradi nešto što niko ne želi.
Najveća greška je početak od kancelarije, a ne od terena.
Zamka “office-first” pristupa
Evo kako se to obično dešava. Osnivač — često bivši operativni menadžer, veteran građevinske industrije ili softverski preduzetnik koji je radio customer discovery — identifikuje stvarni problem. Izveštavanje je manuelno. Status je nemoguće pratiti. Komunikacija između kancelarije i terena je haotična.
Oni dizajniraju rešenje. Ima čistu kontrolnu tablu. Ima mobilnu aplikaciju. Ima notifikacije, izveštaje i admin panel. Pokažu ga donosiocima odluka — CTO-ovima, direktorima operacija, VP-ovima građevinskih projekata. Svima se dopadne.
Izgrade ga. Pokrenu pilot. A onda usvajanje na terenu padne skoro na nulu u roku od četiri nedelje.
Šta se dogodilo?
Proizvod je dizajniran za ljude koji su potpisali ugovor, a ne za ljude koji moraju da ga koriste. Kontrolna tabla je prelepa za VP-a koji sedi za laptopom u čistoj kancelariji i pregleda status projekta. Beskorisna je za šefa gradilišta koji pokušava da zabeleži isporuku materijala dok pada kiša, nosi rukavice i ima još deset stvari koje zahtevaju njegovu pažnju.
Zašto je ovu grešku tako lako napraviti
Osnivači optimizuju za ljude do kojih mogu da dođu. Donosioci odluka prihvataju pozive, prisustvuju demo prezentacijama i daju strukturisan feedback. Terenske radnike je teško kontaktirati, često su skeptični prema novim alatima i daju povratne informacije koje je teže interpretirati („jednostavno mi se ne sviđa“ ili „predugo traje“).
Customer discovery intervjui sa rukovodiocima daju uvide o strateškim problemima — „potrebna nam je bolja vidljivost projekata“ — ali ne hvataju operativnu realnost kako se posao zaista odvija. To jesu stvarni problemi, ali nisu konkretni dizajnerski zahtevi.
Istraživanje koje je zaista važno za operativni softver — provođenje vremena na gradilištima, posmatranje kako se radni nalozi kreiraju u realnim uslovima, razumevanje improvizovanih rešenja koja ljudi imaju u svojim postojećim procesima — teže je uraditi i manje je prijatno za osnivače koji su navikli na razgovore u salama za sastanke.
Tu postoji i kognitivna pristrasnost. Osnivači imaju tendenciju da grade softver koji bi oni sami želeli da koriste. Ako je osnivač proveo karijeru u projekt menadžmentu, finansijama ili izvršnom rukovodstvu, softver koji njima deluje intuitivno biće dizajniran za ljude poput njih. Ljudi koji obavljaju fizički posao sa ograničenim vremenom i pažnjom imaju drugačije zahteve koji se ne vide iz kancelarijske perspektive.
Šta se dešava kada terenski radnici ne usvoje proizvod
Neadopcija na terenskom nivou ne znači samo da se softver ne koristi. Ona stvara lanac posledica koji potkopava celu vrednost platforme:
Kvalitet podataka opada. Analitika i kontrolne table koje su prodale proizvod VP-u dobre su samo koliko i podaci koji dolaze sa terena. Ako terenski radnici ne beleže posao u aplikaciji — jer je komplikovana, jer ne odgovara njihovom workflowu, jer je sporija od slanja poruke šefu — podaci su nepotpuni, nekonzistentni i nepouzdani.
Rukovodioci gube poverenje. Kada VP pita „zašto ovaj projekat pokazuje 40% završenosti kada znamo da je 70% gotovo?“, odgovor je „zato što terenski radnici ne ažuriraju aplikaciju“. Rukovodilac, koji je mislio da kupuje bolju vidljivost projekta, shvata da je kupio skup alat koji ne daje pouzdane informacije.
Improvizovana rešenja se šire. Terenski radnici koji moraju da prate svoj posao, ali ne mogu da koriste aplikaciju, vraćaju se alatima koje već poznaju — papir, Excel tabele, WhatsApp grupe. Sada imate trošak novog softvera plus dodatno opterećenje paralelnih sistema.
Pilot propada. Kompanija ili ne obnavlja ugovor ili ne širi implementaciju izvan pilota, uz obrazloženje „niska stopa usvajanja“. Osnivač pretpostavlja da je problem u change managementu, investira u obuke i otkriva da obuka ne popravlja proizvod koji nije dizajniran za svoje primarne korisnike.
Ispravan redosled
Ispravan pristup izgradnji operativnog softvera obrće tipičan redosled.
Počnite od najtežeg korisnika, ne od najlakšeg kupca.
Najteži korisnik je osoba koja radi u najgorim uslovima, ima najmanje vremena i najveći otpor prema promenama. Za softver u građevinarstvu to je često terenski radnik ili šef gradilišta. Za softver za terenski servis to je tehničar koji ima pet intervencija dnevno. Dizajnirajte prvo za njih.
Ako proizvod funkcioniše za najtežeg korisnika u najgorim uslovima, funkcionisaće i za sve ostale. Obrnuto je retko tačno.
Radite istraživanje na terenu pre wireframe-ova.
Pre nego što dizajnirate bilo šta, provedite vreme posmatrajući stvarni rad. Ne intervjuišite — posmatrajte. Provedite jutro sa šefom gradilišta. Posmatrajte kako tehničar zatvara radni nalog na mobilnom uređaju. Razumite koje informacije su im potrebne, kada su im potrebne, kako ih trenutno dobijaju i šta se još bori za njihovu pažnju.
Uvidi iz posmatranja su kategorijski drugačiji od uvida iz intervjua. Intervjui vam govore šta ljudi misle da im treba. Posmatranje vam govori šta zapravo rade.
Prvo izgradite iskustvo za teren.
Kada počnete sa razvojem, počnite od workflowa koji koriste terenski korisnici — ne od admin kontrolne table, ne od izveštaja, ne od pregleda za rukovodioce. Oni jesu važni, ali zavise od podataka sa terena. Izgradite mobilno iskustvo, logovanje radnih naloga, fotografije, ažuriranja statusa. Dovedite to u red pre nego što napravite izveštavanje koje od toga zavisi.
Validirajte sa terenskim korisnicima pre pregleda rukovodstva.
Pre nego što pokažete demo donosiocu odluke, pokažite ga terenskim radnicima. Njihov feedback je teže dobiti, ali je vredniji. Ako šef gradilišta kaže „da, mogao bih ovo da koristim“, to je jači signal nego kada VP kaže „ovo je tačno ono što nam treba“.
Sekundarna greška: mešanje funkcionalnosti i rešenja
Prva greška često vodi ka drugoj: izgradnji funkcionalnosti koje izgledaju kao rešenja, bez testiranja da li zaista menjaju ponašanje.
Osnivač operativne platforme doda funkciju „dnevni izveštaj“ jer su je korisnici tražili. Funkcija se izgradi. Uđe u proizvod. Usvajanje je nisko.
Zašto? Zato što razlog zašto terenski radnici nisu slali dnevne izveštaje nije bio nedostatak formulara — već to što je formular imao 40 obaveznih polja, trajao 20 minuta i podaci su završavali negde gde ih oni nikada nisu videli. Novi digitalni formular sa 40 obaveznih polja nije bolji od papirnog koji su ranije ignorisali.
Rešenje nije bila funkcionalnost — bio je problem dizajna ponašanja. Zašto bi terenski radnik brinuo o popunjavanju dnevnog izveštaja? Šta dobija time? Šta se dešava ako ga ne popuni? Šta bi ga učinilo bržim? Koji je minimalni skup podataka koji i dalje ima vrednost?
Na ova pitanja se ne odgovara u dokumentu sa zahtevima. Ona zahtevaju duboko razumevanje workflowa i onoga što zaista pokreće ponašanje korisnika.
Šta ovo znači za vaš vremenski plan i budžet
Pravilno ulaganje u istraživanje na terenu i dizajn koji počinje od terena menja strukturu troškova projekta na načine koji su predvidivi, ali često neprijatni.
Prvih 4–8 nedelja pravilno vođenog razvoja operativne platforme trebalo bi da uključuju minimalno koda i mnogo vremena na terenu. To deluje sporo. Deluje kao da nema napretka. Investitori pitaju zašto još nema prototipa.
Alternativa — izgradnja office-first verzije, pokretanje pilota, neuspeh u usvajanju i ponovna izgradnja — traje 12–18 meseci i košta znatno više. Faza istraživanja na terenu nije luksuz; ona je upravljanje rizikom.
Kako BuildConTech pristupa ovome
Kada radimo na izgradnji nove operativne platforme, istraživanje na terenu je deo našeg procesa. Ne dizajniramo arhitekturu samo na osnovu dokumenta sa zahtevima — provodimo vreme sa stvarnim korisnicima, u stvarnim okruženjima, pre donošenja arhitektonskih odluka.
To znači da na početku gradimo sporije, a u sredini mnogo brže. Početno ulaganje u istraživanje smanjuje broj ponovnih izgradnji, obim promena u projektu i verovatnoću da pilot propadne zbog slabog usvajanja na terenu.
Radimo kao embedded partneri, što znači da smo odgovorni za rezultat — ne samo za isporuku. Kada je usvajanje na terenu nisko, to je i naš problem. Ta odgovornost oblikuje način na koji pristupamo istraživanju, dizajnu i arhitekturi.
Ako gradite operativnu platformu i želite da izbegnete najčešću i najskuplju grešku u ovoj kategoriji, rado ćemo razgovarati.
Povezano štivo: