”Asiantuntijatyötä” tekevä, mitä teet työksesi?

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Mistä muuten nuo alapeukut koodareille? Eikö mielestänne ohjelmointia lasketa asiantuntijatyöksi?

En ole alapeukuttanut, mutta meillä ainakin työpaikalla on kehittäjät ja koodarit erikseen. Siis toiset testaavat järjestelmää ja tietävät, mitä käyttäjä siitä haluaa ja tarvitsee ja koodareille vain viedään lista, mitä pitää toteuttaa. Eli koodari tekee lähinnä suorittavan tason työtä ja se asiantuntijuus tulee jostain ihan muualta. Eräänlaista asiantuntijuuttahan se koodaaminenkin tietysti on, mutta hieman eri näkökulmasta. 

Oho, jossain on vielä vanhat menetelmät. Itse oon viimeksi 1990-luvulla tähän törmännyt. Nykyään yleensä koodari tekee ihan kaikkea ketterässä kehityksessä: ideoi ja speksaa asiakkaan kanssa protoillen, suunnittelee teknisen ympäristön, tietokannan, ohjelmistoarkkitehtuurin, koodaa, suunnittelee ja toteuttaa käyttöliittymän, tekee testausautomaatiota.

Sinulta taisi mennä pointti ohi. Ohjelmisto käsittelee sellaista tietoa, josta koodarilla ei juurikaan ole asiantuntemusta. Sen takia ei ole mitään järkeä, että koodaaja opettelisi sen alan asiantuntijuuden tai alan asiantuntijat opettelisivat koodaamaan. Ei puhuta nyt mistään tietokonepeleistä tai nettisivuista, vaan ihan tarkkaan määritellyistä säännöksistä ja niiden viemistä järjestelmään. 

Tuollainen organisointi on vanhanaikaista, tehotonta ja virhealtista. Nykyään on tapana, että koodari eli devajaa eli Software Developer ymmärtää mitä ja miksi järjestelmään tehdään. Näin siksi, että lopputulos on kerralla oikeanlainen ja säästyy aikaa, rahaa ja vaivaa.

Tottakai meilläkin koodaaja tietää, mitä ja miksi järjestelmään mitäkin tehdään, mutta hänen ei tarvitse olla se, joka on vastuussa säännöksien muutoksien moninaisista vaikutuksista. Me asiantuntijat perehdymme niihin uusiin säännöksiin, mietimme, mitä se merkitsee käyttäjille ja mihin kaikkiin toimintoihin tämä muutos lopulta vaikuttaa. 

Otetaan esimerkiksi vaikka ohjelmisto, jota käytetään terveydenhuollossa. Sitten terveydenhuoltoon tulee jokin uusi salassapitopykälä, jolla rajataan tiettyjen henkilöiden oikeuksia järjestelmässä eri tavalla kuin aiemmin. Tämä pykälä voi kuitenkin olla niin moniulotteinen, että siinä tarvitaan koko organisaatiotasolla tarkat pohdinnat, kenelle ja millaisissa tilanteissa annetaan minkäkinlaisia oikeuksia ja miten aikaisemmat muuttuvat ja linkittyvät muihin seikkoihin. Ei sen koodarin siinä kohdassa tarvitse tuntea lakipykälää, mitä oikeuksia minkäkinlaiset valtuudet sisältävät. Hänelle vain toimitetaan tiedot, millaisia käyttäjäoikeuksia järjestelmään pitää luoda ja hän toteuttaa sen sitten. Ei voida mennä vain viemään uutta lakipykälää koodaajalle, että siinä, ole hyvä ja tee, koska se yksittäinen lakipykälä harvoin on sellainen, ettei se vaikuttaisi moneen muuhunkin asiaan. 

Niin, ja te ohjelmiston suunnittelijat ette ole perehtyneet lakiopintoihin tai ymmärrä ammattien työnkuvia ja näiden vaikutuksia oikeuksiin. Eli joku sanoo teille, miten tehdään ja te kerrotte koodareille... turha linkki välissä oli mikä? Sinä.

mitähän sinä nyt selität? Nimenomaan olemme perehtyneet niihin lakiopintoihin ja seuraamme niiden muutoksia. Niiden pohjalta sitten katsomme, miten ohjelmiston osalta näihin pitää reagoida. 

Oikeastaan sinun ja koodarin hommat eivät eroa paljonkaan toisistaan. Sinä käännät lain sanelemia vaatimuksia bisnesvaatimuksiksi ja koodari kääntää bisnesvaatimuksia järjestelmän digitaalisiksi prosesseiksi.

Osittain noin, mutta minä en kanna koodarin eteen bisnesvaatimuksia, vaan ehdotuksia ja ohjeita, joissa jo itsessään on niiden digitaalisten prosessien kuvauksia. En siis kanna koodarin eteen sitä lakipykälää ja asiakkaan vaatimusta, vaan kaivan siitä ohjelmistosta kaikki ne kohdat, joihin muutokset pitää tehdä, että homma toimii. 

Tunnistan tuollaisen roolin, joka tosiaan nykyään on kyllä harvinaistunut, mutta kyllä jossain vuodesta toiseen samaa tuotetta kehittävissä tiimeissä näitä on. Esim. terveydenhoitosoftaa tekemään ko. rooliin voidaan palkata ohjelmistoa työkseen käyttänyt sairaanhoitaja tai lääkäri, ja se voi olla hyvin hyödyllinen rooli. 

Useimmille meille it-alan ihmisille tämä ei enää silti ole nykypäivää, koska harva on tuotekehitystiimeissä, vaan ollaan konsultteina milloin missäkin. Projektit voi olla hyvinkin lyhyitä, ja toimialat vaihtuu äärilaidasta toiseen lyhyellä aikavälillä sen mukaan mitä tilauksia nyt saadaan. Itse tykkäänkin enemmän tämäntyyppisestä työstä, koska siinä saa todella haastaa itsensä, kun on pakko oppia sekä tekniikoita että toimialoja supernopeaan työn ohessa. Mutta varmaan joillekin muunlaisille luonteille on unelma päästä ehkä vähemmän stressaavaan tuotekehityshommaan, jossa kullekin on se oma osaamislokero jossa saa rennosti tehdä omia hommiaan vuodesta toiseen.

No niin, kiitos, juuri tätä tarkoitin. Meillä tosiaan suunnitellaan vähän laajempaa järjestelmää, eikä se todellakaan olisi onnistunut minään lyhyenä projektina, kun ala on sellainen, että muutosta tulee ihan koko ajan ja koko ajan pitää vain kehittää sitä vanhaa eikä vain heittää vanha ohjelmisto pois ja tehdä uusi tilalle. 

Eikö tuollaisissa lyhyissä projekteissa se osaaminen ja työn laatu jää tosi heikoksi, jos niitä samoja ohjelmistoja ei kehitetä eikä edes seurata, vaan aina rynnätään seuraavaan projektiin? 

Ei se jää heikoksi jos on asiantuntijoita tekemässä :-)

Okei. Taitaa olla aika yksinkertaisista ohjelmistoista kyse, jos ei tarvitse edes mitään seurantaa. Oma kokemukseni tosiaan sellaisesta iisakin kirkosta, jossa on riittänyt hiottavaa vuosikausiksi.

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

"Väitöskirjan tekijä on asiantuntija.

Putkimies ei ole asiantuntija.

Palkanlaskija ei ole asiantuntija. Lääkäri ja kätilö ovat."

-Melko typerää luokittelua, kuka on asiantuntija ja kuka ei.

Kysymyshän on kontekstiin sidotusta määrittelysta. Lääkäi on asiantuntija terveyskeskuksessa, kun hän diagnosoi potilasta. Putkimies on asiantuntija, kun hän rakentelee röörejä lääkärin kotitalossa. Putkimieshän voi olla yrittäjä monen vuoden kokemuksella ja kyetä suunnittelemaan ja rakentamaan omakotilaton koko lvi-järjestelmän. Eikö se ole asiantuntjuutta?

Enpä haluaisi itselleni taloa, jonka joku raksamies ja putkimies suunnittelivat ja piirsivät. Tai siis piirsivätkö edes vai rakensivatko vain lennosta. Asenteena ilmeisesti ”ei niitä taloja ennenkään tietokoneella ole rakennettu” :|

Tarvitaanko silti asiantuntijaa, vai riittääkö pelkkä suunnittelupuolen ammattimies?

Suunnittelija on asiantuntija eli insinööri. Sunnitteluun ei ole valmista ohjetta, vaan se vaatii soveltamista. Miten monta kertaa tämä ontässä ketjussa jo väännetty rautalangasta...

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Mistä muuten nuo alapeukut koodareille? Eikö mielestänne ohjelmointia lasketa asiantuntijatyöksi?

En ole alapeukuttanut, mutta meillä ainakin työpaikalla on kehittäjät ja koodarit erikseen. Siis toiset testaavat järjestelmää ja tietävät, mitä käyttäjä siitä haluaa ja tarvitsee ja koodareille vain viedään lista, mitä pitää toteuttaa. Eli koodari tekee lähinnä suorittavan tason työtä ja se asiantuntijuus tulee jostain ihan muualta. Eräänlaista asiantuntijuuttahan se koodaaminenkin tietysti on, mutta hieman eri näkökulmasta. 

Oho, jossain on vielä vanhat menetelmät. Itse oon viimeksi 1990-luvulla tähän törmännyt. Nykyään yleensä koodari tekee ihan kaikkea ketterässä kehityksessä: ideoi ja speksaa asiakkaan kanssa protoillen, suunnittelee teknisen ympäristön, tietokannan, ohjelmistoarkkitehtuurin, koodaa, suunnittelee ja toteuttaa käyttöliittymän, tekee testausautomaatiota.

Sinulta taisi mennä pointti ohi. Ohjelmisto käsittelee sellaista tietoa, josta koodarilla ei juurikaan ole asiantuntemusta. Sen takia ei ole mitään järkeä, että koodaaja opettelisi sen alan asiantuntijuuden tai alan asiantuntijat opettelisivat koodaamaan. Ei puhuta nyt mistään tietokonepeleistä tai nettisivuista, vaan ihan tarkkaan määritellyistä säännöksistä ja niiden viemistä järjestelmään. 

Tuollainen organisointi on vanhanaikaista, tehotonta ja virhealtista. Nykyään on tapana, että koodari eli devajaa eli Software Developer ymmärtää mitä ja miksi järjestelmään tehdään. Näin siksi, että lopputulos on kerralla oikeanlainen ja säästyy aikaa, rahaa ja vaivaa.

Tottakai meilläkin koodaaja tietää, mitä ja miksi järjestelmään mitäkin tehdään, mutta hänen ei tarvitse olla se, joka on vastuussa säännöksien muutoksien moninaisista vaikutuksista. Me asiantuntijat perehdymme niihin uusiin säännöksiin, mietimme, mitä se merkitsee käyttäjille ja mihin kaikkiin toimintoihin tämä muutos lopulta vaikuttaa. 

Otetaan esimerkiksi vaikka ohjelmisto, jota käytetään terveydenhuollossa. Sitten terveydenhuoltoon tulee jokin uusi salassapitopykälä, jolla rajataan tiettyjen henkilöiden oikeuksia järjestelmässä eri tavalla kuin aiemmin. Tämä pykälä voi kuitenkin olla niin moniulotteinen, että siinä tarvitaan koko organisaatiotasolla tarkat pohdinnat, kenelle ja millaisissa tilanteissa annetaan minkäkinlaisia oikeuksia ja miten aikaisemmat muuttuvat ja linkittyvät muihin seikkoihin. Ei sen koodarin siinä kohdassa tarvitse tuntea lakipykälää, mitä oikeuksia minkäkinlaiset valtuudet sisältävät. Hänelle vain toimitetaan tiedot, millaisia käyttäjäoikeuksia järjestelmään pitää luoda ja hän toteuttaa sen sitten. Ei voida mennä vain viemään uutta lakipykälää koodaajalle, että siinä, ole hyvä ja tee, koska se yksittäinen lakipykälä harvoin on sellainen, ettei se vaikuttaisi moneen muuhunkin asiaan. 

Niin, ja te ohjelmiston suunnittelijat ette ole perehtyneet lakiopintoihin tai ymmärrä ammattien työnkuvia ja näiden vaikutuksia oikeuksiin. Eli joku sanoo teille, miten tehdään ja te kerrotte koodareille... turha linkki välissä oli mikä? Sinä.

mitähän sinä nyt selität? Nimenomaan olemme perehtyneet niihin lakiopintoihin ja seuraamme niiden muutoksia. Niiden pohjalta sitten katsomme, miten ohjelmiston osalta näihin pitää reagoida. 

Oikeastaan sinun ja koodarin hommat eivät eroa paljonkaan toisistaan. Sinä käännät lain sanelemia vaatimuksia bisnesvaatimuksiksi ja koodari kääntää bisnesvaatimuksia järjestelmän digitaalisiksi prosesseiksi.

Osittain noin, mutta minä en kanna koodarin eteen bisnesvaatimuksia, vaan ehdotuksia ja ohjeita, joissa jo itsessään on niiden digitaalisten prosessien kuvauksia. En siis kanna koodarin eteen sitä lakipykälää ja asiakkaan vaatimusta, vaan kaivan siitä ohjelmistosta kaikki ne kohdat, joihin muutokset pitää tehdä, että homma toimii. 

Tunnistan tuollaisen roolin, joka tosiaan nykyään on kyllä harvinaistunut, mutta kyllä jossain vuodesta toiseen samaa tuotetta kehittävissä tiimeissä näitä on. Esim. terveydenhoitosoftaa tekemään ko. rooliin voidaan palkata ohjelmistoa työkseen käyttänyt sairaanhoitaja tai lääkäri, ja se voi olla hyvin hyödyllinen rooli. 

Useimmille meille it-alan ihmisille tämä ei enää silti ole nykypäivää, koska harva on tuotekehitystiimeissä, vaan ollaan konsultteina milloin missäkin. Projektit voi olla hyvinkin lyhyitä, ja toimialat vaihtuu äärilaidasta toiseen lyhyellä aikavälillä sen mukaan mitä tilauksia nyt saadaan. Itse tykkäänkin enemmän tämäntyyppisestä työstä, koska siinä saa todella haastaa itsensä, kun on pakko oppia sekä tekniikoita että toimialoja supernopeaan työn ohessa. Mutta varmaan joillekin muunlaisille luonteille on unelma päästä ehkä vähemmän stressaavaan tuotekehityshommaan, jossa kullekin on se oma osaamislokero jossa saa rennosti tehdä omia hommiaan vuodesta toiseen.

No niin, kiitos, juuri tätä tarkoitin. Meillä tosiaan suunnitellaan vähän laajempaa järjestelmää, eikä se todellakaan olisi onnistunut minään lyhyenä projektina, kun ala on sellainen, että muutosta tulee ihan koko ajan ja koko ajan pitää vain kehittää sitä vanhaa eikä vain heittää vanha ohjelmisto pois ja tehdä uusi tilalle. 

Eikö tuollaisissa lyhyissä projekteissa se osaaminen ja työn laatu jää tosi heikoksi, jos niitä samoja ohjelmistoja ei kehitetä eikä edes seurata, vaan aina rynnätään seuraavaan projektiin? 

Ei se jää heikoksi jos on asiantuntijoita tekemässä :-)

Okei. Taitaa olla aika yksinkertaisista ohjelmistoista kyse, jos ei tarvitse edes mitään seurantaa. Oma kokemukseni tosiaan sellaisesta iisakin kirkosta, jossa on riittänyt hiottavaa vuosikausiksi.

Eihän tässä ollut seurannasta kyse vaan osaamisesta ja työn laadusta. Osaavasti ja laadukkaasti tehty MVP on sellainen että vaikka tulisi toisesta firmasta yhtä pätevät ukot jatkamaan niin homma luistaa. Sekin on sitä asiantuntijuutta että ohjelmisto on teknisesti toteutettu niin että sitä on helppo kehittää edelleen.

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Mistä muuten nuo alapeukut koodareille? Eikö mielestänne ohjelmointia lasketa asiantuntijatyöksi?

En ole alapeukuttanut, mutta meillä ainakin työpaikalla on kehittäjät ja koodarit erikseen. Siis toiset testaavat järjestelmää ja tietävät, mitä käyttäjä siitä haluaa ja tarvitsee ja koodareille vain viedään lista, mitä pitää toteuttaa. Eli koodari tekee lähinnä suorittavan tason työtä ja se asiantuntijuus tulee jostain ihan muualta. Eräänlaista asiantuntijuuttahan se koodaaminenkin tietysti on, mutta hieman eri näkökulmasta. 

Oho, jossain on vielä vanhat menetelmät. Itse oon viimeksi 1990-luvulla tähän törmännyt. Nykyään yleensä koodari tekee ihan kaikkea ketterässä kehityksessä: ideoi ja speksaa asiakkaan kanssa protoillen, suunnittelee teknisen ympäristön, tietokannan, ohjelmistoarkkitehtuurin, koodaa, suunnittelee ja toteuttaa käyttöliittymän, tekee testausautomaatiota.

Sinulta taisi mennä pointti ohi. Ohjelmisto käsittelee sellaista tietoa, josta koodarilla ei juurikaan ole asiantuntemusta. Sen takia ei ole mitään järkeä, että koodaaja opettelisi sen alan asiantuntijuuden tai alan asiantuntijat opettelisivat koodaamaan. Ei puhuta nyt mistään tietokonepeleistä tai nettisivuista, vaan ihan tarkkaan määritellyistä säännöksistä ja niiden viemistä järjestelmään. 

Tuollainen organisointi on vanhanaikaista, tehotonta ja virhealtista. Nykyään on tapana, että koodari eli devajaa eli Software Developer ymmärtää mitä ja miksi järjestelmään tehdään. Näin siksi, että lopputulos on kerralla oikeanlainen ja säästyy aikaa, rahaa ja vaivaa.

Tottakai meilläkin koodaaja tietää, mitä ja miksi järjestelmään mitäkin tehdään, mutta hänen ei tarvitse olla se, joka on vastuussa säännöksien muutoksien moninaisista vaikutuksista. Me asiantuntijat perehdymme niihin uusiin säännöksiin, mietimme, mitä se merkitsee käyttäjille ja mihin kaikkiin toimintoihin tämä muutos lopulta vaikuttaa. 

Otetaan esimerkiksi vaikka ohjelmisto, jota käytetään terveydenhuollossa. Sitten terveydenhuoltoon tulee jokin uusi salassapitopykälä, jolla rajataan tiettyjen henkilöiden oikeuksia järjestelmässä eri tavalla kuin aiemmin. Tämä pykälä voi kuitenkin olla niin moniulotteinen, että siinä tarvitaan koko organisaatiotasolla tarkat pohdinnat, kenelle ja millaisissa tilanteissa annetaan minkäkinlaisia oikeuksia ja miten aikaisemmat muuttuvat ja linkittyvät muihin seikkoihin. Ei sen koodarin siinä kohdassa tarvitse tuntea lakipykälää, mitä oikeuksia minkäkinlaiset valtuudet sisältävät. Hänelle vain toimitetaan tiedot, millaisia käyttäjäoikeuksia järjestelmään pitää luoda ja hän toteuttaa sen sitten. Ei voida mennä vain viemään uutta lakipykälää koodaajalle, että siinä, ole hyvä ja tee, koska se yksittäinen lakipykälä harvoin on sellainen, ettei se vaikuttaisi moneen muuhunkin asiaan. 

Niin, ja te ohjelmiston suunnittelijat ette ole perehtyneet lakiopintoihin tai ymmärrä ammattien työnkuvia ja näiden vaikutuksia oikeuksiin. Eli joku sanoo teille, miten tehdään ja te kerrotte koodareille... turha linkki välissä oli mikä? Sinä.

mitähän sinä nyt selität? Nimenomaan olemme perehtyneet niihin lakiopintoihin ja seuraamme niiden muutoksia. Niiden pohjalta sitten katsomme, miten ohjelmiston osalta näihin pitää reagoida. 

Oikeastaan sinun ja koodarin hommat eivät eroa paljonkaan toisistaan. Sinä käännät lain sanelemia vaatimuksia bisnesvaatimuksiksi ja koodari kääntää bisnesvaatimuksia järjestelmän digitaalisiksi prosesseiksi.

Osittain noin, mutta minä en kanna koodarin eteen bisnesvaatimuksia, vaan ehdotuksia ja ohjeita, joissa jo itsessään on niiden digitaalisten prosessien kuvauksia. En siis kanna koodarin eteen sitä lakipykälää ja asiakkaan vaatimusta, vaan kaivan siitä ohjelmistosta kaikki ne kohdat, joihin muutokset pitää tehdä, että homma toimii. 

Tunnistan tuollaisen roolin, joka tosiaan nykyään on kyllä harvinaistunut, mutta kyllä jossain vuodesta toiseen samaa tuotetta kehittävissä tiimeissä näitä on. Esim. terveydenhoitosoftaa tekemään ko. rooliin voidaan palkata ohjelmistoa työkseen käyttänyt sairaanhoitaja tai lääkäri, ja se voi olla hyvin hyödyllinen rooli. 

Useimmille meille it-alan ihmisille tämä ei enää silti ole nykypäivää, koska harva on tuotekehitystiimeissä, vaan ollaan konsultteina milloin missäkin. Projektit voi olla hyvinkin lyhyitä, ja toimialat vaihtuu äärilaidasta toiseen lyhyellä aikavälillä sen mukaan mitä tilauksia nyt saadaan. Itse tykkäänkin enemmän tämäntyyppisestä työstä, koska siinä saa todella haastaa itsensä, kun on pakko oppia sekä tekniikoita että toimialoja supernopeaan työn ohessa. Mutta varmaan joillekin muunlaisille luonteille on unelma päästä ehkä vähemmän stressaavaan tuotekehityshommaan, jossa kullekin on se oma osaamislokero jossa saa rennosti tehdä omia hommiaan vuodesta toiseen.

No niin, kiitos, juuri tätä tarkoitin. Meillä tosiaan suunnitellaan vähän laajempaa järjestelmää, eikä se todellakaan olisi onnistunut minään lyhyenä projektina, kun ala on sellainen, että muutosta tulee ihan koko ajan ja koko ajan pitää vain kehittää sitä vanhaa eikä vain heittää vanha ohjelmisto pois ja tehdä uusi tilalle. 

Eikö tuollaisissa lyhyissä projekteissa se osaaminen ja työn laatu jää tosi heikoksi, jos niitä samoja ohjelmistoja ei kehitetä eikä edes seurata, vaan aina rynnätään seuraavaan projektiin? 

Ei se jää heikoksi jos on asiantuntijoita tekemässä :-)

Okei. Taitaa olla aika yksinkertaisista ohjelmistoista kyse, jos ei tarvitse edes mitään seurantaa. Oma kokemukseni tosiaan sellaisesta iisakin kirkosta, jossa on riittänyt hiottavaa vuosikausiksi.

No sitähän tässä on yritetty kertoa, että ei yhdessäkään oikeassa softafirmassa tehdä tuollaista enää, eikä ole tehty enää vuosikymmeneen.

Ketju täynnä egojen kalsketta ja kalinaa. Vaatii ehdottomasti korkeampaa koulutusta ja kauan. Ei se tällaisiin mittasuhteisiin muuten kehity.

Kaikkien pitää saada olla itsenäisiä, päteviä, osaavia, korvaamattomia ja tasokkaita. Ollaan siis asiantuntijoita, kun oikein silmin katsotaan. Pomoja ja päälliköitä ja johtajia ja suuuuuunnnittelijoita. Ei mitään suorittavaa porrasta.

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Miksi asiakkaan pitäisi välittää tuosta, ja miksi sinä kuvittelet että sinun määritelmäsi asiantuntijatyöstä on millään tapaa oikea?

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Kyllä käytännössä jokaisessa projektissa asiakkaan kanssa käydään jonkinlaista dialogia siitä miten mikäkin vaatimus kannattaa toteuttaa, miksi jotain asiaa ei ehkä kannata toteuttaa siten kun asiakas on sen visioinut, minkälaisia rajoitteita valitut teknologiat aiheuttavat, miksi jokin asia kannattaisi ehkä toteuttaa jotenkin toisin ja usein ihan siitäkin että haluaako asiakas oikeasti jotain mitä kuvittelee haluavansa. Ei meidän ole kuitenkaan tarkoitus opettaa asiakasta koodaamaan vaan nimenomaan tarjota oma osaaminen hänen käyttöönsä.

Olen asiantuntijatyön ja asiantuntijatöiden virallinen validoija.

Sosiaalihuollon tietojärjestelmää päivittäin käyttävänä alan ymmärtää, miksi julkisen puolen tietojärjestelmät ovat niin umpisurkeita ja vanhanaikaisia.

Veljeni on osakkaana eräässä hyvin menestyvässä ohjelmointialan yrityksessä. Titteliltään joku senior program director tms. Kulkee ympäri Suomea opettamassa ja kouluttamassa, suunnittelee yhdessä asiakkaiden kanssa isoja ja vaativia projekteja. Ja kyllä, osallistuu myös koodaamiseen, koska on alansa ns. huippuasiantuntija ja koodaaminen vertautuu hänelle intohimoon ja melkein taiteeseen.

Kunpa jatkossa minunkin käyttämiäni ohjelmistoja ym. pääsisivät suunnittelemaan ja toteuttamaan alan todelliset huiput. Keinotekoisia ja vanhanaikaisia hierarkioita roikottavien tyyppien sijaan. Olisi ihana tehdä töitä nykyaikaisilla ja sujuvilla, ketterillä työvälineillä.

T. Sosiaalialan erityisasiantuntija

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Miksi asiakkaan pitäisi välittää tuosta, ja miksi sinä kuvittelet että sinun määritelmäsi asiantuntijatyöstä on millään tapaa oikea?

No näköjään se ei sitten ole yleinen totuus, sen verran voin myöntää. Vielä viimeisen kerran sanon, että minun käsitykseni mukaan asiantuntijatyö on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, kerro minulle, mitä minun pitää tehdä" ja suorittava työ on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, ratkaise se puolestani". Mutta tämä on nyt näköjään vain minun näkemykseni ja olen pahoillani, jos joku nyt sai sen käsityksen, että puhun ammattitaidosta tai osaamattomuudesta. Sitä en missään vaiheessa ole tarkoittanut, vaan sitä tekemisen lähestymistapaa.

Tämä jaottelu on nimittäin ihan todellinen muissakin yhteyksissä. Esimerkiksi liikuntapalveluissa on eri arvonlisävero personal trainerin ohjaukselle ja ryhmäliikunnalle. Toisessa ostat asiantuntijuutta ja toisessa  ostat palvelun valmiina, vaikka se ryhmäliikunnan vetäjä olisikin pt ja ohjelma ammattitaidolla suunniteltu. Toki voidaan ajatella, että ryhmäliikunnassakin ostat vetäjän asiantuntijuutta, mutta se rooli asiakkaaseen nähden on ihan erilainen. 

Mutta minä en ole oikea ihminen määrittelemään näitä ehdottomasti. Yritän nyt vain selittää sitä, miten minä sen käsitän. Teidän ei tarvitse olla kanssani samaa mieltä eikä pahastua. 

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Miksi asiakkaan pitäisi välittää tuosta, ja miksi sinä kuvittelet että sinun määritelmäsi asiantuntijatyöstä on millään tapaa oikea?

No näköjään se ei sitten ole yleinen totuus, sen verran voin myöntää. Vielä viimeisen kerran sanon, että minun käsitykseni mukaan asiantuntijatyö on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, kerro minulle, mitä minun pitää tehdä" ja suorittava työ on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, ratkaise se puolestani". Mutta tämä on nyt näköjään vain minun näkemykseni ja olen pahoillani, jos joku nyt sai sen käsityksen, että puhun ammattitaidosta tai osaamattomuudesta. Sitä en missään vaiheessa ole tarkoittanut, vaan sitä tekemisen lähestymistapaa.

Tämä jaottelu on nimittäin ihan todellinen muissakin yhteyksissä. Esimerkiksi liikuntapalveluissa on eri arvonlisävero personal trainerin ohjaukselle ja ryhmäliikunnalle. Toisessa ostat asiantuntijuutta ja toisessa  ostat palvelun valmiina, vaikka se ryhmäliikunnan vetäjä olisikin pt ja ohjelma ammattitaidolla suunniteltu. Toki voidaan ajatella, että ryhmäliikunnassakin ostat vetäjän asiantuntijuutta, mutta se rooli asiakkaaseen nähden on ihan erilainen. 

Mutta minä en ole oikea ihminen määrittelemään näitä ehdottomasti. Yritän nyt vain selittää sitä, miten minä sen käsitän. Teidän ei tarvitse olla kanssani samaa mieltä eikä pahastua. 

Edelleen vaan missaat sinulle rautalangasta väännetyn pointin kokonaan. Nuo analogiasikin menevät kerta toisensa päin mäntyä. Vähän surullista, että et ilmeisesti vaan tajua.

Vierailija kirjoitti:

[No näköjään se ei sitten ole yleinen totuus, sen verran voin myöntää. Vielä viimeisen kerran sanon, että minun käsitykseni mukaan asiantuntijatyö on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, kerro minulle, mitä minun pitää tehdä" ja suorittava työ on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, ratkaise se puolestani".

Ja kun sinä menet sen speksin kanssa koodarille, että ”hei, minulla on tällainen speksi, miten se kannattaa toteuttaa?” niin miten se ei mielestäsi ole nimenomaan tuota määritelmäsi mukaista asiantuntijatyötä?

Vierailija kirjoitti:

Sosiaalihuollon tietojärjestelmää päivittäin käyttävänä alan ymmärtää, miksi julkisen puolen tietojärjestelmät ovat niin umpisurkeita ja vanhanaikaisia.

Veljeni on osakkaana eräässä hyvin menestyvässä ohjelmointialan yrityksessä. Titteliltään joku senior program director tms. Kulkee ympäri Suomea opettamassa ja kouluttamassa, suunnittelee yhdessä asiakkaiden kanssa isoja ja vaativia projekteja. Ja kyllä, osallistuu myös koodaamiseen, koska on alansa ns. huippuasiantuntija ja koodaaminen vertautuu hänelle intohimoon ja melkein taiteeseen.

Kunpa jatkossa minunkin käyttämiäni ohjelmistoja ym. pääsisivät suunnittelemaan ja toteuttamaan alan todelliset huiput. Keinotekoisia ja vanhanaikaisia hierarkioita roikottavien tyyppien sijaan. Olisi ihana tehdä töitä nykyaikaisilla ja sujuvilla, ketterillä työvälineillä.

T. Sosiaalialan erityisasiantuntija

Niin, hänenkään työnkuva ei silti ole koodaaja, vaikka hän sitä työssään välillä tekee. Nimenomaan, kunnon ohjelmiston tekemiseen tarvitaan vähän muutakin näkemystä, kuin vahva koodaajatausta. Eli noita jäykkiä ja vanhanaikaisia järjestelmiä syntyy nimenomaan, kun ei ole sitä käyttäjän alan näkemystä tai kokemusta, vaan annetaan vain tehtävä jollekin koodarille, joka itse järkeilee ne hierarkiat alaa ymmärtämättä. 

Vierailija kirjoitti:

Vierailija kirjoitti:

[No näköjään se ei sitten ole yleinen totuus, sen verran voin myöntää. Vielä viimeisen kerran sanon, että minun käsitykseni mukaan asiantuntijatyö on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, kerro minulle, mitä minun pitää tehdä" ja suorittava työ on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, ratkaise se puolestani".

Ja kun sinä menet sen speksin kanssa koodarille, että ”hei, minulla on tällainen speksi, miten se kannattaa toteuttaa?” niin miten se ei mielestäsi ole nimenomaan tuota määritelmäsi mukaista asiantuntijatyötä?

No tottakai se siinä vaiheessa onkin, jos se koodaaja antaa sinulle ohjeet, miten se koodataan ja sinä sitten sen itse toteutat. Eli tuossa tapauksessa sinä itse olet se suorittavan tason koodaaja ja se, jolta kysyit ohjeita on asiantuntija. Kyllä, tuossa tilanteessa se toinen koodaaja on asiantuntija ja sinä et. 

Vierailija kirjoitti:

Vierailija kirjoitti:

Sosiaalihuollon tietojärjestelmää päivittäin käyttävänä alan ymmärtää, miksi julkisen puolen tietojärjestelmät ovat niin umpisurkeita ja vanhanaikaisia.

Veljeni on osakkaana eräässä hyvin menestyvässä ohjelmointialan yrityksessä. Titteliltään joku senior program director tms. Kulkee ympäri Suomea opettamassa ja kouluttamassa, suunnittelee yhdessä asiakkaiden kanssa isoja ja vaativia projekteja. Ja kyllä, osallistuu myös koodaamiseen, koska on alansa ns. huippuasiantuntija ja koodaaminen vertautuu hänelle intohimoon ja melkein taiteeseen.

Kunpa jatkossa minunkin käyttämiäni ohjelmistoja ym. pääsisivät suunnittelemaan ja toteuttamaan alan todelliset huiput. Keinotekoisia ja vanhanaikaisia hierarkioita roikottavien tyyppien sijaan. Olisi ihana tehdä töitä nykyaikaisilla ja sujuvilla, ketterillä työvälineillä.

T. Sosiaalialan erityisasiantuntija

 

Niin, hänenkään työnkuva ei silti ole koodaaja, vaikka hän sitä työssään välillä tekee. Nimenomaan, kunnon ohjelmiston tekemiseen tarvitaan vähän muutakin näkemystä, kuin vahva koodaajatausta. Eli noita jäykkiä ja vanhanaikaisia järjestelmiä syntyy nimenomaan, kun ei ole sitä käyttäjän alan näkemystä tai kokemusta, vaan annetaan vain tehtävä jollekin koodarille, joka itse järkeilee ne hierarkiat alaa ymmärtämättä. 

Kyllä hän koodariksi itseään kutsuu ja koodarina pitää. Ja koodareina itseään pitävät myös muut tuon yrityksen asiantuntijat, jotka ovat asiantuntijoita juuri siinä ohjelmistosuunnittelussa ja -kehittämisessä. Pikemminkin tuntuu siltä, että sinun käsityksesi koodareista on pysähtynyt jonnekin kauas menneisyyteen. 

Ja ilmeisesti sosiaali- ja terveydenhuollon ohjelmistot tehdään sinun mainostamallasi metodilla, ja tulokset näen itse päivittäin. 

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Miksi asiakkaan pitäisi välittää tuosta, ja miksi sinä kuvittelet että sinun määritelmäsi asiantuntijatyöstä on millään tapaa oikea?

No näköjään se ei sitten ole yleinen totuus, sen verran voin myöntää. Vielä viimeisen kerran sanon, että minun käsitykseni mukaan asiantuntijatyö on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, kerro minulle, mitä minun pitää tehdä" ja suorittava työ on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, ratkaise se puolestani". Mutta tämä on nyt näköjään vain minun näkemykseni ja olen pahoillani, jos joku nyt sai sen käsityksen, että puhun ammattitaidosta tai osaamattomuudesta. Sitä en missään vaiheessa ole tarkoittanut, vaan sitä tekemisen lähestymistapaa.

Tämä jaottelu on nimittäin ihan todellinen muissakin yhteyksissä. Esimerkiksi liikuntapalveluissa on eri arvonlisävero personal trainerin ohjaukselle ja ryhmäliikunnalle. Toisessa ostat asiantuntijuutta ja toisessa  ostat palvelun valmiina, vaikka se ryhmäliikunnan vetäjä olisikin pt ja ohjelma ammattitaidolla suunniteltu. Toki voidaan ajatella, että ryhmäliikunnassakin ostat vetäjän asiantuntijuutta, mutta se rooli asiakkaaseen nähden on ihan erilainen. 

Mutta minä en ole oikea ihminen määrittelemään näitä ehdottomasti. Yritän nyt vain selittää sitä, miten minä sen käsitän. Teidän ei tarvitse olla kanssani samaa mieltä eikä pahastua. 

Edelleen vaan missaat sinulle rautalangasta väännetyn pointin kokonaan. Nuo analogiasikin menevät kerta toisensa päin mäntyä. Vähän surullista, että et ilmeisesti vaan tajua.

Miten niin menevät mönkään ja miten niin missaan? Jos et ymmärrä tuota personal trainer -esimerkkiä, se olet sinä, jolta menee nyt pointti ohi. Tuon paremmin en pysty enää asiaa selittämään. Minä kyllä ymmärrän varsin hyvin, mitä minulle on sanottu, mutta minä yritän nyt selittää, mikä ero on minun näkemykselläni ja teidän muiden näkemyksellä. Te puhutte osaamisesta, kun minä puhun työnkuvasta. 

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Miksi asiakkaan pitäisi välittää tuosta, ja miksi sinä kuvittelet että sinun määritelmäsi asiantuntijatyöstä on millään tapaa oikea?

No näköjään se ei sitten ole yleinen totuus, sen verran voin myöntää. Vielä viimeisen kerran sanon, että minun käsitykseni mukaan asiantuntijatyö on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, kerro minulle, mitä minun pitää tehdä" ja suorittava työ on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, ratkaise se puolestani". Mutta tämä on nyt näköjään vain minun näkemykseni ja olen pahoillani, jos joku nyt sai sen käsityksen, että puhun ammattitaidosta tai osaamattomuudesta. Sitä en missään vaiheessa ole tarkoittanut, vaan sitä tekemisen lähestymistapaa.

Olen iloinen että ymmärrät itsekin, miten väärässä olet.

Sinulla on ilmeisesti kuva, että koodaus on samanlaista kuin vaikkapa latojan työ: saadaan malli, ja ladotaan kirjasimia niin, että asiat toteutuvat mahdollisimman pitkälti sen mukaan, mitä mallissa on. Ohjelmointi ei ole tällaista. Ohjelmoinnissa pitää rakentaa se allaoleva mekaniikka soveltuvalla tavalla (tietoturvalliseksi, ylläpidettäväksi jne), jotta pinnalle jää se, mitä asiakas haluaa. Tämän erottaa esim. sirkustaiteilijan tai räätälin työstä esim. se, että kyseessä on tietotyö.

Sinänsä tämä keskustelu toki selittää, miksi monet ohjelmistoprojektit menevät niin paskasti.

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Asiantuntijatyöhön liittyy jonkinlainen tiedonhankinta-, opettamis- ja valistuselementti. En osaa tätä nyt oikein paremmin selittää. Jostain kumman syystä tässä nyt oletetaan, että ei-asiantuntijatyö tarkoittaisi sitä, ettei mitään osaamista tarvittaisi. Siitä ei ole ollenkaan kysymys. 

Ihan varmasti joka ainoan ohjelmoijan työhön liittyy ainakin jatkuva tiedonhankintaelementti. Joskus jopa rasittavuuteen asti: on pakko oppia jatkuvasti itsenäisesti uutta, ilman että kukaan kurssittaa tai antaa edes aikaa siihen.

No tuohan liittyy aika moneen alaan. Entäs nuo muut elementit? Paljonko käytät aikaa, että asiakkaalle menee perille koodaamisen perusperiaatteet ja että hän tietää, miten häneen minkäkinlainen koodaaminen vaikuttaa?

Miksi asiakkaan pitäisi välittää tuosta, ja miksi sinä kuvittelet että sinun määritelmäsi asiantuntijatyöstä on millään tapaa oikea?

No näköjään se ei sitten ole yleinen totuus, sen verran voin myöntää. Vielä viimeisen kerran sanon, että minun käsitykseni mukaan asiantuntijatyö on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, kerro minulle, mitä minun pitää tehdä" ja suorittava työ on sellaista, että asiakas tulee sanomaan "hei, minulla on ongelma, ratkaise se puolestani". Mutta tämä on nyt näköjään vain minun näkemykseni ja olen pahoillani, jos joku nyt sai sen käsityksen, että puhun ammattitaidosta tai osaamattomuudesta. Sitä en missään vaiheessa ole tarkoittanut, vaan sitä tekemisen lähestymistapaa.

Tämä jaottelu on nimittäin ihan todellinen muissakin yhteyksissä. Esimerkiksi liikuntapalveluissa on eri arvonlisävero personal trainerin ohjaukselle ja ryhmäliikunnalle. Toisessa ostat asiantuntijuutta ja toisessa  ostat palvelun valmiina, vaikka se ryhmäliikunnan vetäjä olisikin pt ja ohjelma ammattitaidolla suunniteltu. Toki voidaan ajatella, että ryhmäliikunnassakin ostat vetäjän asiantuntijuutta, mutta se rooli asiakkaaseen nähden on ihan erilainen. 

Mutta minä en ole oikea ihminen määrittelemään näitä ehdottomasti. Yritän nyt vain selittää sitä, miten minä sen käsitän. Teidän ei tarvitse olla kanssani samaa mieltä eikä pahastua. 

Edelleen vaan missaat sinulle rautalangasta väännetyn pointin kokonaan. Nuo analogiasikin menevät kerta toisensa päin mäntyä. Vähän surullista, että et ilmeisesti vaan tajua.

Miten niin menevät mönkään ja miten niin missaan? Jos et ymmärrä tuota personal trainer -esimerkkiä, se olet sinä, jolta menee nyt pointti ohi. Tuon paremmin en pysty enää asiaa selittämään. Minä kyllä ymmärrän varsin hyvin, mitä minulle on sanottu, mutta minä yritän nyt selittää, mikä ero on minun näkemykselläni ja teidän muiden näkemyksellä. Te puhutte osaamisesta, kun minä puhun työnkuvasta. 

Ei pidä paikkaansa, analogiasi eivät sovi tähän keskusteluun ja koodaamiseen ollenkaan. 

Vierailija kirjoitti:

Vierailija kirjoitti:

Vierailija kirjoitti:

Sosiaalihuollon tietojärjestelmää päivittäin käyttävänä alan ymmärtää, miksi julkisen puolen tietojärjestelmät ovat niin umpisurkeita ja vanhanaikaisia.

Veljeni on osakkaana eräässä hyvin menestyvässä ohjelmointialan yrityksessä. Titteliltään joku senior program director tms. Kulkee ympäri Suomea opettamassa ja kouluttamassa, suunnittelee yhdessä asiakkaiden kanssa isoja ja vaativia projekteja. Ja kyllä, osallistuu myös koodaamiseen, koska on alansa ns. huippuasiantuntija ja koodaaminen vertautuu hänelle intohimoon ja melkein taiteeseen.

Kunpa jatkossa minunkin käyttämiäni ohjelmistoja ym. pääsisivät suunnittelemaan ja toteuttamaan alan todelliset huiput. Keinotekoisia ja vanhanaikaisia hierarkioita roikottavien tyyppien sijaan. Olisi ihana tehdä töitä nykyaikaisilla ja sujuvilla, ketterillä työvälineillä.

T. Sosiaalialan erityisasiantuntija

 

Niin, hänenkään työnkuva ei silti ole koodaaja, vaikka hän sitä työssään välillä tekee. Nimenomaan, kunnon ohjelmiston tekemiseen tarvitaan vähän muutakin näkemystä, kuin vahva koodaajatausta. Eli noita jäykkiä ja vanhanaikaisia järjestelmiä syntyy nimenomaan, kun ei ole sitä käyttäjän alan näkemystä tai kokemusta, vaan annetaan vain tehtävä jollekin koodarille, joka itse järkeilee ne hierarkiat alaa ymmärtämättä. 

Kyllä hän koodariksi itseään kutsuu ja koodarina pitää. Ja koodareina itseään pitävät myös muut tuon yrityksen asiantuntijat, jotka ovat asiantuntijoita juuri siinä ohjelmistosuunnittelussa ja -kehittämisessä. Pikemminkin tuntuu siltä, että sinun käsityksesi koodareista on pysähtynyt jonnekin kauas menneisyyteen. 

Ja ilmeisesti sosiaali- ja terveydenhuollon ohjelmistot tehdään sinun mainostamallasi metodilla, ja tulokset näen itse päivittäin. 

Hohhoijaa. Minä en kutsuisi sinun veljeäsi pelkäksi koodaajaksi, joten en nyt ihan ymmärrä, millä tavalla minun käsitykseni tässä nyt on väärä. Eihän se nyt minun syyni ole, jos veljesi ei käytä osuvampaa nimitystä omasta työnkuvastaan. Jos joku sanoo olevansa tarjoilija, ei kai se minun syyni ole, jos erehdyn luulemaan häntä suorittavan tason työntekijäksi, jos hän onkin oikeasti hotelliketjun johtaja, joka välillä käy siellä salissa tarjoilemassa. Jotenkin nurinkurinen tämä asenne, että sanotaan työnkuvan olevan pelkkää koodaamista, mutta sitten suututaan, kun joku olettaa työnkuvan olevan pelkkää koodaamista.