Category: Darbas

Stephen Few: „Show Me the Numbers“

Analizė, Darbas, Knygos, ,

Nors ši knyga išleista prieš maždaug dešimtį metų, ji išlieka vienas geriausių grafikų bei lentelių dizaino vadovėlių. Joje viskas paprastai paaiškinta su galybe pavyzdžių, ir, kas labai svarbu, viskas puikiai pritaikoma. Autorius teigia, kad visi pavyzdžiai jo knygoje daryti Exceliu, bet knygoje kalbama apie principus, o ne apie technines detales, tad knygoje išdėstytos žinios pravers kiekvienam.

People who can’t tell their stories in understandable ways are either naive (unaware of the world outside of their own small spheres), lazy (unwilling to craft the story in familiar terms), full of themselves (more interested in impressing than communicating), unskilled in the use of everyday language, or just don’t understand their stories well enough to tell them clearly.

Stephen Few, „Show Me the Numbers“

Knyga nėra vien tik techninė, nors joje yra nemažai informacijos apie tam tikras grafikų plonybes: kada reikia naudoti legendas, ar reikia visada žymėti ašis ir panašiai. Knygoje išdėliojami ir pagrindiniai duomenų vizualizavimo principai:

  1. Sugalvok, ką nori pasakyti. Kiekvienas grafikas turi būti kuriamas žinant jo tikslingumą. Ar nori parodyti kokį nors ryšį tarp kintamųjų? Ar nori atkreipti dėmesį, kad pardavimai krenta? Ar palyginti kelių šalių duomenis?
  2. Pasirink geriausią būdą savo istorijai papasakoti. Išmesk iš grafiko tai, ko visai nereikia ir kas trukdo: ar tikrai reikia skaičių prie kiekvieno taško? Gal užtenka mažiau spalvų? Gal reikia rodyti ne tokį detalų grafiką iš kasdienių duomenų, o apsiriboti apibendrintais mėnesiniais? Ar tikrai čia vieta skritulinėms diagramoms? (Joms niekur ne vieta! Jas visas reikia keisti stulpelinėmis diagramomis!)
  3. Įsitikink, kad grafikas yra aiškus, paprastas ir tikslus:
    • Grafike turi dominuoti duomenys, o ne dizaino elementai.
    • Išmesk viską, ko nereikia: tiek nereikalingus duomenis, tiek nereikalingus grafiko elementus (ašis, legendas, spalvas, tinklelį, tekstą, ir pan.)
    • Pasistenk, kad grafiko elementai ryškumu neperspjautų pačių duomenų.
    • Paryškink informaciją, kuri svarbi tavo žinutei. Tarkim, jei lygini Lietuvą tarp Europos Sąjungos šalių, piešk Lietuvą kita (ryškesne) spalva.

Mūrininkų vertybės duomenų sistemoms

Darbas, Filosofija, Programavimas, , ,

Skaitant Diana Darke knygos skyrių apie viduramžių mūrininkų gildijas man įstrigo jų deklaruojamos vertybės, kuriomis turėtų būti vadovaujamasi statyboje. Geras statinys turi būti gražus, tvirtas ir patogus. Kaip suprantu, šias vertybes perėmė ir vėlesnieji laisvieji mūrininkai, kurie fizinių akmenų jau nebetašė. Šių raštuose teisingas gyvenimas irgi stovi ant trijų kolonų: grožio, stiprybės ir išminties.

Dirbu su įvairiausiomis duomenų sistemomis, duomenų bazėmis ir jų analize. Tai ganėtinai toli iki viduramžių katedrų statybos, bet kažkiek panašumo stipriai prisimerkus įžiūrėti galima: tai sudėtingos sistemos, kurias ne vienerius metus kuria ištisos komandos žmonių, ir nebūtinai pagal vieną aiškų nekintamai patvirtintą detalųjį planą. Tikiu, kad ir kuriant duomenų sistemas galima vadovautis tomis pačiomis trimis vertybėmis.

Grožis. Duomenų ataskaitos turi būti ne vien funkcionalios, bet ir estetiškai gražios. Svarbu ne vien duomenų teisingumas, bet ir jų pateikimas: teisingai parinkti šriftai, spalvos, grafikų dizainas leidžia duomenis žymiai lengviau suprasti. Galutinis duomenų vartotojas dažniausiai yra ne programuotojas ar analitikas, o vadovas arba išorinis klientas, kuris tikriausiai neturi daug laiko ir noro gilintis į duomenų subtilybes, todėl viskas jam turi būti aišku iš pirmo žvilgsnio. Nereikia pamiršti teisingų grafikų ir ašių pavadinimų, legendų, santrumpų išaiškinimo, reikia visose ataskaitose naudoti tokias pačias spalvas ir datos formatus. Net jeigu ruoši tik paprastą Excelio ataskaitą, verta įdėti papildomai pastangų tam, kad ji būtų aiški ir graži, o ne atrodytų kaip plikas atsitiktinių skaičių kratinys.

Stiprybė. Duomenų sistemos turi būti „tvirtai suręstos“: jos neturi sugriūti papūtus stipresniam vėjui ar nežymiai pasikeitus aplinkai. Sistemas reikia stengtis kurti taip, kad pasikeitęs duomenų formatas paduodamas iš išorinio tiekėjo ilgam „neužlenktų“ viso duomenų ūkio. Faktas, kad duomenų struktūros nuolat keičiasi, vieni laukai atsiranda, kiti išnyksta. Faktas, kad keičiasi ir duomenų kiekiai. Faktas, kad kartais duomenys vėluoja. Faktas, kad kartais vienu metu ataskaitas nori pažiūrėti šimtus kartų daugiau vartotojų nei įprastai. Faktas, kad kartais duomenys dingsta ir fiziškai, tad reikia juos atstatyti iš atsarginės kopijos. Realybėje nutinka labai daug neplanuotų dalykų, tačiau duomenų sistema turi būti pakankamai stipri juos atlaikyti, ar bent jau suprasti, kada reikia neprikūrus dar didesnių problemų tvarkingai nuleisti rankas.

Patogumas. Visos kuriamos sistemos turi būti patogios klientui. Niekada nereikia pamiršti, jog dirbama klientui, o ne savo pačių patogumui: žali duomenys csv formatu yra patogūs analitikui, bet nesuprantami vadovui. Analitikui gal būt patogu duomenis pasiimti per SQL užklausą, bet gal būt klientui reikia tik nuolat po akimis matyti kelis pagrindinius skaičius. Nereikia pamiršti, kad klientas ne visada gali iki galo teisingai išreikšti savo poreikius: reikia stengtis suprasti, ką tais poreikiais klientas nori pasiekti. Gali būti, jog jis nori vienokios specifinės ataskaitos Excel formatu, bet iš tiesų jis tuos duomenis įkels į kitą sistemą ar ataskaitą – gali paaiškėti, jog lengviau duomenis ten patiekti tiesiogiai, o ne per Excel bylas. Duomenų sistemos sėkmę užtikrina patogus problemos sprendimas klientui, o ne vien tik aklas techninės specifikacijos išpildymas.

Ar ofisas vis dar reikalingas?

Darbas, Pastebėjimai, Vadyba, ,

Pastarąsias dešimtį dienų dirbau ne iš namų. Dirbau ir ne iš ofiso: daugiau nei savaitei persikėliau į pajūrį. Darbo ritmas nuo to visai nepasikeitė, rutina išliko ta pati. Atsikelti prieš aštuonias, pasidarius kavos perskaityti elektroninį paštą, žiaumojant sumuštinį atnaujinti vienos ar kitos sistemos duomenis ar parašyti vieną kitą lengvesnę duomenų bazės užklausą. Po to įprastiniai dienos skambučiai su klientais, darbas, darbas, darbas, pietų pertraukėlė ir vėl darbas. Ir tada, jau kokią 18 valandą, galima kiek atsipūsti, nueiti prie jūros, pavakarieniauti, paskaityti knygą. Ir tikriausiai dar atsakyti į kelias darbines užklausas.

Dirbu nuotoliniam darbui dėkingoje IT srityje, tad darbas namie ar prie jūros visai nesiskiria nuo darbo ofise. Jei tik yra pakankamai stabilus internetas, galima dirbti bet kur. Ir atrodo, jog pagaliau tai tapo suvokiama vis daugiau kompanijų: jeigu prieš pandemiją pas klientus Londone reikėdavo reguliariai skraidyti kas dvi savaites „atsiskaityti už darbus“, dabar visai pakanka kassavaitinio skambučio. Susitaupo ne vien kelionės nuovargis, bet ir begalės laiko bei pinigų. Nors klientai – ne IT bendrovė, jie irgi į ofisą nebeskuba, fizinis buvimas visuose susitikimuose nebeatrodo efektyvus darbo būdas.

Vienas didžiulis ofiso privalumas išliko: ofise nėra vaikų. Jei vaikai neina į darželį ar mokyklą, tai namuose vis tiek tenka dirbti bent jau pusantro etato, be eilinių darbinių užduočių reikia pasirūpinti ir jais. Neturintys vaikų bendradarbiai visai mielai nuolat dirbtų iš namų ar sodybos. Socializacija svarbu, bet juk nebūtinai darbinėje aplinkoje.

Mano artimiausioje aplinkoje jau bent trys kompanijos nusprendė, kad jiems arba reikia dvigubai mažesnio ofiso, arba jo nereikia visai. Taip, tai gana mažos kompanijos, taip, jos visos dirba IT srityje ar bent jau ne Lietuvos rinkai (tad jau ir šiaip yra įpratę su klientais bendrauti per atstumą). Bet lūžis galvoje įvyko, ofisų paklausa turėtų mažėti. Ir, tikiuosi, pagaliau numirs atviro plano ofisų idėja: juose nei susikaupsi, nei ramiai padirbsi.

Post Scriptum. Nors bendrinėje kalboje dažniausiai vartojamas žodis „ofisas“, lyg ir taisyklinga būtų sakyti „biuras“. Bet tikrai nesuprantu, kuo prancūziškas / vokiškas „biuras“ yra geriau už anglišką „ofisą“ – galų gale abu šie žodžiai kilę iš tos pačios lotynų kalbos (burra ir officium)

Ką rinkčiausi duomenų ūkyje

Darbas, Programavimas, Python, , , ,

Kuo didesnis klientas, tuo mažiau laisvės technologijų pasirinkimui – dažniausiai dirbi tais įrankiais, kurie jau naudojami organizacijos viduje. Naujų programavimo kalbų, operacinių sistemų ar duomenų bazių klientams nesinori, nes kažkam organizacijos viduje tas naujas technologijas reikės prižiūrėti. Jei visas tavo lėktuvų parkas sudarytas iš Airbusų, įsigyti vieną Boeingą „pažaidimui“ nelabai protinga. Tačiau kartais sveika pagalvoti, kokias technologijas rinktumeisi, jeigu viską darytum nuo nulio.

Duomenų bazė

Anksčiau buvau pratęs dirbti su MySQL – greita, paprasta, lengva administruoti. Šiuo metu rinkčiausi Postgres, nes nebegaliu gyventi be Common Table Expressions, o MySQL jų palaikymas dar tik labai šviežias. SQL kodas, rašomas su WITH ... AS ( ... ) yra žymiai lengviau skaitomas, o tai labai svarbu, jeigu tenka rašyti sudėtingas ne vieno šimto eilučių SQL užklausas. Be to, Postgres turi begales papildomų funkcijų ir galimybių – kuo reikia sudėtingesnės verslo logikos, tuo mažiau pradeda tikti MySQL.

Savaime suprantama, galima naudotis ir MS SQL Server ar Oracle, tačiau lemiamas argumentas visgi yra kaina.

Programavimo kalba

Pradėjęs nuo Perl, jaunystėje daug ko daręs su PHP, po to perėjęs prie Ruby, kažkiek krapštęs R, nesusigyvenęs su Scala, šiuo metu viskam rinkčiausi Python. Daug reikiamų bibliotekų duomenims maigyti, nuo paprasto ETL iki dirbtinio intelekto ir beveik bet kokio machine learning (na, galbūt dar vis kokiais specifiniais statistiniais algoritmais čia jį lenkia R, bet universalumu R tikrai nusileidžia). Be to, python kuo toliau, tuo labiau populiarėja – tai ne eksperimentinė nišinė kalba, kurią gerai supranta tik sauja žmonių: tai svarbu, norint užtikrinti, jog kažkada kas nors iš tavęs galės sklandžiai perimti projektą.

Operacinė sistema

Labai dažnai dirbant Microsoft ekosistemoje tenka dirbti su Windows serveriais – nieko labai blogo, bet žymiai labiau esu pratęs prie Linux (ir daugiausiai Debian / Ubuntu). Konsolėje jaučiuosi kaip namie, juodas ekranas man jaukus ir savas, todėl rinkčiausi būtent jį. Bet kartu labai suprantu, kad administruoti naują operacinę sistemą to niekad nedariusiam yra labai sudėtinga, tad jei visi kompanijoje naudoja Windows, naujų žvėrių zoosode matyt nereikėtų.

Darbų dirigentas

Manau, kad įvairiems ETL darbams planuoti ir diriguoti naudočiau Apache Airflow. Rašyta python, turinti daug galimybių, aprėpianti beveik visus įmanomus poreikius, po truputį tampanti industrijos standartu (bent jau atviro ir nemokamo kodo ekosistemoje). Taip, reikia rašyti kodą, bet tai, mano nuomone, privalumas. Daug programuotojų gal ir nustebs, bet labai dažnai drag&drop įrankiai didelėse organizacijose labai vertinami, nes jie suteikia (dažniausiai nepasiteisinančią) viltį, jog duomenų ūkį lengvai galės administruoti koks nors net SQL nemokantis stažuotojas iš finansų analizės poskyrio. Paprastiems dalykams gražūs pele stumdomi daiktai gal ir veikia, bet kai viskas susivelia į vieną didelį neišnarpliojamą kamuolį… (taip, piktai žiūriu į tave, Alteryx).

Kiti būtini dalykai

git. Būtina naudoti git. Bet kokia forma (github, gitlab, bitbucket, savo pačių daryta, bet kokia…), bet būtina naudoti kodo versijavimą. Niekaip nesuprantu, kodėl didelėse organizacijose kodo versijavimas toks retas. Vis dar kodas taisomas tiesiai serveryje, vis dar dažnai kokioje nors direktorijoje kaupiasi programos pavadinimu load_foo_v12.192_final_do_not_use.sql. Tikriausiai kultūriškai tai ateina iš Excelio ir įvairiausių „vartotojui draugiškų“ drag&drop įrankių – lengvai jų į versijavimo sistemą nesudėsi.

Testai. Jeigu versijavimo sistemas tai dar pas klientus galima kur nors rasti, testus duomenų bazėms bei ETL programoms labai mažai kas rašo. Kuo mažiau kompanijoje inžinierių, tuo mažesnė tikimybė, jog kodas bus tikrinamas testų pagalba.

Machine learning’o projektuose sunkiausia ne techninė dalis

Analizė, Darbas, Pastebėjimai, Vadyba, , ,

Buvęs LinkedIn duomenų analitikas Peter Skomoroch konferencijoje Strata skaitė neblogą pranešimą apie tai, kas sunkiausia įgyvendinant machine learning ar dirbtinio intelekto projektus. Ne, ne techninės kliūtys. Sunkiausia tai, kad labai sunku tokius projektus tiksliai suplanuoti ir subiudžetuoti – o ir jų nauda dažnai sunkiai įvelkama į skaičius (kvantifikuojama). Didelei korporacijai, kurioje visi įpratę IT projektus vykdyti griežtai subiudžetuotais projektais (nesvarbu, kad dauguma jų tuos biudžetus vis tiek ryškiai perlipa), sunku suprasti, jog beveik neįmanoma suprognozuoti, ar veiks algoritmas ar ne, bei kiek laiko užtruks jį ištreniruoti. Niekas negali pasakyti, kada jau bus galima į gyvenimą paleisti save vairuojančias mašinas: visos prognozės buvo labai netikslios (berods Uber kažkada seniai sakė, jog 2020-aisiais jie vairuotojų nebeturės ir važinėsime autonominėmis mašinomis. Vis dar mane namo veža žmonių valdomi Toyota Prius).

The transition to machine learning will be about 100x harder than the transition to mobile.
Some of the biggest challenges are organizational, not technical.
Machine Learning shifts engineering from a deterministic process to a probabilistic one.

Peter Skomoroch

Labai svarbu, kad machine learning projektams vadovautų žmonės, kurie gerai supranta kompanijos duomenis, o ne vien yra matematikos profesoriai. Geras projektų vadovas supranta, kas machine learning‘e yra lengva, o kas sunku, ir, net jei tai ne itin sudėtinga problema techniniu požiūriu, supranta ar ji turi verslo vertę. Gal būt visai neverta šiai problemai skirti dėmesio? Taip pat svarbu suprasti turimų duomenų niuansus ir kokybę – dažnai teoretiniai matematikai tai pražiūri, nes matematiniuose modeliuose visi duomenys vienodai geri ir kokybiški. Realybėje – ne itin.

Duomenys nebūtinai sukuria daug verslo vertės

Analizė, Darbas, Pastebėjimai, Vadyba, , ,

Šiandien užtikau gerą straipsnį apie tokį požiūrį, su kuriuo, deja, gana dažnai susiduriu kompanijose: reikia surinkti kuo daugiau duomenų, viską bet kaip sudėti į duomenų bazę ir iš to vis tiek gausis kas nors gero. Na, žinai, gi ten machine learning, dirbtinis intelektas, visa kita gi šiais laikais. Svarbu duomenų būtų.

Didesnėse kompanijose tai dažnai galima suprasti: pinigų projektams kaip ir yra, norisi užsidėti varnelę, kad „kažką darai su dirbtiniu intelektu“, net jei ir nieko nesigaus, tai bent jau bandysi. Nesvarbu, kad nelabai aišku, kokia reali to nauda verslui, ir kas bandoma pasiekti. Bet tai, pasirodo, dažnai pasitaiko ir tarp startuolių: vietoje to, kad pastangas skirti klientų paieškai ar geresniems procesams, per daug koncentruojamasi į duomenis, lyg jie būtų ta magiška burtų lazdelė, kuri visus staiga padarys milijonieriais.

Straipsnyje galima rasti gerų patarimų ir įžvalgų, kurių niekada reiktų nepamiršti, dirbant su duomenų projektais:

  • Kokie yra duomenų gavimo kaštai? Būtina bent jau apytiksliai paskaičiuoti, kiek kainuoja visi duomenų inžinieriai, visi vadovai, kuriems reikia ataskaitų ir planų, visi serveriai, infrastruktūra, visų vadovų laikas, kurį jie praleidžia kasdieną stebėdami analitines ataskaitas vietoje to, kad galbūt galvotų, kaip užkariauti naujas rinkas ir geriau padėti klientams.
  • Kokią naudą mes gauname iš duomenų? Kas atsitiktų, jei vienos ar kitos ataskaitos ar algoritmo nebūtų? Kiek verslo vertės susideda iš to, kad turime tikslesnę informaciją ir ją galime greičiau pasiekti? Taip neretai galima suprasti, kad visgi lengviau paskambinti klientui ir jo paklausti, kas jį mūsų svetainėje trikdo nei valandų valandas praleisti Google Analytics bandant išskaityti gudrias įžvalgas.
  • Per kiek duomenys pasensta? Dažnai net nepastebima, kad kelių metų duomenys jau niekam neįdomūs ir netgi nelabai naudingi: klientų poreikiai pasikeitė, elgsena kitokia, žiūrėk jau ir Facebook ne toks visiems įdomus, aplinka nujudėjo visai kitur. Kai supranti, kad tavo duomenys labai greitai sensta ir vien jų kiekis nesukuria tvaraus konkurencinio pranašumo (nes bet kas, investavęs metus ar kitus darbo gali irgi įgyti ne ką mažiau panašių duomenų), jų nuolatinis atnaujinimas ir kiekybės siekimas vien dėl kiekybės nušvinta kitomis spalvomis. Gal verčiau mažiau duomenų, bet labai gerai atrinktų? Ir gal užtenka logistinės regresijos ir visai nereikia neuroninio tinklo su dešimt tūkstančių faktorių?

Ar jums tikrai reikia besimokančių (machine learning) sistemų?

Analizė, Darbas, Pastebėjimai, Vadyba, , ,

„Žiūrėk, turim duomenų, gal galėtumėt ką nors padaryt su machine learning ar dirbtiniu intelektu? Juk čia gi dabar ateitis“ – labai dažnas šiuolaikinis prašymas iš potencialių klientų. Neretai pasirodo, kad realių problemų sprendimui nereikia nei gudrių algoritmų, nei dirbtinio intelekto: didžioji vertė iš duomenų išspaudžiama žymiai paprastesnėmis priemonėmis, vien tik sutvarkius duomenis ar pasinaudojant senais gerais statistikos įrankiais. Kita vertus, logistinės regresijos terminai panašiai kaip ir bet kokios diskusijos apie neuroninius tinklus: nei apie vienus, nei apie kitus nedaug kas girdėjęs.

Problema tame, kad dirbtinis intelektas ir besimokančios sistemos yra dažnai minimos tokiose stebuklinguose kontekstuose, kad paprastas žmogus vargu ar gali suprasti, kad, nepaisant visų pastarųjų metų pasiekimų, jos nėra visagalės. Taip, jos gali atpažinti objektus paveiksliukuose, taip, jog pusėtinai gali išversti vienos kalbą į kitą, taip, jog gali kūrybiškai imituoti meno kūrinius. Ne, besimokančios sistemos dar negreit sukurs naują Nobelio literatūros kūrinį, ne, jos nesugalvos jums naujos verslo strategijos, ne, jūsų atsitiktinė duomenų sankaupa netaps aukso grynuoliu, nešančiu jums milijonus vien todėl, kad nutarėte investuoti į dirbtinį intelektą.

Vienas geriausių kriterijų, kuris labai greitai atmeta visas dirbtiniam intelektui kol kas neįkandamas idėjas yra užduoti sau klausimą, ar su norima spręsti užduotimi susidorotų paprastas žmogus. Jei žmogus duomenyse gali atrasti paaiškinamus sąryšius bei dėsnius, tai yra šansų, kad tai galės atlikti ir dirbtinis intelektas, nors to garantuoti negalima. Jei žiūri į klientų duomenis, ir pradedi suprasti dėsningumus, tuos dėsningumus galbūt atras ir besimokančios sistemos. O jei duomenys nieko nesako net protingiausiam žmogui, tikėtina, jog nieko protingiau nesugalvos ir dirbtinės sistemos.

Panašios nuomonės yra ir šio dienoraščio autorius. Jis gal dar griežtesnis: jei įmanoma duomenis perkratyti statistinės analizės pagalba ir jų ryšius aprašyti matematinėmis formulėmis, dirbtiniam intelektui – ne vieta. Nors suprantu, jog riba tarp sudėtingos statistikos ir besimokančių sistemų kartais nebe tokia ir aiški.

Kad ir kaip ten bebūtų, duomenys atneša daugiausiai verslo vertės, kai yra labai aiškiai suprantama, ką su jais norima padaryti ir kai yra užduodami teisingi verslo klausimai. Vien perleidus atsitiktinių duomenų rinkinį per dirbtinio intelekto algoritmus, verslo įžvalgų grynuolio nerasi. Garbage in, garbage out.

Įsitraukimo metrikos veda klaidingu keliu

Blogsfera, Darbas, Pastebėjimai, , ,

Jau prieš gerą pusmetį rašiau, kad kuo toliau, tuo labiau nesu patenkintas socialiniais tinklais: nors ir turiu išugdytą įprotį turint laisvą minutę įsijungti Facebook ar Instagram, retokai ten randu ką nors įdomaus. Dauguma istorijų tapę vienodos ir nebeįdomios, o Instagram nuotraukos atrodo lyg gamintos pagal vieną klišę. Jei netikite, užeikite į @insta_repeat profilį.

@Insta_repeat profilyje surinktos vienodos skirtingų autorių nuotraukos

Kodėl taip nutiko? Kodėl vis kompulsyviai norisi maigyti telefoną ir prasukti dar, ir dar, ir dar, ir dar vieną ekraną „turinio“ ir vis tiek nesijausi pasisotinusiu? Turbūt labiausiai reiktų kaltinti duomenų analitikus ir ganėtinai naują vadybos idėją, jog viską reikia matuoti, o geriausias matas, kurį visada reikia gerinti – įsitraukimas (engagement). Kuo ilgiau „skrolini“, tuo daugiau praleidi laiko programėlėje, tuo geresnės tavo įsitraukimo metrikos. 

Kai didžioji dalis produkto vystymo sprendimų daroma vien tik analitikos pagalba, labai galima nuklysti į lankas. Lengvas ir neįpareigojantis turinys tampa didesniu prioritetu nei asmeniniai įrašai, antraštinis masalas ima viršų prieš kokybišką turinį: tokį ir dažniau paspausi, ir jame praleisi daugiau laiko, nes bandysi išnarplioti, kas iš tiesų slepiasi po antrašte. Ir visai nesvarbu, jog vartotojas lieka susierzinęs ir nepatenkintas, jog jis jaučia, kad kažkaip nelabai čia įdomu – analitinės įsitraukimo metrikos juk rodo, jog viskas gerai!

When a measure becomes a target, it ceases to be a good measure.

Charles Goodhart

Socialiniai tinklai ir portalai tampa naujienų „greitmaisčiu“ (junk food): naudos mažai, bet nuo jų žvėriškai sunku atsitraukti. Juk tai pirmiausiai turint galvoje ir buvo viskas konstruojama. Bet ar tai nėra trumpalaikio tikslo vaikymasis aukojant ilgalaikį vartotojų pasitenkinimą? Ar tokia analitika iš viso gali padėti suprasti vartotojų elgseną kiek gilesniame lygyje? Ar gali atsakyti, kodėl vartotojai yra patenkinti ar ne? Kuo toliau, tuo labiau manau, kad nelabai. Įsitraukimo metrikos yra svarbu, tačiau jos neturi tapti vienintele kelrode žvaigžde. Kaip teigia Goodharto dėsnis, „kai matuojamas rodiklis tampa siekiamu tikslu, jis pasidaro prastai pritaikomu rodikliu“. Kai pradedami optimizuoti įsitraukimo rodikliai, užmirštami visi kiti dalykai, kurie vartotojui teikia vertę ir pradeda darytis nuobodu.

Wexler, Shaffer, Cotgreave: The Big Book of Dashboards

Analizė, Darbas, Knygos, Pastebėjimai, , ,

Dirbant su duomenimis ir neturint didelės menininko gyslelės man kartais trūksta teorinių žinių apie grafikų dizaino teoriją, spalvas bei bendrą „user experience“. Kai greitai sumetinėji grafikus Excelyje, tai gal tai ne taip stipriai jaučiasi, bet kai reikia sukurti kažką sudėtingesnio, reikia ieškoti pagalbos knygose. „The Big Book of Dashboards“ pradžiai tam visai tinka.

Knygos stipriausia dalis yra tie keli skyriai apie pagrindus: kodėl niekada nereiktų naudoti skritulinių diagramų, kodėl reikia žūt būt vengti šviesoforo spalvų (daltonikai jų neskiria), kodėl reikia vengti per didelio informacijos kiekio vienoje vietoje ir panašiai. Kuriant įvairiausias ataskaitas visada pirmiausia reikia išsiaiškinti klientų klausimus, kuriuos turėtų atsakyti duomenys ir ataskaitų struktūrą taikyti prie jų. Žinau, skamba lyg akivaizdžių ir paprastų tiesų kartojimas, bet realybėje tai ne taip lengvai pasiekiama. Negana to, ataskaitos turėtų numatyti ir tolimesnius klausimus, kurie gali kilti klientams: jeigu ataskaitos grafikas rodo, kad pardavimai Latvijoje mažesni nei užsibrėžtas tikslas, tikriausiai vartotojui kils klausimas kodėl? – Tikriausiai reikia ir būdo, kaip probleminį regioną išskaidyti pagal vadybininką arba prekių grupę, o išskaidžius „tooltipe“ (koks to teisingas lietuviškas pavadinimas? Etiketė?) pateikti ir išsamias detales: kiek ko kada parduota.

Daugiau nei pusė knygos yra įvairių ataskaitų pavyzdžiai, ir, nors jos tikrai įdomios, bet greitai pradeda kartotis, juolab, kad visas jas kūrė tie patys knygos autoriai. Po keletos ataskaitų jau mintinai žinai, kuriuos grafinius elementus ir dizaino sprendimus jie mėgsta. Būtų žymiai geriau, jei knygoje būtų daugiau tvirtos teorijos. Bet bendrai tariant, knyga verta dėmesio, ypač jei tai pirmoji šia tema skaitoma knyga.

David Graeber: „Bullshit Jobs. A Theory“

Darbas, Ekonomika, Knygos, Pastebėjimai, ,

2013-ais metais antropologas David Graeber parašė ese apie tai, kad kuo toliau, tuo labiau žmonija dirba beprasmius darbus. Jie ne vien tik nekuria vertės, bet ir kartu varo žmoniją į depresiją: jei visą dieną turi generuoti kvailas ataskaitas Sodrai, sunku jaustis, kad sukūrei ką nors prasmingo. O kuo toliau, tuo tokių darbų daugėja.

„Bullshit Jobs. A Theory“ yra platesnė šios ese versija. Nemažai vietos skiriama ekonominiam aspektui, mat dažniausias prieštaravimas iš ekonomistų visgi būna, kad rinka yra efektyvi ir jei darbas nesukurtų vertės, niekas žmogaus nesamdytų, tačiau centrinė knygos tema visgi yra žmogus ir jo santykis su darbu. Kodėl mes dirbame, ar darbas būtinas savęs realizavimui, kodėl mums tapus turtingesniems mes nepradėjome dirbti trumpiau ir kodėl mes vis blogai jaučiamės ir nesidžiaugiame, nors mūsų gerovė didėja. Labai geri antropologiniai klausimai, apie kuriuos ne dažnai susimąstau.

Mūsų ekonominė politika turi pagrindinę tezę: turtas bei lamė sukuriama per darbą. Tam, kad visi būtų laimingi, reikia kad augtų ekonomika, o ekonomikos augimas koreliuoja su sukurtomis darbo vietomis. Ne vienas politikas žarstydamas pažadus teigia, jog sukurs tūkstančius naujų darbo vietų, ir visi tai priima kaip absoliutų gėrį. Tačiau lengviausia yra sukurti darbo vietas prikuriant kokių nors taisyklių ir apribojimų – tarkim jei padvigubintum mokesčių inspekcijos ataskaitų apimtį, reiktų dvigubai daugiau buhalterių ir dvigubai daugiau mokesčių inspekcijos valdininkų: darbo vietos sukurtos, visi dirba, visi kažkuo užsiėmę, bet reali nauda abejotina. O kuo toliau, tokių darbų vis daugėja.

Blogiausia yra tai, kad dirbdami tokį darbą žmonės nesijaučia laimingi, nes jie vargiai mato tokio darbo prasmę. Sunku didžiuotis tuo, kad sukūrei eilinę ataskaitą. Seniau tai, ką žmogus pagamina, buvo jo svarbiausia identiteto dalis („aš – stalius, nes gaminu baldus“, „aš – kalvis“, „aš – ūkininkas“), o per pastarąjį šimtmetį mes bandome savo identitietą kurti ne per tai, ką sukuriame, o per tai, ką vartojame („aš – Žalgirio fanas“, „aš vartoju tik Apple produkciją“). Bet to neužtenka, nes kad ir kiek ko vartojame, tai neužpildo identiteto tuštumos.

David Graeber stipriai palaiko visuotinių bazinių pajamų idėją – visi turėtų gauti standartinę išmoką, kuri užtikrintų bazinį pragyvenimą, ir taip būtų galima atsikratyti labai daug biurokratijos. Be to, žmonės būtų laisvi užsiimti tuo, ką nori, ir jiems nebūtina būtų sėdėti nekenčiamuose darbuose. Ši idėja verčia pergalvoti ir kitas problemas: tarkim, tokiu atveju visai nereikia pensinio amžiaus (išmokos juk mokamos iki pat mirties) – gal ir pačios SoDros problemas galima spręsti žymiai radikaliau nei perstumdant kėdes Titanike. Tiesa, vis dar išlieka klausimas, ar nedirbantys nekenčiamų darbų žmonės irgi jausis laimingi. Sakoma, kad pasididžiavimo savo pasiekimais jausmas aplanko tik tada, kai tai atėjo per sunkų darbą ar kančią.