Teema 11.

UI (user interface) ei võrdu UX-ga (user experience).

Hakkasin uurima internetist antud teema kohta ja leidsin hästi kirjutatud venekeelse artikli (1). Tahaks autori mõtteid ka siin jagada.

Artikli alguses toob autor näidet kasutuskogemuste ja kasutajaliideste erinevuste kohta. Ja selletab neid võileiba abil (Joonis 1).





Joonis 1.


Kui me sööme võileba siis tunneme maitset - see on kasutuskogemus (UX). Komponentid, mida me näeme võileiba sees (tomat, juust, leib) on kasutajaliidese osad (UI). Artiklis on seletatud, miks on nii kasutajaliides kui ka kasutuskogemus tähtsad. Näideid toon hiljem.

Üks UX-disainer, kasutajanimega Useagility, kirjutas oma blogis: „Teie web-ressurss saab väga ilus olla, kuid kasutajad loobuvad ta kasutamisest kui nemad ei saa resursis orienteerumisest aru.“

Nüüd esimene näide, kus on UX hea ja UI mitte nii. Pangaautomaat - autor räägib, et kasutaja saab väga lihtsalt vajaliku tegevust teha. Näiteks sisestada kaarti, valida vajalikku tegevust (raha välja) ja võtta oma kaarti välja. Lihtne ja mugav protsess, kus kasutaja saab hea UX. Autor pakub, et sellel juhul keegi ei mõtle kuivõrd ilus pangaautomaadi menüü on. Kuid enda poolt tahaks öelda, et Swedpanga automaatides on palju parem UI, kui näiteks Danskepanga automaatides. Võib olla olen lihtsalt rohkem harjutanud Swedbanga automaadi kasutada. Sellest osast autor teeb järeldust: web-ressurss, kus on hea UX ja halvem kasutajaliides on igal juhul parem, aga mitte vastupidi. Edasi autor toob paa näidet, kus on sama probleem - halb UI ja hea UX (India panga koduleht jne), sellest saab artiklis lugeda.

Nüüd vaatame ressurssi, kus on hea UI ja halb UX. Valisin minu jaoks kõige põnevama näide. Pildi peal on e-pood, kus on ilus disain. Kuid parempoolne toode on hinnata (Joonis 2). Kasutaja peab vajutama nupu „Buy now“, et hinda vaadata. Nagu autor ütles - pood pakub osta „kassi kotis“ (vene keeles see tähendab, et ostja ei tea mille eest ja kui palju ta maksab).

Joonis 2. 

1 - http://lpgenerator.ru/blog/2014/07/16/sekrety-yuzabiliti-pochemu-horoshij-polzovatelskij-interfejs-ui-ne-ekvivalenten-polozhitelnomu-polzovatelskomu-opytu-ux/

Teema 10.

Arendus- ja ärimudel.

Arendusmudel.

Kord rääkisin oma sõbraga, kes töötab logisitkafirmas Kuehne+Nagelis, mis hetkel tegeleb tarkvara logistikaga protsesside lihtsustamise jaoks. Antud projektis kasutatakse agiilse mudeli – Scrum. Rutiinselt Scrum mudelis on kolm rolli: toote omanik, Scrum Master ja arendusmeeskond. Kuid nendel on rollide jaotus veidi teine - nendel on lisaks Project Manager ja Teamleader ametikohad olemas.

Project Manager. Meie puhul talle alluvad teamliidrid. Teamliidri all saab mitu arendusmeeskondi olla. Ning igal meeskonnal on oma Scrum Master.

Terve protsessi jagatakse koostisosadeks (sprint), antud juhul kestavad nad 2 nädalat ja neid jagatakse järgmiselt:

1. Esimeses etapis toote omaniku (Project Owner) poolt tuleb tootelog (product backlog). Siis planeerimiskoosolekul püstitatakse eesmärke, mis on kahe nädala jooksul vaja saavutada. Muidugi, eesmärgid algul tulevad kasutajate poolt toote omanikule. Kui eesmärgid on kinnitatud, siis Teamleaderid, Scrum masterid ja arendusmeeskonnad hakkavad jagama ülesandeid ja hindama seda, et nad jõuks need lahendada sprinti aja jooksul.

2. Arendamise protsess (sprint). See etapp on pikeim, arendusmeeskonnad programmeerivad oma osasid. Igapäevaselt tehakse koosolekuid (daily scrum, stand up), kus iga arendaja räägib eelmise päeva tulemustest ja käesoleva päeva plaanidest oma scrum masterile (algul oma meeskonnas). Kui tööline lubas midagi hommikul teha, siis see motiveerib ta täita oma lubadusi homseks päevaks. Järgmisena tuleb ühine koosolek, milles osalevad kõik arendusmeeskonnad (Scrum of Scrum).

3. Sprint review (Demo). Etapp, millal kõik eesmärgid on saavutatud ja testitud. Suur koosolek, kus arendajad näitavad tulemusi, mis nad saavutasid selle sprinti jooksul. Kasu on selles, et terve meeskond näeb sprinti tulemusi. Demo tõstab meeskonna vaimu.

4. Retrospektiiv. Viimane etapp, kus arutletakse millised probleemid olid selles sprintis, et parandada tööprotsessi tulevikus. Nagu ma aru sain, ei pea see osa olema ametlik. Töölised saavad vabalt öelda, mis nendele ei meeldinud jne. Tihti retrospektiivid toimuvad ka töövälisel ajal, näiteks baaris või restoraanis.

Antud firmas on olemas iganädalane planeerimiskoosolek (estimation), mille käigus hinnatakse ülesandeid järgmiseks sprindiks. Tavaliselt sprint review, retrospektiiv ja plaaneerimiskoosolek toimub samal päeval. Kolm korda aastas on ka suur XL sprint review olemas kuhu tuleb toote omanik (kuna ettevõte on rahvusvaheline). Teamliidrid tavaliselt tegelevad organisatsiooni ja rahaliste küsimustega.

Ärimudel.

Mina uurisin mudeleid avatud lähtekoodiga ja nendega seotud plussidega.

Turvalisus. Nagu arvatakse, Eric Raymond tarkvara avatud lähtekoodiga on turvalisem. Selgitab ta seda sellega, et kräkkeridel on huvitavam katki teha kinnist tarkvara. Ning isiklikud andmed lähtekoodiga tarkvaras reeglina šifreeritakse, suletud koodiga mõnikord mitte. Näidisena oli toodud: kui 1997 aastal oli leitud "Ping o'Death", Linuxi arendajad parandasid ta mitu tunni jooksul, siis tarkvarad kinnise koodiga ei ole mitu kuud parandatud (1).

Teised plussid. Turu mudeliga saab kiiresti leida vajaliku kogust arendajaid, kes hakkavad tarkvara ideid arendama. Samal ajal saab kiiresti saada tagasisidet kasutajatelt ja produkti muuta. Samamoodi tegid Jaapani firmad nutiseadmete tootmise ajal. Sageli teised arendajad adapteeruvad sama tarkvara teiste operatsiooni süsteemidega ja annavad töövõimelise versiooni tasuta. Lai OS kasutusvaldkond on suureks plussiks ka.

Teises osas vaatasin Open Source projekte - kuidas luuakse tasuta tarkvara, mis pärast tulu toob. Näiteks, tahaks rõhutada Automattic ja WordPress-ile (2). Matthew Charles Mullenweg 2005 aastal lõi Automattic-u, mille peaprojektideks olid WordPress ja Aksimet. Juba 2007 aastal Matthew-le pakuti müüa Automattic 200mln dollari eest, sellel ajal firmas töötas 18 inimest (ta keeldus).



1 - http://www.libertarium.ru/121515



2 - https://automattic.com/

Teema 9.

How To Become A Hacker by Eric S. Raymond, Estonian translation by Kaido Kikkas (1)

Lugesin antud artikli läbi ning saan öelda, et mulle meeldis see töö ja tõlge. Ainsa asjana, mis mulle ei meeldinud oli see, et autor räägib intelligentsusest ja viisakusest. Kuid KKK osas ta ropendab vastustes kräkkimise kohta, parem oleks selliseid küsimusi ignoreerida. Teine, mis oli kohe nähtav – Windowsi antireklaam ja Linuxi reklaam. Kuid need on autori eelistusteks ja nad on põhjendatud.

Samal ajal oli näha, et autor on väga uhke häkkerikultuuri suhtes. Ja mul tekkis selline tunne, et tegelekult on raske nende hulka sattuda. Kuid ma ei taha öelda, et see peaks lihtne olema. Varasemalt ma olen kohtunud selliste suletud ühiskondadega, kes lihtsalt ei tahtnud endale uusi liikmeid sisse võtta. Tavaliselt see lõpeb sellega, et noorpõlvkond loob oma ühendusi. Siis nad hakkavad omavahel konkureerima. See oli lihitsalt subjektiivne mõte tunne järgi; ma ei tea kuidas tegelekult äsi käib. Mul tuli selline mõte kuna on olemas rahvusvaheline häkkerite võistlused, näiteks Pwn2Own. Sellel aastal oli kõige edukamad hiinlased (Qihoo 360). Mina arvan, et see on hea tegevus, mille käigus kräkkitakse midagi selle jaoks, et tarkvara tootjad saaksid süsteemi augusi parandada. Kuna Qihoo 360 lõi 360 total security, siis negatiivseid sõnumid ka on olemas. Näiteks, et antud tarkvara koguneb infot aukude kohta kasutajate poolt.

Nüüd tahaks jägada oma arvamust nendest kohtadest, kus ma leidsin sama tendentsi oma kogemuses: “Ühtegi probleemi ei tuleks kaks korda lahendada”. Olen täiesti nõus sellega. Minu esimene eriala on seotud vesiviljelusega. Ning antud valdkonnas tehakse erinevaid katseid palju. Katsede tulemused ja meetmeid põhjalikult kirjeldatakse teadusartiklides ja jagatakse laiali. Tehakse seda selle eesmärgiga, et uued teadlased saaksid midagi muud uurida või arendada sama uurimusteema (objekti) teistes tingimustes. Miks ma rõhutan, et seda on vaja? Ma osalesin konverentsidel Venemaal ning nägin kuidas ülikoolid omavahel konkureerivad. Nad ei jäganud tehtud katseid ja töid. Siis oli imelik kuulda - et ühe ülikooli doktorant räägib oma katsetest ning teise ülikooli õpejõud ütleb, et samad katsed meil oli ammu tehtud. Selline konkureerimine ja tulemuste peitmine pidurdab kõvasti valdkonna arendamist. Õnneks tänapäeval olukord läheb paremaks.


Allikad


1 - http://www.kakupesa.net/hacker/

Teema 8.

Kaheksas teemas pakuti vaadelda IT-juhte erinevaid rolle. Neid jagati kuueks tüübiks:

juht (leader) – juht peab nägema lõpptulemust väga selgelt ning tema ülesanneks on viia meeskonda tulemuse saamiseni. Ta peab looma sobilikku töömeeskonda ning valima õiget strateegiat.

teavitaja/suhtleja (communicator) – väga oluline aspekt selleks, et juht oskaks õigesti jagada infot ja seletada tööülesandeid niiviisi, et need oleks meeskonnale arusadavad.

treener/juhendaja (coach) – juht peab suutma motiveerida töölisi töö käigus ennast arendada. See protsess potensiaalselt võib palju aega võtta, kuid protsessi tulemusena tõuseb tulemuste kvaliteet ja üldjõudlus.

mentor/õpetaja (mentor) – mentori roll on treeneri rolliga sarnane. Erinevus seisneb selles, et mentor tavaliselt töötab isiklikult töölise- või väiksema grupiga. Tööd tehakse kauem ja intensiivsem. Selline mentor peab väga detailselt strateegiat juurdlema.

arengumootor (change agent) – minu arvates on just selline oskus meie kiiresti arenevas maailmas tähtsaim. Juht aitab luua organisatsiooni mis suudab erinevate muudatustega kohandada. Hetkel tehnoloogiat arendatakse väga kiiresti ja muudatuste tempot suurendatakse ka. Seega selline oskus on väga väärtuslik.

ülemus (power broker) – juht kasutab võimu.

Analüüsida tuntud IT juhtide rolle on päris keeruline kuna me saame infot nende kohta peamiselt massmeediast, mistõttu meil puudub terve pilt top juhtidest. Selge on see, et igas valdkonnas juht kõigepealt peab oskama ennast analüüsida, oma tugevaid ja nõrgaid juhtimisoskusi teada. Ning vajadusel leida asendajat kes vajalikke oskusi omab (1 ja 2).

Ma proovin analüüsida Bill Gatesi oskusi ja rolle juhina. Kõigepealt saab öelda, et ta ise väga hästi teab IT valdkonda ja omab mentori ja treeneri oskusi. Algusest peale tahtis ta teha Microsoftist gigant korporatsiooni, tal oli selge pilt edasiliikumiseks. See on heaks näitajaks, et tal on liidri roll ka olemas. Leidsin infot ka sellest, et ta väga rangelt töötajaid valib. Sageli võttis tööle oma tuttavaid, kelle tugevaid ja nõrgaid kohti ta varasemalt juba teadis. See räägib sellest, et ta oskab luua õiget meeskonda edasise koosarendamise- ja tulemuste saavutamisega, mis on liidri rolli näitajaks ka. Bill rakendab innovatsiooni meetmeid pidevalt ja investeerib raha erinevatesse tehnoloogiatesse. Ta saab aru, et mõned nendest kokkuvõteks edu ei saavutagi. Kuid tema jaoks on selge, et tänapäevases maailmas tuleb uusi tehnoloogiaid kiiresti arendada. Ainult sellel juhul saab ta turul konkureerida. See osa näitab arengumootori rolli (3 ja 4). Mul tekkis selline arvamus, et Bill Gates on rohkem liider, kuid tal on kindlasti olemas teiste rollide tunnused ka.

Teine IT juht, keda ma proovin analüüsida, on Mark Zuckerberg. Mark Zuckerberg on tugev isik oma valdkonnas ja armastab seda mida ta teeb nagu Bill Gates. Tal oli selge visioon ja see visioon on seni elus. Visiooni põhimõteks oli luua enam avatud maailma ja anda võimalust inimestele vaba info jagamiseks, mis on liidri rolli näitajaks. Mark rakendab innovatsiooni sotsiaalvõrgus ja, kuigi mõned nendest on ebaedukad, ei karda ta nendest loobuda. Ta väga kiiresti adapteerub muutvas situatsioonis. Näiteks, inimesed hakkasid Facebooki kritiseerima seetõttu, et seal pole isiklik elu kaitstud. Siis tehti muudatusi, et kasutaja ise võiks valida Facebooki konto avalikkust ja saaks muuta kontot nii nagi kasutajale endale on vajalik - arengumootori näitajad. Facebook valib endale sobivaid töölisi vestluste kaudu. Kui inimene lõpuks astub tööle peab ta kohe koolitust läbima kus ta vajalikke oskusi saab. Oskused tulevad kogemuste abil, kuid tööhimu peab kohe ka olema - meentori ja treeneri roll (5 ja 6). Kokkuvõttes, minu arvates on Mark Zuckerberg pigem treener/juhendaja.

Allikad:

1 - https://www.sagamorepub.com/files/lookinside/304/9302-li.pdf

2 - https://beta.wikiversity.org/wiki/IT_eetilised,_sotsiaalsed_ja_professionaalsed_aspektid/IT_juhtimine_ja_riskihaldus

3 - https://mubbisherahmed.wordpress.com/2010/08/23/bill-gates-chairman-microsoft-management-style-and-cios/

4 - http://theyouthimpact.org/what-makes-bill-gates-a-great-leader/

5 - https://www.linkedin.com/pulse/7-qualities-make-mark-zuckerberg-ace-ceo-priya-florence-shah

6 - http://www.inc.com/ekaterina-walter/as-zuckerberg-turns-30-leadership-lessons.html