Tarkvarafirma Joostes Marss oli Hulkuvate Kasside Riiklikule Inspektsioonile tarninud juba õige mitu versiooni nende andmeregistrist. Kuigi projektides esines teinekord konarusi, harjusid kõik osalised vähehaaval üksteisega ning asjad sujusid. Andmeregistrile kasvatati järjest uusi kombitsaid, kelli ja vilesid ning ametnikud olid rahul.

Siis leidis loomakaupluste kett Krants, Kõuts & Kirjak, et aitab paberi ja pliiatsiga asjaajamisest ning kutsus Eesti erinevate tarkvarategijate esindajaid oma lahendusi pakkuma. Joostes Marsi direktor Tõnis hõõrus käsi: keegi ei tea kassidest rohkem kui meie! Ja projektijuht Joosep saadeti KK&K peakorterisse esitlust tegema.

Joosep näitas hulgaliselt ägedaid vorme, graafikuid ning raporteid ja kiitis süsteemi rikkalikke võimalusi. “Kasutajad saavad ise töövooge disainida näiteks!”, vedas ta uhkelt ekraanil kastikesi. Võit tundus käes olevat.

Ent kui tulemused välja kuulutati, osutus võitjaks hoopis AS Pärlike, keda Joostes Marss polnud enne just kuigi tõsiseks konkurendiks pidanud. Aga… aga töövood! protesteeris Joosep. Nojah, see on tore küll, nõustus KK&K IT-juht Iko. Aga meil on siin lihtsad inimesed, nad ei kasutaks niikuinii kõiki neid võimalusi. Pärlikese lahendus on palju mugavam. Ja pealegi ma kuulen, et teil on Inspektsioonis vahel stabiilsuse probleemid. Stabiilsuse probleemid muidugi olid, seda ei saanud Joosep salata, aga see oli erinevate lisavõimaluste hind ning eelmine klient oli nende eest täiesti valmis olnud väikest ohvrit tooma.

AS Pärlike töötas projekti kallal mõned aastad, elu sujus, tehti jätkuarendusi jne. Ühel päeval aga tuli Iko Pärlikesse ja teatas, et nende IT-kulud on liiga suured ja nad peavad plaani anda oma arendus pigem OÜ Ülo&Aivari kätesse, kuna nonde tunnihind on mitu korda madalam. Pärlikese boss oli endast väljas: Aga… aga meie progejad on ju palju paremad! Ülo ja Aivar on ju täitsa metsast, mida nemad ka teavad? Nojah, võib-olla, arvas Iko. Aga meil pole midagi väga keerulist niikuinii vaja, küll me hakkama saame.

Mis siis tegelikult juhtus? Ilmselt on paljud meist olnud ühes või mitmes ülalkirjeldatud rollidest ja vastavalt oma vaatenurgale kas rõõmustanud võidu üle või kirunud, kuidas klient on ikka taipamatu ega saa meie väärtusest aru.

Tegelikult on majandusteaduses kindlaks tehtud, et enamik konkureerivate ettevõtetega turge käivad läbi neli konkreetset faasi:

1. Võistlus funktsionaalsuse baasil, kus hinnatakse seda, kelle tootel on rohkem võimalusi.
2. Võistlus töökindluse baasil, kus kõigil on piisav funktsionaalsus on olemas, aga oluliseks saab, et süsteemile võib kindel olla.
3. Võistlus kasutajamugavuse baasil, et toode saaks uutele kasutajatele võimalikult kerge vaevaga kättesaadavaks.
4. Võistlus hinna põhjal. Kui kõige muu osas tundub kliendile, et vahet pole, saab ainsaks määravaks teguriks hind.

Need faasid kehtivad igal pool ekskavaatoritest mikroprotsessoriteni ning nende osas rakenduvad järgmised reeglid:

• Igas järgmises faasis kahaneb kasumimarginaal.

Kui puhtalt funktsionaalsuse juurdetreimisega tegelevatel firmadel on marginaalid tihti 30-40% kandis, siis ainult hinnapõhises konkurentsis tuleb rahulduda paari protsendiga.

• Ettevõtetele on ühest kategooriast teise liikumine äärmiselt raske ning see saab neile tihti saatuslikuks.

Minu Microsoftis töötatud aja keskele jäi ka Trustworthy Computingu initsiatiivi väljakuulutamine. Kui varem oli hiigelsuure ettevõtte igal tasemel ja üksuses olnud edu valemiks konkurentide löömine suurema hulga funktsionaalsusega, siis nüüd kerkis (kasvõi Linuxi jt uute tulijate survel) fookusesse turvalisus ja töökindlus ning ümber orienteerumine nõudis väga raskeid pingutusi. Siiski sai Microsoft ülesandega enamvähem mõistlikult hakkama (NB! oluline pole mitte ideaalne õnnestumine, vaid see, et olla klientide jaoks piisavalt hea) ning Linuxi poolt enam otsene häving Microsofti ei ähvarda. Uueks ohuks on saanud hoopis Google ja Apple, turg on liikunud kasutajamugavusele keskendumise faasi. Mis siin lõpuks saab, näitab aeg. Analoogselt on ka mitmed varasemad väga edukad ettevõtted areenilt kadunud.

• Uutesse faasidesse jõutakse vähemnõudlike klientide kaudu.

Ülaltoodud loos esindas Krants, Kõuts & Kirjak vähemnõudlikku klienti, kellele oli olulisem uue süsteemi kiire omandamine ja hind. Hulkuvate Kasside Riiklik Inspektsioon nõuaks ilmselt veel mõnda aega uusi kelli ja vilesid, kuid millalgi saab ka neil isu täis ja rõhk liigub töökindlusele ning kasutajamugavusele. See on aga kuldne võimalus AS Pärlikesele, kes on harjunud nendele aspektidele rõhuma, et Joostes Marsi käest magus klient ära rabada. Samamoodi õõnestab Ülo&Aivar pidevalt Pärlikese turgu jne.

• Mida paremat tööd me teeme, seda kiiremini jõuab kätte faasivahetus.

See on ärijuhtidele kõige valusam reegel. Kui teha kõike, mida peetakse eduka äri aluseks: kuulata oma klienti, uurida nende vajadusi, investeerida uutesse tehnoloogiatesse jne, siis tähendab see, et mõnda aega teenitakse head kasumit, kuid seda kiiremini saabub aeg, kus klient küllastub meie poolt pakutavast, tal pole enam rohkem funktsionaalsust (või töökindlust või mugavust) vaja, meie poolt välja töötatud lahenduste loomine muutub odavamaks ning altpoolt tulijal ja järgmisele faasile keskendujal tekib kuldne võimalus hoopis oma väärtust pakkuda.

Ehk siis, mida paremini me töötame, seda kiiremini endale ise auku kaevame.

Rääkisin ühe tuttavaga teemal, mida on võimalik IT-s karjääri poolest üldse peale hakata. Enda üllatuseks leidsin, et ükski IT-d õpetav Eesti kool ei loetle just kuigi põhjalikult võimalusi ja ameteid, millega pärast nende stuudiumi lõpetamist on võimalik tegeleda, ja samuti ei kujuta ka paljud tudengid ette, mida nad täpsemalt pärast kooli tegema hakkavad. Hakkasin neid seetõttu ise kirja panema ja mõningase mõtlemise järel jõudsin järgmise tabelini (kliki, et suurendada):

Siin on ära toodud üksteisest ülesannete sisu poolest erinevad ametid, mille täiskohaga pidajaid ma ise näinud olen, ja kus tarkvaraalasest (päris tervet IT-d+arvutiteadust ei oleks jõudnud ühte tabelisse kirja panna) haridusest kasu oleks. Grupeering on mõneti meelevaldne ja mõnes situatsioonis liigitataks ameteid ehk teisiti. Siiski läheb praktiliselt igas tarkvaraprojektis peaaegu kõiki ka vaja, kuigi olenevalt projekti suurusest võib mõnele neist kuluda 0,1% ühemehefirma omaniku ajast kuni tervete meeskondadeni. Nt Microsoftis on tiim, kes päevast päeva lihtsalt jooksutab igapäevaste Office’i buildide suitsuteste. Testid käivad automaatselt, kuid sellegipoolest on vaja, et keegi kontrolliks, et kõik sujub, koordineeriks parandusi, saadaks vastavaid teavitusi jne.

Peale nende on muidugi veel musttuhat spetsiifilisemat varianti, üks huvitavamaid ametinimetusi, mida ma olen kohanud, oli Emulation Ninja Microsofti XBoxi divisjonis, aga need on üldjuhul teisendid tabelis toodud ametitest.

Kuna aga need ametid erinevad mitte ainult tehnoloogia, vaid ka sisu poolest, oleks väga hea, kui ülikoolid mõistaksid nende olemasolu ja annaksid ka spetsiifilisemaid teadmisi, kuidas ühes või teises hakkama saada. Igaüks neist vääriks eraldi loengukursust, kardetavasti utoopia, aga unistada ju võib.

Veel: siit ei järeldu, et ma pooldaksin mingit superkitsast spetsialiseerumist. Minu peamine point on, et nende tegevusalade olemasolu tuleb teadvustada ning ennast nende läbiviimiseks korralikult ette valmistada, kuid õige professionaal võiks vallata päris paljusid selle tabeli lahtritest. Inimene on ikkagi generalist, spetsialiseerumine on putukatele

Eelnevalt alustatud teema kokkuvõtteks vastuseid mõnedele küsimustele, mida mult vahel Microsofti ja muu tootearenduse kohta on küsitud.

Kui Office’i ajagraafik on sellisel määral fikseeritud (vt teema 2.osa), kuidas jääb vigade parandamisega?

Vigade puhul kehtib sama põhimõte, mis feature’de puhulgi. Vigade parandamiseks on planeeritud teatud aeg ning kui tähtaeg lähemale jõuab, tõuseb järk-järgult latt, millise tõsidusega vigu veel parandatakse ja milliseid mitte. Peamiseks põhjuseks on siin kusjuures ära hoida, et ühe tuntud vea parandamine ei tekitaks uusi tundmatuid vigu. Kui release’ini on jäänud loetud päevad, parandatakse vaid tõsiseid turvavigu ning kui mõni selline leitakse, lükkub release tõesti edasi, et täiendavaks testimiseks aega anda. Iga selline edasilükkamine on aga kulla hinnaga, sest ka kõik seonduvad ja planeeritud tegevused alates CD-de trükkimisest kuni SteveB kõneni mõnel asjakohasel üritusel lükkuvad edasi.

Vead, mida ei jõutud parandada, jäävad (vastavalt tõsidusele) kas service pack‘i või järgmisse versiooni. Kuna tarkvara poodidesse jõudmine võtab aga mõnevõrra aega, saamegi situatsiooni, kus vahel on poest ostmise ajaks juba ka esimene service pack downloaditav.

Milline võiks olla tootearenduse versioonihaldus?

Eristaks siin kõigepealt kaht äärmust:

“Rätsepatöö” tarkvara oluliseks eripäraks on, et kliendile tehakse pidevalt mingeid väikesi kohendusi ja mugandusi. Niipea kui klient midagi tahab ja selle eest on nõus maksma, tehakse ka vastav asi ära.

Teises servas on tarkvara nagu MS Windows, mis elab oma elu, ja kui sa pole just Citigroup või US Department of Defence, on sul üsna vähe võimalust seda kuidagi suunata.

Samas on hulk tarkvarasid, mis on alguse saanud rätsepatööst, aga sealt edasi on neid veel (esialgu) käputäiele klientidele müüdud. Kuna arendusmeeskond on harjunud kliendi erisoovidele orienteeruma, tehakse ka siin mõnda aega samamoodi edasi. Tulemuseks on, et lisaks ilusale ja elegantsele põhifunktsionaalsusele kasvab tootele veel igasuguseid erikujulisi kombitsaid ja konfiguratsioone, mida läheb vaja vaid ühel või teisel meie klientidest. Ja kui me igaühele natuke erineva asja paigaldame, on versioonihalduse seisukohalt tulemuseks tohutu peavalu, sest selles situatsioonis muutub kasvõi regressioonitestimine kiiresti võimatuks.

Minu isiklik arvamus on, et sellist koodibaasi fragmenteerumist tuleks iga hinna eest vältida ja erinevad kliendid peavad saama võimalikult standardseid ja ühetaolisi tükke, nii on pikas perspektiivis ka nende enda elu lihtsam ja vigu vähem. See lähenemine aitab vältida ka “dll hell’i”. Tootearenduse puhul on meil igasuguseid versioone niigi palju (vanad versioonid, viimased versioonid, uued beetad jne), nii et peame oma konfiguratsiooni võimalikult lihtsana hoidma.

Suurte toodete näitena võib siin jälle tuua MS Office’i, mis koosneb praeguseks juba kümnetest erinevatest üksiktoodetest, aga selle asemel, et lasta kasutajail sealt suvalisi kombinatsioone valida, müüb Microsoft ikkagi ainult näputäit standardkonfiguratsioone. Sellegipoolest on Office’i arenduses terve tiim, mis tegeleb täiskohaga ainult versioonide ning build scriptide haldamisega.

Kui palju meil dokumentatsiooni vaja läheb?

Tootearenduse puhul tuletame meelde esimeses osas sissetoodud suurust ϰ, mis muuhulgas mõjutab otseselt ka aega, mis programmeerijatel tuleb kulutada toote hilisemalt toetamisele. Seetõttu on ka dokumentatsioon palju olulisem kui teenusena loodud tarkvara puhul, et toetusprotsess efektiivsem oleks. Konkreetselt Microsofti standardiks on see, et koodile tekib neli erinevat dokumentatsiooni: spetsifikatsioon, arendaja loodud tehniline disain, testija kirjutatud testplaan ja technical writeri tehtud kasutajajuhend.

Selle üle, kas viimase jaoks peaks eraldi inimene olema, võib muidugi vaielda. Me kõik oleme lugenud dokumentatsioone, mis on kirjutatud inimese poolt, kellel pole ilmselgelt olnud piisavalt võimalust asjast aru saada, vt kasvõi LRF-1914 näidet Joeli artiklis.

Jätkuks eelmisele samateemalisele sissekandele.

Tootearenduse ajagraafikutest

Tootearenduse puhul on meil tüüpiliselt võimalik oma ajagraafikutes paindlikumad olla ja rohkem ise kuupäevi seada. See aga loob suure kiusatuse võtta endale suhtumine, et asi on valmis siis, kui ta on valmis.

Siin tekib meil kaks probleemi:

Esiteks projektikolmnurga põhimõte, mille kohaselt erinevad uued võimalused võtavad meilt ka ekstra aega ja raha (või kui me katsume aja ja raha fikseerituna hoida, siis kahandavad kvaliteeti).

Teiseks ei kasva aja ja rahakulu võimaluste hulga kasvades mitte lineaarselt, vaid kiiremini, kuna projekti keerukus suureneb ja projekti otseselt mitte edasiviivatele tegevustele kulub rohkem aega.

Konkreetselt Microsofti hiljutisest ajaloost leiame kaks näidet, mis selle sündroomi erinevaid aspekte illustreerivad:

Negatiivne näide: Windows Vista (arendus kestis mai 2001-november 2006). Longhorn/Vista projekt oli algul mõeldud suhteliselt väikese sammuna pärast Windows XP-d. Siis aga hakkas toimuma “projektiosmoos”, igasugused lisaideed ja võimalused “imendusid” järjest projektile juurde. Vt näiteid selle tagajärjel kokku pandud fantasmagooriast Paul Thurrotti väga illustratiivsest ülevaatest. WinFS, Avalon/WinPF, Indigo/WinCF ja Monad/PowerShell on vaid üksikud markantsemad näited, mis oleksid pidanud Vistasse naha ja karvadega integreeritud olema.

Pauli tsiteerides:

In late August 2005, Microsoft was still developing Windows Vista as it did previous Windows versions: New features were being added on the fly, and would continue to be added right up through the release candidate stages.

Uh-oh. Lõppkokkuvõte on meile kõigile teada. Vista sai valmis oluliselt hiljem ja oluliselt väiksemate võimalustega, kui oli alguses planeeritud (ja mitu aastat enne valmimist ka inimestele demotud!), rääkimata ulgumisest ja hammaste kiristamisest, mida mõned muudatused kasutajates indutseerisid.

Positiivne näide: Microsoft Office. Office 2010 RTM versiooninumber on 14.0.4760.1000. Kuigi Office’i versiooninumbritega on mõningast trikitamist sooritatud, pole maailmas just palju tarkvarapakette, mis sellise arvuni oleks jõudnud, ning Office’i väljalasked on juba üle kahe dekaadi küllaltki kellavärgina toiminud.

Office’i puhul fikseeritakse esimese asjana valmissaamise kuupäev. Näiteks Office XP puhul öeldi üle kahe aasta ette ära, et ship date on 3/2/1 (2.märts 2001 USA kuupäevastiili järgi) ja nii ka juhtus (Wikipedia artikkel näitab poodidesse jõudmise ehk launchi kuupäeva). Sarnaselt on fikseeritud ka beetade jt oluliste sündmuste ajad. Alati muidugi päris õigeks ajaks ei saa, aga üldiselt on hilinemised mõõdetavad mõnede kuudega. Kui mõni feature pole vastavaks ajaks piisavalt valmis, jäetakse ta lihtsalt sellest release’ist välja ja järgmine kord proovitakse uuesti.

Kui ma SharePointi Portal Serveri tiimiga ühinesin, oli just alanud kõige esimese SharePointi versiooni loomine (isegi see polnud veel teada, et seda just SharePointiks hakatakse hüüdma). Mitmesugused inimesed (mina sealhulgas) fantaseerisid kokku kõikvõimalikke võimalusi, mis tootes peaks kindlasti olemas olema. Meie õnneks lõikas toote juhtkond enamiku sellest värgist halastamatult plaanist välja, keskendudes vaid võimalustele, mille osas olid olemas kõige kindlamad ja konkreetsemad potentsiaalsete klientide soovid.  Tol hetkel paljud (mina sealhulgas) seda küll ei adunud ning vandusid tulist kurja, et keegi ei hakka sihukest toodet iialgi ostma. Lohutuseks oli vähemalt asjaolu, et tuleb ka teine versioon, kuhu need featured kindlasti sisse saavad.

SPS 2001 sai siiski valmis ning mõned inimesed isegi ostsid seda.

SPS ver 2 puhul sooritati sama harjutus, suur hulk asju jäid plaanist välja, aga inimesed ostsid ka SharePoint Portal Server 2003 litsentse ja isegi oluliselt suuremal hulgal kui 2001 omi. Sama asi kordus ka 2007 ja 2010 puhul.

Huvitav on siin aga asjaolu, et mõned featured, mis juba esimesest versioonist välja jäid, on sealt endiselt väljas! Ja mitte midagi hirmsat pole sellest juhtunud, vastupidi, SharePoint on Microsofti ajaloos kõige kiiremini kasvanud käibega (kuude arv nullist miljardini) toode.

Ehk siis jutu moraal: kui me arvame, et me teame täpselt, mis meie tootes peab olemas olema, siis me suure tõenäosusega eksime – ajagraafikute õhkulaskmisest ja feature creep‘ist oluliselt parem variant on põhiasjad korda saada ning seejärel klientide tagasisidet kuulata, mis neile järgmiseks kõige-kõige olulisem on.

Järgneb…

PS Minu Wordpressi ReCaptcha plugin muutus hiljuti üleagressiivseks ning liigitas kõik viimase paari kuu kommentaarid spämmikasti, mida ma pahaaimamatult tühjendanud olen. Mõned kommentaarid läksid nüüd ilmselt kaduma – vabandan.

Olen praeguseks oma professionaalses elus sattunud osalema mitmesugustes projektides alates super-spetsiifilistest ühele kliendile optimiseeritud süsteemidest kuni super-üldistatud masstoodeteni.

Mis neil tegelikult vahet on?

Tarkvaraprojekti iseloomustavad kõige põhilisemad põhiparameetrid on:

• Kasutajate arv K
• Programmeerijate arv P

Toon lihtsuse mõttes sisse tähise ϰ = K/P (kreeka täht KAPA = Kasutajate Arv jagatud Programmeerijate Arvuga)

Finantsiliselt kehtib üldjuhul reegel, et suur ϰ => suur $, vaadake kasvõi Bill Gatesi. Sellepärast ongi peaaegu iga teenusearendaja kinnisideeks teha oma rätsepatööst “toode” ning liikuda tagumiktundide müügilt tiražeerimisele.

Samas tähendab suurem ϰ ka suuremat vigade parandamise kulu, iga täiendus või parandus tuleb viia palju suurema hulga inimesteni, kellel see omakorda mingeid probleeme või destabiliseerimist võib esile kutsuda.

Seega, mida suurem ϰ, seda kõrgem peab olema toote kvaliteet:

• Läheb vaja paremaid programmeerijaid ja analüütikuid

Nt Microsofti tootearendusdivisjonid võtavad tööle ehk 2% inimestest, kes sinna oma CV-sid saadavad. Sellepärast on neil ka vaja piisavalt häid inimesi nagu tolmuimejaga mujalt maailmast kokku tõmmata. Vt ka staaride teemat.

• Läheb vaja rohkem testimist

Diagrammid illustreerivad arendustsükli jooksul kulutatavaid inimtunde – kui projekt on “valmis”, lisandub sellele muidugi ka väline testimine.

Teema jätkub edaspidi…

Originaalslaidid siin.

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

Üks kõige ohtlikumaid olukordi inimese jaoks on lahing sõjas. Piirkond on täis suurt kuumust, ohtlikke aineid, ülehelikiirusega ringi lendavaid metallitükke jne.

Samas, kõige olulisem mõjutaja inimese elus on enesealalhoiuinstinkt. Seega, kui sõduritel on vaja näiteks üle mingi lagendiku rünnaku joosta, on see nende jaoks kõige loomuvastasem asi maailmas.

Sellegipoolest, kui antakse vastav käsk, siis sõdurid tõusevad püsti ja jooksevad üle selle lagendiku.

 Miks?

 Peamiselt sellepärast, et neisse on pikkade ja raskete õppuste kestel sisse drillitud absoluutne sõnakuulamine. Nad teavad, et käsk on vanem kui meie ja et nende enda elu pole suures plaanis oluline. USA merejalaväelastel pole lubatud kasutada sõna “mina”.

Põhiväljaõppe käigus õpivad sõdurid oma ülemust kartma rohkem kui surma. Sest ülemus on suur ja hirmus (nagu mina). Ülemus ütleb, et jookse ja sõdur jookseb. Ütleb, et lama ja sõdur lamab. Ütleb, et lenda ja sõdur vehib kõigest hingest kätega, et lendu tõusta.

Paljudele tsiviilelu organisatsioonijuhtidele meeldiks oma organisatsiooni samamoodi juhtida. Et aina käsuta ja kõik kohe teevadki nii, isegi kui see nende isiklikele huvidele või enesealalhoiule vastu käib.

Paljud proovivadki nii teha. Paraku küll mitte väga edukalt. Sõjaväes pole sõduril kusagile pääsu – kui ta jalga laseb, siis püütakse ta kinni, pannakse vangi või lastakse maha. Tsiviilelus saadetakse nõme ülemus aga varem või hiljem pikalt või siis lihtsalt ignoreeritakse teda.

See suhtumine on tegelikult väga levinud, mul on endal ka tihti kiusatus olnud karmi käsutamise abil probleeme lahendada. Ja kui ma kunagi oma vennale rääkisin, et minu  tiimi liikmete töö tulemused ei vasta alati päris sellele nagu ma soovisin, oli tema esimeseks reaktsiooniks: kas sa nende suhtes mingeid sanktsioone ei saa rakendada?

Vabandust, vennas, see asi pole paraku nii lihtne.

Hoiatava näite sellest, kuidas väline halvaga ähvardamine ei aita, leiame tegelikult meditsiinist. Südameoperatsioonil käinud inimesi hoiatatakse üldjuhul, et kui nad oma eluviise (olgu siis liigse söömise, joomise, suitsetamise vms osas) ei muuda, siis nad surevad varsti ära. Kui paljud inimesed aga tegelikult ennast parandavad? Selgub, et 2 aastat pärast operatsiooni on 90% patsientidest tagasi endiste harjumuste juures!

Kirjutasin kunagi IBMi teemal, kuidas nad oma kunagise liidripositsiooni kaotasid, aga tegelikult kehtivad samad seaduspärad ka peaaegu kõigi teiste ettevõtete ning tööstusharude puhul.

Clayton Christensen toob oma raamatutes välja järgmise diagrammi:

Tehnoloogiline areng toimub siin järgmiste etappide kaupa:

1. Turul on ettevõtted, mis parandavad pidevalt oma tooteid vastavalt kasutajate soovidele (vasakpoolne “säilitava innovatsiooni” nool). Nad ei tee mitte midagi valesti, vastupidi! Need ettevõtted kuulavad väga hoolega oma kliente, leiutavad oma valdkonnas uusi tehnoloogiaid ja teevad üldse kõiki häid asju, millest me äriraamatutest lugeda võime.
2. Nende toodete võimekus muutub piisavalt täielikuks, et keskmine kasutaja ei saa uutest täiendustest enam erilist kasu. Mõtleme kasvõi palju aastaid kestnud kurtmisele, et “mis mul sellest uuest MS Office’i versioonist abi on”.
3. Mingil hetkel tuleb turule samas valdkonnas, aga teistel põhimõtetel töötav toode, mis ei rahulda peamiste tarbijate vajadusi, aga on näiteks oluliselt odavam, lihtsam kasutada vms. Esialgu jääb see vaid kitsasse nišši.
4. Uus toode täieneb, kuni ta on järjest suurema hulga kasutajate jaoks “piisavalt hea” ning vana toode marginaliseerub äkitselt.
5. Ring algab otsast peale.

Näiteid taolistest murrangutest, nii minevikus toimunutest kui praegu käimasolevatest:

• Digitaalfotograafia vs “klassikaline” ehk keemiline fotograafia. Oli aeg, kus digitaalfotograafia kvaliteet oli oluliselt halvem, aga praeguseks on pigem klassikaline film nišitooteks tõrjutud.
• Peronaalarvutid vs superarvutid. Varased personaalarvutid ei saanud spetsialiseeritud superarvutitele lähedalegi, aga praegu on järjest vähem organisatsioone, kellele enam tavalistest arvutitest ei piisaks.
• Tulirelvad vs vibud ja nooled. Kõva inglise vibumees oli efektiivsem kui esialgse musketiga relvastatud vastane, aga tulirelvaga treenimine oli lihtsam ning odavam.
• Aurulaevad vs purjelaevad. Algul olid aurulaevad aeglasemad ja neid kasutati ainult vähese tuulega sisevetel.
• Telefon vs telegraaf. Telefoni sai algul kasutada vaid kohalike kõnede tarvis.
• Paber vs pärgament. Pärgament on palju kvaliteetsem, kuid ka palju kallim.
• Kiirrongid vs lennukid. Olenevalt elanikkonna tihedusest võib pakkuda suuremat mugavust ning kättesaadavust.
• Eralennukid vs Concorde. Concorde loodi eliidile, kelle aeg oli kulla hinnaga. Siis aga said eralennukid piisavalt odavaks ning kättesaadavaks, et nende kasutusmugavus kaalus üles Concorde’i suurema kiiruse.
• Laserprinterid vs trükikojad. Mitte nii võimsad, aga väikeste koguste trükkimiseks täiesti piisavad.
• Plastik vs metall. Eriti algusaegadel nõrgem ja vähem vastupidav, kuid odavam.
• Raketid vs suurtükid. Algul ebatäpsed, kuid lihtsamad kasutada – praeguseks efektiivsemad ja laiemas kasutuses.
• Kodukino vs päriskino.
• Süntesaatorid vs klaverid.
• Downloaditav muusika vs CD-d
• Mobiiltelefonid vs tavatelefonid
• VoIP vs GSM
• Elektroonilised postkaardid vs paberpostkaardid
• Mehitamata droonid vs mehitatud sõjalennukid
• Ultraheli vs MRI ja arvutitomograafia
• Internetipoed vs tavalised poed
• LCD vs CRT. Esimesed LCD-d olid oluliselt kehvema kvaliteediga kui CRT-d.
• Sinu lemmikinternetitehnoloogia vs MS Windows+MS Office
• jne jne.

Oluline tähelepanek on, et praktiliselt alati süüakse vana tegija turult pea täielikult välja. Näiteks IBM ei tooda enam personaalarvuteid. Miks?

Esiteks: kui meil on tegemist end turul sisseseadnud ettevõttega, on tema käive ja kasum tavaliselt küllaltki kõrged, investoritele on aga vaja kasvu. Väikesel internetifirmal on lihtne igal aastal mitukümmend protsenti käivet kasvatada, aga võtame näiteks Microsofti, mille käive läheneb 60 miljardile dollarile aastas. Et saavutada kahekohalist protsendikasvu, peaks Microsoft endale haarama või kusagilt tekitama uue kümnemiljardilise turu, selliseid aga lihtsalt ei eksisteeri naljalt. Ainuke kindel (aga radikaalseid uuendusi vältiv) kasvumootor on võimalikult hästi olemasolevat turgu teenida ning sellega satumegi ülalkirjeldatud olukorda.

Microsoftis on väga palju väga nutikaid inimesi, kes on kindlasti suutelised Youtube’e või Twittereid leiutama, kuid vastavad turud on (vähemalt esialgu) kaugelt liiga väikesed ning ebahuvitavad. Tegelikult toimub vastupidine: põhisuuna jaoks ebasobivad mõtted juuritakse pigem välja! Siis aga mööduvad aastad ning uute tehnoloogiate darvinistlikust konkurentsist kerkib esile mõni, kellest lähtuvale ohule on äkitselt lootusetult hilja reageerida.

Teiseks: edukas ettevõte on tüüpiliselt harjunud toimima olukorras, kus tegevust planeeritakse hoolega. Iga edukas juht teab, et oma turu tundmine on võtmetähendusega, ning keskendab oma tähelepanu sellele, et võimalikult hästi mõista oma kliente, konkurente ning muid faktoreid. Murrangulised tehnoloogiad hakkavad aga tüüpiliselt tegutsema turul, mida praegu üldse ei eksisteerigi, seega pole juhil ka võimalik seda turgu analüüsida ega midagi planeerida! Me kõik teame juhtumeid, kus üht või teist uut tehnoloogiat on taevani kiidetud, kuidas sellest saab kogu maailma tulevik, aga paari aasta pärast ei pole sellest enam kippu ega kõppu kuulda. Sellised näited muudavad iga juhi ettevaatlikuks, kuni taas kerkib esile tehnoloogia, mis osutub ikkagi edukaks, ja hammustab meid tagumikust.

Kolmandaks: suures ettevõttes toimivad tootmisprotsessid pole niisama lihtsalt allapoole skaleeritavad, et väikeses nišis edukalt tegutseda. Sama tootmisviis, mis tagab edu olemasoleval turul, on uuel turul hoopis takistuseks.

Neljandaks (kõige olulisem faktor): ”vanade” firmade kliendid pole muutusest huvitatud. Uus tehnoloogia on esialgu kehvem kui olemasolev ja miks peaks klient halvemale variandile üle minema? Ja nii monopoliseeritaksegi ettevõtte parim ressurss olemasolevate kasumlike klientide teenimiseks, mis takistab meil sisseharjunud rajalt kõrvale astumist.

Kui me arvame, et kõik need fenomenid leiavad aset ainult kusagil kaugel, siis eksime – täpselt sama efekt leiab igapäevaselt aset ka Eesti tarkvaraturul. Nimesid nimetamata teame me kõik kohalikul turul tegutsevaid ettevõtteid, mis pakuvad nö täisteenust: suure meeskonnaga tehtavat analüüsi, disaini, programmeerimist ja juurutamist. Neil kõigil tekib mingi miinimumlävi, millest odavamaid projekte ei hakata isegi mitte kaaluma.

Samas noolivad nende turuosa altpoolt pidevalt “Tarkpeade butiik” ning “OÜ Mees & Koer” tüüpi tegutsejad, kes on võimelised sama ülesannet mitte küll nii täielikult, kuid see-eest mitu korda odavamalt või kiiremini lahendama. Mingil hetkel hakkavad aga ka nemad muretsema selle pärast, kuidas oma olemasolevaid kliente võimalikult täielikult õnnelikuks teha, värbavad hulga uusi inimesi ning sama tsükkel jätkub – igaüks avaldab pidevat survet endast toiduahelas kõrgemal paiknejatele.

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

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.

Kes arvab, et kliendil on alati õigus?

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.

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

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.

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

Võrreldes seitsme ahvi looga, mille autentsus päris verifitseeritud polnud, kirjutan seekord täiesti pädevast organisatsioonikäitumislikust uurimusest.

Meil kõigil on olnud töökaaslasi, kes ümbritsevate inimeste elu ja motivatsiooni rikuvad. Loodusest on teada, et kui tünnis üks õun mädanema läheb, pole ka teistel pikka pidu. 

Samas arvatakse enamasti, et üksikisiku ja grupi vastuolu puhul pannakse üksikisikud pigem rühma poolt paika, mitte vastupidi. Grupikuuluvus on lõppude lõpuks väga tugev inimesi suunav ning motiveeriv jõud, mida on uuritud aastakümneid. Selgub aga, et mitmesugustest iseloomuomadustest kerkivad üles kolm, mis levivad nakkusena läbi terve grupi. 

Dr. Will Phelps Rotterdam School of Managementist korraldas järgmise katse:

Hulk üliõpilasi organiseeriti väikestesse rühmadesse, kus nad pidid 45 minuti jooksul lahendama ülesandeid ning võtma vastu lihtsaid juhtimisalaseid otsuseid. Edukaimale tiimile oli ette nähtud lahe auhind, nii et kõik olid motiveeritud endast parimat andma.

Osalejate teadmata oli mõnes rühmas aga värvatud isik, kes tegi küll ülesannet kaasa, aga näitas selle juures üles üht kolmest negatiivsest joonest:

1) Tülinorija tegi teistele häbistavaid märkusi nagu: “nalja teed või?”, “tead sa üldse ärist midagi?” jne. Ka õiendas ta kaaslaste kallal, et nende töö pole piisavalt hea, kuid ei soovitanud ühtki alternatiivi.

2) Laiskleja pani vahepeal jalad lauale ning saatis sõbrale SMSi. Või siis võttis kotist võileiva ning sõi seda. Teistega suheldes kasutas väljendeid nagu “ükspuha” või “mul vahet pole”.

3) Depressiivne pessimist istus pea maas ja tegi nägu, nagu oleks tema kass just ära surnud. Edasi kurtis ta, et nende ülesanne pole huvitav ning seadis kahtluse alla, kas sellega saadakse üldse valmis.

Kuigi rühmades olid üldiselt tublid ja andekad inimesed ning “tõrvatilk” ei jätnud iseendast tööd tegemata, avaldas tema lisamine dramaatilist mõju. Inimesed hakkasid vaidlema ja tülitsema, vähem suhtlema ja infot jagama. Samuti aga võtsid nad üle vastavad negatiivsed jooned. Tülinorija puhul hakkasid ka teised norima, aga mitte esialgset norijat, vaid ka kõiki teisi. Laiskleja puhul muutusid ka teised ükskõikseks ning pessimisti puhul kaotas kogu rühm oma esialgse erksa hoiaku ning vedeles lihtsalt, pea laual. Varem või hiljem ütles keegi midagi sellist nagu “ah, teeme lihtsalt midagi ära ja lähme”.

Kokkuvõttes oli paljude katsete järel “tõrvatud” rühmade keskmine produktiivsus 30-40% madalam kui teistel! Will Phelps kirjutab veel, et ka mitmetes päris töökohtades läbiviidud uurimuste alusel pole tiimitöö tulemuste ennustamisel parimaks näitajaks mitte parima liikme võimekus ja isegi mitte keskmise tiimiliikme võimekus, vaid kõige halvema, kõige nõrgema liikme oma!

Inimesed, kes nii käituvad, ei tee seda enamasti pahatahtlikult. Tegeliku elu tülinorija arvab näiteks, et ta lõõbib niisama ja loob kamraadlust. Phelpsi eksperimendis teised inimesed tihti naersid tülinorija naljade peale, aga kui neilt hiljem küsiti, kas nad tahaks veel selles tiimis töötada, oli nende vastuseks kindel ei. Pessimist arvab, et ta on lihtsalt aus, aga viib sellega ikkagi teiste energiataset alla jne.

Igal juhul küsin nüüd endalt tihti pärast selle uurimusega tutvumist, kas ma näitan üles üht neist kolmest joonest? Ja kui teie organisatsioonis on keegi taoline, juhtige küsimusele tähelepanu, enne kui terve tünnitäis õunu hukas on.