Mari-Liisi ITSPEA blogi

Arendus ja ärimudelid on asjad mis käivad käsikäes, ning mis mõlemas osas peavad olema paindlikud. Sellest annab ka aimdust väljatöötatud metoodikate arvukus.  Nüüd mis puutub reaalsesse töösse, siis tihtipeale ongi nii, et vastavalt sellest milline on sinu klient, milline on suhtlus kliendiga - sellest tuleneb ka metoodika mida arenduses kasutatakse. Sellest omakorda tulenevalt on üsna harv olukord, kus tehakse puhast Scrummi või puhast Waterfalli - enamasti mikstiakse mitut metoodikat kokku. Halb on olukord, kus ollakse kinni nö koolis õpitust - st ülikoolis tehakse selgeks, et Waterfall on sisuliselt see kus analüüs on ette valmis tehtud, nüüd kui töötan riigihangetega ja analüüs on ette tehtud, siis järelikult teeme selles üüratus projektis puhast Waterfalli ning välja tuleb SKAIS 2. SKAIS 2 ei ole muidugi erand, neid natuke keeruliselt lõppenud riigiprojekte on mitmeid, kus tulemus ei ole ühegi osapoole jaoks positiivne. Samas ma leian ka, et rakse on teistsugust tule

See on huvitav, kuidas IT-s tõesti on kirjutamata reeglid, millest kinni pidamine teeb ühe arendaja ARENDAJAKS. Ka meil Eestis on hinnatud pigem oskustega arendajad olenemata nende kraadist. Tihtipeale on arendajad enne kooli lõppu, osadel erandjuhtudel enne ülikooli algust, IT firmadesse ära värvatud. Küll aga oma töökohta silmas pidades, on igapäeva arenduses veel olemas mingid veidrad ootused töötaja suhtumisele, mis juskui kirjeldavad tema professionaalsust, aga mida koolis ei õpi: Probleemilahendus on kunts.  Probleemi lahendusse tuleb läheneda loominguliselt. Probleemidel ei ole õiget ega valet vastust ning teatud olukordades sa ei saagi teada mis oli õige ja mis vale. Enamasti on klient, kes udutab aiast, kui ta probleem on ikkagi selles augus aia sees ning selle parandus on asi, mida ei saa tingimata hinnata 1-5ni. St probleemi lahendus ei ole koolitöö kus on õige ja vale vastus Laiskus on voorus.  Mina omakorda olen arvamusel, et minu koodikirjutamise oskuse edasivi

Millegipärast on käibel endiselt ajast ning arust lähenemine, et IT-s on võimalik karjääri teha järgmiselt:  1) kõigepealt alustad nooremarendajana 2) seejärel liigud arendaja ja sealt edasi vanemarendaja positsioonile 3) siis tihtipeale saavad IT firma aru, et ahah - seda meest/naist ei tohi lasta kusagile minna ja ta on väga kasulik 4) Siit edasi edutatakse arendaja tiimi juhiks või arenduse juhiks või juhtide juhiks - asja iva on selles, et eeldatakse väga pädevast arendajast ka ühtäkki head oskust inimesi ja arendusprotsessi juhtida ning klientidega suhelda.   Nüüd siin lähevad asjad minu arust natuke valesti - ja seda mitmel põhjusel.  Esmalt asutus jääb endale vajaminevast ressursist ilma - hea arendaja, seda enam firma jaoks ei ole.  Teisalt nõuded juhile on kõike muud, kui oskus hästi tarkvara arendada. Seega võetakse oma ala spetsialist ja üritatakse teda pressida täiesti teise valdkonna raamidesse, eeldades head tulemust, sest et endiselt - ta ju oskab hästi