Archive for the 'Analüüs' Category

Apr 27 2010

Kasutajad ja spetsifitseerimine

Neljas loeng projektijuhtimisest.

Siit leiate esialgsed slaidid. Audiot sedapuhku ei olnud – ebaõnn. Võite vaadata eelmise aasta vastavat sissekannet.

Slide1_w600_h450
Ka tänane loeng on suurel määral analüüsist. Aga isegi kui te ise olete ainult projektijuht ja analüüsiga ei tegele, peaksite ikkagi teadma, mis toimub ja kuidas on õige asju teha.
Slide2_w600_h450

Slide3_w600_h450

Slide4_w600_h450

Slide5_w600_h450

Slide6_w600_h450

Slide7_w600_h450

Kes arvab, et kliendil on alati õigus?

Slide8_w600_h450

Slide9_w600_h450

Slide10_w600_h450

Slide11_w600_h450

Slide12_w600_h450
Slide13_w600_h450

Slide14_w600_h450

Olen tihti näinud spetsifikatsioone, mis on lihtsalt üks laam teksti lehekülg lehekülje järel.

Et kui juhtub A, siis kirje B peab liikuma asukohta C.

Välja arvatud juhul kui on täiskuuneljapäev, siis tuleb kirjest D lahutada 15% ja liigutada ta asukohta E

Siis tuleb meil veel liita kokku kirjed F ja G ning saata nad teise süsteemi.

Ja siis kaob kilpkonnaonu vee alla ja mullid tõusevad pinnale. Ja mullid teevad ai-tummer-ker-kommer-ker.

Ja esimese lehekülje lõpuks jäävad kõik lugejad magama.

Slide15_w600_h450
Slide16_w600_h450
Slide17_w600_h450
Slide18_w600_h450
Slide19_w600_h450
Slide20_w600_h450
Slide21_w600_h450
Slide22_w600_h450
Slide23_w600_h450
Slide24_w600_h450

1.Paneme paika mingi konkreetse eesmärgi 2.Esitame küsimuse, “kuidas me teame, kas me oleme eesmärgile jõudmas” 3.Konstrueerime vastava mõõdiku
Slide25_w600_h450

Paljude mõõdikute lähteandmed saa ajaarvestussüsteemidest.

Kunagi ma arvasin, et ajaarvestussüsteemid on kuradist, sest programmeerijaid ei tohi hinnata selle põhjal, kui palju aega nad projektile kulutavad.

Aga ajaarvestussüsteemi primaarseks eesmärgiks pole mitte see, kui palju inimene aega kulutab ja kui kaua ta kontoris istub, vaid hoopis see, millele me organisatsioonina oma ressursid kulutame.

Antud juhul oleks mõõdikuks see, et taskidel, mis on ajaarvestussüsteemis, on olemas ka vastavad väljad selle jaoks, mis sorti hooldusega on tegemist.

Slide26_w600_h450

Äärmiselt oluline tähelepanek: Neid mõõdikuid ei tohi kasutada inimeste töötulemuste hindamiseks!

Slide27_w600_h450
Slide28_w600_h450
Slide29_w600_h450
Slide30_w600_h450
Slide31_w600_h450
Slide32_w600_h450

2 responses so far

Apr 15 2010

Vajadused ja nõuded

Kolmas loeng projektijuhtimisest.

Siit leiate slaidid. Ja siit audiosalvestuse.

slide1_w600_h450
Tänane loeng on suurel määral analüüsist. Aga isegi kui te ise olete ainult projektijuht ja analüüsiga ei tegele, peaksite ikkagi teadma, mis toimub ja kuidas on õige asju teha.
slide2_w600_h450

Räägin teile kõigepealt ühe loo.

Kui ma veel ise vaene üliõpilane olin, kärutasin vahel maailmas ringi häälega. Üldiselt lahe kogemus, sest rahvas, kes hääletajaid peale võtab, on üldiselt väga kenad inimesed.

Sekka sattus muidugi ka igasuguseid imeinimesi. Oli näiteks üks tegelane, kes ise ka ei teadnud, kuidas täpselt oma sihtkohta jõuda, tema meetodiks oli lihtsalt kohalike käest juhiseid küsida. Mina ei olnud kahjuks kohalik ja eriti aidata ei osanud. Kohalikku keelt ei tundnud me ka keegi ja nii juht seletaski inimestega käte ja jalgade abil. Ise oli ta küllaltki joviaalses tujus ja valis küsimiseks ka rahvast, kelle adekvaatsus minu meelest kõvasti soovida jättis, aga kes olin mina, et teda selle eest kritiseerida, eks.

Ja nii me tiirutasime ja tiirutasime, kuni lõpuks kulus mõnekümne kilomeetri läbimiseks mitu tundi.

Sel ajal oli mul küll teine elustiil ja rohkem aega kui praegu ja viivitusest polnud väga hullu, aga mõnes teises olukorras oleks see küll harja punaseks ajanud.

 Tegelikult on meil siin ilmne analoogia tarkvarategemisega. Me võime tarkvaraprojekti ka läbi viia selliselt, et teema natuke midagi, siis küsime suvaliselt inimeselt instruktsioone, siis teeme jälle natuke, küsime mõnelt teiselt inimeselt jne. Mis te arvate, milliseid ajahinnanguid me sellise meetodi kasutamise korral saame anda?

 Või siis võime hankida endale kaardi.

slide3_w600_h450

Ma olen ise suur kaartide ja kaarditarkvara fänn, katsun alati võimalikult suurt navigeerimisvõimekust omada, kui kusagil käin või sõidan.

Tänapäeval on selleks head võimalused, veebis ja GPS seadmetes olevad kaardid ütlevad meile minuti täpsusega, kuhu me mis ajaks jõuame.

 Ja tarkvara on ka parem teha, kui meil on täpne instruktsioon ees, et nüüd teeme seda ja siis toda. Ajahinnangutest rääkimata.

slide4_w600_h450

Tegelikus elus juhtub aga, et meie tarkvara valmistamise instruktsioonid on pigem sellised. Natuke parem kui turbanis vanamehelt saadud instruktsioonid, aga mitte väga.

Ja ajahinnangud on ka muidugi vastavad.

 Tänane loeng ongi sellest, kuidas oma kaart võimalikult täpseks saada.

slide5_w600_h450

Definitsioonide erisus on peamine segaduse ja kommunikatsiooniprobleemide allikas tarkvaraprojektis.

Definitsioonid tuleb algusest peale paika panna.

slide6_w600_h450

Lugu: HR department vs arendaja nimemuutuse teemal.

slide7_w600_h450

Nõuded tegelikult omaette pikk teema, sestap siin kaetud lühidalt.

slide8_w600_h450

slide9_w600_h450

slide10_w600_h450

slide11_w600_h450

Lõpliku spetsifikatsiooni sisu on tihti tracetav tagasi ärireegliteni.
slide12_w600_h450
slide13_w600_h450
Tarkvara võib olla nt veebisait või pihuarvutite süsteem vms asi
baba-interface
slide14_w600_h450
slide15_w600_h450
slide16_w600_h450
slide17_w600_h450
Näide: tehnoloogiline kitsendus, et me tohime kasutada ainult vaba tarkvara. projekt tehti .neti peale.

slide18_w600_h450
Kui mõni neist osadest jääb alguses kirjeldamata, ei pääse me sellest ikkagi – lõpuks tuleb ta lisada ja see võib tähendada olulist projekti ümbertegemise kulu.
slide19_w600_h450
slide20_w600_h450
slide21_w600_h450
slide22_w600_h450
slide23_w600_h450
slide24_w600_h450
slide25_w600_h450
slide26_w600_h450
slide27_w600_h450
slide28_w600_h450
slide29_w600_h450
Lugu: visioon
slide30_w600_h450
slide31_w600_h450
slide32_w600_h450
slide33_w600_h450

No responses yet

Mar 07 2009

Vajadused ja nõuded

Teine osa Projektijuhtimise loengutest.

Siit leiate slaidid. Audiosalvestus: 1. osa, 2. osa, 3. osa.

2010 täiendatud loengumaterjalid:
Vajadused ja nõuded,
Kasutajad ja spetsifitseerimine.

No responses yet

Jan 24 2009

Tunne oma kasutajat II

Published by Targo under Analüüs, Kliendid

Mis te arvate, millise elualaga tavakodanikul kõige rohkem probleeme esineb? Kas ehk kasutatud autode müüjatega? Või kinnisvaraagentidega?

Ameerikas on lahe organisatsioon nimega Better Business Bureau (BBB), kuhu inimesed saavad saata igasuguseid kaebusi ettevõttete kohta ja ka uurida, kui palju mingi firma või asutuse peale kaevatud on. Muuhulgas teevad nad ka statistikat erinevate teenuste ja tööstusharude osas. Järgmine tabel on toodud 2008 sügise seisuga:

TOP COMPLAINTS

1. Cellular Telephone Service & Supplies
2. Computers Software & Services
3. Internet Shopping Services

4. Auto Dealers – New Cars
5. Internet Services
6. Travel Agencies & Bureaus
7. Collection Agencies
8. Auto Dealers – Used Cars
9. Banks
10. Auto Repair & Service
11*. Searchers of Records
11*. Real Estate Management
13. Hotels
14. Contractor – General
15. Apartments
16. Telephone Communications
17. Wholesalers & Distributors
18*. Plumbing Contractors
18*. Movers
18*. Furniture – Retail
* Indicates a tie.

Ma arvan, et enamik selle jutu lugejaist tegutseb minu poolt esiletõstetud valdkondades. Tarkvarategijad “edestavad” kaebuste hulga poolest nii autoremontijaid kui inkassofirmasid.

Milles on asi? Töötasin ise oma eelmises elus Microsoft Office SharePoint Serveri tiimis. Microsofti põhimõtteks on “eat your own dogfood” ja üldiselt kasutasime me oma tooteid nii et seda nägu. Sellegipoolest, nüüd olen liikunud laia maailma avarustesse ja päriselus SharePointi juurutades taon tihtilugu peaga vastu seina, et kuidas küll tootesse sellised narrid ebamugavused sisse on jäänud.

Ehk siis veelkord: tunne oma kasutajat, sest ta ei ole teps mitte selline nagu sina! Kui ma vaatan kontoris enda ümber ringi, keda ma näen? Peamiselt noori, introvertseid, küllaltki kõrge haridustasemega mehi. Kes on meie kasutajad? Kui mõne kliendi koridoris ringi jalutan ja IT osakonnast välja saan, näen hoopis teistsugust pilti: inimesi on nii noori kui vanu, naisi on pigem rohkem kui mehi, kõikvõimaliku tausta, hariduse ja huvidega. Neid ei huvita karvavõrdki meie toodete tehnokraatlikud aspektid, nad tahavad, et asjad lihtsalt töötaks ja seejärel oma muu elu juurde tagasi pöörduda. Täpselt nagu mind ei huvitaks oma külmkapi konfimine, ei taha nad meie tarkvaraga tegemist teha rohkem kui hädapärast vaja.

Kuidas aga teada saada, mis inimestele tegelikult ebamugavust valmistab? Minge ja külastage oma kasutajaid. Iga sellise käigu järel tunnen ma ise, nagu oleks silmadelt kae langenud ja asjad on äkitselt palju selgemad. See soovitus ei ole mitte ainult projektijuhtidele või analüütikutele, vaid eelkõige just programmeerijatele ja muule rahvale, kes tavaliselt kasutajaga kokku ei puutu. Võin kihla vedada, et mõne sellise käigu järel kasvab dramaatiliselt teie väärtus nii kliendile kui ka organisatsioonile, kus te töötate, ja tarbijakaitseorganisatsioonid hakkavad saama teie aadressil oluliselt vähem kaebusi.

One response so far

May 22 2008

Assumption is the mother of all f*ck ups

iceberg.jpg

Tarkvarafirma Joostes Marss ostis hiljuti AS HüperKonsultantidelt uue HüperGeneraatori(tm) versiooni. HüperGeneraator on kirjade järgi vahend, mis kirjutab programmeerija eest 97,4% koodist ise valmis, joonistad ainult diagrammi ette, vajutad nuppu ja voilà, rakendus ongi olemas.

Järgmises projektis otsustatigi HüperGeneraator täie hooga tegevusse rakendada. Nagu ikka, tehti pärast esialgset analüüsi valmis projekti graafik. Programmeerijad Priit ja Peeter vaatasid eeldatava mahu üle, lugesid vormid-päringud-moodulid kokku ja leidsid, et kuus kuud tööd tuleb kindlasti ära. Projektijuht Joosep polnud nõus: aga HüperKonsultantide demost oli ju näha, et need vormid, mis varem võtsid päeva, võtavad nüüd ainult pool tundi! Üle kahe kuu ei tohiks kindlasti minna! Priit ja Peeter ei osanud ka suurt midagi vastu kosta, Joosepil on uhkem ametinimetus, eks tema teab paremini.

Tippjuht Tõnis vaatas graafiku üle, imestas küll, et kas tõesti saab nii ruttu, aga eeldas, et küllap projektiga lähemalt seotud inimesed teavad paremini. Samamoodi imestas klient Kustav, aga lõpuks löödi siiski käed.

generator.jpg

Tegelikkuses selgus muidugi näiteks, et

  • HüperGeneraator genereerib koodi ainult positiivse stsenaariumi jaoks, igasuguste vigade käsitlemine tuleb hiljem juurde pookida.
  • Vormide asetusest on HüperGeneraatoril küllaltki fikseeritud arusaam ja kui Kustav leidis, et tema töötajad kõiki vajalikke andmeid korraga ei näe, tuli need ringi teha.
  • Sama päringute kohta.
  • Kui midagi oli juba valmis genereeritud ja sinna seejärel muudatusi tehtud, aga äkitselt oli vaja andmemudelit kohendada, siis uuesti genereerimine hävitas muidugi olemasolevad muutused.
  • jne. jne.

Asi lõppes muidugi sellega, et Priit ja Peeter tegid kõvasti ületunde, Joosep kutsuti mitu korda Tõnise juurde vaibale, Kustav sai omakorda ministeeriumi ülemuste käest pähe jne.

Küsimus, kas koodi genereerimine on üldse mõistlik idee, on eraldi teema (sellest millalgi tulevikus), aga praegu on huvitav tähele panna, millistele eeldustele kõik osalised oma tegevuse rajasid. Igas olukorras jaguneb otsuste alusmaterjal kaheks: info, mis tegelikult teada on, ja asjad, mida me eeldame. Olukorras, kus on tegemist millegi tundmatuga (olgu see siis tehnoloogia, teostaja, partner või klient), on teadaolev info suures vähemuses, jäämäe veealuse osa moodustavad eeldused.

Antud juhul:

  • Kõik osalised eeldasid, et HüperGeneraator on antud projekt jaoks sobiv vahend.
  • Priit ja Peeter eeldasid, et Joosepil on eelnev kogemus taoliste vahenditega.
  • Joosep eeldas, et kui programmeerijad juba uue ajagraafikuga nõus on, siis saavad nad sellega ka kindlasti hakkama.
  • Tõnis eeldas, et projektirühm on kava korralikult läbi mõelnud.
  • Kustav eeldas, et Joostes Marsil on tekkinud uued võimalused projekte senisest kiiremini täide viia.

Üks eeldus viis teiseni ja kui projekt lõpuks kümne kuu pärast (sest liiga agressiivselt planeeritud projektid võtavad vahepealse ümbertegemise tõttu veel rohkem aega) valmis sai, ei jõudnud keegi ära imestada, kuidas asjad küll nii hulluks said minna.

Joostes Marss pole teab mis hiigelfirma, aga isegi seal oli halbadel eeldustel katastroofiline tagajärg. Suurtes, paljude inimestega organisatsioonides on eeldustel kriitiline roll. Töötan praegu Microsofti Office’i divisjonis, mis koosneb kümnetest väiksematest produktidest, igaühel omakorda kümned arendajad. Kõik need produktid on omavahel tihedalt integreeritud, kui näiteks SharePoint lisab uue andmetüübi, peavad inimesed Outlooki, InfoPathi, Accessi, ECMi, Searchi ja mitmetes teistes gruppides, mis SharePointist andmeid oskavad lugeda, mõtlema, kuidas seda kõige paremini toetada. Muidugi katsutakse sama ülesande mitmekordset lahendamist vältida, aga see põhjustab enamasti situatsiooni, kus mitmed tiimid ootavad kellegi järel, et need selle ühise lahenduse valmis teeksid, teised tiimid ootavad jällegi esimeste järel jne. Sellises ahelas on rohkesti võimalusi halbadel eeldustel põhinevate otsuste tegemiseks, olgu siis tegemist tehnoloogia, ajagraafiku, inimeste võimekuse või millegi muu valesti hindamisega. Sellepärast tuleb ka panna suurt rõhku uurimisele, mis meie edu jaoks kriitilistes lõikudes tegelikult toimub ja kuidas asjad töötavad. Olulisel kohal on siinkohal näiteks täpsusküsimise ja täpsusvastamise rakendamine.

Eeldused võib jagada mitmesse kategooriasse, millest igaühe kohta saab enamasti küsida häid, täpseid küsimusi. Vaatleme näiteks HüperKonsultantide reklaamlauset:

HüperGeneraator 5.0 on parim projektide läbiviimiseks! HüperGeneraator suurendab teie koodikirjutamiskiirust sada korda!!!

Juba ainuüksi seda lauset lugedes, ilma tehnilistesse detailidesse süüvimata, peaksime mõtlema järgmistele eeldustele, mis selles reklaamis peituvad:

1. Väärtuse eeldus: koodi kiiresti valmimine on hea. Küsimus: kas koodi kiire valmimine on meie projekti juures tegelikult kõige olulisem?

2. Mõõtmise eeldus: koodi hulka ja valmimiskiirust on võimalik mingi ühe mõõdupuu järgi mõõta. Küsimus: kas me saame koodi kirjutamise kiirust mõõta? Kuidas?

3. Võimalikkuse eeldus: koodi genereerimine on alati võimalik. Küsimus: kas koodi genereerimine on alati võimalik?

4. Sihtgrupi eeldus: HüperGeneraator suurendab konkreetselt meie koodikirjutamiskiirust. Küsimus: kas meie oleme toote õigeks sihtgrupiks? Või on tegemist raamatupidajatele, kes tegelikult programmeerida ei oska, mõeldud abivahendiga?

5. Eksistentsi eeldus: meie probleemiks on, et kood ei saa piisavalt kiiresti valmis. Küsimus: kas koodi kirjutamise kiirus on probleemiks? Või võtab mõni muu tegevus hoopis rohkem aega?

6. Kategooria eeldus: Kõik projektid on sarnased ja HüperGeneraatoriga lahendatavad. Küsimus: kas erinevad projektid on võrreldavad? 

7. Samalaadsuse eeldus: meie projektid on samasugused kui teised. Küsimus: kas meie projekt on samasugune kui teised HüperGeneraatoriga lahendatud projektid?

8. Unikaalsuse eeldus: HüperGeneraator on parim vahend koodivalmimiskiiruse suurendamiseks. Küsimus: kas HüperGeneraator on ainus vahend, mida me kasutada saaksime?

9. Ajalise kestvuse eeldus: ka meie tulevased projektid on HüperGeneraatori abil lahendatavad. Küsimus (juhul kui praegune projekt on tõesti HüperGeneraatori jaoks sobilik):  aga meie järgmine ja ülejärgmine projekt?

Sarnaseid eeldusi võib leida igasugustest situatsioonidest. Tulevad näiteks misjonärid ukse taha ja küsivad: “Kas te usute, et Jumal soovib teile head ja armastab teid kogu südamest?”. Selle kohta võiks kohe mitukümmend eeldust leida, aga jäägu see heale lugejale mõtlemiseks :)

No responses yet

May 02 2008

Tunne oma kasutajat

Published by Targo under Analüüs, Kliendid, Lugejate lemmikud

customer_service.jpg

Eelmises kirjutises tuli juttu oma kasutajate mõistmise tähtsusest. Leidsin vahepeal veel rea lugusid sellest, kuidas erinevad firmad on kasutaja tundmaõppimist tõsiselt võtnud ning seeläbi huvitavaid ja innovatiivseid lahendusi tootnud.

dyson_cleaner.jpg

  • Ameerikas on praegu väga populaarsed James Dysoni leiutatud tsükloneraldusega tolmuimejad. Jättes kõrvale asjaolu, et tegemist on tehnilise uuendusega, mis tolmuimemist efektiivsemaks muudab, võime küsida, miks selle tolmuimeja kate just läbipaistev peab olema? Kas selleks, et näha, kui palju seal tolmu sees on? Tegelikult meeldib paljudele inimestele alateadlikult näha, kuidas praht tolmuimejas ringi käib ja seeläbi “tappa saab”. Katsugu ta veel tulla silmailu rikkuma! :) Inimesed ei saa sellest enamasti ise arugi, aga neile meeldib Dysoni tolmuimejaga koristamine millegipärast rohkem kui teistega.

jogger.jpg

  • Kõik teavad, et tervisejooks on kasulik, aga sellegipoolest ei tule jätku enamikul inimestest püsivust sellega tegelemiseks. Kuidas asja parandada? Jooksmisest tulenev kasu on pikaajaline protsess, raja lõpus pole enamasti mingit kohest rahuldust. Kuidas aga kohe jooksjale mingi preemia anda? Nike ja Apple tulid kahe peale välja tootega, mis ühelt poolt ergutab sind jooksmise ajal ning teiselt poolt laseb enda tulemusi teiste omadega võrrelda. Ja kas saab olla suuremat rahuldust, kui näha, kuidas sa teiste inimestega võrreldes arened? Pole siis imestada, et Nike Plus on hea äri.

 elderly_driver.jpg

  • Et paremini mõista vanema põlvkonna autojuhte, leiutas Nissan spetsiaalse ülikonna, mis takistab teatud liigutusi, et mõista, milline on auto ergonoomika vanemate inimeste seisukohalt. Sarnased ülikonnad on olemas ka selleks, et simuleerida näiteks rasedat naist või muid iseärasusi.  

Tarkvara seisukohalt võime siin mõelda: enamikus IT-firmades on olemas infrastruktuur ja tööriistad (alates kiirest internetiühendusest arendusvahenditeni), mis meie jaoks IT lihtsaks ja mugavaks teevad. Enamikul meie kasutajatest seda aga pole ja me peaksime iga valminud tarkvaratoodet vaatama eelkõige nende inimeste seisukohalt, kellel on väiksemad võimalused. Näiteks kas meie vormid mahuvad ka väiksema kui 21″ ekraani peale ära? Kas meie andmehulgad on edastatavad ka vähema kui 1Gbit kohtvõrgu kaudu? Kas meie rakendused jooksevad ka alla 2GB mäluga?

autobahn.jpg

  • Autoteema teisest äärmusest leiame näite, kuidas Honda saatis Honda Legendi disainerid ja insenerid 6 kuuks Saksamaale, et nad uuriksid, mis tunne on reaalselt autobahnil kihutada ja mida ühel autol selle jaoks vaja läheks, Jaapanis sellist võimalust polnud.
  • Paljud lahendused tulevad pähe lihtsalt inimeste igapäevaelu vaadeldes. Nii on leiutatud näiteks kohvikruusihoidjaga pesumasin, väike külmkapp ühikatubade jaoks, mille pealne on lahtivolditav väikeseks lauaks jne. Minu lemmikuks on siin Whirlpool Gladiator GarageWorks ja spetsiaalne garaažikülmkapp, juba ammu ei hoita garaažis ainult autosid, vaid sellest on saanud paljude meeste elu- ja hobikeskus, mille jaoks on kohandatud terve hulk kodutehnikat.

 big_bazaar.jpg

  • Kes on Aasias reisinud, teab, et suur osa sealsest jaekaubandusest toimub kaootilistel avaturgudel. Kui Kishore Biyani Indias Pantalooni supermarketite keti asutas, olid tema poed alguses samasugused nagu nende lääne ekvivalendid, korrapäraselt seatud riiulite ja sirgete vahekäikudega. Hoolimata sellest, et poed olid ilusad, puhtad ja odavad, ei tulnud inimesed sinna, sest selline kauplemisviis polnud neile omane. Ei aidanud muu, kui imiteerida traditsioonilisi turge, praegu on Pantalooni poed ebakorrapärased, kaubad vedelevad näiliselt juhuslikult, asjade üle on võimalik tingida, aga rahvast käib seal nagu murdu.

iridium.jpg

  • Oluline on aga, et me annaks endale aru, kas tegemist on vaid ühe kasutaja iseärasusega või laiema suunaga. Tihti saavad suured projektid alguse kellegi kinnisideest, mis tegelikult aga kedagi ei huvita, üheks suurimaks ja kallimaks näiteks siinkohal on Iridiumi satelliidid. Algse idee kohaselt pidi olema tegemist tootega “mobiilsele ettevõttejuhile”, kes kogu aeg maailmas ringi rändab. Ärimehed ei tahtnud aga suurt, kallist ja kobakat satelliittelefoni, pärast 5 miljardi dollari kulutamist saadi poole aastaga vaid 10000 kasutajat ning Iridium läks vähem kui aasta pärast pankrotti. Praeguseks on Iridiumi võrk siiski kasutuse leidnud, aga hoopis avamerepurjetajate ja muude rändurite seas.

  medical.jpg

  • Teise näite sellest, kuidas me ei saa aru, kes meie klient tegelikult on, leiame meditsiinist. Meditsiiniskännerid on tõeline tehnikaime, näidates 3D pilti kõigest, mis inimese kehas toimub. Aparatuuri tootjad rääkisid arstidega, milliseid võimalusi viimastel vaja läheks ja said pika nimekirja. Kui aga masinad valmis tehti, selgus, et nende kasutusaeg hoopis langes. Milles asi? Selgus, et päriselt ei kasuta masinaid mitte arstid, vaid laborandid, kellele arst lihtsalt ütleb, et teha seda või toda. Ja kuna uuel masinal oli liiga palju nuppe ja vidinaid, millest laborandid aru ei saanud, jäid ka uued võimalused unarusse.

See on tegelikult tarkvaramaailmas igapäevaselt toimiv efekt. Inimene, kes meilt toote tellib, ei ole tihti teps mitte seesama, kes seda lõpuks kasutama hakkab!

mac_portable.jpg

  • Kui Apple oma esimese sülearvuti lõi, oli firmal juba tugev kogemus lauaarvutitega, ja juba tollal pandi Apple’is suurt rõhku disaini perfektsusele. Mac Portable oligi perfektne… lauaarvuti seisukohalt. Tüüpiliseks näiteks on, et Portable’i aku pidas vastu üle 10 tunni (!), mis tegi arvuti palju suuremaks ja raskemaks kui konkureerivad tooted, aga näitab hästi, et tegijatel polnud täpset aimu, mis elu sülearvutikasutaja elab.

hud1.jpg

  • Veel näide meditsiinitehnikast: Laparoskoopia on kirurgia haru, kus inimese sisse torgatakse fiiberoptiline kaabel ning ning kirurg vaatab ekraanilt, mis sul sees toimub. Katsetusel süsteemi testides toimis kõik hästi. Kui aga millalgi tegelikku operatsioonisaali mindi, leiti, et ruum on abistajaid täis ja kirurg peab kogu aeg üle nende küünitama, et ekraani näha. Lahenduseks oli heads-up display, spetsiaalsed prillid, millelt pilti saab vaadata, aga ilma kasutajat tema loomulikus keskkonnas jälgimata poleks tehnoloogid iial selle mõtte peale tulnud.

64 responses so far

Apr 25 2008

Kliendiempaatia

Published by Targo under Analüüs, Kliendid, Lugejate lemmikud

psychic.jpg 

Enamik maailma tarkvaraarendajaid arvab, et nad on kliendikesksed ja teevad kõik, et kliendi soovidega arvestada. Kuidas on siis võimalik, et maailmas on nii palju inimesi, kes oma tarkvaraga raasugi rahul pole?

Selgub, et tegelikult jääb enamikul ettevõtetest tõelisest kliendikesksusest kõvasti puudu.

Mida tähendab olla kliendikeskne? Eelkõige tugevat empaatiat. Kui me ei saa aru, miks klient midagi teeb, arvab või mõtleb, pole tegelik kliendikesksus võimalik.

Näiteid sellest, kuidas erinevad ettevõtted on minu isiklikus kogemuses empaatiat üles näidanud:

harmony.jpg

  • Enne, kui Google internetiotsimootorite turule sisenes, peeti loomulikuks, et kasutaja peab otsimootori poolt tagastatud tulemusi veel käsitsi läbi sõeluma, et leida, mida tal tegelikult vaja on. AltaVistaga oli tavaline, et tegelikult vajalik link oli kusagil viiendal-kuuendal leheküljel. Miks pean mina sellist käsitööd tegema? Google’i innovatsioon eemaldas olulise ärritaja minu internetikasutuselamusest.
  • Üldiselt ma vihkan lennukiga lendamist, alates turvakontrolli absurdsusest kuni selleni, et mul surevad lennukis alati jalad ära. Lastega koos reisides on aga üks minu seisukohalt kena erand, see on SAS. Kui teistel lennufirmadel lastakse lennukisse kõigepealt äriklass ja siis muu rahvas istmeridade järjekorras, siis SAS laseb kõigepealt peale väikeste lastega reisijad. Samuti jagavad nad lennu ajal lastele vanusekohaseid mänguasju, mis ei maksa ilmselt suurt midagi, aga uus mänguasi teeb lastel alati tuju heaks. Asjaolu, et nad suudavad mõista lastega reisija spetsiifilist olukorda, näitab head empaatiat ja ma valin Ameerika ja Euroopa vahel lennates peaaegu alati SASi kui võimalik.
  • Nagu paljudel teistelgi inimestel, on mul koju kogunenud hulk pultidega elektroonikavärke, neid pulte on paras hunnik, mõnede operatsioonide jaoks (et näiteks telekas+võimendi XBoxilt kaabel-TV peale ümber lülitada) on vaja kolme erinevat pulti, millest on alati mõni kadunud. Mitmed tootjad pakuvad nn universaalpulte, millel aga alati 10% funktsionaalsusest puudu jääb ja ikka originaalset pulti vaja läheb. Sealt järgmine tase on lihtsad programmeeritavad puldid, mis on kenad, aga paistab, et insenerid, kes need välja on mõelnud, pole neid kunagi kasutada proovinud, sest kui minul professionaalse programmeerijana kulub alati pool tundi manuaali sirvimist, et nuppe ja makrosid õigeks timmida, pole lihtkasutajal vähimatki lootust. Vidin, mis lõpuks hädast välja aitas, on Logitech Harmony pult, kus iga liigutus on tõesti korralikult läbi mõeldud ja intuitiivne, jällegi märk, et loojad on võtnud vaevaks kasutaja harjumusi korralikult ja põhjalikult tundma õppida.

Tarkvara alal on olukord tegelikult iseäranis hull, programmeerija elab kliendiga võrreldes tihti omaette maailmas ja lükkab oma loodu lihtsalt avalikkuse ette, kusjuures mõlemad osalised jäävad teineteise jaoks anonüümseks. Tegelik kasutajakesksus tuleb kõne alla aga vaid siis, kui me mõistame klienti palju sügavamal tasemel, kui üksnes tellimusse kirjapandut üks-üheselt koodisse ümber vorpides. Kui lasta kliendil vabalt igasugustest asjadest rääkida, saame tihti teada, mida ta tegelikult hindab ja mis tema elu palju lihtsamaks võiks muuta.

Enamik Eestis toodetavast tarkvarast tehakse konkreetsetele klientidele ja seega on seal küllaltki palju võimalust isiklikuks, individuaalseks lähenemiseks, iseasi on, kui palju seda ära kasutatakse.

Võtmetähendusega viga, mis enamasti tehakse, on see, et palju lihtsam on leida vigu teiste inimeste kaupades ja teenustes. Mina võin leida sada häda näiteks lennukiga lendamise juures, aga kui lennufirma inimesed kaebavad, et tarkvara on jama, õiendame me vastu, et mida kuradit teie ka tarkvarast teate.

child.jpg

  • Esimene lugu: Juba viieaastane laps teab, et isaga tuleb käituda natuke teistmoodi kui emaga, et oma tahtmist saada. Polegi oluline, milline see erinevus just on, aga lapsed tabavad selle kohe ära, sest neil on loomupärane avatus, uudishimu ja empaatia ja nad kasutavad seda ära, et kummalegi poolele meele järele olla. Kuna enamik lapsevanemaid oma lapsi väga kõrgelt hindavad, leiame me siit ideaalse kliendisuhte mudeli :) Kui me oma kliendi tundeid sama hästi ära tabaksime, kui väike laps seda teeb, ei läheks nad iialgi konkureeriva firma poole üle.

Erinevate äride edulugudest leiame mitmeid näiteid, kuidas inimeste tunnetest arusaamist edukalt on ära kasutatud.

Näide: üldiselt teevad inimesed arenenud maades järjest vähem ise süüa ja käivad pigem väljas ning ostavad valmistoitu. Sellele fenomenile on leitud palju põhjendusi nagu:

  • Inimesed on laisad ega viitsi kokandusele aega kulutada!
  • Nad on kiirtoiduga ära hellitatud ega hinda enam tavalisi toite!
  • Neil puuduvad traditsioonilised kultuuriväärtused, mis väärtustavad perekonda, kodust elu ja toidutegemist!

Süvitsi asja uurides leiti aga, et tegelikult on asi selles, et inimesed ei tea päris hästi, kuidas süüa teha ja kardavad ebaõnnestumist. Kodumasinate tootjad keskenduvad tänapäeval eelkõige sellele, kuidas teha toidutegemine võimalikult lollikindlaks. Näiteks teab kogenud kokk täpselt, millal on rasv pannil just täpselt õige kuumusega, sest ta säriseb sel hetkel kindlal iseloomulikul viisil. Selline kokk võib õpetada mind palju tahes, ilma suure harjutamise ja paljude ebaõnnestumisteta ei suuda ma seda ikka järele teha. Kuni Tefal leiutas panni, mille keskel on punane täpp, mis vastava kuumuse juures helendama hakkab.

Või siis teine kokk, kes teab kohe peale vaadates, kas riis on piidavalt kaua keenud. Zojirushi leiutas riisikeetja, mis väidetavalt parima kokaga samatäpselt õigesti keedab. Muuseas, ei olegi nii väga oluline, kas sellised tooted tegelikult toidu paremaks teevad, aga nad on märkimisväärsed selle poolest, et aitavad inimesel oma hirmust üle saada,  ning on seetõttu väga populaarsed.

cement.jpg

  • Teine lugu: Cemex on suur tsemenditootja Mehhikos. Palju inimesed, kellel vaja oli ehitada, kurtsid aga, et tsement on liiga kallis. Lihtne lahendus oleks muidugi olnud hinda langetada, siis oleks aga langusega kaasa läinud ka kõik teised tootjad ning hinnasõda oleks lihtsalt firma kasumi ära söönud. Selle asemel uuris Cemex, millist elu need inimesed elavad? Selgus, et paljud neist töötavad tegelikult USAs ja saadavad raha koju, mille eest siis kodused ehitavad. Suur hulk raha läheb aga kaduma erinevate vahendajate tõttu. Lahendus? Cemex asutas Construmexi, rahavahendusteenuse, millega inimesed said saata raha otse Cemexi poolt sertifitseeritud ja garanteeritud ehitajaile, ilma et vahendajad või kahtlasema väärtusega ehitusmehed suuremat osa sellest pihta oleks pannud. Inimesed olid väga rahul, sest said oma asjad odavamalt ehitatud, kuigi tsemendi hind jäi endiseks.

Eesmärgiks on, et me saaksime aru kliendi probleemidest, millest tal endal ehk üldse aimugi pole ja käituksime nagu selgeltnägijad :) Pilt artikli alguses illustreerib seda ideaali: lahendada probleem enne, kui klient sellest arugi saab!

baggage.jpg

  • Kolmas lugu: Üks põhjus, miks lendamine on nii ebameeldiv, on sekeldamine pagasiga. Perega reisides on kohvreid üksjagu ning nende tarimine ühest punktist teise võtab tihti ära kogu rõõmu, mille me muidu uute paikade uudistamise esmamuljest saaksime. Enamikul lennufirmadel on ükskõik, mis reisijast saab, kui ta lennuki pealt maha on läinud. Disney aga lahendas olukorra elegantselt, pakkudes tasuta teenust, mis inimeste pagasi kohe lennuki pealt hotelli viib, et nad ei peaks sabades seisma ja muidu kannatama. Virgin Atlantic läheb veel kaugemale: nad tulevad sulle sinu lähtekohta autoga järele ja viivad pärast sihtkohta ära, ilma et ise peaks üldse millegagi vaeva nägema. Peale selle saab inimene Atlanticu lennul süüa, millal ise tahab, ja mitmesuguseid muid mõnususi. Kuna nad inimese kõigi murede eest sel viisil hoolt kannavad, võib Virgin Atlantic endale lubada ka priske marginaaliga hinnasilti: lend võib maksta kuni 12 tuhat dollarit.

Oluline tähelepanek nende lugude juures on, et inimene ei osta mitte tsementi, vaid ilusa maja ehitamise ja selles elamise kogemust. Ta ei osta mitte lennupiletit, vaid lihtsalt ja mõnusalt ühest kohast teise saamise teenust. Sama kehtib ka tarkvara puhul! Kui me saame tarkvara eest raha kätte, aga klient seda reaalselt kasutama ei hakka, ei ole meie äri tegelikult õnnestunud. Kui me suudame kliendile pakkuda tervikliku kogemuse, on ta meiega palju rohkem rahul ja meil tekivad võimalused talle müüa ka mitmesuguseid muid huvitavaid ning mõlemapoolselt kasulikke teenuseid.

One response so far

Apr 14 2008

Kas klient teab, mida ta tahab?

Published by Targo under Analüüs, Kliendid

customer_wants.jpg

Kui tihti me oleme kuulnud itimeeste kurtmist, et klient on loll ja ei tea, mida ta õieti tahab? Kuidas sellega tegelikult asjad on?

 waitress.jpgpsychologist.gif

Programmeerija ideaal oleks muidugi klient, kes saadab täpse spetsifikatsiooni, kus kõik on viimse pulgani ära kirjeldatud, ja on pärast tulemusega ilusti rahul, mitte ei virise, et tahtis tegelikult midagi muud. Kui me saaks vaid olla rollis, kus me küsime, mida vaja, kirjutame tellimuse üles ja toome kohale. Sellist asja võib teha aga ka miinimumpalgaga ettekandja kohvikus! Kõrgelt haritud ja tasustatud spetsialistilt aga peakski ootama enamat, kliendiga suhtlemisel peame me olema palju rohkem psühholoogi kui ettekandja rollis, et aru saada, mis on kliendi tegelikud probleemid ja väärtused.

Näiteid ettekandja-tüüpi küsimustest, mida kliendilt tihti küsitakse, aga mis tegelikult tihti eksiteele viivad:

  • Mida te produktilt ootate?
  • Mida me peaks teisiti tegema?
  • Mis vajadused teil tulevikus saavad olema?
  • Mis hinda te maksaks, kui me teeme, mida te tahate?

Need küsimused annavad tavaliselt järgmisi tulemusi:

  • Kliendid ei suuda (vahel ka ei soovi) oma tegelikke vajadusi sõnadesse panna
  • Nad jätavad arvestamata lahendused, mida nad ei tunne, sest nad lihtsalt ei tea, millised tehnoloogiad on olemas
  • Nad küsivad lihtsalt featuure, mis teistel süsteemidel olemas on, mõtlemata, kas neid tegelikult vaja läheb
  • Nad keskenduvad konkreetsete probleemide lahendamisele, mitte üldisele tulemusele

 mechanical_horse.jpg

Kui Karl Benz oleks inimestelt selliseid küsimusi küsinud, oleks nad vastanud, et “areta meile kiirem hobune”! Tema aga võttis kätte ja leiutas hoopis auto, sest teadis, et inimeste tegelik probleem pole mitte hobustes, vaid selles, et nad soovivad kiiremini ühest kohast teise jõuda.

 787.jpg

Või näide tänapäevast: kui Boeing küsiks minult, millise uue lennuki nad peaksid konstrueerima, teeks ma lolli nägu ja ütleks: “suure?” Kui nad aga küsivad, mida ma lendamisest arvan, oskaks ma kohe tuua hulga arvamusi hinnast, kiirusest, mugavusest jne. Õnneks küsiski Boeing inimestelt just nimelt seda, mis neile lendamise juures oluline on, ja tulemuseks on lennuk, mis on tehtud peamiselt plastikust, väidetavalt palju odavam osta ja ülal pidada. Mina ei tea lennukimaterjalidest suurt midagi ja poleks sellise lahenduse peale kunagi tulnud, aga sellegipoolest eeldame me tihti, et meie kliendid meile just nimelt ütleks, kuidas me oma lennuki peame ehitama.

Näiteid sügavamatest küsimustest, mis meil palju paremini aitavad klienti mõista:

  • Milline teie igapäevane töökogemus on?
  • Mis teid kõige rohkem häirib? Kõige rohkem meeldib? Kas teil on mõni kogemus, mille sarnased te tahaks, et me oleksime?
  • Mida te oma elus/töös saavutada püüate?
  • Mis teeb produkti teie elu/töö jaoks väärtuslikuks?
  • Kes teile teie elus/töös kõige paremat nõu või ideid annab?
  • Milliseid muutusi te olete hiljuti teinud, et oma elus/töös midagi parandada ja miks?

Selliste küsimuste küsimine avab meile tihti täiesti ootamatud (aga äriliselt väga kasulikud) võimalused olemasolevate toodete parandamiseks või uute loomiseks, mille peale me varem poleks tulnudki.

vodafone.jpg

  • Näide: mobiiltelefonide plahvatuslikust levikust viimasel kümnendil hoolimata pole paljudel, eriti vanematel inimestel endiselt mobiili. Selle asemel, et neilt küsida: “kuidas te ilma mobiilita elatud saate? Millist mobiili teil vaja oleks?” küsisid Vodafone’i inimesed neilt: “kuidas te inimestega suhtlete?” Tulemuseks oli Vodafone Simply, lihtne telefon, mis meenutab disaini poolest tavalist juhtmeta telefoni, millega inimesed harjunud on, sellel on kergesti loetav ekraan, igasuguste ikoonide ja pulkade asemel on selgelt välja kirjutatud, kas levi on hea või halb, ja millel puuduvad igasugused segadusse ajavad kellad ja viled.

Seega on väga oluline oma klienti tema igapäevaelus jälgida. Kas tegemist on inimesega, kelle motoks on “ei mingit raiskamist!” või “igaks olukorraks tuleb valmis olla!”? Üht tüüpi inimesele meeldib hoopis erinev kasutajaliides kui teisele.

 tv.jpg

  • Veel üks näide: tädi Maali läheb poodi ja tahab telekat osta. Snoob müügimees küsib, kas ta tahab 4:3 või 16:9 aspektiga telekat ja tädi Maali põgeneb ehmunult. Kui temalt aga küsida, mida ja kus ta tavaliselt vaatab, kas talle meeldib, kui telekas on laia ekraaniga nagu kinos, läheb äri arvatavasti palju paremini, müügimees saab head komisjonitasu, ostab naisele lilli ja kõik on õnnelikud.

Kokkuvõtteks, klient teab tegelikult küllaltki hästi, mida ta tahab, tuleb ainult õigeid küsimusi küsida.

One response so far

Mar 30 2008

Täpsusvastamine

Published by Targo under Analüüs, Juhtimine

 target.jpg

Eelnevalt käsitletud täpsusküsitlemise teema lõpuks ka natuke juttu vastamisest. Ka kõige konkreetsem, täpsem ja asja tuumani tungivam küsimus pole suurt midagi väärt, kui sellele vastata pikalt, laialivalguvalt ja mitteasjassepuutuvalt.

Hoiatuseks muidugi, et jutt käib endiselt tööalastest vestlustest, kus tuleb mingit konkreetset probleemi lahendada. Kodus naisega rääkides pole selline kõneviis ilmselt kuigi edukas :) Igapäevaelus on küllaltki tavaline, et küsimusele ei vastata otse või välditakse vastamist üleüldse. Kui näiteks pärast kinoskäiku küsida, kuidas film meeldis, vastatakse sellele tihti hoopis kommentaaridega sellest, kui palju kinos rahvast oli ja kuidas paks mammi näris kõrvalistmel kogu aeg popkorni.

Kui meil on vaja ärilisi otsuseid teha, olukorrast ülevaadet saada või probleemi uurida, on abiks aga kolm reeglit:

1. Vasta küsimusele

captain_answer.jpg

Näide.
Küsimus: kas me oleme graafikus?
Vastus: me seadsime projekti alguses pingelised tähtajad ega oodanud partnerite poolset viivitust. Samuti unustasime me pühadeperioodi graafikusse lisada.

Selle asemel, et küsimusele vastata, hakkas vastaja pajatama lugulaulu graafiku saamisloost, mis pole üldjuhul antud punktis üldse oluline. Parem variant oleks:

Küsimus: kas me oleme graafikus?
Vastus: Ei, me oleme kaks nädalat maas.

Me saame vestlusega edasi liikuda ega pea olulisi infokillukesi õngitsema ja filtreerima.

2. Alusta vastuse tuumast

kernel.jpg

Enne pikema selgituse andmist on hea vastuse põhiolemus edasi anda, et vastaspool ei peaks pinevalt mõtlema selle üle, kuidas sinu jutust olulist tabada ja saaks keskenduda lihtsalt info vastuvõtmisele.

Näiteid headest tuumvastustest:

  • Jah
  • Ei
  • <Mingi arv>
  • <Mingi tähtaeg>
  • Ühelauseline vastus
  • Bullet pointid (lühidalt)
  • Ei tea (selle asemel, et pika ja ähmase jutuga seda peita)

3. Anna vajalik lisainfo, aga lühidalt

info.gif

Siin on abiks tähele panna, et kui küsija on see, kes peab otsuse langetama, aitavad teda kõige rohkem konkreetset ja täpsed vastused. Kui tal on vaja rohkem teada, küsib ta juba ise edasi (eeldusel muidugi, et tegemist on inimesega, kes oskab küsida).

Lisaks eelpooltoodule saab vastaja kasutada muidugi ka teisi võtteid:

- Selgitamine.
Küsimus: Mis on praegu kõige tähtsam asi, millega sa tegeled?
Vastus: Kas kõige tähtsam kliendi või ajagraafiku seisukohalt? (selle asemel, et mõlemat varianti lahti seletada)

- Ümbersuunamine.
Küsimus: Kuivõrd see projekt meie kasumit suurendab?
Vastus: Ei suurendagi. Eesmärk on kvaliteedi tõstmine.

- Riskikontroll.
Kui paistab, et eelnevate küsimustega on midagi olulist vahele jäänud, võib kumbki pool küsida midagi üldist stiilis:
Küsija: Kas on veel midagi, mida ma graafikust mahajäämise kohta peaksin teadma?
või
Vastaja: Riskianalüüs on muutnud, kas ma saaks selgitada, enne kui me teemat vahetame?

One response so far

Mar 24 2008

70 küsimust

Published by Targo under Analüüs, Juhtimine, Kliendid

question.jpg

Eelmises postituses sai mainitud, et iga sisuka lause kohta on võimalik küsida 70 erinevat küsimust, mis kõik annavad lisainformatsioonikillukesi, mille põhjal on palju prem mitmesuguseid otsuseid vastu võtta.

Selline lähenemine on osa täpsusküsitlemise (Precision Questioning) metoodikast, kus vestlust suunatakse lühikeste konkreetsete küsimuste ja vastustega. Erinevalt tavalisest diskussioonist, kus vastaja kontrollib, kui palju ja millist infot edastada, kontrollib vestlust küsitleja. Lühikesed küsimused/vastused:

  • Võimaldavad vastajal probleemi paremini läbi mõelda
  • Lasevad küsijal probleemi samm-sammult uurida
  • Ei ujuta küsijat liigse infoga üle
  • Lasevad küsijal esitada lisaküsimusi

Vaatleme nüüd järgmist näidet: projektijuht Joosep tormab sisse ja edastab klient Kustavilt järgmise hädasõnumi: “Süsteem ei skaleeru ja kukub kogu aeg kokku!!!
Milliseid küsimusi oleks meil täpse tegevuskava koostamiseks võimalik küsida? Hea lugeja võib paberile kirja panna, mitu küsimust ta kokku saab :)  

NB: Oluline on vahet teha täpsetel ja ebatäpsetel küsimustel. Täpsed küsimused hoiavad vestlust laiali valgumast, allpool on näiteid nii täpsetest kui ka ebatäpsetest küsimustest.

PQ metoodikas jagatakse küsimused seitsmesse kategooriasse, hea küsitleja leiab vähemalt 10 küsimust igast kategooriast.

decision.jpg

1. Metaküsimused (kas probleem on uurimist väärt?)

Näiteid ebatäpsetest küsimustest:
1. Kes me peame sellest praegu rääkima? (Joosepi arvates kindlasti peame)
2. Kellele see korda läheb? (Joosepile ilmselgelt läheb)

Näiteid täpsetest küsimustest:
1. Mida me tahame kohe praegu selle vestlusega saavutada?
2. Kui kiire selle probleemiga on?
3. Kui tähtis see muude probleemide kõrval on?
4. Kui palju aega me saame selle arutamisele kulutada?
5. Kas mina olen õige inimene sellega tegelemiseks?
6. Kelle me veel peaksime siia kutsuma, et asja arutada?
7. Kelle probleemi me katsume lahendada? (Kustavi? Joosepi? Minu?)
(Teiste kategooriate küsimuste vahepeal)
8. Kas me keskendume õigele probleemile?
9. Kas meil on vaja vahepeal järele mõelda?
10. Kas me läheneme probleemi tuumale?

clarification.gif

2. Selgitavad küsimused

Näiteid ebatäpsetest küsimustest:
1. Mismõttes? (laialivalguv)
2. Mida tähendab “kukub kokku”? (avab ukse pikale seletusele, mis väljub üks küsimus/üks vastus raamidest)

Näiteid täpsetest küsimustest:
1. Kas skaleerumise all on mõeldud horisontaalset või vertikaalset skaleerumist?
2. Kas kokkukukkumise all on mõeldud crashi, hangumist, aeglast reageerimist või midagi muud? (valikvastustega küsimused on üldjuhul paremad avatud küsimustest)
3. Millal see juhtus?
4. Kus see juhtus?
5. Kui tihti see juhtub?
6. Mis on trend?
7. Kui kaua probleem on kestnud?
8. Millist versiooni nad kasutavad?
9. Mis on kasutatavate masinate parameetrid?
10. Joonista graafik, kus on näidatud jõudluse sõltuvus mõjuritest (eeldab, et me oleme põhjuste kategooriast juba ühtteist küsinud)

assumption.jpg

3. Küsimused eelduste kohta

Eeldus tähendab antud kontekstis midagi, mille tõesus on vajalik selleks, et esialgne väide oleks tõene.

Näiteid:
1. Kas tegemist on viimase, meie poolt toetatava versiooniga? (oluline eeldus, mille ignoreerimine tihti palju aega kulutab)
2. Kas süsteemi kasutatakse sihtotstarbeliselt?
3. Kas probleem on tegelikult meie süsteemis või sellest väljaspool?
4. Kas nende mõistes skaleeruvus on tegelikult mõõdetav?
5. Kas skaleeruvus sellest punktist edasi on oluline?
6. Kas tegemist on ühe konkreetse probleemi või mitme kokkusegatud probleemiga?
7. Kui põhjuseid on mitu, siis kui palju neid on?
8. Kas nende probleemide (või põhjuste) koos vaatlemine omab mõtet?
9. Kas kliendi definitsioon skaleerumisest/kokkukukkumisest on sama, mis meie oma?
10. Milline on nende definitsioon?

critical_thinking.jpg

4. Kriitilised küsimused

Kriitilise küsimuse eesmärk on teada saada, “kuidas me teame, et info on õige” (sest paljudes olukordades, näiteks situatsioonis, kus keegi meile midagi müüa proovib, ei pruugi see nii olla). Antud näitelause puhul tundub ehk, et me pinnime Kustavit liiga palju ja usaldusliku suhte puhul pole kõiki neid küsimusi vaja küsida, aga kindlasti leiab situatsioone, kus kõik need näited marjaks ära kuluvad.

Näiteid ebatäpsetest küsimustest:
1. On see tõesti nii?
2. Kust sa tead?
3. Miks sa nii arvad?

Näiteid täpsetest küsimustest:
1. Kas kliendi kirjeldatud olukord on tegelikult võimalik? (tegu võib olla moonutatud infoga)
2. Kas olukord on tegelikult spetsifitseeritud parameetritest väljas?
3. Millised andmed neil on?
4. Kes neid andmeid kogus?
5. Kas inimene, kes neid kogus, on meie silmis usaldusväärne (või on tegemist karjapoisiga, kes viiendat korda hunti hüüab?)
6. Kas andmed on statistiliselt pädevad?
7. Kas tegemist on kvalitatiivselt või kvantitatiivselt mõõdetud andmetega?
8. Kas see lähenemine (kvalitatiivne vs. kvantitatiivne) on antud kontekstis korrektne?
9. Kes oli isik, kes Joosepile teate edastas?
10. Miks me peame sellele probleemile reageerima?

cause.jpg

5. Küsimused põhjuste kohta

Näiteid ebatäpsetest küsimustest:
1. Mis selle põhjustas?
2. Miks see juhtus?

Näiteid täpsetest küsimustest:
1. Mis oli vahetult “kokkukukkumisele” eelnev sündmus?
2. Millised muud tegurid peavad mängus olema, et eelnenud sündmus mõju avaldaks?
3. Millised faktorid süsteemi mõjutavad (kasutajate arv, kirjete arv, kirjete suurus, võrgu kiirus, võrgutopoloogia, arvutite parameetrid jne)?
4. Millised neist faktoritest soodustavad probleemi esiletulekut?
5. Millised aitavad probleemi vältida?
6. Milline on seos nende faktorite esinemise vahel (korrelatsioon, juhus)?
7. Kas nende faktorite mõju on lineaarne? Polünomiaalne? Eksponentsiaalne?
8. Millised on süsteemis ilmnevad tagasisidetsüklid?
9. Kas me peame uurima mõjufaktoreid omakorda mõjutavaid faktoreid (kaudseid tingimusi)?
10. Kas me peame uurima faktoreid muudest kategooriatest (peale tehniliste näiteks kasutajate harjumused)?

effect.jpg

6. Küsimused tagajärgede kohta

Näiteid ebatäpsetest küsimustest:
1. Mis selle tagajärjed on?
2. Ja edasi?

Näiteid täpsetest küsimustest:
1. Milline on mõju süsteemile endale (jääb pärast “kokkukukkumist” ebastabiilseks, stabiliseerub)?
2. Milline on mõju andmetele (kas midagi läheb kaduma)?
3. Kui paljusid kasutajaid see mõjutab?
4. Kui kaua süsteemi taastumine võtab?
5. Millised on muud kõrvalmõjud?
6. Mis on “kokkukukkumise” halvimad võimalikud tagajärjed?
7. Mis on vähim halvad võimalikud tagajärjed?
8. Millised eelpool uuritud tagajärgedest on tavalised (vs. harvaesinevad)?
9. Kas süsteem on mittelineaarne (s.t tagajärjed mõjutavad põhjuseid ja tekitavad võimenduva tagasisidetsükli)? Hoiatav lugu: tegelesin kord veebiserveriga, kus iga timeout’i puhul saadeti kusagile vearaport. Saatmine nõudis aga lisaressursse ja suurendas timeout’ide tõenäosust, mis omakorda põhjustas lisaraportide saatmist jne, kuni ajutisest probleemist sai crash.
10. Milline on mõju meie ärisuhtele?

action.jpg

7. Tegevuskava alased küsimused

Näiteid ebatäpsetest küsimustest:
1. Mida peaks tegema?
2. Kuidas vastata?

Näiteid täpsetest küsimustest:
1. Mida peaksin mina isiklikult tegema?
2. Mida peaks programmeerija Priit tegema (eeldusel, et me oleme kindlaks teinud, et Priit on õige inimene probleemiga tegelema)?
3. Kelle abi Priidul vaja läheb?
4. Millal me selle valmis saaks?
5. Kas me saame Kustavile vastava lubaduse anda?
6. Millised on vahe-eesmärgid (kui parandus on üleantav mitmes osas)
7. Kas parandus on ajutine või pikaajaline?
8. Kuidas sobib paranduse tegemine Priidu järgmise nädala kavadega?
9. Kuidas sobib paranduse tegemine firma üldise strateegiaga?
10. Kas meil on alternatiivseid lahendusi?

Tegelikult tuli pähe veel terve hulk muidki küsimusi, aga kõiki pole mõtet kirja panna, toodud näidetest piisab. Harjumus ja oskus mitmesugustes olukordades selliseid küsimusi küsida aitab nii mõndagi probleemi efektiivsemalt lahendada (lisaks on tegemist hea ajutrenniga).

gay_parade.jpg

Harjutamiseks võiks võtta mõne suvalise poleemilise teema (näiteks: “Homoparaad Tallinnas demonstreerib Eesti ühiskonna arengut paremuse (või halvemuse, vastavalt väitleja seisukohale :) ) poole”) ning selle kohta täpseid, konkreetseid küsimusi küsida, nendele lühidad, konkreetsed vastused välja mõelda ning siis vastuste põhjal küsida uusi uurivaid küsimusi. Vaadake, kui kaua vastas seisev poliitik või müügimees või muu tegelane, kes midagi tõestada püüab, vastu peab :)

No responses yet

Next »