Tablica koja iz mjeseca u mjesec raste, isti podatak koji se prepisuje u tri sustava i zahtjev kojem se ne zna trenutačni status česti su znakovi da je poslovni proces prerastao postojeće alate. Vlastita web aplikacija može pomoći, ali nije prvi korak u svakom projektu. Najprije treba jasno opisati posao koji aplikacija mora podržati.
Počnite od procesa, a ne od tehnologije
Prije razgovora o programskom jeziku zapišite tko pokreće posao, koje podatke unosi, tko ih pregledava i što znači da je zadatak dovršen. Na primjer, kod sustava za rezervacije nije dovoljno navesti „treba kalendar”. Treba znati tko otvara termine, koliko mjesta svaki termin ima, kada se rezervacija potvrđuje i što se događa pri otkazivanju.
Takav opis otkriva stvarni opseg. Neki se koraci mogu riješiti boljom organizacijom postojećeg alata, a za druge je potrebno novo sučelje ili povezivanje s vanjskim sustavom. Korisno je popisati i iznimke: pogrešan unos, nedostupnu uslugu, promjenu narudžbe i rad s više korisničkih uloga.
Primjer: od pristiglog zahtjeva do dovršenog posla
Zamislimo servis koji upite prima e-poštom, termine vodi u tablici, a status popravka javlja telefonom. Korisnik pošalje opis problema, djelatnik ga prepiše u tablicu, tehničar dodaje bilješke, a netko treći priprema račun. U tom postupku nije najveći problem nedostatak lijepog obrasca. Problem je što se ne zna koja je verzija podatka točna i tko je odgovoran za sljedeći korak.
Prva verzija aplikacije mogla bi zato imati jedan zapis zahtjeva, nekoliko jasno imenovanih stanja, dodjelu odgovorne osobe i povijest važnih promjena. Korisnički portal, automatizirane poruke i povezivanje s računovodstvom mogu doći kasnije ako se pokažu potrebnima. Takav primjer nije opis izvedenog projekta, nego način da se pri planiranju odvoji nužan tijek rada od poželjnih dodataka.
Proces treba proći s osobama koje ga stvarno obavljaju. One će prije programera primijetiti da se zahtjev ponekad vraća na dopunu, da jedan posao ima više uređaja ili da je otkazivanje moguće samo prije određene faze. Te iznimke treba zapisati prije procjene prve verzije.
Kada je dovoljna prilagodba postojećeg sustava?
Ako se posao odvija unutar WordPress stranice, zasebna aplikacija možda nije potrebna. Prilagođena tema može riješiti prikaz i uređivanje sadržaja, a dodatak može dodati posebnu funkcionalnost. WooCommerce proširenje ima smisla kada je problem vezan uz katalog, košaricu, naručivanje ili administraciju trgovine.
Samostalna PHP aplikacija prikladnija je kada sustav ima vlastite korisnike, pravila, podatke i tijek rada koji nisu prirodan dio WordPressa. Primjeri su interni portal za obradu zahtjeva, posebna platforma za rezervacije ili sustav koji povezuje više poslovnih evidencija. Odluku ne treba donositi po tome što je trenutačno popularno, nego po tome što će biti razumljivo za korištenje i održavanje.
Kako usporediti postojeći alat i novo rješenje?
Usporedba ne bi trebala stati na početnoj cijeni izrade. Postojeći alat možda traži mjesečnu pretplatu, ručni prijenos podataka i prilagodbu rada njegovim pravilima. Vlastita aplikacija traži razvoj, hosting, održavanje, sigurnosne kopije i osobu koja odlučuje o daljnjim promjenama. Trošak i korist ovise o broju korisnika i učestalosti posla, pa ih je korisno promatrati kroz dulje razdoblje.
Ako se postupak događa nekoliko puta mjesečno, ručni rad može biti jednostavniji od nove aplikacije. Ako se ponavlja svakodnevno, uključuje više ljudi i pogreška zahtijeva skupo ispravljanje, ušteda vremena i preglednost mogu opravdati razvoj. Vrijedi isprobati postojeći alat na tri stvarna scenarija: uobičajenom poslu, iznimci i ispravku pogreške. Rezultat je bolja podloga za odluku od popisa funkcija u prodajnom opisu.
Treba provjeriti i izlaz iz rješenja: mogu li se podaci izvesti, u kojem su obliku i tko ih može preuzeti? Sustav koji je jeftin za početak može postati skup ako se poslovni podaci kasnije ne mogu uredno preseliti.
Što pripremiti za procjenu projekta?
Za prvi razgovor ne treba gotova tehnička specifikacija. Dovoljno je pripremiti nekoliko konkretnih primjera:
- Kako se posao obavlja danas i gdje nastaju zastoji ili dvostruki unos?
- Tko će koristiti sustav i što svaka skupina korisnika smije vidjeti ili mijenjati?
- Koji se podaci već nalaze u tablicama, bazama ili drugim aplikacijama?
- S kojim se servisima rješenje mora povezati, a koja su povezivanja samo poželjna?
- Koji rezultat mora biti spreman u prvoj verziji?
Posebno je korisno razlikovati obvezne funkcionalnosti od ideja za kasnije. Time prva verzija ostaje usmjerena na stvaran problem, a procjena roka i cijene postaje jasnija. Ako je postojeće podatke potrebno prenijeti, treba provjeriti njihovu kvalitetu i dogovoriti tko potvrđuje točnost nakon prijenosa.
Kako teče programiranje web aplikacije?
Nakon potvrde opsega oblikuje se podatkovni model: koje zapise sustav čuva, kako su povezani i koje promjene treba pamtiti. Zatim se planiraju korisnički zasloni i pravila koja se izvršavaju u pozadini. Razdvajanje tih dijelova olakšava provjeru: zaslon može biti jasan, a da poslovno pravilo pritom nije prepušteno samo pregledniku.
Razvoj je praktično podijeliti u manje cjeline. Jedna cjelina može obuhvatiti unos i pregled zahtjeva, druga odobravanje, a treća obavijesti i izvještaje. Svaku treba isprobati s uobičajenim primjerom, pogrešnim unosom i korisnikom koji nema dopuštenje za radnju. Takve provjere otkrivaju probleme dok ih je još jednostavno ispraviti.
Posebnu pozornost traže podaci koji se dijele s drugim sustavima. Treba odrediti što je izvor istine, kako se obrađuje neuspjelo povezivanje i smije li se ista radnja sigurno ponoviti. To su odluke koje utječu na pouzdanost aplikacije jednako kao i izgled njezina sučelja.
Kako dogovoriti prvu verziju i provjeru prihvata?
Prva verzija ne mora obuhvatiti svaku zamisao, ali mora omogućiti cjelovit osnovni posao. Za primjer servisnog zahtjeva to znači da se zahtjev može zaprimiti, dodijeliti, obraditi i zatvoriti, a odgovorne osobe mogu vidjeti što je učinjeno. Nedovršena polovica deset funkcija manje vrijedi od jednog pouzdanog tijeka od početka do kraja.
Za svaku važnu radnju dogovorite što korisnik treba vidjeti nakon uspjeha i što se događa kada unos nije potpun. Provjera prihvata može se napisati običnim jezikom: „Djelatnik bez prava odobravanja ne može zatvoriti zahtjev”, „otkazani termin ponovno je slobodan” ili „dvostruki klik ne stvara dvije narudžbe”. Takvi primjeri služe i naručitelju i razvojnom timu jer preciziraju očekivani rezultat.
Promjene nakon prve verzije gotovo su sigurne. Zato je korisno od početka dogovoriti tko ih predlaže, kako se određuje prioritet i kada se nova funkcija smatra spremnom. To ne znači pisati opsežnu dokumentaciju za svaki gumb, nego sačuvati odluke koje bi se inače morale ponovno otkrivati.
Sigurnost je dio poslovnog pravila
Prijava u sustav sama po sebi ne znači da svaki prijavljeni korisnik smije otvoriti svaki zapis. Aplikacija mora provjeriti dopuštenje za konkretnu radnju i konkretan podatak. Treba planirati i sigurno spremanje lozinki, zaštitu osobnih podataka, sigurnosne kopije te način oporavka od pogreške. Te se odluke lakše donose na početku nego nakon što se sustav počne koristiti.
Na razini izvedbe, podaci koje korisnik pošalje moraju se provjeriti, a prikazati tako da se ne tumače kao izvršni kod. Za rad s bazom koriste se parametrizirani upiti. To su temeljne mjere, ali ne zamjenjuju provjeru ovlasti, ažuriranje ovisnosti i testiranje stvarnih korisničkih scenarija. OWASP-ove smjernice za provjeru ulaza dobar su pregled načela.
Dogovorite predaju i nastavak rada
Projekt ne završava kada se prva verzija otvori u pregledniku. Prije predaje treba provjeriti dogovorene scenarije, opisati administracijske postupke i odrediti kako se prijavljuju pogreške. Važno je znati tko ima pristup izvornom kodu, gdje se čuvaju sigurnosne kopije i kako se uvode promjene bez prekida rada.
Dobro planirana aplikacija nastaje iz razumljivog zadatka i jasnih granica prve verzije. Tek kada su one poznate, ima smisla odlučiti treba li razviti samostalnu PHP aplikaciju, proširiti WordPress ili doraditi postojeći sustav. Ako razmišljate o takvom projektu, pogledajte našu uslugu razvoja programskih rješenja po mjeri i opišite proces koji želite poboljšati.
