Kokios programavimo paslaugos gali būti reikalingos papildomai?

Kada standartinio funkcionalumo gali nepakakti

Standartinis sprendimas dažnai padengia įprastus scenarijus, tačiau verslo taisyklės skiriasi. Poreikis atsiranda, kai darbuotojai tą pačią informaciją perrašo tarp sistemų, klientui negalima pritaikyti būtinos kainodaros, tiekėjo duomenys neatnaujinami, užsakymo būsena neatitinka realaus proceso arba ataskaitai tenka rankiniu būdu jungti kelis šaltinius.

Dažnos papildomo programavimo kryptys

Sistemų integracijos

Duomenų mainai su apskaitos, ERP, sandėlio, klientų valdymo, tiekėjų ar prekyviečių sistemomis. Reikia tiksliai aprašyti, kurie duomenys perduodami, kuria kryptimi, kada, kas laikoma pirminiu šaltiniu ir kaip tvarkomos klaidos.

Mokėjimo ir pristatymo procesai

Gali prireikti specifinio mokėjimo būsenų apdorojimo, pristatymo taisyklių, etikečių, paštomatų, kurjerių ar kelių sandėlių logikos. Pirmiausia verta patikrinti palaikomas standartines integracijas.

Individualūs moduliai ir verslo taisyklės

Pavyzdžiai – nestandartinė kainodara, komplektai, produktų konfigūravimas, užsakymų tvirtinimas, lojalumo procesas, dokumentų generavimas ar specifinė paieška. Funkcija turi būti aprašyta vartotojo scenarijais ir aiškiomis taisyklėmis.

B2B funkcionalumas

Įmonėms gali reikėti individualių katalogų ir kainų, darbuotojų rolių, limitų, tvirtinimų, pasiūlymų, dokumentų ar pakartotinių užsakymų. Svarbu nustatyti, kas ką mato, keičia ir patvirtina.

Administravimo įrankiai ir automatizacijos

Masinis duomenų redagavimas, importai, eksporto failai, pranešimai, užduočių eilės ir kontrolės ekranai gali sumažinti rankinį darbą. Automatizacijai būtinos klaidų būsenos, žurnalai ir galimybė darbuotojui įsikišti.

Duomenų migracija

Keičiant platformą gali reikėti perkelti prekes, klientus, užsakymus, turinį, nuorodas ir kitus duomenis. Migracija apima ne tik kopijavimą, bet ir laukų atitikimą, valymą, bandomąjį perkėlimą bei rezultatų patikrą.

Našumo, prieinamumo ir naudojimo patobulinimai

Kartais individualių darbų reikia norint sutvarkyti lėtą procesą, sudėtingą formą, klaviatūros valdymą ar kitą konkrečią kliūtį. Tokius darbus verta pagrįsti matavimu arba aiškiai pakartojama problema.

Kaip nuspręsti: nustatymas, modulis ar individualus kūrimas?

1. Aprašykite problemą ir norimą rezultatą, neminėdami iš anksto pasirinkto techninio sprendimo.
2. Patikrinkite, ar poreikį galima išspręsti sistemos nustatymais ar pakeitus procesą.
3. Įvertinkite palaikomą esamą modulį ar oficialią integraciją, jos licenciją, atnaujinimus ir suderinamumą.
4. Jei būtinas individualus kūrimas, nustatykite mažiausią vertingą apimtį ir priėmimo kriterijus.
5. Suplanuokite testavimą, diegimą, stebėseną, dokumentaciją ir priežiūrą po paleidimo.

Ką pateikti programuotojui

• dabartinio proceso ir problemos aprašą;
• naudotojų roles ir jų veiksmus;
• pavyzdinius duomenis bei laukų paaiškinimus;
• išorinių sistemų dokumentaciją ir prieigos sąlygas, jei jos žinomos;
• taisykles, išimtis ir klaidų scenarijus;
• duomenų saugumo bei teisių reikalavimus;
• aiškius kriterijus, pagal kuriuos darbas bus priimamas.

Kas lemia projekto apimtį

Vertinimui įtakos turi sistemų dokumentacija, duomenų kokybė, taisyklių skaičius, integracijų patikimumas, testavimo aplinka, migravimo apimtis, saugumo reikalavimai ir palaikymas po diegimo. Todėl patikimas pasiūlymas rengiamas pagal konkrečią užduotį, o ne vien funkcijos pavadinimą.