Targo tarkvara

Ajendatuna ilmselt hiljuti populaarsust kogunud filmist Sotsiaalvõrgustik, küsis üks sõber mult, miks mina Facebooki ei leiutanud. Olin muidugi kõrvust tõstetud sellise kaudse hinnangu üle oma võimekusele, aga pidasin siiski vajalikuks õiglus jalule seada ja talle põhjendada, miks minust kunagi Mark Zuckerbergi vmt internetimiljardäri ei saa.

On väga levinud eksiarvamus, et millegi leiutamine ja rikkaks saamine seisab eelkõige briljantse idee taga. Tuleks vaid õige mõte ja kõik läheb nagu lepase reega. Tegelikult kehtib muidugi Edisoni ütlus, et geenius on 1% inspiratsiooni ja 99% perspiratsiooni. Facebook kasvas välja tavapärasest üliõpilaste isikuandmete andmebaasist, milletaolisi oli maailmas kümneid tuhandeid. Zuckerbergil oli muidugi kõvasti õnne, aga eelkõige oli tal maniakaalset eesmärgipärasust, töövõimet ning soovi olla esimene. Ilma nende omadusteta poleks temast keegi kunagi kuulnud ja need omadused on olemas eranditult kõigil edukatel ideerealiseerijatel Thomas Edisonist Bill Gatesini (või minu poolest Taavi Kotkani). Ärimaailma ideedel põhinev osa on halastamatult võistluslik, aga seda mitte sellepärast, et headest ideedest puudus oleks, vaid sellepärast, et müriaad leidureid püüab oma ideid teiste omadest kõrgemale upitada.

Lõppkokkuvõttes on suhteliselt vähetähtis, kes mingi idee peale algselt tuli. iPhone, mida vahel pea innovatsiooni etaloniks peetakse, sisaldas tehnoloogiliselt vaid inkrementaalseid uuendusi, kõik põhikomponendid olid juba ammu enne seda olemas. Oluline oli aga teistest parem teostus disaini  ja käepärasuse vallas. Samamoodi osutub Winklevosside ja Patersonide hädakisa selle üle, et nende ideid on ebaõiglaselt ära kasutatud, küllaltki narriks – idee kui sellise väärtus on müüt, tähtis on teostus.

Ja kui keegi kurdab (ning neid kurtjaid olen ma kohanud palju-palju), et oh, oleks vaid hea idee, teeniks sellega palju raha, siis pole nende tegelikuks sooviks mitte ägeda idee realiseerimine, vaid igatsus taevast sülle langeva lotovõidu järele. Muidugi eksisteerib ka akrobaaditrikke nagu Million Dollar Homepage või Punane kirjaklamber, aga neid esineb suhteliselt harva ja tõeliselt rikkaks keegi nendega ei saa.

Esialgse küsimuse juurde tagasi tulles: selles, et mul Facebook “leiutamata” jäi, polnud süüdi mitte ideedepuudus. Ideid on mul nagu putru, võin soovijatele jagada kui vaja. Tegelik põhjus on mõistagi selles, et ma olen selle ala suurmeistritega võrreldes kaugelt liiga laisk ja mugav, et end vastaval määral millegi realiseerimisele pühendada. Ja sama probleem on ka neil kurtjatel

Tavaliselt ma päevakajalistest asjadest ei kirjuta, aga hiljuti käsitles Kotkas Äripäevas teemat, mis mulle endalegi sügavamalt korda läheb. Täpsemalt ütles ta:

Kui me suudaks inseneride hulka kordades suurendada ehk siis populariseerida oluliselt rohkem reaalharidust, oleksime ka oluliselt rikkam riik. Miks me ei taha olla insenerirahvas? No ju siis meile ei meeldi parem elu.

Enamik ühiskondlikust diskussioonist käib tänapäeval selle üle, kuidas mõnel on liiga palju, teisel liiga vähe, kuidas anda, kuidas võtta ja kuidas üleüldse on elu väga karm, kole ja ebaõiglane.

Selle asemel võiks aga ju keskenduda küsimusele, kuidas meie ühist pirukat suuremaks kasvatada, mitte pisikest jupitada. Suurim ühiskondlik väärtus tekib tänapäeval eelkõige uute asjade väljamõtlemise, elluviimise ning efektiivse tootmise kaudu, selleks aga on vaja:

1. Insenerkonda, kes vastavate tehniliste lahendustega hakkama saaks.
2. Ettevõtjaid, kes neile inseneridele hea loomekeskkonna rajavad.

Praegu on Eestis võrreldes nt USA, Jaapani või Soomega mõlemast struktuurne puudus ja kuni see ei muutu, ei kasva ka meie pirukas. Loomulikult ei teki kumbki klass inimesi iseenesest, selleks on omakorda vaja järgmisi muutusi inimeste suhtumises:

1. Au sisse tõsta ratsionaalne maailmakäsitlus ja kriitiline mõtlemine. Mingil kombel oleme vajunud intellektuaalsesse sohu, kus isegi “kvaliteetajakirjandus” käsitleb tõemeeli homöopaatiat ja UFOsid kõrvuti päris teemadega ning keegi ei vaevu mõttevirkust üles näitama ning kirjutajat liistule tõmbama, kas ta oma väiteid ka kaitsta suudab.
2. Edendada harjumust probleeme lahendada. Eestis muidu toredate kohalike progejatega koos töötades tuleb mul teinekord nutumaik suhu, kui keegi jälle ütleb, et oi, see on nii keeruline asi, mina küll ei tea, kuidas seda teha või uurida. No mis siis, et keeruline, hakka kusagilt servast harutama ja küll ta välja tuleb. Aga näed, ei oska isegi harutama hakata.
3. Tõsta ettevõtluse mainet. Paljude eestlaste jaoks on ettevõtja ikka suli ja kaabakas, mis on tohutu kontrast nt USA suhtumisega, kus antakse aru, et ettevõtja on see, kes tekitab teistele töökohti ja aitab neil ühiskondlikku väärtust luua. Ameerikas töötades puutusin kokku nt keskealise naisega, kes töötas UPSi kontoris, kuid unistas oma eradetektiivibüroost, orienteerujaga, kes eksportis puitu Jaapanisse, süsopiga, kes sebis töö kõrvalt väikest plaadistamisettevõtet teha jne jne, kõigil oli ettevõtmispisik sees ja ümbritsevad inimesed respekteerisid seda.

Muidugi ei muutu ka inimeste suhtumine üleöö, selle aluseks on omakorda haridus. Konkreetsete ideedena:

1. Vähendada laste hirmu reaalainete, eriti matemaatika ees, seostades seda rohkem tegeliku eluga. Näidata lastele, kuidas maailm töötab, sealhulgas tehnoloogia ja majandus, ning kuidas matemaatika on selle aluseks.
2. Õpetada oluliselt rohkem loogikat. Praegu on algklasside matemaatikatunnid ainult üks suur arvutamise õppimine. Kunagi olid 3 klassi õpikutes sees näited stiilis “see lause on väär” või “kui päike paistab, siis on ilm soe”, praegu ma sellise alusstruktuuri loomist sealt enam ei leidnud. Kui meil on seljaajusse jõudnud peamised süllogismid ning meetod, kuidas ühtedest faktidest teisi tuletatakse, jääb ühiskonnas ka igasugust häma palju vähemaks.
3. Integreerida matemaatika ja füüsika õpetamine. Praegu on matemaatikaõpetajad tihti kimbatuses, kui neilt küsitakse, miks mul seda ruutvõrrandit (või vektorit või tuletist) vaja on? Kui aga kohe pärast matemaatikatundi teha füüsikatunnis praktilisi ülesandeid sellest, kuidas rakett ümber Kuu lendab, asetuvad ka vektorid oma kohale.
4. Rohkem esimesest klassist algava reaalainete süvaõppega koole. Praegu on neid Eestis minu teada vaid üks, ennast targaks linnaks pidavas Tartus aga võib su laps olla ükskõik kui suur tehnika ja matemaatika huviline, variante pole.
5. Matemaatika riigieksam. Selle kohustuslikkuse kaotamine ning matemaatika tundide asendamine ajaloo ja muu humanitaariaga on minu arvates maksnud Eestile tänaseks peaaegu 10% SKP-st. Kui eksamit peetakse liiga raskeks, olgu siis nt A ja B variandid erinevate raskustega, aga mitte olukord, kus terve keskkooli vältel on võimalik reaalaineid täielikult ignoreerida. See ei tähenda muuseas, et kõik peaks ülikoolis mingit seonduvat eriala edasi õppima, aga ka torumees või elektrik, kes on saanud koolis kirjanduse ajaloo asemel ekstra füüsika tunni, on arvatavasti produktiivsem. (Paneme tähele, et teatrikriitiku kohta vastupidine näide ei kehti!)
6. Füüsika ja tehnikakallakuga koolid (või vähemalt üks kool). Mitte lihtsalt reaalkallakuga, vaid selline, kus on juba põhikoolis füüsika fakultatiivkursused.
7. Lapsevanemates arusaam, et reaalained tagavad edu. Pärast Eesti vabanemist tekkis ühiskonnas mingil moel mõtlemine, et vaja on õppida eelkõige keeli, kõnekunsti ja avalikkussuhteid. Need kõik on vajalikud, kuid ei muuda fakti, et IT-spetsialist, keemik või aatomiinsener teenib maailmas keskmiselt oluliselt rohkem kui tõlk või PRi tegija.

Ehk siis kokkuvõttes saame järgmise pildi:

Ja kui ära teeme, oleme viie (ja mitte teistest aeglasemalt kasvava Euroopa, vaid maailma) rikkaima riigi seas nagu naksti. 

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…

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.

Sellekevadine Tartu Ülikooli projektijuhtimise kursuse epopöa on vähemalt minu jaoks selleks korraks otsa saanud ja kõik eksamitööd parandatud.

Kokkuvõttena torkavad üliõpilaste töödes silma mitmed ühised jooned, millest mõned, kui neid päris elus rakendada, rohkem või vähem eepiliste projektifeilidega lõppeks (neil, kes korralikult loengus käisid, läheb muidugi paremini )

Eksamil tuli kirjutada järgmist (kõik punktid olid enne teada):

• Mingi tarkvaraprojekti kirjeldus
• Projekti etapid
• Projekti tehnoloogilised osad
• Projekti kalkulatsioonid
• Meeskonnamudel
• Ja lõpuks üks suur tabel kirjeldamaks, kes, mida ja miks projekti vältel teeb.

Esimese asjana jäi paljudele segaseks, millised kulud ühe projekti või ettevõtte juhtimisega kaasnevad. See tähelepanek ei ole isegi mitte tarkvaraspetsiifiline, aga rakenduks ka suvalisele muule projektile.

Erilist äramärkimist vajab siin see, et paljud ei tea, millised on tegelikult Eesti maksud. Mitmed tulid tulu-, aga mitte sotsiaalmaksu peale, mitmed eeldasid aga lihtsalt, et projekt täpselt nii palju maksabki, kui palju raha nemad koju viivad. Oleks elu vaid nii lihtne

Loengus oli toodud arvutus, mille järgi kujuneb programmeerimistöö tunnihind järgmistest komponentidest:

• Tehniliste töötajate netopalk.
• Tulu-, töötuskindlustuse ja sotsiaalmaks - Eesti ettevõtete tegelik palgakulu oli kuni viimase ajani 1,71*netopalk, aga maksud kipuvad viimasel ajal ebastabiilsed olema.
• Kontorikulud. Siia alla kuuluvad suurima kuluna mittetehniliste töötajate (juhtkond, raamatupidamine, müügipersonal, IT tugi, ilus tüdruk ees lauas jne jne) palgakulud ja teiseks üür, elekter, riistvara amortisatsioon jne. Kontorikulud kõiguvad ettevõttest ettevõttesse muidugi suuresti, aga võiks arvestada viiekohalise summaga iga tehnilise töötaja kohta kuus.
• Puhkuste ja haigepäevade tasu, kus väärtust ei toodeta, aga palgakulu jookseb edasi.
• Tööaja sisene ebaefektiivsus. Kui mingi asi võtab 10 tundi programmeerimist, siis ei tähenda see sugugi mitte kümmet tööl istutavat tundi. 70% efektiivsus on enamasti super tulemus, enamik organisatsioone jääb oluliselt alla selle.
• Ettevõtte kasumimarginaal.

Konkreetsed arvud võib igaüks siia nüüd ise asendada ja kokku korrutada – tulemuseks on nii mõnegi inimese jaoks ehmatamapanevalt suured käärid. Nende asjaolude mittearvessevõtmine oleks päris elus nii mõnegi särasilmse firma pankrotti viinud.

Teiseks, kui midagi kirjutad, siis tunne oma lugejaskonda.

Mitte ilmaasjata ei tulnud küsimustes projekti struktuuri mitu korda kirjeldada:

• Üks neist vaadetest on kliendile (kes tahab lihtsalt lühidalt ja konkreetselt teada, mida ja mis ajaks ta saab)
• Teine on juhtivale tehnilisele personalile (kes tahab teada, milliseid metoodikaid ja tehnoloogiaid me kasutame)
• Kolmas on projekti igapäevastele osalistele (kes tahavad teada, mida mingil päeval plaanitakse teha)

Ja last but not least, tuleb arvestada õppejõuga, kes selle kõik läbi vaatab, et kas inimene on kursusest ka midagi kõrva taha pannud või imes kogu jutu lihtsalt pastakast välja

Paljudes töödes oli näha suhtumist: mina olen vinge programmeerija, progemine on ainus asi, mis loeb, tean kõike kõige paremini ja ei pea teistele midagi selgitama. Bzzzt, selline suhtumine seab inimese karjäärile üldjuhul olulise tõkke, rääkimata olukordadest, kus projekt hävib seetõttu, et kliendile jäid asjad segaseks.

Ja lõpuks: sõbrad, õppige kirjutama.

• Ärge kirjutage poole lehekülje pikkusi lõike, neid ei viitsi ükski klient lugeda.
• Vaadake, et professionaalne tekst annaks edasi võimalikult palju konkreetseid detaile.
• Kasutage teksti ilmestamiseks jooniseid või kasvõi bullet pointe, et oleks võimalik ühe pilguga haarata, millest jutt käib.

Ja korrektne on kirjutada standardne, kontseptsioon, stsenaarium ja mõttetu, vastasel korral arvab iga haritum klient, et te olete lohakad ja kirjutate koodi ka üle jala.

Kokkuvõttes oli tegemist aga vähemalt minu enda jaoks hinnalise kogemusega, loodetavasti said ka kuulajad oma filosoofilisele potentsiaalile lisa. Ülaltoodud kaebustest hoolimata olid mitmed tööd täitsa head ja nende autorid (te teate, kes te olete ) võtan ma vajadusel kindlasti oma kampa.

Majandusteadusliku definitsiooni järgi on rahal kolm peamist rolli:

• Vahetusvahend (et me ei peaks oma tarkvara otse ülikondade ja pirukate vastu vahetama)
• Arveldusühik ehk väärtuse mõõt (et me saaks aimu, mitu pirukat meie tarkvara väärt on)
• Akumulatsioonivahend (pirukaid ja Windows Vista karpe teatavasti tagavaraks ei kogu)

Igapäevasuhtlemises on rahal aga tihti kehv aura, raha seostatakse peamiselt asjade, kulutamise ning tarbijalikkusega.

Ma ise olen eluaeg vilets tarbija olnud, aga raha meeldib mulle sellegipoolest. Täpsemalt meeldib mulle idee raha teenimisest kui väärtuse loomisest.

Konkreetselt tarkvara kontekstis: vaba vs kommertstarkvara on väga poleemiline teema, mille üle vaieldakse hääli kähedaks ja kulutatakse klaviatuure auklikuks. On inimesi, kelle arvates tarkvara eest raha küsimine on võrreldav kutsikate piinamise ja muude koledustega. On inimesi, kes teevad tarkvara lihtsalt sellepärast, et neile meeldib tehnoloogia ja asjade kallal nikerdamine. Kas sellest tarkvarast ka kellelegi kasu on, pole nende jaoks nii väga oluline, nad saavad oma rahulduse lihtsalt asjaga tegelemisest.

Samas, kui ma teen valmis mingi tarkvaratüki ja selle eest raha saan, tähendab see, et ma olen maailmale lisanud konkreetselt selle rahahulga eest lisaväärtust, sest kellegi arvates oli tegemist piisavalt hea asjaga, et selle eest maksta. Mida rohkem makstakse, seda suurem on kliendi silmis minu tarkvara väärtus ja seda rohkem olen ma asjaga rahul.

Seega, mõtteviisis, mille järgi me tahame oma tarkvara eest võimalikult palju raha saada, pole midagi halba ega koledat, sest see sunnib meid pidevalt mõtlema, kuidas oma tarkvara kasutaja jaoks võimalikult väärtuslikuks teha. Ainult tehnoloogilisele aspektile keskendumine tekitab situatsiooni, kus programmeerija meelest on tegemist millegi ülivingega, aga kasutaja kehitab sellegipoolest õlgu, sest konkreetselt tema mugavuse peale pole keegi mõelnud.