API-liidestused ja erilahendused: miks üks nupp võib maksta rohkem kui terve alamleht?

Veebiprojekti pakkumist vaadates tekib vahel täiesti arusaadav küsimus.

Kuidas on võimalik, et ühe lihtsa nupu või väikese funktsiooni hind on suurem kui näiteks terve uus alamleht?

Leht on ju suur asi. Seal on tekstid, pildid, kujundus, mobiilivaade, võib-olla kontaktivorm ka. Nupp on… noh, nupp. Vajutad ja midagi juhtub. Mis seal siis nii kallist olla saab?

Vastus on lihtne:
sa ei maksa nupu eest. Sa maksad selle eest, mis juhtub pärast klikki.

Ja just siin lähevadki kliendi loogika ja arenduse loogika vahel teed korraks lahku.

Sest visuaalselt võib üks nupp olla väga väike. Aga tehniliselt võib ta olla terve väike tööpäev, vahel ka terve väike närvivapustus.

Nupp ise on odav. Äriloogika selle taga ei ole.

Kui veebilehele lisada uus tavaline sisuleht, siis on töö üsna arusaadav. Struktuur on olemas, kujundusloogika on olemas, sisuhaldus on olemas. Lisad uue lehe, sisestad sisu, kohandad kujunduse ja tehtud.

Aga kui keegi ütleb:
“Lisame siia lihtsalt ühe nupu, mis saadab andmed CRM-i, kontrollib kliendi staatust, kuvab erineva sõnumi sõltuvalt vastusest ja paneb seejärel automaatselt müügitiimile teavituse teele.”

…siis ei räägi me enam nupust.
Me räägime süsteemide omavahelisest suhtlusest, andmete liikumisest ja loogikast, mis peab töötama ka siis, kui elu ei lähe päris plaani järgi.

Ja elu ei lähe peaaegu kunagi päris plaani järgi.

API-liidestus ei ole “ühenda ära”, vaid “lahenda ära”

Sõna API kõlab vahel kliendi jaoks natuke nagu pistik. Et võtad ühe otsa siit, teise sealt ja ühendad ära. Tehniline toru, mis paneb süsteemid omavahel rääkima.

Päriselus on asi tavaliselt veidi lõbusam.

Kõigepealt tuleb aru saada:

• millist süsteemi ühendatakse
• millised andmed peavad liikuma
• mis formaadis need liiguvad
• kas ühendus on ühe- või kahesuunaline
• kas kasutajal peab tulema kohe vastus
• kas andmed peavad kuskile salvestuma
• mida teha siis, kui väline süsteem ei vasta või annab vea

Ja juba ongi see “üks nupp” muutunud päris arendustööks. Täpselt selliste tööde jaoks ongi olemas seadistused ja erilahendused — mitte lihtsalt ilus tehniline sõnakõlks, vaid päris töömaht.

Väline süsteem on alati väike loterii

Kui teed tavalist sisulehte, siis kontrollid enamasti omaenda süsteemi sees toimuvat. Kui teed API-liidestust, siis sõltud sa lisaks ka kellestki teisest.

See teine süsteem võib olla:

• CRM
• laohaldus
• broneerimissüsteem
• makselahendus
• raamatupidamistarkvara
• kliendiportaal
• mõni kolmanda osapoole teenus

Ja iga välise süsteemiga kaasneb oma iseloom.

Dokumentatsioon võib olla hea. Võib olla ka täiesti kohutav.
API võib olla stabiilne. Võib olla ka tujukas.
Mõni teenus annab veateateid arusaadavalt. Mõni vastab umbes stiilis “error 400, edu”.

See tähendab, et arendaja ei tee lihtsalt ühte nuppu valmis. Ta peab tegema lahenduse, mis suudab toime tulla ka sellega, kui teine pool on aeglane, katki või lihtsalt veider.

Veakäsitlus maksabki

See on koht, mida hinnapakkumistes kõige vähem märgatakse.

Klient näeb tulemust: vajutan nuppu ja asi töötab.

Arendaja näeb aga küsimusi:

• mis juhtub, kui API ei vasta
• mis juhtub, kui andmed on vigased
• mis juhtub, kui kasutaja klikib kaks korda
• mis juhtub, kui väline süsteem tagastab vale formaadi
• mis juhtub, kui ühendus katkeb poole peal

Kui neid olukordi ei lahenda, siis võib funktsioon näiliselt töötada, aga reaalsuses olla väga habras. Ja habras funktsioon on täpselt see asi, mis demo ajal töötab ja päris klientide kasutuses ära laguneb.

Keegi ei taha sellist nuppu. Eriti mitte siis, kui selle taga liiguvad päringud, tellimused, kliendiandmed või raha.

Testimine on osa tööst, mitte lisand

Veel üks põhjus, miks “väike asi” võib kalliks minna, on testimine.

Tavalise lehe puhul testid, kas kujundus on korras, mobiil töötab ja sisu on paigas. API-liidestuse puhul tuleb testida palju rohkem:

• kas andmed liiguvad õigesti
• kas kõik vajalikud väljad täituvad
• kas vead käituvad loogiliselt
• kas kasutaja saab aru, mis juhtus
• kas süsteem töötab eri olukordades
• kas turvalisus on korras

Ehk siis jälle: sa ei maksa nupu eest. Sa maksad selle eest, et see nupp ei muudaks su tööpäeva hiljem tulekahjuks. Ja kui see nupp on juba live’is, siis peab keegi suutma seda ka hallata, jälgida ja vajadusel parandada — siin tuleb mängu ka veebihaldus ja tugi.

Miks see kliendile vahel ebaõiglane tundub?

Sest tulemus on visuaalselt väike.

See on täiesti inimlik. Kui uus alamleht näeb “suurem” välja kui üks funktsionaalne nupp, siis tundub loogiline, et alamleht peaks olema kallim. Aga veebiarenduses ei määra hinda ekraanil võetav pindala. Hinda määrab keerukus.

Mõni leht on suur, aga lihtne.
Mõni nupp on väike, aga tema taga toimub väike tehniline ooper. Täpselt samal põhjusel ei ole ka ühe tunni hind alati ühe hinnaga.

Millal tulebki arvestada suurema kuluga?

Kui nupp või funktsioon:

• suhtleb välise süsteemiga
• sõltub reaalajas andmetest
• peab tegema otsuseid vastavalt kasutaja sisendile
• mõjutab tellimusi, hindu, saadavust või kliendi staatust
• vajab autentimist või turvakontrolli
• peab töötama väga kindlalt ja vigadeta

…siis on üsna normaalne, et see maksab rohkem kui mõni tavaline sisuleht. Eriti kui räägime näiteks e-poe moodulitest, broneerimisloogikast või keerulisematest automaatikatest.

Hea pakkumine seletab selle lahti

Caoticas usume, et siin ei pea kliendile lihtsalt ütlema: “see on tehniline asi, usalda meid.”

Palju parem on selgitada ausalt ära, kust töömaht tuleb.

Kui mõni väike funktsioon tundub kallis, siis enamasti ei ole küsimus selles, et keegi üritab nupu eest kullahinda küsida. Küsimus on selles, et selle nupu taga elab äriloogika, andmevahetus, veakäsitlus, turvalisus ja testimine.

Ja need on täpselt need asjad, mida klient ekraanil ei näe, aga mille puudumist hakkaks ta väga kiiresti tundma. Just sellepärast peab ka hea veebilehe pakkumine sellised asjad selgelt lahti seletama, mitte peitma neid kuskile ühe rea taha.

Ehk siis vana hea tõde veebiarendusest: ekraanil väike ei tähenda tehniliselt väike.

Vahel on kõige kallim asi kogu projektis just see üks tagasihoidlik nupp, mis peab päriselus päriselt töötama. Ja kui see nupp istub keerukama süsteemi sees, siis ei räägi me enam lihtsalt ühest klikist, vaid korralikust modulaarsest ja läbimõeldud veebiarhitektuurist.