Teistmoodi IT

Üks uudsemaid viimase aja lahendusi, mida olen tugitehnoloogiate osas näinud, on kahtlemata käepeal Emma Watch (1). See on loodud pidades silmas kordinatsioonihäiretega, sh näiteks Parkinsoni tõve põdevaid, inimesi. Sellele on küll eelnenud erinevaid lahendusi näiteks spetsiaalse kinda või lusika näol, kuid antud lahenduse puhul on kiiduväärt just selle lihtsus teostuses.

Lahenduse tööpõhimõte on järgmine: käepaela sees töötavad väikesed vibreerivad mootorid. Nende mootorite mõjul töötab käepael vastupidiselt treemorile ehk vibreerib kasutaja värinate suhtes vastupidises suunas tagades nii käe stabiilsema liikumise. Stabiilsem käeliikumine toob Parkinsoni tõve põdevale inimesele tagasi võimaluse tõmmata sirgeid jooni ning kirjutada käekirjas, mis loetav.

Kuigi toote taga olev leiutaja Haiyan Zhang (2) tegeleb teleprojekti raames loodud käepaelaga edasi, loodab ta, et leidub ka teisi töögruppe, kes oleksid valmis sarnast lahendust teiste võimalike abivahendite kontekstis kasutama. 70% Parkinsoni põdevatest inimestest peavad igapäevast võitlust värinatega (3), muutes sellise toote rohkem kui vajatuks.

Kasutatud kirjandus: 
1. http://metro.co.uk/2016/12/08/woman-with-parkinsons-can-write-again-using-incredible-invention-6309459/ 
2. http://www.sbs.com.au/guide/article/2017/03/13/meet-aussie-inventor-whose-watch-reduces-parkinsons-tremors
3. http://parkinsonslife.eu/parkinsons-smart-watch-haiyan-zhang-emma-lawton/

Inimese ja arvuti suhtlus, ergonoomika ja kasutatavus

Seekordse postituse eesmärgiks on analüüsida ühte positiivset ning ühte negatiivset näidet kasutajakogemusest veebis. Positiivse näitena pakume kasutaja rahulolu vaatepunktist välja Airbnb ning negatiivse näitena õpitavuse kontekstis Jira Service Desk'i. 

Alustame Jira Service Desk'ist, mida artikli autor on viimase aasta jooksul oma töös kasutanud, ning mille õppimine on olnud vaevarikkam, kui see ideaalis olla võiks. Kuigi tarkvara kasutamine lähtesätteid kasutades on võimalik ning mitte liialt keeruline, nõuab igasugune täpsustav seadistamine kas dokumentatsiooniga tutvumist või konsultatsiooni Jira eksperdilt. Kõige suuremaks probleemiks on autor hinnangul see, et tarkvaras kasutatakse kahetasandilt seadistust, kus esimeseks tasandiks on üldsätted ja teiseks projektipõhised sätted. Probleem tekib sellest, et mõlemad tasandid on omavahel ristviidatud ning sagedane on olukord, kus kasutajal puudub arusaam, kas muudetakse üld-või projektipõhiseid sätteid. Täiendavat ajakulu toidab fakt, et üldsätteid ei saa mitte alati projektidele otse kohaldada, vaid neid tuleb projektide endi all täiendavalt seadistada. Keerukust õppimisel lisab omakorda see, et üld-ja projekti sätted ei ole otseselt duplikaadid ning kasutaja peab teadma, millisel tasandil üks või teine seadistus asub. 

Ühtlasi näib, et kõikvõimalike vaikimisi loodud töövoogusid ja lisasätteid ei peaks alati hoidma listides nähtaval ning mõistlikum lahendus võiks olla nende täiendav importimise võimalus vajadusel (ja olukorras, kus kasutaja on veendunud, et just seda ta vajab). Keerukama tarkvara puhul on kerge tekkima infokülluse probleem, mida aitaks hõlpsasti lahendada "less is more" lähenemine. 

Positiivse kasutaja rahulolu näitena vaatame Airbnb'd. Kuigi paljuski aitab selle teenuse meeldivusele kaasa teenuse kontseptsioon tervikuna, on nad suutnud luua ka läbimõeldud ja mugava veebilehe. Nad olid üks esimesi, kelle esilehel oli pikka aega fookuses ainult üks otsingukast: kuhu, millal, kui mitu inimest. Selline lahendus on sedavõrd lihtne, et läbib igal juhul n.n. vanaema testi. Samuti on nad mõistlikult liigendanud oma otsingufiltrid ning toovad tulemustes välja just need aspektid, mille järgi ööbimiskohta reaalselt otsitakse: hind, asukoht ning pildid. Kui võrrelda Airbnb lahendust näiteks Booking.com pakutuga, on erinevus sisuliselt mõõtmatu. Viimase puhul on esilehel ja otsingutulemustes märksa rohkem infot, pidevalt avanevad kõikvõimalikud pop-up'id ning "fear of missing out" mõtteviisist lähtudes kuvatakse nii kollaselt kui ka punaselt kõikvõimalikke teavitusi. Kahtlemata kuulub antud juhul rahulolu valdkonda ka turunduslik võte retargeting'i näitel, mida Booking.com teeb nii intensiivselt ja läbimõtlematult, et teatud sihtgrupid väldivad selle kasutamist.  

Arendus- ja ärimudelid

Järgnevalt analüüsime Scrum arendusmudelit ning SaaS ärimudelit ettevõtte näitel, kus artikli autor hetkel töötab. Ettevõte on konkreetselt tarkvaraarenduses tegutsenud 1,5 aastat, kuigi on olnud valdkonnas tegev juba varasemalt, ning arendab ühistranspordisektorile suunatud tarkvara. 

Veel poolteist aastat tagasi ostis ettevõtte arendustöid sisse tarkvaraarendusega tegelevast firmast ning arendusmudelitest kõige enam vastas tollasele tegelikkusele Waterfall. Tänaseks on liigutud üle Scrum mudelile ning peamine põhjus selliseks valikuks on antud mudeli paindlikus. Arendustsükkel kestab kaheksa nädalat ning sisaldab endast kahte arendussprinti, mis mõlemad kestvad omakorda kaks nädalat. Nende vahele jääb ühenädalane paus, mida kasutatakse backlog’i korrashoidmiseks ning sprindi planeerimiseks. Ülejäänud nädalad kuluvad vastavalt majasiseseks testimiseks, kliendipoolseks testimiseks ning kasutajate koolitamiseks. Kuivõrd reaalselt on Scrum’i ettevõttes juurutatud umbes aasta, on vara öelda, kuivõrd hästi see ettevõtte ja tema klientide vajadused katab. Samas võib kindlalt väita, et kliendi ligipääs dokumentatsioonile Confluencis ning kliendipoolne testimiskohustus aitab arendada kliendi vajadusele paremini vastavat tarkvara ning tagab, et olulised lisafunktsionaalsused ei jää süsteemis riiulile seisma. Samuti on tänuväärt retrod, mis ei aita mitte ainult vigadest õppida, vaid ka tulevikutegevusi paremini planeerida. Olulise lisatähelepanekuna tuleb aga välja tuua, millise kaalu asetab Scrum mudel kliendi poolele. Nimelt ei ole mõeldav Scrum põhine arendus olukorras, kus kliendi poolel puudub kompetents ja ressurss enda rolli täitmiseks. 

Ärimudelitest kaldutakse antud toote puhul SaaS mudeli suunas, kuid nagu ka artiklis mainitud, on siingi tarkvara rendi põhise mudeliga piir hägune. Erilist raskust lisab fakt, et tegemist on ühistranspordisektoriga, kus müügitsükkel on sageli võrdlemisi pikk ja keerukas. Täpsemalt võiks väita, et tegemist on kasutuskorra põhise lahendusega, sest tasu arvestatakse müüdud piletite põhiselt. Olukorda lisab keerukust fakt, et üks ettevõte tegevussuundi hõlmab endas tarkvara pakkumist, mis on arendatud pidades silmas konkreetset riistvara. Tegemist pole küll tervikplatvormiga, kuid jätab ettevõttele kohustuse vähemalt teatud osas täita ka riistvara hooldamise rolli. Üldjoontes võib väita, et valitud ärimudel toimib, ning suuremad raskused peituvad pigem turu õiges segmenteerimises ning täiendavate tegutsemisvaldkondade leidmises. Hetkeseisuga jääb puudu äri ning arenduspoole koostööst ning mis jäi eelnevalt mainimata, tegelikult puudub ettevõttes Scrumi mudeli üks osapooli - tooteomanik. Probleemiks on, et täidetakse küll klientide vajadusi, kuid puudub suurem pilt ning täpsem siht vajaduste osas, mida tasuks järgmisena arendada. Samuti on kriitiliseks kohaks küsimus sellest, mida tuleks teenusena pakendada ning millise hinna eest. Arendustundide kõrval on samavõrra oluline projektijuhtimise ning kasutajatoe teenuse pakkumine ning hinnastamine.

Kuidas saada häkkeriks

Eric S. Raymondi tekst on otsekohene ja aus sissevaade häkkeriks olemise maailma ning teksti stiilist on tajuda autori laia kogemustepagasit ja kirge teema suhtes. Paralleele tema pidepunktide potentsiaalseks rakendamiseks võib leida kõikjalt. Toome näiteks soovituse mitte teha vaimule tuima tööd ning automatiseerida kõik, mis vähegi võimalik. Soovitusena kõlab see muidugi mõistlikult ning isegi tehtavalt, kuid see eeldab, et inimene, kelle tööd automatiseeritakse, ei ela hirmus oma ametikohta kaotada ning tal on teisi oskusi, mida rakendada. Kahjuks ei ole lihttöödele mitte alati võimalik leida tasuvaid alternatiive ning maailmamastaabis on teada, et tänastele lihttöölistele alternatiivse töö leidmine võib automatiseerimise ja robotite ajastul olla keeruline, kui mitte võimatu.




Loogilise jätkuna jõuame teise teksti läbiva teemani: see seab inimesele võrdlemisi kõrged ootused. Laskumata haridussüsteemi või lapsevanemaks olemise puudujääkidesse, peame nentima, et mitte alati ei jõua koolipingist tööturule motiveeritud ning oma intellektuaalseid võimeid maksimaalselt rakendavad soovivad inimesed. Isegi kui uuesti koolipinki jõudnud kaugõppurite jaoks on Raymond'i nõue uskuda enda õppimis- ja arenemisvõimesse pigem kerge, ei pruugi see olla nii kõikide inimeste näitel. Kokkuvõtvalt võime vast isegi öelda, et autor seab lugejale ja potentsiaalsele häkkerile liiga kõrged intellektuaalsed ja vaimse treenituse nõuded, kusjuures nende välja kommunikeerimises ollakse väga julged, ehk isegi liiga teravad.




Soovin, et autori käsitlus eri programmeerimiskeeltest antud tekstis ning täiendavalt viidatud artiklis "Why Python?" (1) oleks minuni jõudnud enne Java õppimist. Arusaam, et keel, mis teeb õppija eest liiga palju ära, loob vaid pealiskaudse arusaamise programmeerimisest, millest ei piisa keerukamate probleemide lahendamiseks, ei ole mulle võõras - Javat õppides astusin selle reha otsa mitmel korral. Autori argumenteeritud väited, et eri keeled esindavad erinevaid lähenemisi programmeerimisele, panevad mind huviga ootama järgmise semestrite programmeerimisaineid. Ühtlasi jäi positiivselt kummitama autori soovitus kas lugeda teiste kirjutatud koodi omandaks koodi kirjutamise stiil ning probleemilahenduse võtted või vabatahtlikult testima uusi rakendusi õppimise eesmärgil.




Tänuväärt on autori arvukad viited täiendavatele internetis leiduvatele materjalidele ja raamatutele. Kui tuua välja mõned kõige kõnekamad neist, siis näiteks Norvig'i tekst "Teach Yourself Programming in Ten Years" (2) analüüsib tabavalt infoühiskonna ebarealistlikke ootusi eesmärkide saavutamise ajakulu osas ning Dewar'i ja Schonberg'i "Where Are the Software Engineers of Tomorrow?" (3) võrdlus eri programmeerimiskeelte ning kriitika Java kui esimese keele kasutamise osas, pakub palju täiendavat mõtlemisainet.




1. http://www.linuxjournal.com/article/3882

2. http://norvig.com/21-days.html

3. http://static1.1.sqspcdn.com/static/f/702523/9242013/1288741087497/200801-Dewar.pdf?

IT juhtimine ja riskihaldus

Mõeldes maailmamastaabis tuntud IT juhtidele, meenub esimeste seas Elon Musk. Kui püüda leida laiast maailmast mõnda tuntud naissoost IT juhti, kelle tegemistest oleks piisavalt palju teada ning keda võiks heaks näiteks tuua, läheb asi keerulisemaks. Õnneks on IT Kolledži vilistlaste seas Kristel Kruustük, kes on tarkvara testimisteenust pakkuva firma Testlio kaasasutaja ning juht. Kuigi mõlemad nimed täidavad tehnilise juhi rolli kõrval aktiivselt ettevõte juhi rolli, on nende teadmised ja pädevus infotehnoloogilistes küsimustes kaasa rääkida, märkimisväärsed. 

Muski iseloomustab IT juhi arhetüüpidest kõige paremini eelviimane - arengumootor. Üheltpoolt on pea et kõik tema ettevõtmised suuremat tüüpi innovatsioon iseeneses, teisalt ei hoia Musk oma ettevõtteid mitte ainult arengu kursil, vaid on sageli teistest mitu sammu ees. Kui mõelda arengumootoriks olemise peale süvitsi, näeme, et Musk on suutnud end kehtestada kahel väljal - ta on loonud motiveeriva keskkonna nii oma ettevõtete sees (1), kui ka inspireerinud teisi ettevõtteid samas tegutsemisvaldkonnas. Viimase kinnituseks on näiteks Muski loobumine oma patentide kasutamise kontekstis hagide esitamisest (2). Kui püüda leida põhjust, miks Musk ei ole jõudnud masside mõistes samale pulgale Apple juhtidega, siis see võib tuleneda üheltpoolt Muski võrdlemisi tagasihoidlikus loomuses kui ka ambitsioonikas tegutsemisvaldkondade valikus. On selge, et edu auto- ja sülearvutiturul ei ole üks ühele võrreldavad. 

Kruustüki arhetüüpi valides näeme teda sobituvat mitmete juhitüüpide kategooriasse, kuid kõige enam samastub ta mulle esimese ehk liidri arhetüübiga. Kaalu sellesse kategooriasse langemise osas lisab peaasjalikult Kruustüki võimekus kommunikeerida oma ettevõtte sihti. Kusjuures viimase osas on tugevasti kaasa aidanud ka väga selge teenuse segmendi valik - kõikide testimisliikide asemel keskendub Testlio mobiilsete seadmete testimisele. Leian, et lisaks oma meeskonna motiveerimisele, on Kruustük pidevate esinemiste abil kindlustanud ka ettevõtte investorite ja IT sektori üldsuse tunnustuse ja usu tema ettevõtmisesse. Olles näinud teda ise esinemas ning kuulnud ka teistelt tagasisidet tema sõnavõttudele, olen veendunud, et mitmed IT sektori inimesed hindavad teda kui väga võimekat ja motiveeritud juhti. Arvestades Kruustüki vanust ja kogemust on vägagi tõenäoline, et juhtimise osas ootavad teda kogemusepagasi kasvades ees veelgi silmapaistvamad ajad.

Kasutatud materjalid: 
1. Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future
2. https://www.tesla.com/blog/all-our-patent-are-belong-you