Išmoktos pamokos pirmajame darbe: SEO, dizainas, specifikacijos ir projektų valdymas

Praeitame įraše rašiau apie tai, kad pirmajame savo darbe (vis dar pagal autorines sutartis) buvau beveik viskuo: nuo Google Adwords kampanijų prižiūrėtojo iki programuotojo. Darbas reklamos agentūroje buvo itin gera pradžia į laisvai samdomo darbuotojo karjerą, nes turbūt išmokė visas įmanomas klaidas.

Be svetainių kūrimo pirmasis dalykas su kuriuo pradėjau darbuotis tai tuomet gana paslaptingos Google Adwords mokamos reklamos. Atsimenu, kad nieko apie jas neišmaniau apart to, kad Google Analytics buvo augantis ir naujas įrankis, kuris dalinai buvo susijęs su pačiu Google Adwords mokamos reklamos servisu.

Būdamas sąžiningas ir norėdamas atlikti darbą teisingai pirmasis žingsnis, kurio ėmiausi, tai iš torrentų parsisiunčiau galybę Apress knygų apie SEO ir Google Adwords. Skaičiau jas angliškai vietoje tinklaraščių kas dieną tam, kad suprasčiau, kas tai per dalykas ir kaip teisingai jas valdyti.

Negaliu nepasididžiuoti, bet tos perskaitytos turbūt 3 knygos buvo itin puiki pradžia į bendrą supratimą apie SEO ar Google, kurį belikdavo papildyti bei neatsilikti skaitant tinklaraščius. Taip suformavau savo bazines žinias, kurios praverčia iki šiandien.

Antroji problema, kurią tuomet suvokiau, kad spaudos dizaineris negali būti interneto dizaineris. Tais laikais beveik kiekvienas dizaineris save laikydavo universaliu dizaineriu, tokių sąvokų kaip UX ar UI apskritai niekas nevartodavo. Ir tai buvo reikšminga bėda.

Bėda, nes dizaineriai nupiešdavo neinteraktyvius gražius atvirukus, kurie kažkokia prasme turėdavo veikti kaip svetainės. Keletas pavyzdžių:

• Meniu punktai nupiešiami taip, kad neturėtų jokių state ir net neina suprasti, kad gali ant jų paspausti.
• Naudojami gradient (tais laikais CSS3 nebuvo dar) ir fonas tapdavo vienu didžiulius paveikslėliu – įsivaizduokie, ką dabar pasakytų Google PageSpeed Insight ataskaita apie tai
• Naudojamas italic šriftas ar net vieną kartą panaudotas comic sans. Taip, taip, pasitaiko visko.

Tam, kad pagelbėčiau kolegoms skaitydavau tuomet populiariausią Smashing Magazine interneto tinklaraštį, kuris iš esmės suformavo mano supratimą apie tai, kas yra web dizainas: kaip elementai turėtų būti išdėlioti, kokios yra gerosios praktikos ir apskritai tai turbūt buvo pagrindas visiems UI/UX išsivysčiusiems ateityje.

Tad pirmasis barjeras prieš parodant dizainus klientams tapdavau aš – tas, kuris dar sugrąžindavo keletą pastabų dizainerei, kad dizainas būtų bent kiek geresnis. Ir, pamenu, patyrusiai spaudos dizainerei tai būdavo peilis – kažkoks mokyklinukas bando aiškinti, kad piešia čia ji ne taip. Būdavo daug trinties, bet jaučiau pareigą daryti gerai ir kokybiškai. Norėjau dalytis žiniomis.

Trečioji problema, buvo tai, kad svetainės būdavo ne pagrindinė reklamos agentūrų duona. Ne paslaptis, kad reklamos agentūros yra dažnai apie ryšius ir santykius, kuomet ateina „geras bičiulis“ bei užsako iš tavęs paslaugų, nes žino, jog „dalykus darai gerai“.

Dėl šios bėdos pastebėjau, jog dažnai klientai perdavus projektą užsimanydavo vis daugiau funkcionalumo arba funkcionalumo kitaip. Jiems būdavo normalu, kad už fiksuotą kainą turi išpildyti visus jų lūkesčius ir norus. Juk jeigu organizuoji renginį arba nori pataisyti skrajutės maketą praktiškai gali kiek nori keisti maketą iki kol tau patinka galutinis rezultatas.

Iš pradžių nebūdavo ir nerašydavome jokių specifikacijų. O, žinoma, gi bičiulio nenuvilsi, tad visus papildomus įgeidžius reikia įgyvendinti ir dar nemokamai. Savaime gaudavosi, kad visa tai galų gale būdavo atliekama mano sąskaita. Niekas nesuprato, kad pridėti papildomą tipą puslapių nėra tik meniu punkto pridėjimas, o reikalauja papildomai suprogramuoti naują esybę, valdymą ir integruoti į pačią sistemą.

Buvau tik kažkur prabėgomis girdėjęs apie specifikacijas, kad tokios apskritai būna. Įmonėje įvedžiau siekį aprašyti (gerų geriausiai tai galima būtų pavadinti poreikius) prieš darant bet kokį projektą ir už papildomus norus neišsakytus kaštus apmokestinti papildomai.

Iš to išlošėme turbūt drauge: man nereikdavo nemokamai ir tuščiai dirbti įgyvendinant besikeičiančius poreikius, o agentūrai atsirado pretekstas iš kliento paimti netgi daugiau. Nors kai kuriais atvejais, daugiau gaudavau jau tik aš iš to paties biudžeto.

Nuo to momento išmokau ir kiekvienam projektui rašydavau technines specifikacijas arba bent jau poreikių aprašymus. Nuolat tobulėjau ir mokiausi jas rašyti tiksliau, geriau ir su kiekvienu nauju klientu turėdavau vis mažiau ginčų apie tai, kas turi būti padaryta ir už kiek.

Ketvirtoji problema su kuria susidūriau tai buvo projektų valdymas. Pasirodo, kad suorganizuoti renginį ar suvaldyti maketo ar vizitinių kortelių darbą nėra tas pats, kas sukurti veikiančią interneto svetainę.

Negali pykti, nes ir šiandien dienai sudėtinga rasti gerus IT projektų vadovus. Tiesiog tam, kad būtų geras IT projektų vadovas tu turi išmanyti, ką daro tavo kolegos dizaineriai, programuotojai ir suprasti procesą. Jeigu to neišmanai ir nesupranti iš esmės, esi pasmerktas likti tik laiškininku tarp klientų ir programuotojo. Buvimas laiškininku dažnai yra tiesiog tuščias ping-pong‘as tarp klientų ir laiškų persiuntinėjimas, kuris nekuria vertės.

Būtent tokį neatitikimą pastebėjau jau dvyliktoje klasėje stebėdamas kaip su manimi dirba projektų vadovas. Pavyzdžiui, mano supratimu, prieš perduodant užduotį programuotojui ji visų pirma turi būti tinkamai aprašyta, gauti prisijungimai, suformuota ir viskas pateikta, jog liktų tik ją atlikti. O gaudavosi taip, kaip norėtųsi tikėti dabar jau IT įmonėse nebebūna, kad „negaliu atsakyti, man reikia pasitikslinti“ arba „aš sugrįšiu su atsakymu“. Tavo atsakymus tiesiog „copy-paste“ siunčiam klientams ir forwardina jų laiškus. Galų gale tu patampi projektų vadovu nori to, ar nenori.

Tąkart problemą sprendėme tokiu būdu, jog dar pirmame kurse neturėdamas automobilio tapau gana dažnu keliauninku traukiniais iš Kauno į Vilnių, kuomet būdavau įtrauktas į susitikimus su klientais.

Buvo miela, kai būdamas pirmakursis su pirmuoju traukiniu 6 val. išvykdavau į Vilnių, kur prieš 8 manęs traukinių stotyje jau laukdavo projektų vadovas ir keliaudavome kartu į susitikimus.

Buvo tikrai baisu, nes įmonės buvo gana didelės ir prabangios. Bent jau taip atrodė man.  Rengdavausi savo geriausią megztuką. Žiūrėdavau, kad ant palto neliktų jokių pūkelių ir tai turbūt buvo mano pagrindinės pirmosios pamokos darbui su klientais.

Klausydavausi ir stebėdavau, kaip išties geras projektų vadovas (nepaisant visų tų problemų su IT) gražiai bendraudavo, klientui pameilikaudavo, spręsdavo konfliktus ar net parduodavo paslaugas. Mokiausi iš pavyzdžio. Ir turiu pasakyti, kad tas mokymasis stebinti yra ne ką mažiau svarbus nei pačiam darant. Kuomet nesuvoki ir nesupranti situacijos vien stebėjimas tau duoda begalę daug konteksto, kurį gali pritaikyti vėliau mokymasis iš savo klaidų ir už tai esu be galo dėkingas.

Pavyzdžiui, išmokau ir tokią paprastą, atrodo elementarią, taisyklę, kad tam, jog būtum punktualus turi ateiti minutę į minutę: nei anksčiau nei vėliau, nes turėdavau tokią tendenciją visada būti visur per anksti bijodamas, kad pavėluosiu.

Juokinga, kad šiais metais kai kurie iš šių tuomet buvusių mano klientų per agentūra tapo mano klientais el. komercijos srityje net patys to nežinodami. Paglosto savimeilę.

Taigi darbas pirmajame darbe dar pagal autorines sutartis su reklamos agentūra paklojo man pamatus tolimesnei mano laisvai samdomo darbuotojo kelionėje. Suformavau savo pirmuosius SEO įgūdžius, gilinau toliau programavimo žinias kurdamas sistemas su WordPress, suformavau pradžią analitiko ir projektų vadovų įgūdžių.

Galų gale projektus iš to, kad darydavome „taip, kaip išeina“ galų gale šioje įmonėje dirbant pradėjome daryti taip, kaip reikia: su specifikacijomis ir poreikių aprašus, preliminariais vertinimais, samdėme profesionalų interneto dizainerį ir karpytoją, o man likdavo viską suprogramuoti bei suvaldyti po procesinę dalį. Klientams ruošdavome net instrukcijas, kaip naudotis sistema ar net tuos mokymus vesdavau aš rodydamas, kaip sistema veikia.