Rohkem lolle küsimusi!

Minule eriti südamelähedane teema on “lollid küsimused”. Analüütikute ülesanne on küsida küsimusi, tahes-tahtmata trehvab sinna sisse ka lolle. Soojenduseks selgitan,  mis on minu arvates üldse “lolli küsimuse” definitsioon. Minu arvates on see midagi “elementaarset” ja “loomulikku”, mida “kõik ju teavad”. Jutumärgid siin ja edaspidi on taotluslikud, sest just sellised eeldused kõigi on konfliktide ja probleemid emad. Võtame kasvõi täiesti iseenesestmõistetavad žestid – teatud kultuurides tähendab pearaputus jaatust ja noogutamine eitust.

Rusikareegel – kui juba mingi loll küsimus pähe tuleb, siis oleks targem ka küsida, muidu on oht oma elementaarsetele ja üldteatud valede eeldustele põhinedes mingi jamaga hakkama saada. Miks lolle küsimusi tihti ei küsita? Paljudele ilmselt ei tule pähegi oma eeldustes või teadmistes kahelda, samuti leidub inimesi, kes niikuinii teavad, kuidas kõik asjad käivad. Enamasti aga kardetakse loll välja näha. Mida vähem pealtvaatajad, seda rohkem “lolle” küsimusi. Mida vähem kardetakse või häbenetakse inimest, kellelt küsimust küsitakse, seda rohkem “lolle” küsimusi. Tüüpiline situatsioon spordirindelt: treener seletab tervele grupile pika jutu maha, lõpetuseks: “Kas kõik
said aru?”. Keegi ei kõssa, kõik noogutavad. Treener läheb veidi eemale, algab arutelu paarides/gruppides: “Oota, mida me tegeme peame?”. Täpselt sama stsenaarium väikeste mugandustega kehtib ka koolis, tööl, arsti juures, puhkehetkedel… Delfi foorumitest ei leia suurel hulgal lolle küsimusi mitte (ainult) Delfi kasutaja väidetavalt madalama intelligentsustaseme tõttu (tuntud ka kui Delfi debiilik), vaid hoopis anonüümsuse tõttu. Juba ennevanasti olid lugejaküsimuste rubriigid selles valdkonnas populaarsed (doktor Noormann kasvõi).

Ehk siis tuleks kaaluda, millal loll välja nägemine on olulisem kui targemaks saamine. Paradoksaalsel kombel võivad targemad inimesed endale rohkem lolle küsimusi lubada – ükskõik mida Albert Einstein küsiks, peaks kõik seda väga oluliseks ja sügavamõtteliseks, kuigi sama küsimus Juku suust kõlaks äärmiselt totralt. Ehk siis: mida rohkem küsida, seda targemaks saad, mida targemaks saad, seda rohkem võid küsida. Igaüks ise valib, mis otsast peale hakata.

Aga on ka mitmeid trikke, kuidas lolle küsimusi esitades siiski tark välja näha, näiteks:
“Kuidas sa seda oma vanaemale seletaksid?”
kinnitavad küsimused: “Kas ma saan õigesti aru, et…”
muidu pettused-valskused: “Mul läks enne kõrvust mööda, kuidas ….”, “Ants tahtis teada…”

Muuseas, üks analüüsimetoodika on küsida hästi mitu korda järjest lihtsalt “Miks?” – ei pruugi just väga tark välja näha, aga töötab ka tavaelus väga edukalt.

Vahel (või siis päris tihti…) tembeldatakse lolliks ka küsimused, millele vastata ei osata või mille vastused on ebamugavad. Nii tore on sellest nurga alt jälgida poliitikuid – tipud muidugi vastavad kõikidele küsimustele nii, et tegelikult pole ühtegi vastust andnud, aga natuke kobamad lähevad ebamugavate küsimuste puhul just küsimuse või küsija halvustamise teed.

Lolle küsimusi ei maksa häbeneda ega neid halvustada. Siinjuures teeksin mina vahet lollil ja laisal küsimusel. Laisk küsimus saab tavaliselt vastuse “RFTM” või “Google”, aga mõnikord inimene tõesti ei tulegi selle peale, et ise vastuseid otsida ja ka “Google” võib vastusena tõepoolest aidata. Nii et kui endal on loll küsimus, mida küsida häbened, soovitaksin võimalusel teha natuke eeltööd ja siis ikkagi küsida. Kui keegi küsib sinult lolli küsimuse, siis vastata viisakalt ja tõsiselt, vähemalt esimesed korrad. Hiljem koorub juba välja, kas need on laisad või lollid küsimused.

Loo moraal – lollid küsimused on teevad tavaliselt kõige targemaks. Ma olen mõnikord koolitustel mänginud udupead, kes küsib ise need lollid küsimused ära, mis kõigil peas keerlevad, aga keegi küsida ei julge. Kõik teavad niigi, et ma tark olen, lisaks muidugi ka ilus ja osav.


Tahan omale kodulehte!

Ma olen üsna kindel, et kõik, kes on oma tutvusringkonnas tuntud kui “arvutispetsialistid” – ükskõik, mida nad siis tegelikult teevad – on kokku puutunud pealkirjas nimetet sooviga. Tuleb sõber/tuttav/sugulane/lehma lellepoeg ja räägib, et tema firmale/klubile/koerale oleks vaja hädasti kodulehte. Sellist tavalist, et midagi eriti uhket. Et kuidas on, teed ära või?

Kui päris ausalt öelda, siis mina sellistest asjades väga vaimustuses ei ole, sest

  1. see ei ole minu ala
  2. see ei paku erilist väljakutset
  3. sõpradega äri tegemine ei ole hea mõte
  4. vt eelmist punkti – rahalises mõttes pole eriti kasu(m)lik
  5. põhiline aur läheb mitte tööle, vaid kliendi õpetamisele, kuidas olla klient ehk kuidas tellida kodulehte

Järgnev jutt läheb kõik viienda punkti alla ehk peaks aitama kodulehtede tellijatel ning teostajatel (edaspidi: “IT-mees”) lihtsamini ühist keelt leida.

1. Miks?

See on kõige olulisem küsimus ja sellest sõltub otseselt ka lahendus. Siin on palju alamküsimusi, millele peaks leidma vastuse enne, kui minna kellegi jutule. Näiteks:

  1. Milline info on kodulehel? Kas ainult kontaktandmete ja põhiinfo jaoks? Või peab seal olema tootekataloog? Hinnakalkulaator? Või lausa e-pood? Ehk teisisõnu – mis info seal on ja mida inimene seal kodulehele teha saab.
  2. Kui palju infot ja mis mahus? Näiteks on suur vahe, kas on näiteks 10 lehekülge või on 100 toote jaoks igal oma lehekülg või on kavas 100 filmi kättesaadavaks teha…
  3. Kui tihti info muutub? Kord kvartalis? Igapäevased uudised?
  4. Milline kujundus? Kas olulisem on sisu või vorm? Kas piisab lihtsalt tekst + mõned pildid? Või on vaja spetsiaalset kujundust, värve, pilte, videoid, animatsioone?  Ehk teisisõnu – kas ilusalt koostatud Wordi dokument ajaks ka asja ära või peab olema midagi, mis kohe pahviks lööb? Ideaalis on kujunduse jaoks eraldi disainer, “IT-mees” ei pruugi erilist ilumeelt või kunstiannet omada. Ja üleüldse – logo on olemas või tuleb see ka välja mõelda?
  5. Kes loob sisu? Ega ometi mitte mina? – ilma naljata, see on oluline küsimus! Kust tulevad kõik vajaminevad tekstid, pildid jms sisu? Täpsustame – veebilehe loomise all mõtleb “IT-mees” tavaliselt seda, et põhimõtteliselt on kõik “paberi” peal valmis joonistatud kirjutatud ja tema tambib selle arvutisse.
  6. Kes selle kupatusega edaspidi jooksvalt tegeleb?  Ega ometi mitte mina? Kas ettevõttes on keegi, kes muudab sisu, tegeleb vajadusel ka tehniliste probleemidega?
  7. Mida veel lisaks? E-mailid? Meililistid? FTP (kui ei tea, mis tähendab, siis pole oluline)? Alamdomeenid?
  8. Palju selle kõige eest makstakse? See on valus ja oluline teema! Kaks külge: esmane summa ja igakuine summa. Vähegi korralikuma asja korral tuleb arvestada mingi igakuise kuluga. Samuti – mida suuremad soovid, seda suurem hinnasilt. Aga kui mingi visioon on olemas, siis saab “IT-mees” öelda, palju see maksab.

Soovitan need küsimused läbi mõelda ja enda jaoks paika panna iga teema miinimum- ja maksimumprogrammi. Mis peab kindlasti olema ja mis võiks olla? Mis rahasummaga oled arvestanud ja üle mille kindlasti ei lähe? Samuti oleks head mõned näidised-visioonid – olgu selleks siis konkurendi koduleht või paberi peale kritseldatud pilt.

2. Sissejuhatus nohikukeelde

Ehk siis juhul, kui tõsiselt asjaks läheb, tuleb õppida vahet tegema kolmel asjal: koduleht, veebimajutus (hosting) ja domeen.

Koduleht

Põhimõtteliselt on koduleht hunnik faile, mida veebibrauser näidata oskab. Veebibrauser on see programm, millega sa “internetis käid”. Teoorias võib koduleht olla ka ainult sinu arvutis, aga sel juhul näed seda ainult sina. Koduleht võib koosneda tegelikult mitmest lehest. Tänapäeval on enamus kodulehti hoopis sisuhaldussüsteemid (SHS, inglise keeles Content Management System, CMS), mis tähendab, et on olemas mingi raamistik, aga sisu loomisega (uudiste kirjutamisega, piltide lisamisega) saavad ka täiesti tavalised inimesed hakkama.

Veebimajutus ehk hosting

Nagu eestikeelne sõna ütleb, tuleb sinu tulevane koduleht ehk veeb kuskile majutada. Kõik maailma kodulehed paiknevad erinevates serverites (need on uhked võimsa netiühendusega arvutid) ja meie käime neid sealt vaatamas. Suurematel firmadel on oma serverid, aga see on võrdlemisi kallis lõbu. Väiksemate firmade ja eraisikute jaoks on olemas terve hunnik igasugu teenusepakkujad, kes oma (kallist) serveriruum sulle pakuvad. Neid leiab maa alt ja maa pealt, eestis ja välismaalt, kõikvõimalike hinna-, garantii- ja muude tingimustega. Enamasti pakuvad veebimajutuse teenusepakkujad ka domeeni registreerimist (vt järgmine punkt). Eestis on tuntumad zone.ee, pilves.ee, väljamaal godaddy.com, hostgator.com. Nimekiri on praktiliselt lõputu ning valik tuleb teha vastavalt vajadustele  (vaata esimest peatükki)

Pakutakse ka tasuta veebimajutust, aga sellel on tavaliselt oma piirangud. Näiteks Eestis hot.ee, zone.ee, maailmas wordpress.com, onepagefree.com ja paljud teised. Seal on sisu ja vormi osas teatud raamid ees, aga samas võib ka sellest täiesti piisata (vaata esimeset peatükki).

Domeen

Domeen on it-nohikute peen sõna aadressi jaoks. Domeen on see, mille inimene aadressiribale sisse toksib ja mille peale Internet teab, millisest serverist (vt eelmist punkti) sinu kodulehekülg lahti teha. Noh, tegelikult on see aadress, domeen on need kaks punktiga eraldatud sõna, mis on aadressis enne esimest kaldkriipsu. Näiteks neti.ee on domeen, postimees.ee on domeen, eesti.ee on domeen, google.com on domeen jne. Domeene ei jagata tasuta, reeglina neid renditakse mingi aastamaksuga. Kes rendib? See oleneb, millega domeen lõppeb. .ee lõpuga domeene haldab Eesti Interneti sihtasutus (http://www.internet.ee/korduma-kippuvad-kusimused). .eu ja .com  ja kõikvõimalikud muud variandid on ka võimalikud, nende osas aitab internet. Praktiliselt pakutakse domeene enamasti koos hostinguga (vt järgmine punkt). Võimalik on registreerida ka mitu domeeni, mis kõik viivad sinu kodulehele. Domeeniga kaasnevad ka vastavad meiliaadressid – tahad olla kuningas@sinufirma.ee? Domeen ei ole kohustuslik, näiteks pakuvad teenusepakkujad tihti tasuta aadressi, mis paikneb nende domeeni peal, näiteks hot.ee/sinufirma või sinufirma.wordpress.com.

3. Kokkuvõte

Julge pealehakkamine on pool võitu!

 


Õigus eksida. Iseenda ees.

Kui eelmine jutt rääkis sellest, et inimestel üleüldiselt tuleks lasta vigu teha, siis seekord pöördume hoopis huvitavama teema – iseenda – juurde.

Kartus eksida passib sügaval enesehinnangu sees. Mida hapram enesehinnang, seda vähem talub ta, kui tal “õigus” ei ole. Tugevad veel julgevad oma nõrkusi näidata, aga nõrgad üritavad iga hinna eest tugevad näida… Eelmises lauses võib kasutada ka sõnapaare tark-loll, ilus-kole jne. Vägisi tahab jälle mõte rändama minna, teemale “olemine vs näimine”, aga see on teine jutt.

Tagasi eksimise ja vigade juurde. Eksimine pole mitte ainult inimlik, vaid ka õpetlik. Vead annavad sageli rohkem infot kui õnnestumised ja võivad meid oma lõppeesmärgile hoopis lähemale viia. Penitsilliini avastamise lugu teate jah? Kogemata läksid katse-taldrikud hallitama ja näe, mis välja tuli! Edison on ka tuntud ütluse poolest: “Ma ei ole ebaõnnestunud. Ma olen leidnud 10 000 viisi, kuidas mitte teha elektripirni”. Nii et vead on head, vigadest saab õppida. Või pigem teistpidi – kui vigadest õppida (ja mitte neid paaniliselt karta, mitte tunnistada ning ennast nende pärast süüdistada), siis on nad head.

Tahtmine olla täiuslik ja teha ainult täiuslikke asju on mõnel tugevam kui teisel. Reaalsuses pole aga inimene, sportlane, tarkvara, maja, Tallinna linn kunagi “lõplikult valmis”, alati saab midagi parandada. On selline tore ütlus nagu “parem tehtud kui täiuslik” (tuntud ka kui “parem varblane peos kui tuvi katusel”, “parem pool muna kui tühi koor” jne). Minu jaoks tähendab see seda, et ma võin proovida – ja alles seejärel otsustada, mis edasi saab. Esimene versioon ei pea olema täiuslik, aga see annab palju rohkem ideid, kuidas edasi minna. Samuti on endal lihtsam, kui alguses väiksemalt ette võtta (suur siht siiski silme ees!). Väikseid vigu on lihtsam parandada ja samm-sammult liikudes saab märksa kiiremini valelt teelt tagasi pöörata. Kõike on veel vähe kulunud – aega, raha, vahendeid.

Niikuinii meie soovid muutuvad, vajadused muutuvad, võimalused muutuvad. Ühel hetkel täiuslik tundunud/olnud asi võib olla peagi aegunud ja vastupidi. Me kasvame oma riietele alguses järgi – ja siis eest ära. Kui väga kaua täpselt parajat kleiti õmmelda, võib see ühel hetkel olla väike või suur või moest väljas. Ma olin 6.klassis surmkindel, et minust saab tippsportlane ja ma lähen võimalikult vara ära spordikooli. 9. klassis olin ma surmkindel, et ma ei hakka mitte kunagi tippsportlaseks ja spordikooli ei lähe relva ähvardusel ka mitte. Ülikooli ajal sai minust siis tippsportlane. Enam ma asjades nii surmkindel pole;)

Loo moraal ja minu moto – jamad juhtuvad, aga alati saab paremaks minna. Ja kindlasti oleks saanud ka hullemini minna. Minevikku muutmine on keeruline, tuleviku ennustamine ainult pisut lihtsam. Kui vähem mõelda sellele, mis kõik valesti läks ja kui halvasti kõik minna saab ning rohkem sellele, kuidas asju veel paremini teha, on endal lihtsam ja ning ka tulemused paremad. Spordis, töös, elus.


Õigus eksida

Inglise keeles on see väljend kõlavam – “the right to be wrong“, kuid ega nimi meest ei riku.

Laste rääkimaõppimine on väga võluv. Enda väljendamiseks kasutatakse kõiki suupäraseid vahendeid, pööramata erilist tähelepanu vormilisele korrektsusele. Kui keel veel ei paindu “sipelgas” välja ütlema, siis sobib ka “ipi”. Aegamisi läheb paremaks ja väljendist “issi pr-pr, mme” saab ka “Isa läks autoga linna ja tuleb homme tagasi”. Kõik saavad aru, keegi ei kurjusta, aidatakse vaid õppimisele kaasa.

Huvitaval põhjusel käitume me aga vanemaks saades sageli nii, nagu vigade tegemine oleks keelatud. Nagu õppimine, millega kaasneb ka vigade tegemine, oleks midagi häbiväärset. Nagu peaks kõike kohe teadma ja täiuslikult oskama.

Kas pole kummaline, et koolis lastakse sul oma vigu parandada ainult siis, kui sa üldse midagi ei oska? Kui teed veidi vähem vigu (st päris läbi ei kuku), siin on sul vaid üks katse kõik õigesti saada ja halvemal juhul ei öelda sulle isegi, mida sa valesti tegid, rääkimata siis selgitamisest, kuidas tegelikult õige oleks. Oleks minu teha, siis ei liigutaks koolis enne edasi, kuni mingi materjal on 100% selge. Praegu minnakse hooga edasi, isegi kui oled omandanud 50-75%, kuigi see 25%, millest sa midagi ei jaga, võib teha võimatuks uue materjali omandamise. Ja aastahinne ei tuleks mitte selle pealt, et kogu materjali hulgast tean x%, vaid x% materjalist tean kõike. See eeldab muidugi individuaalseid õppeprogramme ja kogu süsteemi mõningast (khm, kapitaalset) ümbertegemist, aga see on üks teine (ja väga pikk) jutt.

Elus on väga vähe asju, mis peavad kohe esimesel katsel õigesti välja tulema. Enda sünd ilmselt – ja ega rohkem esimese hooga meelde ei tulegi. Kusjuures isegi sünd ei pea olema ideaalne, minul isiklikult oli seal arenguruumi kindlasti palju, aga mul oli ja on terve elu aega seda kompenseerida. Isegi spordis on tavaliselt mitu katset – ja mitte keegi ei vaata, mis su kõige kehvema katse tulemus oli. Mõni mees (või naine) jõuab alles ei-tea-mitmendal olümpial medalini ja kellelgi ei ole hiljem meeles, mitu korda ta 2, 22 või 102 koha sai. Käsi püsti, kes teab, mitmes Kristina Šmigun Nagano olümpial oli?

Tarkvaral on samuti mitmed eri versioonid ja veaparandused ning juba enne laiemale publikule esitamist tehakse mitmeid masin-, loom- ja inimkatseid, et vigu välja peilida. Ideaalset koodi ei kirjuta keegi, ideaalset spekki ka mitte.

Äkki peaks inimõigustesse panema sisse õiguse eksida? Õigus oma otsuseid muuta, õigus vaateid muuta, õigus asju valesti teha – ja seejärel parandada. Kas lubada eksida teistel või endal, on aga suur vahe. Teiste suhtes oleme me enamasti leebemad ja saame aru, et vead käivad õppimise juurde ja vigade parandus on positiivne, kuid iseenda suhtes oleme karmimad. Aga see on jällegi teine jutt, mis on juba kuju võtmas.


Kõigile analüütikutele

Viisil “Itimees” (Bläck Rokit)

Räägin neile seda lugu, kes on spekimehe sugu:
spekimees on lahe säga, kõigile ta meeldib väga.
Iga õige mees oma speki teeb ja kes speki teeb, ongi spekimees.

Ja ei ole asju mitte millest ei saa teha spekke,
spekke on ju vaja, spekke on palju vaja.

Ta on vinge mees, aina spekke teeb,
ikka sõiduvees nagu kala.

Spekimees on lahe säga, kõigile ta meeldib väga,
ei see pane imestama kui ta ongi kala.

Ja kui spekimees joob kalja, kohe speki laseb välja.
Eriti just hommikuti spekke tuleb ühte jutti,
aga öösel spekk ei tule .
See on spekimehe mure, kui tal tõesti siis ei tule,
aga ükskord tuli tal küll.

Ta on spekimees,
Ta on spekimees,
ta on spekimees, eks ole.


SharePoint Foundation ja grupipõhine navigatsioon

SharePoint Server võimaldab määrata navigatsioonilinkidele (ja ka veebiosadele jms) sihtrühmasid (target audience) ja seega näidata näiteks erinevatele kasutajagruppidele erinevat navigatsiooni. SharePoint Foundationil seda võimalust ei ole, toimub ainult turvapügamine (security trimming) ja seegi mitte otse navigatsioonilinkide puhul, vaid siis, kui näiteks loend on määratud ennast navigatsiooni näitama – sel juhul näidatakse linki ainult kasutajatele, kel on õigus seda loendit näha. Kui aga lisada täpselt sama sisuga lingi ise ja käsitsi, siis õigusi ei kontrollita.
Niisiis oli meil kasutajanõue, et ka SharePoint Foundation platvormi korral saaks näidata kasutajagruppide lõikes erinevat vasakmenüüd (kiirkäivitusala, Quick Launch). Lisakitsendused: navigatsioonilahendus pidi toimima kolmel eri saidil (üks sait ja kaks tema alamsaiti); kõigi kolme saidi puhul oli nii kattuvat kui ka unikaalset navigatsiooni; linke peab saama hallata administraator SP kasutajaliidesest.
Nõuetest tulenevalt otsustasime asja lahendada kombinatsiooniga linkide loend + control juhtlehele (master page).

Linkide listile lisasime kaks lisaveergu: tõeväärtuse veerg, mis näitab, kas linki kuvatakse vahepealkirjana ning valikuveerg (mitmikvalik/checkbox), mis määras ära millisel konkreetsel saidil linki näidatakse. See viimane seos on hardcoded (kuna saitide hierarhia on püsiv ning selle seadistatavaks tegemine ei olnud hetkel otstarbekas). Linkide listi igal üksusele saab määrata õigusi ning üleüldse teha kõike, mida ühes SP listis teha saab.
Juhtlehe control kuvab igal lehel listi üksuseid vastavalt kasutaja õigusele ning üsna samamoodi, nagu muidu kiirkäivituslinke – genereerides põhimõtteliselt vastavalt päringu (query) tulemustele HTMLi, isegi samade CSS-i klassidega. Controli panime kiirkäivitusala alla, nii et kasutaja ei pea isegi aru saama, kas tegu on tavapärase navigatsiooni või siis meie “erilisega”.

Näidis:

Lisanavigatioon “Lisanavigatsiooni vahepealkirjast” kuni “Link 2-ni” (kaasaarvatud)  on meie erinavigatsioon, üleval on SP tavaline kiirkäivitusala ja allpool prügikasti ja kogu saidi sisu lingid.


Raha!

Kapitalistlik ühiskond – teame kõik. Laulusalmgi ütleb, et “raha paneb rattad käima”. Kapitalistlikus maailmas on suurema osa juriidiliste isikute eesmärgiks teenida kasumit. Hea küll, riigiasutused tegelevad peamiselt raha kulutamisega ja MTÜd ümber jaotamisega, aga äriettevõtete eesmärk on kasum. Raha. Samas füüsilised isikud ehk inimesed toimivad natuke teisiti (video) , vähemalt siis, kui peamised vajadused on rahuldatud, st kõht on täis, soe tuba ja mees/naine ka kõrval. Noh, tegelikult on muidugi nii, et inimene on rahul siis, kui tal naabrist paremini läheb, aga see on teine jutt. Igal juhul motiveerivad inimest pärast madalamate vajaduste rahuldamist pigem “pehmed” väärtused: hea seltskond, võimalus teha ägedaid asju, mõjutada maailma  ja oma alal hea olla.

Tänane jutt on seega sellest, kuidas viia kokku äriettevõtte soov teenida palju raha ja tema töötajate soov teha toredas seltskonnas toredaid asju.

Igaks juhuks olgu öeldud, et praktikas pole mul ühegi ettevõtte juhtimise kogemust ja ka teoorias olen ma väga nõrk, aga seda lihtsam on mul sõna võtta.

Niisiis, kasum vs töötajad. Üldiselt on näiteks tarkvaraarenduses töötajad ettevõtte kõige suurem kulu. Õnnetul kombel aga päris ilma töötajateta ei saa ning IT-valdkonna inimesed on sektori tööjõupuuduse tõttu pisut ära hellitatud – üle keskmise palgale lisanduvad muud hüved ja ka töö ise peab olema huvitav ning väljakutsuv. Rahaga arendajat uimaseks lüüa on keeruline ja uimane arendaja ei tee tavaliselt ka kõige paremat tööd. Samas ei kõiguta ühte arendajat tavaliselt väga palju, kas ja kui palju omanikud kasumit saavad. Boonused on kahtlemata toredad asjad, aga nagu öeldud, raha ei ole siinkohal nii oluline motivaator. Teiselt poolt ei huvita ühte abstraktset omanikku (näiteks mõnda fondi) üleüldse, kas arendajal on tore ja kas ta saab uue kiire arvutiga uue mugava tooli peal istudes uusi ägedaid tehnoloogiaid katsetada.

Igipõline huvide konflikt? Kapitalistlik vereimeja ja rõhutud tööline? Minu arust mitte. Ettevõte ei teeni pikas perspektiivis kasumit, kui seal ei tehta head tööd. Töötajal ei ole häid töötingimusi, head palka ja toredaid kolleege väga kauaks, kui ettevõte kasumit ei teeni. Ja selle pärast ongi ettevõtetel juhid, kes peavad kahte näiliselt vastandlikku poolt veenma, et tegelikult on nad ühes paadis. Omanikule meelde tuletama, et kui ta oma töötajate eest ei hoolitse, siis need lähevad ära ja pole enam kedagi, kes kasumit teeniks. Töötajale meenutama, et kogu aeg ei saa ka ainult lust ja lillepidu olla, vahepeal tuleb ebameeldivaid asju ka teha, kui need raha sisse toovad, muidu lülitatakse maksmata arvete tõttu kontoris elekter välja.

Tegelikult on see muidugi vana kuldmunasid muneva hane lugu, mille näiteks Covey oma P/PC (T/TV) tasakaalust rääkides välja toob. Lühidalt – kui oled talumees, siis poputa oma kuldmune munevat hane. Kui oled hani, siis mune piisavalt kuldmune, muidu süüakse sind pärast poputamist jõulude ajal ära. Kehtib mitte ainult tarkvaramaailmas, vaid universaalselt.


SharePointi ärirollid

Jutukeses Ringmäng ümber SharePointi kirjutasin kolmest SharePointi põhirollist, aga seda peamiselt IT-inimeste ja arenduse vaatevinklist. Medalil on aga alati ka teine pool, kellest kõik alguse saab ning kes kõigele sellele sebimisele mõtte (loe:kasumi) annab – äripool. Lisaks ei lõpe tarkvaraprojekt sugugi live’i minekuga, vaid siis alles päris elu algabki.

Iga IT-projekti argipäev on tavakasutaja ja IT ühendamine. Igal rakendusel on tavaliselt

  • tavakasutaja
  • sisuline administraator – keegi äripoolelt, kes tavakasutaja jaoks asju sätib. Sõltuvalt rakendusest on tema tööpõld väga lai või väga kitsas (elementaarne näide on foorumi moderaator (või blogipidaja), keerukamad on mitmed ärirakendused). Üldiselt äripoole vastutaja, puhver IT ja tavakasutaja vahel, jagab infot mõlemal suunal, näiteks teeb täiendusettepanekuid.
  • tehniline administraator – keegi IT-poolelt, kes asja toimimas hoiab, alates serverite püstihoidmisest kuni varunduse ja muu selliseni

Lisaks üldrollid nagu kasutajatugi, projektijuht jne. See on siis kõige lihtsam IT-projekt. SharePoint ei ole aga just väga lihtne projekt (kordame kõik koos: Sharepoint on strateegiline platvorm). SharePoint on nagu termotuumaenergia (tuli/nuga/vms), mis õigetes kätes võib suuri asju teha, aga valedes (või lihtsalt teadmatutes) kätes lõpeb suure jamaga. SharePoint ongi mõeldud äripoolele suurte võimaluste andmiseks, aga sellega kaasneb ka suur vastutus.

Üks töötava SharePointi rakenduse rollide võimalik jaotus on toodud http://www.letscollaborate.co.za/Resource-Centre/SitePages/JobDescriptionsIndex.aspx:

Omast tarkusest märkisin punasega ärirollid, sinisega tehnilised rollid ja lillaga vahepealsed, kuigi siin on ka vaieldavusi ja kõik sõltub konkreetsest olukorrast. Kui on tehtud veel mingit SharePointi eriarendust (ärirakendus, line of business (LOB) application), siis lisanduvad siia veel konkreetse rakenduse samad rollid (hea küll, serveri admin jääb võibolla ära).

Loomulikult on ei ole väiksemas organisatsioonis vaja igale rollile oma inimest, aga tihtipeale jäävad need rollid üleüldse õhku rippuma – äripool arvab, et see on IT ülesanne ja IT arvab, et sellega peaks äripool tegelema. Lõpptulemus – vt paar lõiku ülespoole.

Igal SharePointi asjal (projektil, installatsioonil, farmil, veebirakendusel jne kuni saidini ja vajadusel iga üksiku sisuelemendini välja) peab olema oma vastutaja, kes tõepoolest sellega ka tegeleb. Vastav inimene peab ka teadma, et see vastutamine kuulub tema tööülesannete juurde ning tal peab selleks ka aega olema. Tihti läheb nii, et inimesele öeldakse, et “nii, sina nüüd vastutad selle eest”, aga muid kohustusi vähemaks ei võeta. Kui just pole tegu eriti entusiastliku või kohusetundliku inimesega ning piisavalt oskusi/teadmisi ka pole, siis sinnapaika see jääbki. Lõpptulemus – vt paar lõiku ülespoole.

TL, TR: SharePoint nõuab äripoolelt:

  1. tugevat organisatsiooni
  2. pühendumist
  3. hoolt ja kontrolli
  4. inimeste aega

Ja sealt edasi on juba kõik võimalik, konkreetsete probleemide lahendamiseks (näiteks kontrollimatud alamsaidid) on targematel inimestel mitmeid nippe ja trikke, aga see on puhtalt delo tehniki.

* jah, mõtlesin ise välja, sest eesti keeles EI OLE vastavaid termineid olemas või on need väga hästi peidetud.


Piirivalvur/majahaldjas

Kui eelmine jutt rääkis sellest, millised rollid SharePointi projekti juures tavaliselt vajalikud on, siis nüüd võtaksin ette selle, mis tegelikult toimuma hakkab. Eeldades, et äripool on võtnud vastu põhjendatud otsuse SP kasutsele võtta ning suudab omi vajadusi/probleeme (analüütiku mõningase abiga) mõistlikult sõnastada, siis on edasine stsenaarium lihtsustatult ja
ideaalses maailmas umbes selline:

analüütik, administraator ja arendaja (või kõik ühes isikus = arhitekt) vaatavad otsa ärivajadustele ning tuvastavad, milliseid vajadusi saab rahuldada OOTB vahenditega (seadistus ja kohandamine), mille jaoks läheb vaja eraldi arendust ning panevad sellest tulenevalt paika arhitektuuri – nii füüsilise, loogilise kui ka informatsioonilise.

Ilmselgelt ei ole see lihtne ülesanne, ilmselgelt ei käi see kiiresti ja ilmselt on vaja korduvalt ka äripoolega suhelda: “Kas me võime teie vajadusi just täpselt nii rahuldada?”. Aga noh, põhimõtteliselt.

Edasi tegelevad:

  • analüütik ja administraator kohandamisega
  • arendaja arendamisega
  • arendaja ja administraator kogu kompoti kokku- ja käimapanekuga
  • analüütik kasutajate koolitamisega/kasutajatoega
  • administraator tööshoidmisega

Ja ongi valmis, nii lihtne see oligi;)

Eelkirjutatust on näha, et administraator on praktiliselt igal sammul tegev, tema rollil on suur osa mängida. Hea administraator, ütleks lausa Administraator, on kulda väärt. Kui on olemas inimene, kes suudab hinnata, mida erinevad vajadused tähendavad SharePointi struktuurile/arhitektuurile, samuti hoida silma peal turvalisusel, jõudlusel, varundusel,
seotud teenustel-toodetel: AD (FS), Exchange, Office, IIS, SQL ja paljudel-paljudel teistel, siis on SharePointi puhul meil juba kolmveerand võitu käes.

Hea administraator on nagu majahaldjas/piirivalvur ühes isikus, kes ühelt poolt süsteemi tõrgeteta toimimas hoiab ja teiselt poolt lööb lärmi, kui kuskilt mingi jama paistma hakkab.

Kuidas teha vahet administraatoril ja Administraatoril (tuntud ka kui “rockstar admin”)?

Üks võimalus on näiteks Microsofti sertifikaadid – ja kuigi ka näiteks 70-667 eksamist on kahtlemata palju kasu, algab Administraator siiski 70-668. Muidugi ei tee paber iseenesest midagi, aga olles pisut nende eksamitega tutvunud, läheks ma vastava serdi omanikuga luurele iga kell;) Teine võimalus – hea administraator tegeleb ennetavalt, mitte ei kustuta tulekahjusid ja heal administraatoril on plaan (vt ka Jaga ja valitse).

Mis juhtub, kui sellele rollile ei pöörata piisavalt tähelepanu ja meil ei ole tugevat administraatorit?

Keegi, tavaliselt IT-st paneb SP purgi(d) püsti. Analüütik ja arendaja mõtlevad välja loogilise strukuuri, ehitavad selle osa lahendusest, mis suudavad, vajadusel mõningaid teenuseid/seadeid sudides ning aegajalt IT-osakonda piinates (“Pange profiilide sünk tööle!”). Arendaja arendab oma asja ja paneb selle üles, vajadusel mõningaid teenused/seadeid sudides. Kui lahendus on piisavalt väike, analüütik ja arendaja teavad, mida nad teevad, suhtlevad omavahel, dokumenteerivad oma tegevusi ja ka muidu läheb kõik hästi, siis kõik töötabki. Pigem läheb aga natuke teisiti. Arendaja ja analüütik vaatavad asju oma mätta otsast, kitsalt ja teineteisest eraldi. Üldpilti ei näe keegi, jõudlus ja turvalisus on täpselt sellised, kuidas välja kukuvad. Kui midagi katki läheb, siis ei pole kellelgi aimu miks läks, kes ja kuidas parandama peaks ning millised muud osad sellest veel sõltuvad (vt ka Jaga ja valitse).

Lõppkokkuvõttes on muidugi oluline, et üleüldse oleks olemas mingigi plaan ja keegi asjadel silma peal hoiaks – hoolimata ametinimetusest.


Ringmäng ümber SharePointi

TechEdil oli põhiküsimus – kumb sa oled, arendaja või IT pro? Viimane on muidugi selline kaunilt laialivalguv mõiste, aga peamiselt mõeldakse selle all kõiki neid, kes ise tarkvara ei kirjuta, küll panevad tööle ja hoiavad töös. Minu ametinimetus on üldiselt analüütik, mis on umbes sama laialivalguv – teoreetiliselt peaks olema analüütik see, kes ainult kirjeldab ja ise midagi ei tee, aga arvestades SharePointi eripära, ma siiski aegajalt teen ka midagi. Niisiis tekkis mul küsimus, et kuidas võiks olla minu ametinimetus SharePointi mõistes ja milliseid erinevaid rolle veel olemas on.

Selgus, et vastus ei olegi nii lihtne;) Paljud allikad eristavad lihtsalt arendajat ja administraatorit, sekka ka arhitekt ja disainer – mis on peamiselt tehnilised rollid. Microsoft ise (nt sertifitseerimise mõttes) eristab kolme rolli: administraator (MCTS eksam 70-667 jne), arendaja (MCTS eksam 70-573 jne) ja lihtsalt spetsialist (MOS eksam 77-886). Erinevad allikad pakuvaid kümneid erinevaid rolle erineva liigituse alusel (SharePoint Mobile Specialist*, SharePoint Workflow Specialist, Site Collection Owner, Site Owner, SharePoint Evangelist ja palju teised alates projektijuhtidest ning koolitajatest ja lõpetades disainerite ja AD administraatoritega – SP loomaaed on kirju. Äripoolest ma parem ei räägigi). Eesti-suuruses organisatsioonis kindlasti pole kõikide rollide jaoks vaja ega leidagi eraldi inimest, aga minu arvates on 3 rolli, mis SP arenduse puhul peaksid olema kaetud. Need on:

  • SP analüütik
  • SP administraator
  • SP arendaja

Ilmselgelt üllatav jaotus, eks? Oluline on siinjuures see maagiline kahetäheline lühend kõigi rollide ees, mis muudab need rohkem või vähem erinevaks tavapärasest tarkvaraarenduse rollist. Võrdluses tavalise IT-projektiga on puudu testija, mis nüüd ei tähenda, et testijaid ei peaks olema, kindlasti peaks, aga üldiselt ei pea selleks olema eraldi SP testija.

Mis need rollid teevad? Lühidalt:

  • Analüütik teab, mida äril vaja on, mida SharePoint teha suudab ja oskab teist esimese heaks ära kasutada.
  • Administraator teab, kuidas SharePoint seda kõike tegema panna ja tegemas hoida.
  • Arendaja tegeleb sellega, mida SharePoint ise teha ei suuda.

Teoreetiliselt võib olla ka olukord, kus arendajat polegi vaja, (hea) administraator suudab lihtsamatel juhtudel täita ka analüütiku ülesandeid. Vastupidi on seis harvem. Aga täpsemalt, mis nendel vahet on? Teeme turniiritabeli ja mängime kõik kõigiga läbi:

  • Arendaja vs administraator. Teoorias on kõik lihtne – arendaja on see, kes koodi kirjutab. Aga kas PowerShelli skriptid on kood või mitte? Kas koodipaigaldused on arendaja või administraatori rolli ülesanded? Ja nii edasi ja tagasi. Hea arendaja peab mõistma SharePointi seadistusvõimalusi, vähemalt selles valdkonnas, kus ta parasjagu arendab. Hea administraator peab suutma arendajale edasi anda süsteemi omapärasid, kitsendusi ja muud sellist.
  • Analüütik vs arendaja. Esimese hooga tundub, et joon analüütiku ja arendaja vahel on üsna selge, aga lähemalt vaadates – kas ikka on? Jah, analüütik ei kirjuta koodi, aga sellest hoolimata suudab ta kokku panna väga viisaka lahenduse. Lõppkasutaja silmade läbi ei ole vahet, kes tulemuse saavutamiseks võeti vahepeal lahti Visual Studio või ei. Teatud juhtudel on olemas kasutusel isegi selline tiitel nagu No-Code Developer.
  • Administraator vs analüütik. Jah, analüütik üldiselt ei installi SharePointi, et pane teenuseid tööle, ei tegele serverite ja andmebaasidega jne, aga kui läheb asi läbi UI seadistamiseks, on analüütik vägagi platsis. Otsingu skoobid – analüütik. Kasutajaprofiilide metaandmed – analüütik. Sihtrühmad – analüütik. Edasi ongi küsimus, kui kaugele analüütik läheb. Kas näiteks keelepaki installeerimine ja kogu MUIsse puutuv on analüütiku või administraatori mängumaa? Ilmselt sõltub vastus asjaoludest, tähtsam on pigem see, et mõlemad teavad, mille eest nad vastutavad ja mille puhul peaksid teisega konsulteerima. Ühesõnaga peab see olema väga tihe koostöö.

Enda jaoks sain umbes sellise pildi:

SP rollid

Omaette küsimus on muidugi see, kes kui suure osa oma valdkonnast ära katab ja kui hästi seda teeb, aga sellest edaspidi

*Nüüd ja edaspidi: eestikeelne terminoloogia – halloo?