Minu arvates on tänase seisuga väga raske saada laia valdkonna profiks, selleks peab kindlast kas annet olema või väga-väga suur motivatsioon asjas parim olla, kuid tavainimesene saab olla prof kitsamates valdkondades (näiteks progeja on 10 aastat kirjutanud pythonit ning see teeb ta pythoni profiks, kuid ei tee seda inimest IT profiks). Usun, et tänapäeval on profiks saamiseks vaja väga palju eeldusi ning nendest kõige tähtsamad oleksid vast kogemus, haridus ja motivatsioon. Haridus on suureks eelduseks leidmaks endale head töökohta ning haritud inimestel on sageli paremad suhted oma ülemustega ja rohkem baasteadmisi. Ning haridust on samuti eelduseks saamaks kogemusi erinevates valdkondades (näiteks erinevates sektorites: riigi-, erasektoris) ning juba see eeldab vähemalt 3 aastat ülikoolis ning sellele lisaks ka tavajuhtudel (keskmine inimene) ning tõenäoliselt freelancimist ja palju higi. Kõige tähtsamaks eelduseks on minu arvates motivatsioon. Kui on motivatsiooni iga päev midagi uut vaadata ja teada saada, siis lõpuks tuleb kindlasti ka tulemus, isegi kui tegemist pole kõige teravama pliiatsi tüüpi inimesega. Otsustuskindlus ja raske töö tulemusena usun, et inimesed võivad saavutada oma unistused. Mis aga omadustesse puutub, siis juba eelnevalt sai välja toodud, et prof võiks olla motiveeritud ja otsusekindel, lisaks peaks IT prof oskama n.ö kastist välja mõelda ning nutikus ja tahe probleemile lahendus leida oleksid ka väga kasuks. Ning vajalikest oskustest saaks välja tuua mõne proge keele oskus (hea, kui on ettekujutus, kuidas arvuti töötab), oskus materjali läbi töötada ja aru saada. Enamasti aga oskus oleneb sellest, mis valdkonna peale prof spetsialiseerub.
Mina analüüsisin kosemudelit ehk "waterfalli" ning tegin seda Toyota näitel. Kuigi Toyota tänapäeval ei kasuta enam seda mudelit, tegi ta seda vanasti. Lugesin läbi artikli, kus küsitleti Satoshi Ishiit, kes on Toyota tarkvaraarenduse juht. Artiklis Ishii kirjeldab, kui halb ja mittesobilik on kosemudel tarkvaraarenduse jaoks. Ta ütleb, et suurimad miinused on see, et koodi ei saa selle mudeli põhjal testida enne kui arenduse etapp on tehtud ning see toob kaasa väga palju riske ja läbikukkumisi. Samuti mainib ta, et mudel loodi siis, kui tarkvara osa firmast oli väike ning autodel ei olnud palju elektroonikat. Ehk mida lihtsam oli tollel ajal mudelist aru saada, seda kergem ülesandeid jagada jne, millega antud mudel saab väga hästi hakkama ning see on selle mudeli üks suuremaid plusse, et kõik on ühisel arusaamal: mida peab tegema ja kuhu firma tahab jõuda. Ishii mainib, et neil on vaja väga palju muudatusi teha, et nende projektide kood oleks normaalne ja n.ö lean, sest mid...
Comments
Post a Comment