Tag: duomenys

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.

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.

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ų?

Duomenų bazių testavimas

Analizė, Programavimas, ,

Prieš keletą dienų užtikau patikusį straipsnį apie automatizuotus duomenų bazių testus. Programiniam kodui jau senokai tapo įprastinė praktika rašyti testus, bet duomenų bazių struktūra testuojama ne visada. Tiesa, gerai sutvarkytoje duomenų bazėje įmanoma sudėti daug saugiklių: stulpeliams uždėti apribojimus, išorinius raktus ir panašiai, tačiau bendras požiūris į duomenų teisingumą bei validumą vis tiek reikalingas.

Autorius siūlo duomenis testuoti trijose vietose: pirminių šaltinių lygyje, tik juos sukėlus į duomenų bazę ir jau po verslo logikos transformacijų. Šis testų sąrašas atrodo visai nebloga pradžia:

  • Ar visi pirminiai raktai lentelėse unikalūs?
  • Ar [svarbiame stulpelyje] nėra null reikšmių?
  • Ar visi išoriniai raktai egzistuoja lentelėse kaip pirminiai raktai (be dublikatų, ir pan. – referencinis integralumas)?
  • Ar skaitinės duomenų reikšmės neiššoka iš tikėtino reikšmių rėžio?
  • Ar agreguoti duomenys atitinka detalesnių duomenų informaciją (ar čekio suma atitinka atskirų prekių sumai čekyje)?
  • Ar yra visi stulpeliai, kurie bus naudojami galutinėse lentelėse?
  • Ar įmanoma be klaidų paleisti dažniausiai pasitaikančias verslo užklausas?

Dar prie šio sąrašo pridėčiau patikrinimą, ar eilučių kiekis įvairiose duomenų bazės lentelėse yra toks, koks ir tikėtasi – labai dažnai dėl kokios nors lentelių jungimo klaidos duomenys susidublikuoja.

Neapdorotų duomenų nebūna

Analizė, Pastebėjimai, Vadyba, , ,

Yra toks gana gajus mitas, kad turint „žalius“ neapdorotus duomenis, galima nesunkiai padaryti objektyvias išvadas – juk neapdoroti duomenys turėtų kalbėti už save, jie neturėtų būti „sutepti“ šališkos žmogiškos nuomonės bei išankstinių nusistatymų. Kuo daugiau neapdorotų duomenų, tuo objektyvesnės išvados. Deja, visiškai neapdorotų duomenų nebūna. Jau pats faktas, kad kažkas juos rinko, reiškia, kad kažkas padarė sprendimą jais domėtis: o kodėl rinko būtent taip, o ne kitaip? Kodėl rinko tokius, o ne anokius? Kodėl skaičiavo žmones, o ne mašinas; kodėl išmetė iš skaičiavimų vaikus ar žmones vežimėliuose, kodėl nusprendė, jog tamsoje duomenys nepatikimi? Net jei duomenis renka automatiniai prietaisai (tarkim, kas kažkiek laiko skaičiuojama temperatūra), duomenys fiksuojami su aiškia paklaida, kuri nustatyta matavimo įrenginio specifikacijoje – pats įrenginys kažkiek matavimą apvalina, kažkiek veikia nepatikimai už tam tikrų temperatūros rėžių. Jei nežinosi šio konteksto, gali padaryti išvadą, kad temperatūra būna stabili (tiesiog nematai temperatūros pokyčių, mažesnių nei vienas laipsnis) ar ji niekada nenukrenta žemiau -20˚C.

Ypač sunku teisingai interpretuoti skaičius, kurie susiję su žmogumi. Nusikaltimų skaičius gali augti jau vien dėl to, kad pasikeitė suvokimas, kas yra nusikaltimas (tarkim, anksčiau gal buvo visuomenėje priimta, kad vaikus mušti ir tai nebuvo laikoma nusikaltimu). BVP ar infliacijos skaičiai gali kisti dėl metodologinių paklaidų. Pajamų duomenys, surinkti apklausos būdu, smarkiai skirsis nuo duomenų, gautų iš mokesčių inspekcijos.

Simply put, the context of data — why it was collected, how it was collected, and how it was transformed — is always relevant. There is, then, no such thing as context-free data, and thus data cannot manifest the kind of perfect objectivity that is sometimes imagined.

https://www.thenewatlantis.com/publications/why-data-is-never-raw

Šiuolaikinė „didelių duomenų“ mada bando įteigti, jog žali duomenys yra patys objektyviausi, nes jie neužteršti išankstinėmis nuostatomis. Kuo daugiau tokių duomenų, kuriuos galima sušerti taipogi labai objektyviam algoritmui, tuo teisingesnės išvados – ir tam net nereikia jokių ekspertų, mat jie tik įneš savo (nebūtinai teisingą) išankstinę nuomonę. Žmonėmis negalima pasitikėti dėl jų subjektyvumo: nuo to gali išgelbėti tik daugybė duomenų. Bet toks pasaulio vaizdas visgi yra utopinis: jei atvirai nedeklaruoji savo prielaidų, nereiškia, jog jų nedarai. Nematomos subjektyvios prielaidos duomenyse atsiranda jau jų rinkimo procese, ir to niekaip neišvengsi. Ką matuoji, tą ir optimizuosi. Duomenys už save nekalba, jie atkartoja duomenų rinkėjų nuomones.

Keletas patarimų apklausų sudarytojams

Analizė, Lifehacks, Pastebėjimai, ,

Artėjant tam pavasario metui, kai į elektroninį paštą bei Facebook’o srautą pradeda plaukti studentų prašymai užpildyti nuobodžias ir skausmingai ilgas bakalaurinių ar magistrinių darbų anketas, užtikau labai neprastą „Partially Derivative“ podcast‘o seriją apie tai, kaip teisingai tas apklausas sudarinėti. Kadangi patarimai buvo vertingi ir man pačiam, dalinuosi trumpa jų santrauka:

  • Prieš sudarant apklausos anketą reikia gerai pagalvoti, kokius duomenis nori surinkti ir kaip tuos duomenis analizuosi. Visai ne pro šalį būtų iš anksto susidaryti sąrašą grafikų, kuriuos norėsi nupiešti ir nuspręsti, kokias regresijas skaičiuosi. Anketa žymiai sutrumpės, kai tikrai žinosi kokių tiksliai duomenų reikia, o ir klausimai bus žymiai tikslesni: gal iš tiesų reikia sužinoti, kaip klientai vertina restorano maisto kokybę, o ne tai, ar jiems tiesiog patiko jame apsilankyti. Kuo trumpesnė anketa – tuo geriau. Niekas nenori švaistyti laiko pusvalandį pildydamas anketą apie restoraną.
  • Tiksliai apibrėžk savo tiriamųjų populiaciją, nes nuo to priklausys ir tavo klausimai. Jei darai apklausą apie Pokemonus, tikriausiai gali naudoti ir ne tokią formalią kalbą, nes tavo respondentai bus jauni, bet jei klausinėji apie pensijų fondus, tai ir klausimai turėtų būti labiau solidūs.
  • Klausimai turi būti trumpi ir aiškūs. Juos respondentai turi suprasti be jokių papildomų paaiškinimų.
  • Klausimai turi būti objektyvūs. Neklausk „Ar tau labai patiko mūsų restorane?“ (Bet juk tai savaime suprantama, ar ne?)
  • Kad ir kokį užduosi klausimą visada gausi kažkokį atsakymą, bet ar pats klausimas buvo teisingai suformuluotas ir teisingai suprastas?
  • Geriausia prieš paleidžiant apklausą ją patestuoti su keliais žmonėmis. Reiktų jų paklausti, kaip jie suprato klausimus, ar jiems nekilo neaiškumų. Kiek užtruko laiko užpildyti anketą? Jei testuojama internete, galima pažiūrėti ties kuriuo klausimu žmonės daugiausiai užtrunka laiko – gal jis per sudėtingas ar tiesiog sunku apsispręsti?
  • Apklausa turėtų būtų kuo trumpesnė, bet jei apklausinėji žmones asmeniškai gyvame susitikime, ji gali trukti ir pusvalandį ar valandą. Apklausiant telefonu respondentai ima dairytis į laikrodį po 10-15 minučių, o internete jie dažniausiai pasiruošę paskirti tik keletą minučių. Tiesa, jei apklausos klausimai yra labai įdomūs, jos trukmė gali būti ir ilgesnė, bet geriausia galvoti, kad tavo apklausa nėra labai įdomi.
  • Reikėtų vengti atvirų klausimų, nes juos sunku analizuoti. Analizuojant juos kažkaip reikės sudėlioti į kategorijas, o tai nėra lengva automatizuoti.
  • Internete reikėtų vengti didelių klausimų blokų, kur prašoma nuo 1 iki 10 sužymėti savo vertinimus daugeliu kriterijų (pvz „Nuo 1 iki 10 įvertinkite: grožį, spalvą, kvapą, vaizdą, pojūtį, šaltį, etc“). Dažniausiai tokie klausimų blokai netelpa mobilaus telefono ekrane ir juos labai sunku teisingai sužymėti, ypač jei reikia slinkti ekraną.
  • Respondentai dažnai yra tinginiai ir linkę pasirinkti lengviausią variantą. Jei reikia rinktis iš kelių kategorijų („obuolys“, „kriaušė“ ar „bulvė“), jie dažnai pasirinks pirmą, todėl kartais vertakiekvienam respondentui atsakymus pateikti atsitiktine tvarka.
  • Jeigu vertinimo skalė susideda iš nelyginio skaičiaus kategorijų („įvertinkite nuo vieno iki penkių“), tingus respondentas žymiai lengviau pasirinks neutralią vidurinę reikšmę. Jei būtinai norima, kad respondentas pagalvotų geriau ir išreikštų savo (kad ir silpną) preferenciją, reikia prašyti rinktis iš lyginio skaičiaus kategorijų („nuo vieno iki keturių“ arba „nuo vieno iki dešimt“). Tiesa, skalė nuo vieno iki dešimt dažnai yra per smulki: lengviau apsispręsti, kai galima rinktis iš 4-5-6 kategorijų.
  • Ar leisti rinktis kategoriją „kita“ paliekant vietos įrašyti savo variantą? Dažniausiai taip, bet reikia palikti vietos tik vienam ar dviem žodžiams, kad nebūtų daug vietos plėstis (kiek vietos paliksi, tiek kas nors ir prirašys, o po to tai sukels problemų duomenis analizuojant ir kategorizuojant). Apklausos testavimo metu reikia stebėti, ar daug kas renkasi variantą “kita” ir pagal tai pakoreguoti atsakymų variantus. Galutinėje apklausoje reiktų tikėtis, kad šio varianto pasirinkimas nedominuos.
  • Analizuojant apklausos duomenis reikia atkreipti dėmesį į atsakymų pasiskirstymą. Jei visi repondentų atsakymai yra beveik vienodi, iš apklausos gausi nedaug informacijos. Jei visi tavo restoraną vertina penkiomis žvaigždutėmis, tikriausiai ne visai teisingai formuluoji klausimą.
  • Apklausos pradžioje nedėk demografinių klausimų (amžius, lytis, pajamos ir t.t.), nes respondentui tai nuobodu. Paklausk ką nors intriguojančio, kad respondentas susidomėtų ir norėtų iki galo užpildyti visą anketą. Žmonės nuo pat pirmųjų klausimų savo anketinių duomenų pildyti nenori – jie vis dar sprendžia ar verta paskirti savo penkias ar dešimt gyvenimo minučių tavo apklausai.

Dear Data,

Analizė, Knygos, Pastebėjimai, , ,

Vieną Kalėdų senelio dovanotų knygų surijau per vieną vakarą. Dvi profesionalios duomenų dizainerės (net nesu tikras, kaip teisingai vadinti duomenų atvaizdavimu užsiimančiuosius) – viena Londone, o kita Niujorke –  ištisus metus kas savaitę viena kitai siųsdavo ranka pieštus atvirukus su duomenų schemomis, diagramomis ir grafikais. Kiekvieną savaitę jos pasirinkdavo vis naują temą – kiek kartų pasakei „ačiū“, kiek kartų per savaitę nusijuokei, kas kabo tavo spintoje, kas yra tavo geriausi draugai, kiek kartų nusikeikei ar kiek išgėrei alkoholio. Pasirodo, per septynias dienas tokių duomenų galima prikaupti devynias galybes, ypač jei žymėsiesi ne vien plikus faktus, bet ir su šiais faktais susijusias aplinkybes: ne visi pasakyti „ačiū“ yra vienodi, kai kurie būna ištarti kita kalba, kai kurie parašyti elektroniniame pašte, kai kurie buvo pasakyti tik iš mandagumo, o kai kurie ypač nuoširdūs, nes buvo sakyti su meile savo vyrui. Per daugiau nei penkiasdešimt savaičių šios dizainerės sugalvojo daug išradingų duomenų vaizdavimo būdų ir kone kiekviena atvirutė stebina detalių gausa – bet detalės neužgožia bendro duomenų piešiamo paveikslo, jos nenumaldomai traukia gilyn, ten kur abstraktūs agreguoti skaičiai nutrindami ribą tarp statistikos ir asmeninio intymumo pavirsta į atskirus išgyventus faktus. Kai dešimt kartų pasakytas žodis „ačiū“ tampa trimis „ačiū“ padavėjai už pateiktą sriubą, dviem „ačiū“ bendradarbiui už persiųstą emailą, padėka draugui už tai, kad jis šalia ir keturiais „ačiū“, kuriuos turėjai pasakyti, bet neišdrįsai, tai nebe plika statistika: tikrai jautiesi gerai pažįstantis autorę.

Peržvelgus šio projekto atvirutes pradedi suprasti, kad duomenimis savo gyvenime galima paversti beveik bet ką, tačiau vien pats duomenų rinkimas priverčia atkreipti dėmesį į tuos dalykus, kuriuos šiaip būtum praleidęs pro pirštus. Vien tai, kad skaičiuoji šypsenas, verčia tave daugiau šypsotis, vien tai, kad seki savo alkoholio suvartojimą, galbūt daro tavo blaivesniu, vien tai, kad surenki duomenis apie žmones, su kuriais bendravai per savaitę, primena tau, kad reiktų paskambinti seniai matytai tetai. Ką matuoji, tuo ir gyveni. Apie ką nuolat galvoji, su tuo ir susitapatini. Bet norint daugiau judėti neužtenka nuolat ant rankos nešioti Fitbit apyrankę – jei duomenys surenkami paprastai ir neskausmingai, į juos lengva numoti ranka ir užsimiršti. Kuo sunkiau duomenis teko rinkti ir analizuoti, tuo juos vertini rimčiau. Kartais nėra blogai duomenis sąmoningai užsirašinėti ranka: tai leidžia stabtelti ir pagalvoti apie kiekvieną konkretų stebėjimą.

Be to, kad ši knyga apie duomenis, ji dar priminė, jog reikėtų dažniau sakyti „ačiū“, tad dar kartą dėkoju Kalėdų seneliui už „Dear Data“.