Mitä seuraavista it-hommista tehdään enää lähitulevaisuuden Suomessa
- java, .net, php koodaus
- c , delphi koodaus
- määrittely, suunnittelu
- dokumentointi
- testaus
- käyttöohjeiden laatiminen
- puhelin email -supportointi
- kuvankäsittely
- html, css, nettisivut
- flash, animaatio, 3D
- projektinhallinta
- projektinjohto
- konsultointi
- kouluttaminen
- muu, mikä?
- java, .net, php koodaus
- c , delphi koodaus
- määrittely, suunnittelu
- dokumentointi
- testaus
- käyttöohjeiden laatiminen
- puhelin email -supportointi
- kuvankäsittely
- html, css, nettisivut
- flash, animaatio, 3D
- projektinhallinta
- projektinjohto
- konsultointi
- kouluttaminen
- muu, mikä?
Vastaukset 14
Vanhimmat
Kyllä kaikkia mainitsemiasi tehtäviä tehdään myös Suomessa. Ei siis kannata yleistää muutamia negatiivisia uutisia, Kiina-ilmiö koskettaa kuitenkin varsin pientä osaa koko työvoimasta.
Se tosin täytyy sanoa, että bulkkiosaamiselle IT-alalla ei ole enää kovin paljon käyttöä. Ilmiö on ihan sama kuin rakennusalalla joku kymmenen vuotta sitten. Silloin raksalle pääsi töihin vaikkei osannut muuta kuin kantaa lautoja. Ei pääse enää.
Mitä ikinä teetkin, opettele se kunnolla. Vaikka paljon puhutaan moniosaajista sillä monesti tarkoitetaan ihan itsestäänselviä asioita kuten se, että ohjelmoija ymmärtää tekemiensä valintojen vaikutuksen järjestelmän turvallisuuteen. Samoin tulisi tietysti hallita riittävästi menetelmiä, kieliä, kantoja ja alustoja jotta kykenisi valitsemaan parhaat menetelmät projektiinsa. Oikeasti tämä ei ole iso vaatimus silloin kun pohjakoulutus on kunnossa ja osaaminen on syntynyt muutamasta eri projektista ja firmasta.
kun työpaikkailmoituksissa lukee, että teemme niin ja niin kriittistä järjestelmää ja työkaluina käytämme näin ja näin eksoottisia kehitystyökaluja.
Ei tarvii kovin nörtti olla löytääkseen bugilistan ao. kehitystyökaluilla tehdyn järjestelmän tietoturvaongelmista.
Mutta asiakas on aina oikeassa, olkoon sovelluskokoonpano kuinka hidas tahansa ja kuinka laajentamismahdoton tahansa, niin se tehdään sillä millä pomo sanoo ja mistä asiakas maksaa.
Jos menet sanomaan, että parempikin kehitystyökalu tämän toteuttamiseen olisi, niin olet näsäviisas, besservisser, yhteistyökyvytön, toisinajattelija, erakko jne.
Toisten varpaille ei saa astua edes hienovaraisesti, vaikka tietäisi kehitystyökalut paremmin kuin omat taskunsa, tai suomenkielen.
tehdä paskatyökaluilla, paskaalustoille jotain paskaohjelmia, jotka on niin hitaita et asiakkaaltakin menee hermot?
Ajattele positiivisesti palkka sentään juoksee.
Onneks en oo ikinä joutunut vääntämään työkseni ym. sontaa vaikka softa koulutus minulla onkin...
Yleensähän projektien aikataulut/työmääräarviot on vedetty niin tiukalle, että kunnollista dokumentaatiota ei ehditä tekemään ;)
Kun tehdään tarjousta otetaan jo kaikki turhat työvaiheet pois, kuten dokumentointi.
Asiakas voi hoitaa testauksen ja sieltä saa hyvät bugiraportit, joten senkin voi jättää tarjouksista pois.
Pääasia että firma saa tilauksen, eiks nii?
Raakaa peliä IT alalla.
"Kun tehdään tarjousta otetaan jo kaikki turhat työvaiheet pois, kuten dokumentointi."
Kun sitten toinen firma joutuu koskemaan toisen tekeleeseen, alkaa verisuonet pullistumaan päästä, kun myynti on myynyt projektin eikä tietenkään kukaan ota hinnassa huomioon, että siitä toisen tekeleestä puuttuu dokumentaatio.
Itse perushomma voiskin olla nopeasti tehty, mutta järjestelmien nykytilanteen selvittämiseen sitten palaakin tunteja ja paljon, kun ei ole minkäänlaisia dokumentaatioita.
Pahimmassa tapauksessa projekti meinaa mennä punaselle ristille ja pomot kiukuttelee ;)
asiakas on testannut ja periaatteessa hyväksynyt toimituksen, muttei suostu maksamaan ennen kuin dokumentaatio on toimitettu.
Bugikorjaukset on tehty jo ja dokuja ei tarvii enää korjata - ne raapastaa kasaan muutamassa tunnissa leikkaa ja liimaa periaatteella ohjelman valikoista selityksineen.
Missään ei sanota, että pitääkö dokumentaatiossa kertoa mitä ohjelma tekee, ainoastaan se miten sitä käytetään.
Kerrankin luin tämmöstä dokumentaatiota ja totesin niin niin mutta mikä sen sovelluslogiikka painikkeiden takana on, osaan minä itsekin painikkeet suomentaa muutamalla rivillä tekstiä...
Jos ei dokumentoija ymmärrä ohjelmasta mitään, niin tämmönen on sitten lopputulos. Ja asiakas saa haluamansa dokumentaation mopon tekemänä, kun konsultit on jo seuraavan projektin kimpussa.
"Yleensähän projektien aikataulut/työmääräarviot on vedetty niin tiukalle, että kunnollista dokumentaatiota ei ehditä tekemään ;)"
Yleensä? On niitä tietysti paljon kaikenlaisia huuhaafirmoja, joissa datanomit kasaavat pienyrityksille jotain PHP- tai VB-räpellyksiä, ja niissä ei kovin usein dokumentointia harjoiteta.
Mutta kyllä keskimääräisessä ohjelmistofirmassa tehdään vähintään riittävä määrittelydokumentaatio toteutettavasta järjestelmästä jo pelkästään sen vuoksi, että sitä voidaan käyttää sopimuksessa pohjana.
Suunnitteludokumentit taas kannattaa tehdä jo pelkästään sen vuoksi, että tällöin oman firman toimintaa saadaan tehostettua huomattavasti. Järjestelmän toteuttamiseen menee aikaa ilman suunnittelua moninkertaisesti verrattuna siihen että suunnittelu tehtäisiin kunnolla, joten projektin aikataulutus ei voi olla mikään este. Sama juttu myös yksikkötestauksen osalta: Testitapaukset ja testimoduulit kannattaa usein melkein kirjoittaa etukäteen suunnitteludokumentaation pohjalta ennen varsinaista koodinkirjoitusosuutta.
- java, .net, php koodaus
Java tulee varmaan jatkossakin olemaan melko vahvassa asemassa erityisesti isommissa yritysprojekteissa ja WWW-palvelinpuolella sekä ennen kaikkea matkapuhelimissa ja muissa sulautetuissa laitteissa.
Dotnettiin ei kannata panostaa, koska sen käyttömahdollisuudet ovat hyvin rajalliset MS-riippuvuuden vuoksi. Sama pätee kaikkiin Visual-alkuisiin kieliin ja C#:iin.
PHP:n suosio todennäköisesti ja toivottavasti hiipuu muutaman vuoden sisällä. Se saattaa kuitenkin olla hyvä osata vielä muutaman vuoden ajan mainostoimistotyyppisissä firmoissa; tosin kannattaa panostaa erityisesti vitos- ja kutosversioon. Nekin ovat melkoisia leluja, mutta vähemmän kuin nelosversio. Esim. Ruby saattaisi hyvinkin syrjäyttää PHP:n lähitulevaisuudessa. Ominaisuuksiltaan se on valovuosia edellä esimerkiksi PHP:n kutosversioon verrattuna.
- c , delphi koodaus
C tulee varmasti jatkossakin olemaan suosittu, mutta ehkä mielekkäämpää olisi opetella C. Oliopohjaisia kieliä on olemassa järkevämpiäkin kuin C ja laitteistoläheisessä ohjelmoinnissa taas C on käytetyin kieli. Useimmat C -projektit sopisivat toteuttavaksi jollain muulla kielellä kuin C :lla.
Delphin ongelma on alustarajoittuneisuus. On tietysti Kylix, Lazarus, jne. mutta silti on vaikea nähdä mitä parempaa niissä olisi muihin kieliin verrattuna. Pascal oli alunperin vain opetuskäyttöön suunnattu kieli, jonka vuoksi se ei välttämättä sovellu parhaalla mahdollisella tavalla oikeaan käyttöön.
- määrittely, suunnittelu
Aina tärkeää osata.
- dokumentointi
Samoin.
- testaus
Kyllä. Erityisesti yksikkötestaus osana ketteriä ohjelmistokehitysmenetelmiä.
- käyttöohjeiden laatiminen
Riippuu paljon tilanteesta. On hyvä tietysti osata.
- puhelin email -supportointi
Jos tarkoituksenasi on toimia asiakaspalvelijana.
- kuvankäsittely
Jos tarkoituksenasi on tuottaa grafiikkaa. Tuskin graafisen alan ammatit ihan hetkessä katoavat maailmasta...
- html, css, nettisivut
Jos teet WWW-sivuja tai sovelluksia, jotka toimivat WWW-pohjaisesti. HTML 4:n ja CSS 2:n standardit on hyvä osata myös tulevaisuudessa.
- flash, animaatio, 3D
Ehkä jos haluat pelejä tehdä?
- projektinhallinta
- projektinjohto
Jos haluat johtaa projektia...
- konsultointi
Vaikeampi opetella, vaatii lujaa erikoisosaamista tietyltä alueelta. Eiköhän konsulteillekin ole kysyntää aina tulevaisuudessakin.
- kouluttaminen
No eiköhän tulevaisuudessakin synny uusia ihmisiä koulutettavaksi...
- muu, mikä?
Varmasti joku asia voi olla hyvä osata jo lähitulevaisuudessa, jota ei ole vielä edes keksitty. Ikuinen halu oppia uutta ja kehittää itseään pitää olla.
On toi Java ihan ok, jos tekee jotain kevyttä ohjelmointia.
Javan voikin sitten unohtaa, jos alkaa jotain vähänkin raskaampia operaatioita tekemään.
hidas hidas hidas...
C:n jälkeen ei ole kovin vaikea oppia C :aa
Useimmiten Javaa käytetään client - server ratkaisuissa, joka ei ole erityisen kevyttä, mutta sopii aivan erinomaisesti Javalla toteutettavaksi. Nykyisillä koneilla melko harvoissa hyötysovelluksissa laskentateho muodostuu käytettävyyden näkökulmasta pullonkaulaksi.
Siis sellaisia, joita väännetään J2EE:llä, .NET:llä (esim. C#). Kyllä siitä itku pääsisi. C ei juurikaan omaa mitään sellaisia ominaisuuksia, joita tarvitaan kun tehdään isoja järjestelmiä, joten kaikki pitää vääntää alkutekijöistä asti. Siis ei mitään järkeä, eikä hyötyä.
Matalamman tason pikkusoftien tekemiseen C sopii ja peleihin ja kännykkäsovelluksiin ainakin vielä toistaiseksi.
No et kai luule että tulevaisuudessa kaikki maailman softat on niitä isoja tietojärjestelmiä? Yhtä suurta tietojärjestelmää kohden on kymmenen pienempää ja suuri osa c:llä/ c :lla toteutettua. Eikä ne pienemmät softat häviä tulevaisuudessakaan minnekään. Lisääntyy vaan. Sitä myöden C tai C ei tule häviämään vielä pitkiin aikoihin.
et vaan osaa :)
mut tietty stl, boost yms kirjastot auttaa kovasti