Archive for July, 2008

Jul 23 2008

Puugid puuri!

bug.jpg

Paljud lugejad mäletavad ehk 1990. aastate esimest poolt, kus iga endast lugupidav eestlane oma isikliku panga asutas. Mingil hetkel avastasid pankurid aga, et lihtsalt kilekottidega sularaha ühest kohast teise tarimisest ei piisa, ja algas buum Eesti IT-maastikul. Tarkvarafirma Joostes Marss oli tol vanal heal ajal loomisjärgus ning tegi suuremaid ja väiksemaid projekte Ahja Kommertspangale.

phone_rage.jpg

Tihti lõppesid Ahja Kommertspanga IT-juhi Ilmari ja Joostes Marsi projektijuhi Joosepi vahelised vestlused aga mõlemapoolse ärritusega. Tüüpiline telefonikõne oli näiteks järgmine:
Ilmar: Kas bugid on ära parandatud?
Joosep: Mis bugid?
Ilmar: Need, millest ma kuu aega tagasi telefonis rääkisin!!
Joosep programmeerija Priidule: On ära parandatud või?
Priit: Midagi ma vist parandasin jah…
Joosep Ilmarile: Jah, on küll parandatud.
Ilmar: Millal kätte saab?
Joosep: Homme saadame.

Mõned päevad hiljem:
Ilmar: No aga ikka ei ole ju kõik ära parandatud!?!
Joosep: Mis siis veel?
Ilmar kirjeldab.
Joosep Priidule: Mis värk sellega on?
Priit: Aa, selle ma unustasin.
Joosep Ilmarile: Teisipäevaks saadame uue!

Kolmapäeval: 
Ilmar: Aga IKKA ei ole ju kõiki asju!!
Joosep: Aga see polegi bug, see on feature.
Ilmar hakkab karjuma, et tema on klient ja tema otsustab, mis on feature ja mis mitte.

Lõppkokkuvõttes võttis projekt kahe kuu asemel kaheksa, Priit logeles enamiku päevi niisama ja tegi vahele meeleheitlikke spurte, et probleeme kontrolli alla saada, kui Ilmarilt järjekordne kõne tuli. Ebaregulaarse rütmi tõttu läks ta tüdruksõbraga tülli ja kirjutas koodi sisse Ilmari aadressil ebatsensuurseid kommentaare.

 bugjail.jpg

Milles asi? Nagu ühes eelnevas, projektijuhtimisele pühendet jutus mainitud, on projekti õnnestumise tagamisel peamine osa korralikul kommunikatsioonil. Arvatavasti kõige olulisem asi, mida projekti käigus tuleb kirja panna ja millest kõik osalised peavad ülevaadet omama, on see, kui palju ja milliseid vigu (ehk buge või puuke) meil parajasti koodist on leitud.

Vigade andmebaasi pidamine on tegelikult väga lihtne asi, selleks on loodud suurel hulgal nii vabu kui kommertsprodukte, enamasti on puuduliku veahalduse põhjused suhtumises.

informationoverload.jpg

Vahel tuuakse vastuväiteks näiteks, et oh, me suudame niisama ka oma vigu meeles pidada. Absurdne. Ma pole veel näinud ühtki inimest, kes suudaks korraga meeles pidada rohkem kui kolme vea üksikasju. Võib ju ka öelda, et me parandame vead kohe nende ilmnemisel ära, aga seegi ei tööta, sest parandamine võtab vahel paratamatult kauem aega, kui meil hetkel käepärast on.

Tegelikult olen ma leidnud, et isegi väikeste projektide puhul, millega ma vahel ise oma lõbuks tegelen (ehk siis 1 inimene, 1000-25 000 rida koodi), on väga kasulik vead kohe avastamisel kirja panna (kui tegemist pole just asjaga, mis sama päeva jooksul valmis saab), sest hiljem on suur osa vajalikust kontekstuaalsest teadmisest  kadunud.

Igas veakirjelduses peavad kindlasti olemas olema järgmised komponendid:

  • Täielik info, kuidas viga reprodutseerida
  • Soovitud tulemus programmi käivitamisel
  • Tegelik tulemus
  • Kellele viga on omistatud (mitte ei eelda kõik inimesed, et keegi teine asja korda teeb)
  • Vea staatus (aktiivne, parandatud, kontrollitud/suletud)

Peale selle kasutavad erinevad organisatsioonid veel mitmeid väljasid, nagu

  • Tõsidus (oluline vahe, kas programm crashib või on mõni ikoon pikseli võrra paigast ära)
  • Prioriteet (erineb tõsidusest, vahel on avalehel oleva ikooni pikselid olulisemad kui kord 10 aasta jooksul juhtuv crash)
  • Vea parandamiseks kuluv hinnanguline aeg
  • Parandamise tähtaeg (kui meil on tegemist vahepealsete verstapostidega)
  • jne.

Kui vigade andmebaasi 100% kasutatakse, siis nende andmete põhjal saab projektijuht teha juba väga võimsaid päringuid, kui palju tööd on veel jäänud, kas programmeerijad jaksavad testijatega sammu pidada, milline on produkti üldine kvaliteet (s.t kas leitakse tõsisemaid või vähemtõsisemaid probleeme) jne. Samas ei tohi lisaväljadega üle pingutada, sest siis ei viitsi keegi neid enam täita. Ülaltoodud 5 välja on aga esmase tähtsusega. Kui vigade registreerimine muutub nii vaevanõudvaks, et inimesed seda enam ei tee, tuleb meil oma protsess alati optimiseerida sellele, et 100% vigadest saaks kirja pandud.

 insult.gif

Esineb ka psühholoogilist laadi vastuväiteid, näiteks võtavad mõned programmeerijad nende koodist vigade leidmist isiklikult ja peavad selle kirjapanemist veel eriti solvavaks. Ütle mulle lihtsalt, mis värk on, ja ma parandan asja ära, pole vaja midagi kirja panna, urisevad nad testijale. Siin saame teha kaks olulist tähelepanekut:

  • Kas on parem, et vea leiab meie testija või klient? Testija peaks olema programmeerija parim sõber ja programmeerija peaks teda igal viisil julgustama, et ta rohkem vigu saaks leida, sest sel viisil päästab testija programmeerija piinlikkusest, mis leiab aset, kui hoopis klient või mõni muu tähtis tegelane vea avastab ja programmeerijal tulekahju kustutamiseks ületunde tuleb teha.
  • Programmeerija produktiivsust ei tohi hinnata lihtsalt vigade arvu põhjal, sest see loob initsiatiivi mitmesuguseks sohitegemiseks ja lõpuks oleme lõhkise küna ees: vigade andmebaas valetab ja ka produktiivsust hindame ilmselt valesti.

Lisaks on vigade andmebaasil mitmeid sekundaarseid väärtusi, näiteks langeb ära vaidlus teemal, kas mingi asi on bug või feature, sest kõik on ilusasti kirja pandud ja kohe vea registreerimisel saab arutada, kas asjad peavad nii olema või ei.

Kokkuvõtteks võib öelda, et võrreldes projektiga, kus projektijuhtimisvahendid täielikult puuduvad, on vigade andmebaas ilmselt esimene asi, millest alustada, sest see annab lihtsa vaevaga kõige suuremat kasu. Lisalugemist muidu Joelilt.

No responses yet

Jul 16 2008

Teadmiste barjäär

Published by Targo under Kliendid

 frank.jpg

Minu 5-aastane poeg on suur Thomas and Friendsi fänn. Vahel joonistab ta paberile hulga vedureid ja korraldab mulle siis viktoriini, kes on kes. Thomas and Friendsi maailmas on üle 50 veduri ja siis on meie vestlus tavaliselt järgmine:

Mina: “Kas see on Skarloey?”
Tema: “Aga isa, sellel on ju valged puhvrid, Skarloey puhvrid on punased, see on Mike!”
Mina: “Ahaa, see on Mike.”
Tema: “Aga kes see on?”
Mina: “Ee… Arthur?”
Tema: “II-SAAA, Arthuril on kaheksa ratast, aga sellel on ainult kuus, see on ju Culdee!! Kuidas sa siis ometi ei tea?”

Asjaolust, et ta kõigi tegelaste detaile peast teab (kuni selleni, et näitab, kui mõne raamatu mõnel illustratsioonil kellegi korsten vale kõrgusega on joonistatud), ei järeldu ilmselt siiski, et ta minust targem oleks.

heart.jpg

Sellegipoolest teevad paljud oma eriala põhjalikult tundvad inimesed täpselt sama vea. Väga tüüpiline on näiteks erialase žargooni kasutamine, et targem ja väärikam välja paista. Näiteks arsti juures: “Teil on idiopaatiline kardiomüopaatia.” (idiopathic cardiomyopathy, andku Eesti arstid mulle andeks, kui valesti tõlkisin). Ja arst vaatab sulle otsa, rohkem midagi lisamata.

Patsient: “idi… mh?” Mida see tähendab? Kas ma suren kohe ära või on veel lootust?
Kardiomüopaatia on tegelikult südamelihase nõrgenemine, mis võib juhtuda väga mitmesugustel põhjustel. Ja idiopaatiline tähendab tavaliselt, et arst ise ka ei tea, millest probleem tingitud on. Aga “teil on idiopaatiline kardiomüopaatia” on ju palju aukartustäratavam, kui “teil jääb süda millegipärast nõrgemaks”. Erialases vestluses on erialaste terminite kasutamine muidugi omal kohal, aga kui me räägime inimesega teiselt alalt, on kena ja viisakas kasutada tavakeelt.

Tegelikult näitab žargooni kasutamine teatud laadi mõttelaiskust, enamasti on asjadest keeruliselt kõnelemine rääkijale palju lihtsam kui selle korralikult läbimõtlemine ja sel viisil seletamine, et sinu vanaema ka aru saaks. Asjaolu, et ekspert mõtleb oma terminites, tekitab tema ja teiste vahele nn teadmiste barjääri, mis teeb suhtlemise ebaefektiivseks, raiskab aega ning riskib olulise info kaotsiminekuga. Mitmesugused tehnoloogid eksivad selle reegli vastu iga päev ja see tuleb neile suureks kahjuks.

dotcom.jpg

Eriti hull on asi siis, kui keeruliste sõnadega varjatakse seda, et inimene ise ka ei tea, millest ta õieti räägib. Kopeerisin järgnevalt ühe eriti markantse näite (allikas siin), kus telereporter vestleb omaaegse dotcom-firma juhiga.

Simon praised Razorfish as “one of the most successful companies on the Web,” but then his tone abruptly changed.
“Successful at what?” he asked. “Good question.”
The camera was now on Dachis.
“We’ve asked our clients to recontextualize their business,” Dachis managed. “We’ve re- … recontextualized what it is to be a business-services … and that’ll continually … ”
Simon’s face went blank. It wasn’t the look of helpless confusion millions of Americans were experiencing as Dachis stuttered at them through their TV sets. Rather, it was the sedate, self-satisfied gaze of a 60 Minutes reporter about to yank the lever of the show’s legendary trapdoor.
“You know,” Simon said, “there are people out there, such as myself, who have trouble with the word recontextualize.” Anyone who had ever watched the show knew where this was going: “People out there, such as myself” meant “the rest of the goddamned United States.” Dachis was on his own now. Even the chief scientist stood mute.
“Tell me what you do,” Simon insisted, “in English.”
“We provide services to companies to help them win,” Dachis offered.
“So do trucking firms!” Simon snapped. Dachis seemed taken aback – the trucking remark was really uncalled for.
“What is it you do?” Simon pressed.
“Our talent is to do a certain thing, whereas the trucking firm …”
“Yes, but what is – what is it you do?”
“We radically transform businesses to invent and reinvent them,” Dachis said. It was his best shot.

Kommentaarid on ilmselt liigsed. Recontextualize, wtf ;)

One response so far

Jul 10 2008

Usaldusest

Published by Targo under Kliendid, Müük

 handshake.gif

Erinevaid meeskondi juhtides on mul vahel ikka juhtunud, et tuleb mõnele inimesele isa ja ema eest olla, toetada, kui tal tüdruksõbraga kehvasti läheb või naisega läbi ei saa. Peamine, millele ma sellistel puhkudel rõhun, on see, et kõik saab alguse usaldusest. Kui ikka naine sinu eest asju varjab (või vastupidi), ei saa suhtest enamasti head nahka.

Sama, ainult veidi teisel tasandil, kehtib ka meie suhete osas klientidega. Tänapäeva majanduses on enamik meie kulutustest tegelikult tehingukulud, sealhulgas mitmed kulutused kontrollimaks, kas vastaspool on ikka usaldusväärne ja saab oma tööga hakkama. Igasugustele juristidele, nõustajatele, audiitoritele jm abimeestele makstakse sealjuures suurt raha, mis muidugi lisandub kõik lõpptoote maksumusele.

2003. aastal ostis Warren Buffett McLane Company, makstes selle eest 1,45 miljardit dollarit ja võttes üle veel 1,2 miljardi eest ettevõtte võlgu. Tavaliselt võtavad sellised tehingud palju kuid ja terve armee audiitoreid, raamatupidajaid jne, aga antud juhul löödi käed kokku kahetunnise koosoleku järel, sest Buffett usaldas oma vastaspoolt ja teadis, et asjad on täpselt nii nagu kirjeldatud. Nii rahaline kui ka ajaline kokkuhoid olid tohutud ja ilmselt ei kahtle keegi Warren Buffetti ärimehegeeniuses, seega on usaldusel täiesti konkreetselt mõõdetav rahaline väärtus.

Kuidas usaldust suurendada? Käisin hiljuti seminaril, kus seda teemat käsitleti ning toodi välja järgmised nõuanded:

curiosity.jpg

1. Tekita uudishimuliku suhtumise õhkkond

Enamasti elavad meie kliendid meie endaga võrreldes küllaltki omaette elu ja teevad asju, mis meile nii mõnigi kord mõistetamatuks jäävad. On aga oluline, et me ei suhtuks sellesse mitte üleoleku ja tõrjumise, vaid uudishimuga. Iga kord, kui klient teeb midagi meie jaoks ootamatut või veidrat, peaks meie reaktsioon olema “hmm, huvitav… miks nad nii teevad?” See kehtib igaühe kohta, firmajuhist kõige noorema programmeerijani.

Uudishimu paneb meid küsimusi küsima ja kliendile keskenduma, mis tekitab temas koheselt usaldusväärsuse tunde.

 thinking.jpg

2. Mõtle valjusti

Ütleme, et me saavutasime olukorra, kus klient tunneb et me teda tõesti hoolega kuulame ja talle tähelepanu pöörame. Samas on aga olemas mitut laadi tähelepanu. Näiteks raisakull pöörab oma “kliendile” samuti palju tähelepanu! Selleks, et meie partner meid raisakulliks (või kasutatud autode müügimeheks) ei peaks, anname talle märku, kuidas meie enda mõtted töötavad. Kui ta meile näiteks oma andmebaasiprobleemist räägib, anname talle kogu aeg tagasisidet, näiteks nii:

“Ja kui andmemahud kasvavad suureks, muutub süsteem aeglaseks, saan ma õigesti aru? Ja, hmm… see muudab siis andmesisestajate töö aeglasemaks ja teil on rohkem tööjõudu vaja, kas nii?”

3. Kirjuta oma järgmine pakkumine kliendiga koos

Selle asemel, et pärast esialgset koosolekut oma karpi tagasi tõmbuda ja seal (enamasti mõne olemasoleva malli põhjal) pakkumine valmis kirjutada (kusjuures klient ei tea, kuidas see õigupoolest valmis ja millised kaalutlused sinna sisse läksid), miks mitte paluda, et klient sinuga kaasa tuleks ja aitaks kirjutada pakkumist, mis mõlema poole huvisid parimal viisil arvesse võtaks?

See on küllaltki radikaalne idee, loe lähemalt siit.

 sandpaper.jpg

4. Ole sina ise, kõik teised on juba võetud

Selle loo rääkis mulle üks juhtimiskonsultant, praeguseks vana ja väärikas mees. Noorena olid ta käinud ühe liivapaberivabriku juhiga kohtumas, et aidata neil paremat müügistrateegiat koostada. Juht küsinud: “millised kogemused teil tööstuses äratarvitatavate abivahenditega on?” Hm, kõik tema eelmised kogemused olid olnud suurlinna valgekraedega.

Iga poliitik teab, et selle asemel, et vastata küsimusele, mis sult tegelikult küsiti, on parem vastata nii, nagu oleks sult küsitud midagi, millele sulle tegelikult meeldiks vastata. Ja nii alustas ka meie noor konsultant tiraadi oma kogemustest mitmesugustelt muudelt aladelt ja kuidas need ka antud situatsioonis hästi ära kuluvad.

Aga! Poliitikud pole just tuntud oma usaldusväärsuse poolest, kas me tahame, et meie partner meid poliitikuks peaks? Ülaltoodud taktika on ju täiesti läbinähtav!

Õnneks oli meie sõbral kaasas vanem kolleeg, kes jutujärje üle võttis ja rahulikult vastas: “Konkreetselt selliseid kogemusi meil pole. Aga rääkige meile oma probleemidest.” Kolm korda võite arvata, kumb usaldusväärsema mulje jättis. Antud juhul oli kliendi vastus: “Arvata oli, pole just palju inimesi, kes liivapaberi müügile spetsialiseeruks.” Ja edasi jätkus jutt juba sellest, kuidas konkreetset ärilist probleemi lahendada.

5. Müü tegudega, mitte sõnadega

Ei vaja ilmselt pikemat selgitust :)

carrier_pigeon.jpg

6. Vasta teadetele uskumatult kiiresti

See on nii lihtne asi, et on imekspandav, kui kehvad enamik ettevõtteid selles osas on. Võtad nendega ühendust, saadad oma soovid ja edasi ei juhtu mitte midagi. Said nad teate kätte? Teevad nad midagi? Mis toimub? Vahel juhtub, et mitme nädala möödudes annab keegi lõpuks elumärki, aga kui tegu pole just monopoolses seisus ettevõttega, olen ma juba ammu katsunud mujalt abi leida. Samas, kui me igale sissetulevale kõnele, emailile vms kontaktile vastame kohe, tekitab see õhkkonna, kus klient tunneb, et temast hoolitakse, temaga arvestatakse ja ta usaldab meid palju rohkem. Kui tegemist on küsimusega, mis vajab pikemat arutamist või ettevalmistamist, tuleb ikkagi kliendile kohe öelda, et me saime tema asjad kätte, tegeleme nendega ning võtame nii ja nii pika aja järel ühendust.

clock.jpg

7. Ära räägi rohkem kui 2 minutit järjest

Isegi juhul, kui klient ütleb, et tahab sinust rohkem teada, ei huvita sinu ja sinu firma tegemised teda rohkem kui veendumaks, et sa oled pädev tema isiklikku probleemi lahendama. Vahel on üsna ehmatav kella jälgida ja avastada kui palju me omaenese asjadest patrame, selle asemel, et lasta kliendil oma probleemi põhjani tungida.

office-sign-feeding.jpg 

8. Kuluta telefoni asemel kingataldu

Selle asemel, et kliendiga telefoni ja emaili teel suhelda, astu sisse, uuri, kuidas nad tegelikult oma elu elavad, millised kommentaarid on lõppkasutajatel jne.

2 responses so far