firmassamme on käytössä kompetenssiin (osittain) perustuva palkkaus. Tuon kompetenssin on sitten joku ohjelmoinnista täysin pihalla oleva pomo määrittänyt, mielestäni pikemminkin naamavärkin ja puhetaitojen perusteella kuin raa'an osaamisen. Onhan tästä asiasta olemassa myös hieno excel-kaavio, jossa jokainen kompetenssitaso on määritetty. Käsittääkseni saattaa olla myös niin, että "vanhoille" työntekijöille on määritetty kompetenssitaso vuodelta nakki, jolloin ko excel-kaaviota ei ollut olemassakaan. Suhteessa tähän excel-kaavioon heidän kompetenssitasonsa on siis väärin mitoitettu
Mikä tässä kummastuttaa on se, että minut on rankattu alemmaksi kuin ne, jotka ovat kauemmin olleet talossa. Näiden henkilöiden pitäisi siis olla kyvykkäämpiä kuin minä. Excel-kaaviossa heidän kompetenssitason kuvaansa määritellään mm GoFfin design patternit. Silti näille henkilöille ei sano sellaiset eriskummallisuudet kuin strategy, template method tai decorator mitään, asiasta päättäville pomoille vielä vähemmän.
Mielestäni lähes laittomaksi asian tekee se näiden "kyvykkäämpien" ihmisten ei ole päästäkseen tuolle tasolle tarvinnut selvittää SCWCD-tutkintoa (koska heidän vanhat kompetenssitasonsa ovat edelleen voimassa, eivätkä kyllä ole selvittäneetkään). Jotta voisi selvittää ko tutkinnon pitää olla ensin selvittänyt SCJP-tutkinnon. Jokainen, joka on joskus testannut näitä testejä tietää, kuinka sivuseikkoihin, detaljeetasoihin ja kompakysymyksiin ne johtavat (esim tein juuri SCWCD-testin jossa JSP ei olisi kääntynyt koska siinä oli välilyönti liikaa, ko kysymys täysin teoria-painoitteinen kysymys, todellisen työn kanssa sillä ei ole mitään tekemistä sillä virheen olisi nähnyt välittömästi).
Mutta summa summarum kysymykseni on siis, kun palkkaus perustuu kompetenssitasoihin, voidaanko vanhat kompetenssitasot "säilyttää" vanhoilla työntekijöillä vaikka heidän oikea osaamisensa eivät sitä vastaakaan ja samanaikaisesti uusilta työntekijöiltä vaatia "uusien" kompetenssikartoitusten määrittelemien taitojen osaamista
Mikä tässä kummastuttaa on se, että minut on rankattu alemmaksi kuin ne, jotka ovat kauemmin olleet talossa. Näiden henkilöiden pitäisi siis olla kyvykkäämpiä kuin minä. Excel-kaaviossa heidän kompetenssitason kuvaansa määritellään mm GoFfin design patternit. Silti näille henkilöille ei sano sellaiset eriskummallisuudet kuin strategy, template method tai decorator mitään, asiasta päättäville pomoille vielä vähemmän.
Mielestäni lähes laittomaksi asian tekee se näiden "kyvykkäämpien" ihmisten ei ole päästäkseen tuolle tasolle tarvinnut selvittää SCWCD-tutkintoa (koska heidän vanhat kompetenssitasonsa ovat edelleen voimassa, eivätkä kyllä ole selvittäneetkään). Jotta voisi selvittää ko tutkinnon pitää olla ensin selvittänyt SCJP-tutkinnon. Jokainen, joka on joskus testannut näitä testejä tietää, kuinka sivuseikkoihin, detaljeetasoihin ja kompakysymyksiin ne johtavat (esim tein juuri SCWCD-testin jossa JSP ei olisi kääntynyt koska siinä oli välilyönti liikaa, ko kysymys täysin teoria-painoitteinen kysymys, todellisen työn kanssa sillä ei ole mitään tekemistä sillä virheen olisi nähnyt välittömästi).
Mutta summa summarum kysymykseni on siis, kun palkkaus perustuu kompetenssitasoihin, voidaanko vanhat kompetenssitasot "säilyttää" vanhoilla työntekijöillä vaikka heidän oikea osaamisensa eivät sitä vastaakaan ja samanaikaisesti uusilta työntekijöiltä vaatia "uusien" kompetenssikartoitusten määrittelemien taitojen osaamista
Vastaukset 8
Vanhimmat
Kyllä tommoset välilyönnin puutteet näkee jo idestä ja notepadilla tai vastaavalla koodaavat voi niputtaa suoraan sinne heikomman osaamisen sakkiin ilman, että tosta tulee liikaa huteja.
Paras kompetenssitason selvittely on muuten se miten asiakkaita palvellaan.
Muuten noilla sun mainitsemilla eriskummallisuuksilla ei ole ihan välttämätöntä käyttöä kovinkaan monessa oikeessa pisneksessä tehtävässä softassa. Monasti vaan sotkevat koodin kun mukana on kuitenkin niitä jotka eivät osaa niitä käyttää. Ja kyllä, kun osa ei osaa, ne aiheuttaa käytännössä tuhoa kun niitä ei pitäs sen takia käytellä. Näin oikeessa elämässä.
Olen hiukan erimieltä kanssasi tässä asiassa:
"Muuten noilla sun mainitsemilla eriskummallisuuksilla ei ole ihan välttämätöntä käyttöä kovinkaan monessa oikeessa pisneksessä tehtävässä softassa"
Mielestäni GofFin strategy ja Template Method (ainakin) ovat kyllä niin perustavaalaatuisia olevia tekniikoita, että jos niitä ei hallitse, on aivan väärällä alalla. Nämä patternit hyvin pitkälti mahdollistavat frameworkkien tekemisen ja mm Servletit ja (Kr)Appletit perustuvat niihin. Siinä olet kyllä oikeassa, että "Ja kyllä, kun osa ei osaa, ne aiheuttaa käytännössä tuhoa kun niitä ei pitäs sen takia käytellä". Vanhaa sananlaskua käyttäen "There's no silver bullet", eli eihän nämä design patternitkaan toimi, jos niitä ei osaa käyttää. Moni Design patternikin vain monimutkaistaa asiaa, mutta monesti ne saattavat myös tehdä ohjelmasta huomattavasti luettavamman, vähemmän-virhe-alttiin ja helpommin muokattavissa olevan.
Mutta pääpointtini tuossa kysymyksessä oli se, että toimitaanko laillisesti, kun minulta vaaditaan periaatteessa enemmän kuin muilta samaa työtä tekeviltä?
No en kyllä noita niin perustavanlaatuisiksi tekniikoiksi sanoisi, ettei voisi IT-hommissa toimia ilman niitä. Pitää muistaa, että nykyäänkin on paljon Cobol-hommia, C-koodia tehdään ihan reippaasti ja joku .NET pelittää tosi hyvin ilman mitään erikoisempaa tommosta kun hommia on tehty valmiiksi tosi isot kasat.
Sanos joku esimerkki vaikka nyt ihan perustapauksesta, jossa toteutetaan C:llä softa joka ohjaa vaikka nyt jotain valoja sekä lukee antureista dataa ja käsittelee niitä vaikka nyt noin kymmenen erilaisen algorimin avulla riippuen anturista. Niin mihin tommosessa tarttee Template Methodeja, välttämättä?
Varmaan Veppipuolella noi voi olla tärkeempiä, mutta taustasysteemeissä, vaikka nyt jossain asiakasrekisterissä ja sen hallinnoinnissa, ei tommonen nyt ole mikään ihan pakko. Tietysti jos osaat perustella miksi olisi, niin mä kuuntelen mielelläni miks.
Sitä meinasin, että jos sä osaat käyttää tollasta, käytät ja toteutat ok niin siitä voi tulla pahoja ongelmia jos joku muu joka ei osaa, menee muuttelemaan systeemiä ja sotkee koko patternin. Siks yleensä pitäs pyrkiä tekemään mahollisimman peruskoodia millä en nyt tarkota mitään globaaleja tai spagettia.
Sinänsähän se on arveluttavaa, että toiselta vaaditaan enemmän kun toiselta, mutta toisaalta kokemus tuo semmosta varmuutta hoitaa hommia muuten. Helpompaa pitää asiat aisoissa jos hyppivät silmille eikä kokenut lupaa yleensä niin helposti liikoja. Sehän on tän alan ongelma, että softaväki sanoo, että homma onnistuu ja sitten ei ookkaa niin helppoa tehä sitä mitä on luvattu.
Tommostakin osaamista otetaan huomioon siinä palkassa. Se pitäs vaan osata sanoa. Muuten palkkaus on sopparipohjanen ja it-hommissa ne neuvotellaan aika pitkälti ite.
Paikan vaihtaminen kannattaa jos liksaa saa liian vähän. Niin se vaan toimii, et uudesta paikasta saa paremmat liksat ja jos vanha tarttee sua oikeesti, niin se nokittaa.
Reippaasti vaan vaihtamaan työpaikkaa jos liksa on alhanen. Se on paras tapa saada lisää liksaa tällä alalla.
nyt menee sivuraiteille, oikaistaan nyt sen verran, että design patternit eivät suinkaan ole mitenkään web-ohjelmiston erikoisjuttu
Eihän sen mun häpeeni ole, jos junior (tai mikä surullisempaa seniori, joka saa parempaa palkkaa) ei osaa edes perus patterneita. Yleensä tapana vielä merkitä dokumenttiin jos koodi käyttää jotain design patternia, tällöin asioista perillä oleva tajuaa aikas äkkiä missä mennään, juniori voi sitten vaikka KVG. Tuo sun ehdottamas idea, että tietoisesti tehtäisiin huonompaa koodia johtaa vaan ongelmiin. Ei design patternitkaan tietenkään ole mikään autiaaksi tekevä asia, mutta usein auttavat keskittymään oikeisiin asioihin. Design patterneita ei pitäisi käyttää sen takia koska se on olemassa, sillä ne saattavat todella monimutkaistaa asioita..
"Sinänsähän se on arveluttavaa, että toiselta vaaditaan enemmän kun toiselta, mutta toisaalta kokemus tuo semmosta varmuutta hoitaa hommia muuten", okei jos tuossa kompetenssitason määrittävässä excel-kaaviossa edes olisi tuo "kokemus" (vastoin yleistä luuloa kyllä koodari oppii vähintään 95% tietonsa/kokemuksensa parissa-kolmessa vuodessa) mutta kun sitä ei mainita
Siis niin, sanoit itekin, että osittain vaan se palkka pohjaa siihen kompetenssikaavioon. Tosin oiskohan niin, että toi kaavio on vaan väline jolla koitetaan pakottaa porukkaa kouluttautumaan omalla ajallaan ja samalla voidaan kertoa kätevällä tavalla miks sitä liksaa ei voi antaa enempää. Kun ei oo tota kompetenssia tarpeeksi bla bla... Kantsii suhtautua tommoseen tolla tavalla.
Meinaan, kuten jo sanoin niin mun mielestäni tommosilla jutuilla ei oo mitään tekemistä sen kanssa suoriutuuko joku hommistaan vai ei. Yleensä kun työnantaja vaatii semmosia, niin kyse on just siitä, että halutaan pitää palkkakuluja alempana. Oon ihan varma, ettet ohittais firman vanhempia työntekijöitä liksoissa vaikka oppisit koko excelin vaatiman litanian hommia.
Palkassa paikaa yleensä kolme asiaa: kokemus, kokemus ja kokemus etkä näitä voi oppia kirjoista tai harjottelemalla teoriaa.
Niin ja vielä disain patterneista. Ei ne oo veppisoftan erikoisjuttu, mutta noissa noita on näkynyt enemmän kun vaikka nyt jossain muualla. Koodia voi tehä pahuksen hyvin tietämättä mitään noista ja toisaalta moni käyttää patterneja ihan tietämättään kun tekee vaan jollain mallilla sen tarkemmin tietämättä miksi sitä tapaa pitäs kutsua. DP:t on kuitenkin vähän tommonen uusi hieno nimitys vanhalle asialle jota on tehty iät ja ajat.
Sinänsä en ehota, että tehtäis huonompaa koodia vaan sitä, että tehään semmosta koodia jota koko tiimi pystyy ylläpitämään. Jos käytetään jotain hienompia juttuja joiden perusideaa joku ei tajua ollenkaan niin siitä tulee vaan ongelmia. Softahommassa meinaan on pakko mennä joissain asioissa sen heikoimman lenkin mukaan ja se on vaan valitettava totuus joka on hyväksyttävä.
myös sua vanhempia? Silloin suurempi palkka on musta ihan luontevaa. Odota vain omaa vuoroasi.
Ja miks ihmeessä palkkauksen pitäis perustua vain johonkin mystiseen "raakaan osaamiseen"? Harva sitä yksinään mitään projektia hoitaa alusta loppuun. Työ on huomattavasti tehokkaampaa, kun kaikki pystyvät kommunikoimaan keskenään, jakamaan tietoa, yms. hellää/kypsää osaamista.
Työnantaja haluaa maksaa muustakin kun tommosesta teknisestä osaamisesta. Hyvä tekijä voi olla semmonen joka osaa pitää asiakkaat tyytyväisenä vaikka osais paljon vähemmän tekniikkaa kun semmonen joka on opetellut kaikki maholliset jutut. Koodaajaporukalle voi olla ihan käsittämätöntä, että osaamisen tason ratkasee se, paljonko tekee tulosta. Eikä sitä yleensä pelkällä teknisellä osaamisella tehä. Eikä ees pelkällä Linukan hieronnalla kun noita rahakkaita ympäristöjä on muuallakin.
Niin ja tosiaan on oleelista, että innokas kaikkien tekniikoiden osaaja ei käytä semmosia tekniikoita joita muut ei pysty ylläpitään.
"Työ on huomattavasti tehokkaampaa, kun kaikki pystyvät kommunikoimaan keskenään, jakamaan tietoa, yms. hellää/kypsää osaamista."
Design patternithan juuri mahdollistaa tuon, vaatimuksena tietenkin on se, että edes seniorikaverit tietävät mitä esim Open/Closed-principle tai vaikkapa Decorator tarkoittaa, tai vaikkapa javan tapauksessa reflektio..
Eli pitää vaan kiltisti työntää ajattelunsa/halunsa oppia perseeseensä ja odottaa, että ikää ("kokemusta" =) ) tulee lisää vai? Ja samaan aikaan katsoa kun "kokeneemmat" kaverit tekevät koodia, jota ei voi mitenkään jatkokehittää/muokata ja joka aina vain täyttää juuri ja juuri minimivaatimukset..
Toisessa viestissä oli hauska lausahdus "Eikä sitä yleensä pelkällä teknisellä osaamisella tehä". Ei tietenkään tehdä, erikoistuminen johonkin asiaan nyt vain mielestäni on aikas tärkeää. Antaa myyjien luvata kuun taivaalta. Minä koitan tehdä oman leiviskäni niin hyvin kuin pystyn..
"Niin ja tosiaan on oleelista, että innokas kaikkien tekniikoiden osaaja ei käytä semmosia tekniikoita joita muut ei pysty ylläpitään." Mielestäni niin sanotut "best practices" -metodit tulisi porukan kyllä hallita