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:
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.
Sisältö jatkuu mainoksen alla
Sisältö jatkuu mainoksen alla
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.
Olen itse koodaajien kanssa yhteistyötä tekevä konsultti ja en voi kuin ihmetellä tuollaista käsitystä, että koodaaja ei olisi asiantuntija. Koodaajat ovat mitä suurimmassa määrin asiantuntijoita. Missä ihmeen paikassa tuolaidta ” tarkkaan määroteltyjen säännöksien viemistä järjestelmään” tehdään. Ei ihan kuulosta koodaamiselta eikä kommentoija kuulosta siltä että hän olisi koodaajaa nähnytkään.
Minähän nimenomaan sanoin, että en ole koodaaja, vaan se asiantuntija. Tuota nimenomaan tarkoitinkin, että koodaaminen on kuitenkin todella kaukana niistä varsinaisista säännöksistä, että koodaaja ei ole siinä asiantuntija. Tuolla kyllä sanoin, että koodaaja toki on asiantuntija siinä koodaamisessa, mutta se voidaan katsoa eräällä tavalla suorittavaksi työksi. Vähän niin kuin laulaja ja laulun opettaja. Toinen myy asiantuntemusta ja konsultointia ja toinen myy omaa tuotostaan. Kumpaakaan tietysti väheksymättä, mutta tällainen vivahde-ero.
Selvästikään et ole koodari, jos luulet, että se on suorittavaa työtä. On olemassa vähän erilaisia mielipiteitä koodaamisen luonteesta. Joidenkin mielestä se on luovaa työtä ja verrattavissa taiteilijaan. Toisten mielestä muihin insinööritieteisiin verrattavaa suunnittelutyötä. Joka tapauksessa nykypäivänä kaltaisesi asiantuntijat kuolevat sukupuuttoon, koska nykyäön nimenomaan ohjelmistokehittäjä toimii useimmiten siinä roolissa, että hän on neuvottelemassa esimerkkisi tapauksessa siåiitä miten jokin säännöksen muutos vaikuttaa.
Juu, en ole koodari, se täytyy myöntää. Ehkä minulla on ollut sitten väärä mielikuva, kun en ole ajatellut, että vaaditaan suurta luovuutta tai suunnittelutyötä, kun koodaajalle kerrotaan, että tähän pitää lisätä tällainen teksti ja tuo tieto pitää saada linkittymään nyt tuon kohdan sijaan tähän ja tuohon. Olen luullut, että siellä koodissa on tietyt kohdat ja komennot, joilla nämä saadaan aikaan ja ne pitää sieltä vain löytää ja saada toimimaan oikein.
En oikein ymmärrä, mitä tarkoitat tuolla, että koodari on yhtäkkiä se asiantuntija. Mielestäni tuolla kerroin, että minä sitä ohjelmistoa kehitän niiden säännösten perusteella ja koodari sitten toteuttaa ne. Koodari ei ainakaan meillä seuraa niitä säädöksiä, hänellä ei ole minkäänlaista koulutusta tälle alalle. Me kehittäjät käytämme itse sitä ohjelmistoa ja olemme muiden käyttäjien kanssa yhteydessä ja sieltä tulee esiin niitä muutostarpeita eikä siellä koodaajan näytöllä.
Eipä joku yksittäisen tekstin tai tiedon linkittäminen mikään iso juttu olekaan. Mutta sitten kun pinotaan niitä pikkujuttuja yhteen kasaan vaikka viisi vuotta niin käytetyistä työtunneista ja järjestelmän toimivuudesta näkee kyllä että onko koodari ollut asiantuntija vai toteuttanut vain laput silmillä bisneksen vaatimuksia yksi kerrallaan.
Pointti onkin siinä, että me asiantuntijat seuraamme koko ajan sitä pikkujuttujen kasaa, ei se koodari. Mielestäni olen jo moneen kertaan sanonut, että me asiantuntijat testaamme sitä ihan koko ajan ja kartoitamme niitä muutostarpeita. Mistä ihmeestä sait käsityksen, että me heittelemme sinne koodarin pöydälle vain jotain irrallisia random-vaatimuksia ja vain toivomme, että joku sitä järjestelmää osaa ja tykkää sitten käyttää?
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.
Olen itse koodaajien kanssa yhteistyötä tekevä konsultti ja en voi kuin ihmetellä tuollaista käsitystä, että koodaaja ei olisi asiantuntija. Koodaajat ovat mitä suurimmassa määrin asiantuntijoita. Missä ihmeen paikassa tuolaidta ” tarkkaan määroteltyjen säännöksien viemistä järjestelmään” tehdään. Ei ihan kuulosta koodaamiselta eikä kommentoija kuulosta siltä että hän olisi koodaajaa nähnytkään.
Minähän nimenomaan sanoin, että en ole koodaaja, vaan se asiantuntija. Tuota nimenomaan tarkoitinkin, että koodaaminen on kuitenkin todella kaukana niistä varsinaisista säännöksistä, että koodaaja ei ole siinä asiantuntija. Tuolla kyllä sanoin, että koodaaja toki on asiantuntija siinä koodaamisessa, mutta se voidaan katsoa eräällä tavalla suorittavaksi työksi. Vähän niin kuin laulaja ja laulun opettaja. Toinen myy asiantuntemusta ja konsultointia ja toinen myy omaa tuotostaan. Kumpaakaan tietysti väheksymättä, mutta tällainen vivahde-ero.
Et olisi voinut naurettavampaa analogiaa keksiä kuin tuon laulaja-laulunopettajan. Sinä ilmeisesti hahmotat opastavasi koodaajia viemään ”monimutkaisia säännöstöjä järjestelmään” . Ja sitten järjestelmät taas laulavat kauniisti :D
T. Konsultti joka ei koodaa
Osallistun puhelinkokouksiin, ja kerron miten asioita pitää tehdä. Luen ja teen paljon powerpointteja ja excel taulukoita.
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Ehkä minulla on ollut sitten väärä mielikuva, kun en ole ajatellut, että vaaditaan suurta luovuutta tai suunnittelutyötä, kun koodaajalle kerrotaan, että tähän pitää lisätä tällainen teksti ja tuo tieto pitää saada linkittymään nyt tuon kohdan sijaan tähän ja tuohon.
Mistä tulee se tekninen ympäristö jossa sovellusta ajetaan? Tietokanta johon ne näytöltä tallennettavat tiedot tallennetaan? Kuka ottaa huomioon esim. GDPR lainsäädännön vaatimukset tietoturvalle ja loppukäyttäjän oikeuksille henkilötietoihinsa? Tämä kaikki on myös koodarin työtä, ei pelkästään valmiiksi rakennetussa sovelluksessa pienten lisäominaisuuksien näpertely.
Itse kun pienehköissä konsulttifirmoissa pääosin pyörinyt niin päässyt "koodarina" osallistumaan vähän kaikkeen alkaen markkinoinnista ja myynnistä arkkitehtuurin suunnittelemiseen, varsinaiseen toteuttamiseen integraationeen, käyttöönottoihin, koulutuksiin jne joten perspektiivi voi olla vähän erilainen kuin jonkun mammuttifirman junnukoodaarilla mutta yksi tärkeä osa koodarin asiantuntijuutta on bisnesvaatimusten "järkeistäminen". Siis se että ne vaatimukset toteutetaan tavalla joka aidosti hyödyttää bisnestä parhaalla mahdollisella tavalla ja toisaalta teknisesti siten että järjestelmä pysyy teknisesti vakaalla pohjalla. Oikein pätevä koodari osaa myös ehdottaa parempia ratkaisuja silloin kun bisnes ei osaa niitä pyytää.
Ehkä tämä on nyt ongelmana tässä keskustelussa. Jos jossain firmassa koodari tekee markkinointia ja koulutuksia ja suunnittelee kaiken alusta loppuun itse ja saa melko vapaat kädet, se on aika kaukana sellaisen firman koodaajasta, jolle tuodaan kaikki lähes valmiina eteen eikä tarvitse kantaa huolta niiden asioiden oikeellisuudesta tai hyödystä bisneksen kannalta. En nyt siksi ihan ymmärrä, miksi tässä pillastutaan, jos totesin, että se ydinkoodaaminen on suorittavaa työtä, jos sitten sille koodaajalle voidaan sen lisäksi heittää vastuu noin monesta muustakin asiasta, jotka eivät varsinaisesti liity itse koodaamiseen.
Minun työssäni se bisnesvaatimusten järkeistäminen on nimenomaan meillä asiantuntijoilla. Me teemme työtä sen eteen, että ohjelmisto palvelee nimenomaan meidän asiakkaitamme, eikä siinä ole yhtään turhaa tai liian vaikeaa ominaisuutta. Me myös testaamme sitä käytössä ihan jatkuvasti ja esitämme ideoita, miten joku asia voitaisiin toteuttaa tehokkaammin. Toki koodaritkin näin tekevät, mutta heidän panoksensa liittyvät siihen rakenteeseen ja toteutukseen eikä sisällöllisiin vaatimuksiin ja käytettävyyteen tai uusiin ohjelmiston ulkopuolisiin mahdollisuuksiin.
Ehkäpä siinä tosiaan on yksi ongelma. Minun korviini tuo sinun käsityksesi koodareista kuulostaa lähinnä juniorien ja harjoittelijoiden hommilta. Toki jos on kyse erityisen monimutkaisista järjestelmistä tai vaikkapa erityisen haastavasta algoritmiikasta niin sitten on eri juttu mutta siinä vaiheessa on kyllä enää ihan turha puhua suorittavasta työstä.
En ehkä ihan ymmärrä, mitä tarkoitat. Siis mikä on eri juttu? Ja kumpi on juniorien ja harjoittelijoiden hommaa, se, mitä minä teen vai se, mitä koodaaja tekee? Minä en siis ole koodaaja, vaan olen se asiantuntija.
Se sinun kuvaamasi koodarin työ on sellaista, jollaista nykyaikana useimmissa firmoissa / tiimeissä ei tee kuin korkeintaan joku juniori jota vasta ajetaan sisään työhön. Sellaisten työ voi alkuun koostua lähinnä yksinkertaisten muutosten tekemisestä jo olemassaolevaan softaan, tyyliin uusi kenttä lisätään näytölle tms. Tuollainen kieltämättä on suorittavaa työtä eikä välttämättä asiantuntijatyötä, mutta juuri kukaan koodari ei ehkä uran ihan alkuaikoja lukuunottamatta sellaista nykyään tee. Paitsi niissä aiemmin kuvatuissa dinosaurusajan projekteissa, joissa yksi speksaa, yksi suunnittelee, yksi tekee käyttöliittymäkerrosta, yksi tietokantakerrosta, yksi bisneslogiikkakoodia jne.
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:
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.
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.
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.
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.
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.
Olen itse koodaajien kanssa yhteistyötä tekevä konsultti ja en voi kuin ihmetellä tuollaista käsitystä, että koodaaja ei olisi asiantuntija. Koodaajat ovat mitä suurimmassa määrin asiantuntijoita. Missä ihmeen paikassa tuolaidta ” tarkkaan määroteltyjen säännöksien viemistä järjestelmään” tehdään. Ei ihan kuulosta koodaamiselta eikä kommentoija kuulosta siltä että hän olisi koodaajaa nähnytkään.
Minähän nimenomaan sanoin, että en ole koodaaja, vaan se asiantuntija. Tuota nimenomaan tarkoitinkin, että koodaaminen on kuitenkin todella kaukana niistä varsinaisista säännöksistä, että koodaaja ei ole siinä asiantuntija. Tuolla kyllä sanoin, että koodaaja toki on asiantuntija siinä koodaamisessa, mutta se voidaan katsoa eräällä tavalla suorittavaksi työksi. Vähän niin kuin laulaja ja laulun opettaja. Toinen myy asiantuntemusta ja konsultointia ja toinen myy omaa tuotostaan. Kumpaakaan tietysti väheksymättä, mutta tällainen vivahde-ero.
Et olisi voinut naurettavampaa analogiaa keksiä kuin tuon laulaja-laulunopettajan. Sinä ilmeisesti hahmotat opastavasi koodaajia viemään ”monimutkaisia säännöstöjä järjestelmään” . Ja sitten järjestelmät taas laulavat kauniisti :D
T. Konsultti joka ei koodaa
Öö, ei. En ole väittänyt opastavani koodaajaa, vaan sitä ohjelmiston käyttäjää. Perehdyn uusiin säännöksiin ja mietin, miten ohjelmistoa voisi kehittää siten, että käyttäjälle nämä uudet säännökset tulevat helposti toteutettaviksi.
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:
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.
Olen itse koodaajien kanssa yhteistyötä tekevä konsultti ja en voi kuin ihmetellä tuollaista käsitystä, että koodaaja ei olisi asiantuntija. Koodaajat ovat mitä suurimmassa määrin asiantuntijoita. Missä ihmeen paikassa tuolaidta ” tarkkaan määroteltyjen säännöksien viemistä järjestelmään” tehdään. Ei ihan kuulosta koodaamiselta eikä kommentoija kuulosta siltä että hän olisi koodaajaa nähnytkään.
Minähän nimenomaan sanoin, että en ole koodaaja, vaan se asiantuntija. Tuota nimenomaan tarkoitinkin, että koodaaminen on kuitenkin todella kaukana niistä varsinaisista säännöksistä, että koodaaja ei ole siinä asiantuntija. Tuolla kyllä sanoin, että koodaaja toki on asiantuntija siinä koodaamisessa, mutta se voidaan katsoa eräällä tavalla suorittavaksi työksi. Vähän niin kuin laulaja ja laulun opettaja. Toinen myy asiantuntemusta ja konsultointia ja toinen myy omaa tuotostaan. Kumpaakaan tietysti väheksymättä, mutta tällainen vivahde-ero.
Selvästikään et ole koodari, jos luulet, että se on suorittavaa työtä. On olemassa vähän erilaisia mielipiteitä koodaamisen luonteesta. Joidenkin mielestä se on luovaa työtä ja verrattavissa taiteilijaan. Toisten mielestä muihin insinööritieteisiin verrattavaa suunnittelutyötä. Joka tapauksessa nykypäivänä kaltaisesi asiantuntijat kuolevat sukupuuttoon, koska nykyäön nimenomaan ohjelmistokehittäjä toimii useimmiten siinä roolissa, että hän on neuvottelemassa esimerkkisi tapauksessa siåiitä miten jokin säännöksen muutos vaikuttaa.
Juu, en ole koodari, se täytyy myöntää. Ehkä minulla on ollut sitten väärä mielikuva, kun en ole ajatellut, että vaaditaan suurta luovuutta tai suunnittelutyötä, kun koodaajalle kerrotaan, että tähän pitää lisätä tällainen teksti ja tuo tieto pitää saada linkittymään nyt tuon kohdan sijaan tähän ja tuohon. Olen luullut, että siellä koodissa on tietyt kohdat ja komennot, joilla nämä saadaan aikaan ja ne pitää sieltä vain löytää ja saada toimimaan oikein.
En oikein ymmärrä, mitä tarkoitat tuolla, että koodari on yhtäkkiä se asiantuntija. Mielestäni tuolla kerroin, että minä sitä ohjelmistoa kehitän niiden säännösten perusteella ja koodari sitten toteuttaa ne. Koodari ei ainakaan meillä seuraa niitä säädöksiä, hänellä ei ole minkäänlaista koulutusta tälle alalle. Me kehittäjät käytämme itse sitä ohjelmistoa ja olemme muiden käyttäjien kanssa yhteydessä ja sieltä tulee esiin niitä muutostarpeita eikä siellä koodaajan näytöllä.
Eipä joku yksittäisen tekstin tai tiedon linkittäminen mikään iso juttu olekaan. Mutta sitten kun pinotaan niitä pikkujuttuja yhteen kasaan vaikka viisi vuotta niin käytetyistä työtunneista ja järjestelmän toimivuudesta näkee kyllä että onko koodari ollut asiantuntija vai toteuttanut vain laput silmillä bisneksen vaatimuksia yksi kerrallaan.
Pointti onkin siinä, että me asiantuntijat seuraamme koko ajan sitä pikkujuttujen kasaa, ei se koodari. Mielestäni olen jo moneen kertaan sanonut, että me asiantuntijat testaamme sitä ihan koko ajan ja kartoitamme niitä muutostarpeita. Mistä ihmeestä sait käsityksen, että me heittelemme sinne koodarin pöydälle vain jotain irrallisia random-vaatimuksia ja vain toivomme, että joku sitä järjestelmää osaa ja tykkää sitten käyttää?
Sinä toimit eri abstraktiotasolla kuin se koodari. Se tässä taitaa olla se juju jota sinä et oikein ymmärrä. Sinä teet varmasti hyvää työtä omalla abstraktiotasollasi mutta jos se koodari ei ole vähintään yhtä asiantuntija omallaan niin ne teidän hyvinkin suunnitellut ja speksatut prosessinne ovat yhtä tyhjän kanssa.
Sisältö jatkuu mainoksen alla
Yritysvideoita ja kohta elokuvan.
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.
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:
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.
Kai se vähän riippuu projektin koostakin. Meillä on usein oma business analyst projektitiimissä (ja/tai mahdollisesti toinen asiakkaalta jos heillä sellainen on) tuossa pääkäyttäjien ja devaajien/koodaajien välissä.
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?
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.)
Ne ohjelmiston tekijät, jotka ymmärtävät syvällisesti myös jotain tiettyä alaa koodin lisäksi ovat melkein yrittäjiä.
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.
Käyttelen paria mittalaitetta, joiden säätäminen on tarkkaa puuhaa. Tulosten tulkinnassa se asiantuntijuus oikeastaan vasta punnitaan, koneen käyttäminen vaatii vain sorminäppäryyttä ja kokemusta. Ikävä kyllä työ on viime vuosina kehittynyt yhä enemmän siihen suuntaan, että mittaan vain muiden näytteitä, toimitan datan ja asiakkaat tulkitsevat sen itse (usein päin persettä).
Alue: Aihe vapaa
En ehkä ihan ymmärrä, mitä tarkoitat. Siis mikä on eri juttu? Ja kumpi on juniorien ja harjoittelijoiden hommaa, se, mitä minä teen vai se, mitä koodaaja tekee? Minä en siis ole koodaaja, vaan olen se asiantuntija.