Lue keskustelun säännöt.
Tervetuloa lukemaan keskusteluja! Kommentointi on avoinna klo 7 - 23.
Tervetuloa lukemaan keskusteluja! Kommentointi on avoinna klo 7 - 23.
Alue: Aihe vapaa
”Asiantuntijatyötä” tekevä, mitä teet työksesi?
Kommentit (213)
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Tietysti koodaaja on asiantuntija omalla alallaan eli ohjelmistokehityksessä, samoin kuin se elintarvikealan asiantuntija on asiantuntija omalla alallaan...
Sisältö jatkuu mainoksen alla
Sisältö jatkuu mainoksen alla
Kehitän digitaalisia uuden sukupolven ratkaisuja. Yritäpä tehdä perässä.
Vierailija kirjoitti:
Ne ohjelmiston tekijät, jotka ymmärtävät syvällisesti myös jotain tiettyä alaa koodin lisäksi ovat melkein yrittäjiä.
Koodaaminen on ala itsessään.
T: yksi joka koodaa työssään eikä ole koodaamisen asiantuntija (vaan tutkimusalansa), ja aina välillä meinaa päästä itku kun selviää, miten paljon parempia algoritmeja maailmassa on, ja minä en niistä ole kuullut.
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:
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Onneksi ei tarvitse olla töissä puljussa jossa omaa ammattitaitoa ei arvosteta lainkaan. Kuulostaa nimittäin aika kauhealta.
Minä huutelen nyt ihan sivusta. En ole it-alalla, mutta ymmärrän kyllä vallan hyvin, että minun substanssiosaamiseni on aivan eri alalta kuin asiakkaani substanssiosaaminen. Eihän asiakas muuten minua tarvitsisi.
Niin, sehän se tässä se olikin että tuon yhden mielestä koodari ei ole asiantuntija koska ei ymmärrä esim. terveydenhuollon bisnesprosesseista riittävästi.
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:
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Niin, kun se koodaaja on ohjelmointialan asiantuntija. Ohjelmointi on aivan oikea, asiantuntemusta vaativa ala itsessään. (Ei jestas että tällaisia lauseita tarvitsee näppäimistöllään tuottaa.)
Niin, mutta teetkö sinä työtä se eteen, että joku muu oppisi ymmärtämään koodaamista? Tottakai vaatii asiantuntemusta ja ihan järjetöntä osaamista, mutta ei se silti työn luonnetta muuta asiantuntijatyöksi. Asiantuntijatyö ei ole synonyymi sille, että työssä tarvitaan asiantuntemusta ja osaamista. Esimerkiksi sirkustaiteilija tai lentäjäkään ei ole asiantuntijoita, vaikka varmasti osaavat todella paljon asioita, joita tavispulliainen ei osaa. 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.
Sisältö jatkuu mainoksen alla
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ä :-)
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:
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Onneksi ei tarvitse olla töissä puljussa jossa omaa ammattitaitoa ei arvosteta lainkaan. Kuulostaa nimittäin aika kauhealta.
Näytätkö kohdan, jossa sanottiin, ettei koodaajalla ole ammattitaitoa?
Sisältö jatkuu mainoksen alla
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:
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Niin, kun se koodaaja on ohjelmointialan asiantuntija. Ohjelmointi on aivan oikea, asiantuntemusta vaativa ala itsessään. (Ei jestas että tällaisia lauseita tarvitsee näppäimistöllään tuottaa.)
Niin, mutta teetkö sinä työtä se eteen, että joku muu oppisi ymmärtämään koodaamista? Tottakai vaatii asiantuntemusta ja ihan järjetöntä osaamista, mutta ei se silti työn luonnetta muuta asiantuntijatyöksi. Asiantuntijatyö ei ole synonyymi sille, että työssä tarvitaan asiantuntemusta ja osaamista. Esimerkiksi sirkustaiteilija tai lentäjäkään ei ole asiantuntijoita, vaikka varmasti osaavat todella paljon asioita, joita tavispulliainen ei osaa. 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.
Käytännössä jokainen tuntemani koodari tekee tuota. Joko oman tiimin/firman sisällä, maksettuina koulutuksina tai erilaisissa meetupeissa ja konferensseissä.
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Sä oot nyt kyllä aivan pihalla! Myönnä jo.
Sisältö jatkuu mainoksen alla
Olen AV:n asiantuntijatehtävissä. Erikoisalaani ovat ihmissuhdetaidot ja erityisesti parisuhde.
Vierailija kirjoitti:
Vierailija kirjoitti:
Ne ohjelmiston tekijät, jotka ymmärtävät syvällisesti myös jotain tiettyä alaa koodin lisäksi ovat melkein yrittäjiä.
Koodaaminen on ala itsessään.
T: yksi joka koodaa työssään eikä ole koodaamisen asiantuntija (vaan tutkimusalansa), ja aina välillä meinaa päästä itku kun selviää, miten paljon parempia algoritmeja maailmassa on, ja minä en niistä ole kuullut.
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Linus Torvalds
Sisältö jatkuu mainoksen alla
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Miksi haluat nähdä asiantuntijuudeksi vain toimialan asiantuntijuuden? Minusta myös ohjelmistotekninen osaaminen on asiantuntijuutta, ja molempia lajeja tarvitaan että käyttäjille hyödyllinen sovellus syntyy.
Mutta ei se ihan noin suoraviivaista silti ole että "koodarille kerrotaan mitä ohjelmistossa tarvitaan ja mitä ei". Kyllä näitä yhdessä asiakkaan edustajan kanssa ideoidaan, tehdään protoja ja kokeillaan olisiko tämä hyvä vai sittenkin tämä toinen.
Esim. itse olen joskus tehnyt sovellusta jolla yrityksissä voidaan kirjata tunteja. En koodarina ollut se, joka aktiivisesti seuraa työaikalainsäädännön muutoksia, vaan jos johonkin työehtosopimukseen tuli muutoksia, asiakkaalla joka oli tilannut projektin oli juristi, joka kommunikoi nämä muutokset minulle joka sitten toteutin asian sovellukseen itsenäisesti. Mutta kun tehtiin uusia juttuja niin ei se niin mennyt että joku olisi sanonut että lisää tällainen uusi näyttö jolla nämä kentät, vaan asiakkaat halusivat että ideoin itse ja ehdotan. He voivat sitten loppukäytön tuntevana vaikka sanoa, että ei, tuo on vähän kömpelö käyttää, kokeillaan muuta, ja sitten muutetaan. Tai sitten joskus he ovat iloisia että ehdotin tapaa joka heille ei olisi tullut mieleenkään. Kun on 20 vuotta koodannut kaikenlaisia järjestelmiä niin jotain itua alkaa väkisinkin olla myös käyttökokemuksen suunnittelusta, ja toisaalta joskus esim. vanhan järjestelmän käyttäjät eivät osaa ajatella sen vanhan systeemin ulkopuolelta, että joku ihan muunlainen toteutus kuin samanlainen kuin vanha olisi hyvä.
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:
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Onneksi ei tarvitse olla töissä puljussa jossa omaa ammattitaitoa ei arvosteta lainkaan. Kuulostaa nimittäin aika kauhealta.
Näytätkö kohdan, jossa sanottiin, ettei koodaajalla ole ammattitaitoa?
No esimerkiksi se missä koodarin "luomusta" verrattiin nakkikioskilta ostettuun ruoka-annokseen.
Sisältö jatkuu mainoksen alla
Kärjistetysti hyvä koodaaja osaa laskea sataan esimerkiski kirjoittamalla 1*100, mutta huono tunaa 100 riviä koodia lisäämäällä aina yhden. Lähtötilanne oli siis se, että bisnesporukalta tuli käsky saada laskettua sataan. Molemmat toimii, mutta kuinka hyvin..
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:
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Niin, kun se koodaaja on ohjelmointialan asiantuntija. Ohjelmointi on aivan oikea, asiantuntemusta vaativa ala itsessään. (Ei jestas että tällaisia lauseita tarvitsee näppäimistöllään tuottaa.)
Niin, mutta teetkö sinä työtä se eteen, että joku muu oppisi ymmärtämään koodaamista? Tottakai vaatii asiantuntemusta ja ihan järjetöntä osaamista, mutta ei se silti työn luonnetta muuta asiantuntijatyöksi. Asiantuntijatyö ei ole synonyymi sille, että työssä tarvitaan asiantuntemusta ja osaamista. Esimerkiksi sirkustaiteilija tai lentäjäkään ei ole asiantuntijoita, vaikka varmasti osaavat todella paljon asioita, joita tavispulliainen ei osaa. 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.
Kyllä ainakin meillä tiedonhankinta ja -siirtäminen ovat ihan keskiöissä siinä että pystytään tarjoamaan asiakkaille laatua. Mentoroidaan junnuja, käydään kinkkisempiä projekteja läpi porukalla, code reviewit jne. Kysytään neuvoa jos tiedetään että joku firmassa osaa jotain paremmin, opetellaan itse jos ei kukaan osaa ja opetetaan muille. Eihän koodari ole koskaan valmis, uusia teknologioita tulee koko ajan ja kaiken voi aina tehdä fiksummin ja paremmin. Firman prinsiippinä on että 80% duunista laskutetaan asiakkaalta ja 20% on itsensä tai muiden kehittämistä.
Kuvitteletko sinä että koodaaminen opetellaan koulussa ja sitten vain koodataan niillä opeilla kuin jossain liukuhihnalla?
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:
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.
Eipä ole mikään ihme, että terveydenhuollon järjestelmät kiveenhakattuja ja vaikeakäyttöisiä monoliittejä, jotka maksavat kymmeniä miljoonia ja käyttöönotot viivästyvät vuosikausia!
Näinpä. Olin joskus CGI:llä töiss'ä ja siellä juuri tuontapaisissa tuotekehitystiimeissä, jotka usein teki esim. valtiolle, kunnille tai julkisvaroin ostetuiksi palveluiksi tuotteita, elettiin ihan muinaisajoissa teknisesti ja metodologisesti.
Itse olin tehnyt ketterää kehitystä jossa "koodari" tekee kaikkea yhdessä asiakkaan kanssa, protoillaan jne. Sitten joudut jonnekin kivikaudelle jossa ensinnäkin softaa kehitetään jollain muinaisajan sovelluskehittimellä, jossa jokaisella on tarkka, tiukkaan määrätty rooli jonka ulkopuolelta ihminen ei osaa mitään eikä haluakaan oppia, ja jossa projektin aloittaa kuukausien speksausjakso jonka aikana koodarit istuu tumput suorina ja odottaa määrittelyvaiheen valmistumista. Hyi että.
Julkisen puolen tietojärjestelmien käyttäjän näkökulmasta ihmettelen kyllä usein, miten vaikeaa niitä on saada toimivaksi. Kun kysyy toimittajan edustajalta, voisiko jonkin toiminnon saada järkevämmäksi, vastaus on, että ei onnistu, "koska se on koodattu näin".
Johtuu pitkälti julkisen puolen hankintamallista (joka taas johtuu osin lainsäädännöstä).
Järjestelmätoimittajat sitoutuvat noudattamaan lainsäädännön vaatimuksia järjestelmän kehittämisessä, mutta muutoksia ei vain pystytä toteuttamaan.
No niin. Eivätkö nämä kommentit nyt kerro sen, että koodaajan ja käyttäjän välille tarvitaan joku asiantuntija ja oikea käyttäjä, eikä se koodaaja ilman alan asiantuntemusta itsekseen kovin toimivaa järjestelmää saa aikaan. Ei jokainen koodaaja voi olla asiantuntija niillä aloilla, joille sitä järjestelmää on tekemässä. Siinä suunnittelussa nimenomaan tarvitaan laaja-alaista näkemystä sieltä käyttäjäpuolelta.
Toki tarvitaan oikea käyttäjä, mutta useimmiten se ei nykyään ole it-toimittajan palveluksessa vaan projektin tilaavan asiakkaan palveluksessa. Esim. järjestelmän pääkäyttäjä asiakasfirmasta on hyvin tyypillinen henkilö kommunikoimaan koodarin ja loppukäyttäjien välillä tässä roolissa.
No tuohan vie nimenomaan sen koodarin vielä kauemmas siitä asiantuntijuudesta, jos ei edes työskennellä sen yrityksen alaisuudessa, jolle sitä ohjelmistoa tehdään eikä edes sen toimialan palveluksessa, vaan tehdään projekti sinne ja toinen tänne. Ja täällä kuitenkin väitetään, että koodarit aina ovat asiantuntijoita sillä alalla, jolle ohjelmistoa suunnittelevat. Miten ihmeessä it-firman koodaaja voisi olla asiantuntija sekä elintarviketeollisuudessa että terveydenhuoltoalalla ja vielä vaikka logistiikassa, jos asiakkaita sattuu tulemaan tällaisilta aloilta? Tämä on nyt se juju, mitä minä yritän selittää. Koodarit ovat toki asiantuntijoita sillä omalla alallaan, mutta ei heiltä voi vaatia täyttä osaamista ja ymmärrystä noiden alojen sisäisistä erityispiirteistä. It-firman koodaaja ei voi sanoa olevansa elintarvikealan asiantuntija, jos hän on koodannut asiakkaalle ohjelmiston, vaan kyllä siinä koodaamisesssa tarvitaan nimenomaan se osaaminen sieltä elintarvikealan sisältä, josta sitten koodaajalle vain kerrotaan, mitä ohjelmistossa tarvitaan ja mitä ei.
Niin, kun se koodaaja on ohjelmointialan asiantuntija. Ohjelmointi on aivan oikea, asiantuntemusta vaativa ala itsessään. (Ei jestas että tällaisia lauseita tarvitsee näppäimistöllään tuottaa.)
Niin, mutta teetkö sinä työtä se eteen, että joku muu oppisi ymmärtämään koodaamista? Tottakai vaatii asiantuntemusta ja ihan järjetöntä osaamista, mutta ei se silti työn luonnetta muuta asiantuntijatyöksi. Asiantuntijatyö ei ole synonyymi sille, että työssä tarvitaan asiantuntemusta ja osaamista. Esimerkiksi sirkustaiteilija tai lentäjäkään ei ole asiantuntijoita, vaikka varmasti osaavat todella paljon asioita, joita tavispulliainen ei osaa. 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.
Kyllä ainakin meillä tiedonhankinta ja -siirtäminen ovat ihan keskiöissä siinä että pystytään tarjoamaan asiakkaille laatua. Mentoroidaan junnuja, käydään kinkkisempiä projekteja läpi porukalla, code reviewit jne. Kysytään neuvoa jos tiedetään että joku firmassa osaa jotain paremmin, opetellaan itse jos ei kukaan osaa ja opetetaan muille. Eihän koodari ole koskaan valmis, uusia teknologioita tulee koko ajan ja kaiken voi aina tehdä fiksummin ja paremmin. Firman prinsiippinä on että 80% duunista laskutetaan asiakkaalta ja 20% on itsensä tai muiden kehittämistä.
Kuvitteletko sinä että koodaaminen opetellaan koulussa ja sitten vain koodataan niillä opeilla kuin jossain liukuhihnalla?
Ihan selkeästi tuo kuvittelee niin. Teksti ja toimintatavat ovat suoraan ysäriltä. Teki heti mieli alkaa vääntämään Delphiä kun luki tuota.
Vierailija kirjoitti:
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?
Kyllähän ne ohjelmistot jollekin ylläpitoon jäävät, useimmiten toteuttajafirmalle, aktiivisen kehitysvaiheen jälkeen. Me kehittäjät tosiaan ryntäämme seuraaviin projekteihin jotka voivat olla aivan eri toimialaa, mutta vanhat projektit ovat edelleen ylläpidossa niin että jos sieltä tulee bugiraportteja niin korjaamme, tai voidaan myös joskus tilata uuskehitystä näihinkin järjestelmiin.
Itse olen jo vanha jäärä joka aloitin ohjelmistoalalla 1990. Kyllä alkuun hirvitti se meno, että projektit voi olla vain viikkojen mittaisia, toteutetaan tekniikoilla joita ei tunne, toimialalla jota ei tunne, mutta kumma kyllä, laatu ja asiakastyytyväisyys eivät näytä laskeneen. Päinvastoin, asiakkaat ovat tyytyväisempiä kun projektit on halpoja, lyhyitä ja kevyitä ja protoilevan kehitysmallin takia sitä mitä he ovat halunneet.
Koodarilta tämä malli vaatii kyllä paljon, joskus liikaa. Esim. nyt olen projektissa jossa käytetyistä tekniikoista en ole ennen kuullutkaan, mutta koska olen kallis asiantuntijakonsultti, en voi sanoa että aion tässä nyt ekat pari viikkoa vähän googletella tutoriaaleja, vaan täytyy olla olevinaan asiantuntija ja illat jaosin yötkin käyttää ilmaiseen itseopiskeluun, että pärjää.
Omassa työssäni asiantuntijana osallistun esimerkiksi rakennushankkeiden ympäristövaikutusten arviointiprosesseihin ja laadin ympäristö- ja vesilupahakemuksia sekä erilaisia ympäristön tarkkailu- ja näytteenottosuunnitelmia. Noin ylipäätään siis em. aiheisiin liittyvää suunnittelu- ja konsulttityötä. :)
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.
Alue: Aihe vapaa
Minä huutelen nyt ihan sivusta. En ole it-alalla, mutta ymmärrän kyllä vallan hyvin, että minun substanssiosaamiseni on aivan eri alalta kuin asiakkaani substanssiosaaminen. Eihän asiakas muuten minua tarvitsisi.