Miks veebilehe jõudlus on juhtimisotsus?

See on lumepalliefekt. Tehnoloogiad arenevad väga kiiresti ja koos sellega kasvavad ka nõuded. Mida kiiremini tehnoloogiad arenevad, seda kiiremini kasvavad ka ootused ja nõuded ning see omakorda sunnib tehnoloogiat veelgi kiiremini muutuma. Veeb, mis oli viis aastat tagasi kaasaegne, on täna sageli aegunud. Muutunud on turvanõuded, kasutatavus ja inimeste ootused.

Sageli ei piisa kosmeetilistest muudatustest. Vaja on muuta äriloogikat ja tarkvaralist alust. Hea näide on mobiil. Kui toetad mitut seadet ja ekraanitüüpi, suureneb ressursivajadus kogu süsteemis. Mobiilivaate otsused mõjutavad otseselt ka veebivaadet. Iga lisanduv seade või ekraanitüüp ei mõjuta ainult üht vaadet, vaid kasvatab kogu süsteemi keerukust ja ressursivajadust korraga.

Sama kehtib serveripoolel. Iga uut lahendust ei saa lihtsalt vana peale ehitada. Tarkvaraarenduses tuleb juba baastasemel teha otsused, mis määravad, kas süsteem suudab ajas areneda või hakkab arengut pidurdama.

Enamasti ärilistest otsustest. Äriline pool ei ole alati tehnoloogiatega kursis. Kui visuaalselt midagi ei muutu, aga arendus toimub taustal, tundub see paigalseisuna.

Olemasolevate funktsionaalsuste töös hoidmine on igav, aga see võtab sageli rohkem ressurssi kui uute arendamine. Tarkvaraarenduses on see kriitiline koht, kus jõudlusprobleemid hakkavad tasapisi kuhjuma.

See ei ole klassikaline disainiotsus, vaid see, kuidas disain tarkvaras implementeeritakse. Disain peab olema implementeeritud nii, et seda oleks vajaduse korral võimalik kiiresti muuta ning disainivigadest tulenevaid probleeme lahendada.

Kasutajate ootusi ei kujunda ainult sinu enda disain, vaid väga suurel määral ka harjumused, mis tekivad teiste teenuste kasutamisest. Uus populaarne teenus mõnes täiesti teises valdkonnas võib kasutajate harjumusi ja ootusi väga kiiresti muuta. Kui tarkvaraline teostus ei võimalda muutusi, kannatab nii jõudlus kui kasutajakogemus.

Disainer ei pea ise infrastruktuurile mõtlema, aga disain ei saa sündida sellest lahus. See ei tähenda vabadust tegutseda eraldiseisvalt, vaid vajadust siduda disainiotsused varakult arenduse ja infrastruktuuritiimiga.

Disaini väljatöötamine peab käima koos arenduse ja infrastruktuuriga, et oleks võimalik juba varakult märgata kohti, kus väiksed muudatused võivad hiljem suurt mõju avaldada.

Näiteks võivad müügi- või reklaamlehed vajada teistsuguseid turvanõudeid või serveripoolseid optimeerimisvõimalusi kui ülejäänud teenus. Kui disainiprotsessis otsustada varakult, millised lehe osad on staatilised, võib see kiirendada veebilehe laadimist kordades rohkem kui hilisemad tarkvaralised optimeerimised nagu cache.

Sageli tehakse need otsused juba projekti alguses ja delegeeritakse tehnilisele tasandile, kuid nende mõju ulatub palju kaugemale kui esialgu paistab. Veebilehe või rakenduse halduse kiirus ei ole seotud ainult serveri jõudlusega ega piirdu infrastruktuuri kuludega.

Jõudlus ei ole ainult serveri kiirus. See mõjutab kasutajakogemust, arendajakogemust (DX) ja seda, kui kiiresti on võimalik probleeme tuvastada ja lahendada.

Kui veeb on maas, loeb, kas info on 10 minuti pärast olemas, kuidas seda kommunikeeritakse ja kui kiiresti leitakse põhjus. Praktikas juhtub ka seda, et probleemiga pöördutakse vale partneri poole ja alles siis selgub, et teenus ei asugi seal, kus eeldati.

Tarkvaraarenduses loevad ka ligipääsud, vastutused, teadmine, kus süsteem üldse asub, ning see, kui selge on, kelle poole infrastruktuuritaseme probleemide korral pöörduda.

Sellele küsimusele ei ole ühtset vastust, sest nii kiirusel, uutel funktsioonidel kui ka kiirel kasvul võivad olla omad plussid. Negatiivne kogemus levib aga kiiremini kui positiivne.

Kui kiire kasvu ajal midagi ei tööta või on aeglane, ei lahkuta lihtsalt vaikselt, vaid probleem tõstatatakse avalikult, näiteks sotsiaalmeedias, ning see jääb sinna kauemaks kui tehniline rike ise. Tehnilise probleemi võib olla suhteliselt lihtne lahendada, kuid mainekahju parandamine ei ole enam pelgalt tehniline on/off küsimus.

Koostöö efektiivsus sõltub eelkõige inimestest, mitte ainult protsessidest või tööriistadest. Esimene kontroll on väga lihtne. Vaata esimese koosoleku osalejate nimekirja. Kas kõik vajalikud rollid ja valdkonnad on esindatud?

Kui jõudlusega seotud teemadega hakatakse tegelema juba varakult ja koostöös, võib esmane planeerimine tunduda küll pikem ja igavam.

Hiljem on aga ühine keel olemas ning nii disainerid kui ka äripool oskavad otsuseid tehes arvestada jõudluse ja tehniliste piirangutega. Seetõttu liiguvad vajalikud muudatused kiiremini, mis loob positiivse emotsiooni ja tugevdab tiimitunnet.

Tehisintellekti tulekuga peab arvestama, et see on arenev keskkond. Areng on nii kiire, et tänane arvamus homme enam ei kehti. Kõige tähtsam on luua majasisene AI pädevus, kes on kõigega kursis, ja siis seda ka usaldada.

WUD on meie tiimile iga-aastane traditsioon.

Lisaks sponsortiimile käivad kohal ka meie arendajad ning kasutajaliidese ja kasutajakogemuse disainerid, et kursis olla muutustega. Ettekanded, suhtlemine teistega ja õhtused arvamuste vahetused aitavad hoida tiimi teadmisi tasemel, et tänapäevases keskkonnas hakkama saada.

Pärast toote valmimist hakkab alles päris töö pihta.