Nuo idėjos iki paleidimo. Taip HMOOD kuria skaitmeninius sprendimus.
Už užbaigtos svetainės ar skaitmeninio sprendimo slypi kur kas daugiau nei dizainas ir kodas. Čia sužinosite, kaip HMOOD dirbu su planavimu, dizainu, programavimu, testavimu ir atsakingu dirbtinio intelekto naudojimu.
Apsilankius svetainėje, pirmiausia dažniausiai krenta į akis vizualinė pusė. Spalvos, nuotraukos, animacijos ir tai, kaip sudėliotas turinys.
Nesimato visų sprendimų, pakeitimų ir darbo valandų, kurios slypi už viso to.
Man vienas įdomiausių skaitmeninių sprendimų kūrimo dalykų yra būtent šis procesas. Pradėti nuo idėjos, tyrinėti įvairias galimybes ir palaipsniui sukurti tai, kas ir gerai atrodo, ir veikia taip, kaip turi.
HMOOD projektą paprastai dalinu į keturis pagrindinius etapus: analizę, dizainą, programavimą ir paleidimą. Etapai suteikia darbui struktūrą, tačiau tai nereiškia, kad viskas vyksta tiesia linija. Kartais programuojant paaiškėja, kad dizainą reikėtų pakoreguoti. Kitais atvejais testavimas parodo, kad funkciją galima įgyvendinti geriau.
Ir tai visiškai natūralu.
Nuo idėjos iki užbaigtos svetainės
Išsiaiškinami tikslai, naudotojai ir poreikiai, o struktūra nubraižoma prieš ką nors kuriant.
Struktūra įgauna vizualinę kryptį: tipografiją, spalvas, nuotraukas, mygtukus ir maketą.
Dizainas tampa veikiančia sąsaja iš dalių, kurios turi veikti kartu bet kokio dydžio ekranuose.
Prieš paskelbiant tikrinamas funkcionalumas, našumas, pritaikymas mobiliesiems ir prieinamumas.
01. Analizė – suprasti prieš kuriant
Projektas prasideda nuo supratimo, ką iš tikrųjų reikia sukurti ir kodėl.
Ko siekia įmonė? Kas naudosis sprendimu? Kokias problemas jis turi išspręsti?
Gali atrodyti, kad tai paprasti klausimai, tačiau atsakymai labai lemia, kaip projektas vystysis.
Svetainė, kurios pagrindinis tikslas – pristatyti paslaugas ir palengvinti susisiekimą, turi kitokių poreikių nei klientų portalas, kuriame naudotojai prisijungia ir tvarko informaciją.
Todėl analizės etapas – tai ne tik pageidavimų ir idėjų rinkimas, bet ir įvertinimas, ką tikslinga kurti.
Tikslas – sukurti aiškų pagrindą prieš pradedant dizaino ir programavimo darbus.
02. Dizainas – nuo idėjos iki vizualinės krypties
Kai tikslai ir poreikiai išsiaiškinti, prasideda vizualinis kūrimas.
Čia dirbu su struktūra, tipografija, spalvomis, maketu ir naudotojo patirtimi. Mėgstu tyrinėti skirtingas išraiškas, ypač tai, kaip animacijos ir interaktyvūs elementai gali padaryti svetainę įdomesnę.
Kartu dizainas turi atlikti funkciją.
Animacija gali atrodyti įspūdingai, tačiau jei dėl jos svetainę sunkiau naudoti arba ji blogina našumą, tai nebūtinai geras pasirinkimas.
Šiame etape dirbtinį intelektą naudoju ir kaip pagalbinę priemonę. Tokie modeliai kaip Sol, Astra ir Opus gali pasiūlyti idėjų, alternatyvių dizaino sprendimų ir techninių įžvalgų.
Taip per trumpesnį laiką galima ištirti daugiau krypčių.
Tačiau DI modelio pasiūlymas vis tiek tėra pasiūlymas. Įvertinu, ar jis tinka projektui, kaip jis veikia skirtingo dydžio ekranuose ir ar iš tikrųjų pagerina naudotojo patirtį.
Galutinis dizainas turi būti ne tik patrauklus vizualiai. Jis taip pat turi būti apgalvotas ir patogus naudoti.
03. Programavimas – kai dizainas tampa funkcionalus
Kai dizaino kryptis patvirtinta, prasideda darbas paversti ją veikiančiu sprendimu.
Tai apima sąsajos kūrimą, funkcijų įgyvendinimą ir užtikrinimą, kad skirtingos dalys veiktų kartu.
Priklausomai nuo projekto, tai gali būti bet kas – nuo gana paprastos svetainės iki sudėtingesnės programinės įrangos su keliomis funkcijomis ir techninėmis sistemomis.
Ir čia DI gali būti naudingas.
DI modelius, be kita ko, naudoju programavimo pagalbai, techniniams pasiūlymams ir klaidų paieškai. Tai gali palengvinti alternatyvių sprendimų nagrinėjimą ir problemų nustatymą.
Tačiau DI sugeneruotas kodas nėra savaime geras kodas.
Pasiūlymas gali veikti vienu atveju, bet sukelti problemų kitu. Jis gali būti be reikalo sudėtingas, sunkiai prižiūrimas arba nepastebėti svarbių detalių.
Todėl kodą reikia peržiūrėti, pritaikyti ir išbandyti.
Man programavimas nėra vien tai, kad kažkas imtų veikti. Svarbu ir suprasti, kaip tai veikia, bei kaip sprendimą bus galima prižiūrėti ir toliau tobulinti.
Testavimas ir klaidų taisymas – darbas, kurio dažnai nesimato
Tai bene ta kūrimo proceso dalis, apie kurią, mano manymu, svarbiausia kalbėti atvirai.
Sprendimas gali atrodyti užbaigtas gerokai anksčiau, nei iš tikrųjų yra paruoštas naudoti.
Neretai nemažai laiko skiriu smulkioms detalėms nagrinėti, animacijoms derinti, klaidoms taisyti ir įvairiems funkcijos elgsenos variantams išbandyti.
Kaip svetainė veikia mobiliajame telefone? Kas nutinka, jei naudotojas kelis kartus paspaudžia tą patį mygtuką? Ar naršymas veikia naudojant klaviatūrą? Kas nutinka, jei užklausa nepavyksta?
Tokie klausimai yra svarbūs.
Testavimas taip pat nėra vien klaidų paieška. Tai patikrinimas, ar sprendimas iš tikrųjų suteikia tą naudotojo patirtį, kurią turėtų suteikti.
Todėl testuoju ir tobulinu nuolat viso kūrimo metu, o ne tik pačioje pabaigoje.
Pakeitimas gali paveikti ir kitas sistemos dalis. Kai kas nors pataisoma ar patobulinama, reikia patikrinti, ar kitos funkcijos vis dar veikia taip, kaip tikimasi.
Šis darbas užima laiko, tačiau yra svarbi kokybės užtikrinimo dalis.
Kaip naudoju DI nedalydamas klientų informacijos
Dirbtinis intelektas natūraliai įsiliejo į mano kūrimo darbą. Kartu manau, kad svarbu aiškiai pasakyti, kokios ribos galioja.
Kai naudoju debesijos DI paslaugas, tokias kaip ChatGPT, Claude ar Gemini, jos neturi gauti tikros informacijos apie klientus ar įmones, su kuriais dirbu.
Tai, be kita ko, apima įmonių pavadinimus, asmenų vardus, nuotraukas, kontaktinius duomenis, vidinius dokumentus ir kitą informaciją, kuri priklauso klientui arba gali būti su juo susieta.
Todėl darbas su tokiais modeliais vyksta naudojant išgalvotą turinį, bendrus pavyzdžius ir bandomuosius duomenis.
Tik tada, kai darbas su debesijos DI modeliais projekte baigtas, į sprendimą įkeliu tikrą klientų informaciją.
Jei dirbant su šia informacija reikia DI pagalbos, vietoj to galiu naudoti vietoje veikiančius modelius privačioje ir izoliuotoje aplinkoje, nesiųsdamas duomenų išorinėms DI paslaugoms.
Šis atskyrimas yra sąmoningas.
Manau, kad visiškai įmanoma naudotis šiuolaikiniais DI įrankiais, nesuteikiant jiems prieigos prie klientų informacijos.
Technologijos turi padėti tobulinti darbo procesą, o ne mažinti tvarkomos informacijos kontrolę.
04. Paleidimas – kai sprendimas susiduria su realybe
Kai kūrimas artėja prie pabaigos, atliekami paskutiniai patikrinimai ir patobulinimai.
Čia, be kita ko, tikrinamas funkcionalumas, našumas, pritaikymas mobiliesiems įrenginiams, prieinamumas ir svarbūs saugumo aspektai.
Tikras turinys taip pat turi būti savo vietoje ir patikrintas užbaigtame sprendime.
Tikslas – kad tai, kas paleidžiama, būtų kruopščiai išbaigta, o žinomos klaidos būtų sutvarkytos prieš paskelbimą.
Tačiau paleidimas nebūtinai reiškia, kad darbas baigtas.
Poreikiai gali keistis. Technologijos tobulėja. Gali prireikti naujų funkcijų, o esamus sprendimus galima patobulinti.
Todėl svarbu pagalvoti ir apie tai, kaip projektą bus galima prižiūrėti ateityje.
Geras sprendimas – daugelio apsvarstymų rezultatas
Dirbtinio intelekto raida man atrodo neįtikėtinai įdomi, ir manau, kad tokie įrankiai vaidins vis didesnį vaidmenį kuriant skaitmeninius sprendimus.
Kartu darbas su HMOOD išmokė mane, kaip svarbu skirti laiko detalėms.
Lengva sužavėti tuo, kaip greitai technologijos gali sugeneruoti dizainą ar parašyti kodą.
Tačiau dažnai tik pradėjus testuoti, derinti ir tobulinti rezultatą paaiškėja, kas iš tikrųjų veikia.
Man būtent kūrybiškumo, technologijų, kruopštaus testavimo ir atsakingų pasirinkimų derinys daro kūrimo darbą įdomų.
Skaitmeninis sprendimas nėra geras vien todėl, kad atrodo užbaigtas.
Jis turi veikti žmonėms, kurie juo naudosis.