Tieto OyJ

[Kautium]

No niin no, riippuu mitä tarkoitetaan alkeellisella virheellä. Nuo bugit menee kategoriaan "ainoa bugiton softa on softa jota ei ole kirjoitettu".
Vierityspalkin puuttuminen on tod. näk. UI-frameworkin feature, laita kaksi ikkunaa vierekkäin niin ne toteaa että nyt ei ole tilaa kaikelle tälle sisällölle joten laitetaan scrollbar autohideen.
Rullahiiren toiminta voi myös olla UI-frameworkin feature, tai sitten vaan se perinteinen erittäin yksinkertainen käpy että on jäänyt pois joku manuaalinen defocus eventtihanskauksessa.

Molemmat on vielä sellaisia bugeja että nuo myös helposti missaa testauksessa. Niin automaattisessa kuin manuaalisessakin.

En nyt ihan ymmärrä millä logiikalla scrollbarin puuttumista voi perustella tuolla tavalla vähätellen, varsinkaan jos se piilottaa osan tiedoista? Pudotusvalikon sisällön kahlaus rullalla on ikävän yleinen vika siihen tehdyn valinnan jälkeen, mutta siinäkin pitäisi nähdä millä tavalla se käyttäytyy, kun kerran korjaus on ollut Tiedon puolelta että "ko. sovellusta käytettäessä ei saa käyttää rullahiirtä lainkaan".

Ikävän usein Tiedon tuotokset ovat tosiaan tällaisia ja taustalla on useimmiten kiire ja testauksen puutteellisuus, kun yritetään maksimoida voittoa.

 

[Alceste]

Ei, vaan kumpi tahansa voi pilata projektin. Pieleen mennyt suunnittelu tai osaamattomat koodarit.

Intia on täynnä osaamattomia koodareita, ja esim. Nokialla yleinen tilanne oli, että joku juttu ensin suunniteltiin suomalaisten toimesta, ja sitten intialaisten käskettiin koodata se. Takaisin tuli hirveä buginen roska ja suomalaisten piti käyttää about yhtä paljon aikaa sen korjaamiseen kuin mitä olisi mennyt sen alunperinkin koodaamiseen suomessa. Ja sitten projektit myöhästeli.

Tämä on nykystandardi isommissa suomifirmoissa nykyään. Vittu kun osaisivat edes tasata rivit oikein.

 

[JCSH]

En nyt ihan ymmärrä millä logiikalla scrollbarin puuttumista voi perustella tuolla tavalla vähätellen, varsinkaan jos se piilottaa osan tiedoista? Pudotusvalikon sisällön kahlaus rullalla on ikävän yleinen vika siihen tehdyn valinnan jälkeen, mutta siinäkin pitäisi nähdä millä tavalla se käyttäytyy, kun kerran korjaus on ollut Tiedon puolelta että "ko. sovellusta käytettäessä ei saa käyttää rullahiirtä lainkaan".

Ikävän usein Tiedon tuotokset ovat tosiaan tällaisia ja taustalla on useimmiten kiire ja testauksen puutteellisuus, kun yritetään maksimoida voittoa.

En vähättele tuon scrollbar bugin merkitystä loppukäytön kannalta, sanon vaan että tuo on bugi jollaisia tulee käytännössä kaikilta koodareilta. Ja kyseessä on bugi jollaisia käytännössä kaikki testaajat missaa. Ja kyseessä on bugi joka menee helposti läpi QA prosessista vaikka se olisi hyvin rakennettu.
Toki tuosta pitää oppia ja toista kertaa ei pitäisi mennä enää samalta tiimiltä / projektilta tuollaisia läpi.

Ja Tiedon korjaus ei ollut että rullahiirtä ei saa käyttää, se oli niiden turvallisuustiedote jossa sanottiin "Älkää käyttäkö rullaa toistaiseksi". Eli kunnes bugi on korjattu niin ei saa käyttää rullaa. Joka on paljon yksinkertaisempi suositus esim. 50 vuotiaille sairaanhoitajille kuin "Jos käytätte ohjelmassa jotain drop-down listaa niin varmistakaa että klickkaatte hiirellä johonkin neutraaliin alueeseen ennen kuin käytätte hiiren rullaa".

Ja joo, varmaan Tieto puskee pihalle tavaraa huonolla testauksella. Mutta ainakaan noiden kahden esimerkin tapauksessa en sanoisi että tuo on mikään systemaattinen ongelma Tiedon prosesseissa. Koska nuo molemmat ovat tyyliin one-line bugeja niin toteutuksen kuin sitä testaavan koodin osalta. Unohtuu asettaa se "alwaysShowScrollbar = true" ja sitten unohtuu yhden testikeissin lopussa tehdä tarkastus "isScrollBarVisible == true".
Ja kerta kyseessä on vielä medical toteutus niin noissa ei yleensä köyhäillä testauksen osalta koska jos kärähtää auditissa niin se on bye bye tulevien soppareiden osalta.

 

[Kautium]

Ja kerta kyseessä on vielä medical toteutus niin noissa ei yleensä köyhäillä testauksen osalta koska jos kärähtää auditissa niin se on bye bye tulevien soppareiden osalta.

Niinhän sitä voisi kuvitella, mutta silti köyhäilevät.

 

[Stephen Elop]

Niinhän sitä voisi kuvitella, mutta silti köyhäilevät.

Ei tossa varmaan mitään köyhäilyä ole. On vain asioita joita ei kuvitellukkaan olevan ongelma. UI-suunnittelussa ja toteutuksessa nörtit tehny softaa io-techiläisille, mutta sairaalan hoitajille homma ei ole niin päivänselvää.

Joitain bugeja/ongelmia ei vain tule aina esille, vaikka kaikki saatavilla olevat rahat pistettäisiin testaukseen ja laadunvarmistukseen. Viimeisin tuo prosessoreiden meltdown- ongelma. Ja Intel todellakin polttaa sitä rahaa prossun suunnittelun testaukseen.

 

[Kautium]

En vähättele tuon scrollbar bugin merkitystä loppukäytön kannalta, sanon vaan että tuo on bugi jollaisia tulee käytännössä kaikilta koodareilta. Ja kyseessä on bugi jollaisia käytännössä kaikki testaajat missaa. Ja kyseessä on bugi joka menee helposti läpi QA prosessista vaikka se olisi hyvin rakennettu.
Toki tuosta pitää oppia ja toista kertaa ei pitäisi mennä enää samalta tiimiltä / projektilta tuollaisia läpi.

Jos ja kun ollaan tekemässä terveydenhuollon tietojärjestelmää, niin aika heikolla tasolla on projekti ylipäätään jos resursseina käytetään koodareita/testaajia, jotka törmäävät ensimmäistä kertaa tuollaiseen.

 

[JCSH]

Jos ja kun ollaan tekemässä terveydenhuollon tietojärjestelmää, niin aika heikolla tasolla on projekti ylipäätään jos resursseina käytetään koodareita/testaajia, jotka törmäävät ensimmäistä kertaa tuollaiseen.

No kerro mulle mistä löytyy koodareita ja/tai testaajia jotka ovat oppineet virheistään koskaan tekemättä niitä virheitä. Tuollaisia yliluonnollisuuksia voisin heti rekrytä pari tiimiini.

 

[Jurputin]

Jos ja kun ollaan tekemässä terveydenhuollon tietojärjestelmää, niin aika heikolla tasolla on projekti ylipäätään jos resursseina käytetään koodareita/testaajia, jotka törmäävät ensimmäistä kertaa tuollaiseen.

Tämä aika tavalla alleviivaa sitä epäilystä että nyt ollaan käyttämässä "Mumbain" kadulta revittyjä koodareita. Lainausmerkit siksi, että Intiassa on paljon osaavaakin it-porukkaa, mutta he eivät kai sovi ennalta asetettuun budjettiin

 

[Kautium]

No kerro mulle mistä löytyy koodareita ja/tai testaajia jotka ovat oppineet virheistään koskaan tekemättä niitä virheitä. Tuollaisia yliluonnollisuuksia voisin heti rekrytä pari tiimiini.

Virheitä saa tehdä ja niistä pitää oppia, mutta ei niitä nöösipoikia/tyttöjä pidä laittaa sellaisiin projekteihin, joissa virheen seurauksena voi olla kyseessä ihmishenki. Varmaan Tiedolla on sellaisiakin projekteja, joissa ei kaikki ole samalla tavalla niin kriittistä.

 

[JCSH]

Virheitä saa tehdä ja niistä pitää oppia, mutta ei niitä nöösipoikia/tyttöjä pidä laittaa sellaisiin projekteihin, joissa virheen seurauksena voi olla kyseessä ihmishenki. Varmaan Tiedolla on sellaisiakin projekteja, joissa ei kaikki ole samalla tavalla niin kriittistä.

Nuo ei ole mitään aloittelijan virheitä. Ne on virheitä joita kokeneetkin, todella hyvät koodarit voivat tehdä. Se voi olla eka kerta kun ne tekee sen virheen 15 vuoden uralla tai se voi olla 10 kerta kun ne tekee sen virheen.
Hitto, hyvä kokenut koodari on tehnyt jokaisen klassisen ja tyhmän virheen vähintään 5 kertaa. Ja joka kerta kun se tekee sen virheen uudestaan niin se vituttaa pikkasen enemmän ja tekee virheen toistosta epätodennäköisemmän. Mutta se ei mitenkään poista sen virheen mahdollisuutta koska kukaan ei ole täydellinen ja kenelläkään ei riitä muisti siihen että muistaa jokaisen virheen jonka on tehnyt.

Tuo oppitunti kestää sen yhden projektin ajan. Siksi koska kun tuollainen pääsee tuotantoon niin todennäköisesti siitä nousee vähintäänkin sellainen paskamyrsky / vittuilu että tieto leviää projektin sisällä. Ja se hyvä, tai edes vähintään keskinkertainen, QA lead menee ja varmistaa että tuo on tsekattu jokaisen komponentin osalta.

Mutta sitten kun tuo projekti loppuu ja tiimit hajoaa ja porukat siirtyy muihin hommiin niin asiat vain unohtuvat. Kunnes joku taas tekee saman virheen.

 

[hsalonen]

@JCSH

QA Lead tai edes se testaaja on vaan, jos asiakas maksaa siitä. Pilotointi on tässä avainsana. Sitä ei vaan voi järjellisesti tehdä, jos koko tuote valmistuu kerralla vesiputouksesta. Nyt on testiympäristökin ollut ilman rullahiiriä

..ja edes jollakin budjetilla on se oikea pilottiprojekti, jossa oikeat käyttäjät testaa jollain yhdellä pienellä terveysasemalla ennenkuin mennään tuotantoon kaikkialla ja virhe koskeekin 100 ihmisen sijasta 50 000 ihmistä.

Minkään ison toiminallisuuden ei muutenkaan pitäisi olla missään projektissa yhden koodarin takana. Sitä voi pilkkoa pienemmiksi palasiksi ja käyttää muita tekemään pieniä palasia. Lisäksi nyt mietin, että kuinka paljon QA:ta on käytetty ja onko ne edes olleet Suomesta? VR:n lippujärjestelmässäkin unohtivat vaan kokonaan kaikki kunnon kuormitustestit ja järjestelmä skaalautui yhtä huonosti kuin IO-Tech Jimm'sin valvojaisten aikaan.

Taitaa taas ketterä kehitys olla kaunis sertifikaatti seinällä ja tuote ei oikeasti valmistu sprinteissä, jossa raakileesta kasvaa täysin toimiva tuote ajan kanssa, kuitenkin niin, että koko ajan asiakas voi testata ainakin osaa toiminnallisuudesta - ja jopa käyttää tuotetta kehitystyön ajan.

--

En edelleenkään usko siihen, että Tieto on täysi tunareita. Uskon paljon mieluummin teoriaan, että jossain on taas säästetty ja koodia on kehitetty vesiputousmallilla Intiassa. Suomessa ketterästi kehitetty tuote, joka olisi ollut protoina vuoden oikeassa käytössä DevOpsin pyöriessä taustalla ei yksinkertaisesti voisi olla näin buginen. Ja eniten vaikuttaa juuri tuo pilottiprojekti. Tuotannon data ja käyttötapaukset voivat olla radikaalisti erilaista kuin on testiympäristön rajalliset ja steriilit testi-caset.

 

[Mictian]

Tuosta LifeCaresta ollut puhetta, niin sitä ei näkemättä edes ymmärrä minkälainen kasa "höyryävää sitä itteään" tuo on.
Ensinnäkin asennus, vajaat 80! .msi pakettia, mitkä pitää asentaa vielä tietyssä järjestyksessä, siinä saa väsätä taskia hetken jos toisenkin.
Ja testaus, tähän väliin huutonaurua, sieltä tulee mistälie intiasta paketit ja eikun tuotantoon, ja sit testataan tuotannon päivitysyönä toimiiko vai ei, eli normimeininki "asiakas lopputestaa tuotannossa".

Eihän ny tommoset pikkuviat kuten hiiren rulla voi haitata, disabloidaan vaan kikkakolmosella koko rulla käytöstä (kuten loppukäyttäjiä ohjeistettiin että rullaa ei saa käyttää, teippasivat rullan toimimattomaksi, tää on nykypäivän atk:ta parhaimmillaan)

Yksi hauska tuossa on kanssa että läppäreissä tuota käytetään Citrixin kautta, koska LifeCare vetää herneet nenään heti jos verkkoyhteys pätkii tasan yhtään...

Ei kyllä voi ruohonjuuritason duunari käsittää miten tuollaista kuraa käytetään ja myydään miljoonilla, mutta se onkin sitä korkeapalkkaisten päätöksiä nuo.

 

[JCSH]

@JCSH

QA Lead tai edes se testaaja on vaan, jos asiakas maksaa siitä. Pilotointi on tässä avainsana. Sitä ei vaan voi järjellisesti tehdä, jos koko tuote valmistuu kerralla vesiputouksesta. Nyt on testiympäristökin ollut ilman rullahiiriä

..ja edes jollakin budjetilla on se oikea pilottiprojekti, jossa oikeat käyttäjät testaa jollain yhdellä pienellä terveysasemalla ennenkuin mennään tuotantoon kaikkialla ja virhe koskeekin 100 ihmisen sijasta 50 000 ihmistä.

Jos kyse on medical hommasta niin siellä on kyllä se QA ja ne testaajat. Olen kerran elämässäni tehnyt päätoimisesti vuoden ajan QA hommia ja se oli juurikin medical projektissa ja voin kertoa että QA noissa hommissa hoidetaan kyllä aika perusteellisesti. Aikataulut voi paukkua, ja usein paukkuukin, mutta QA:n kohdalla ei oiota mutkia koska siinä puhutaan oikeasti vitun suurista sakoista jos kärähtää auditeissa. Puhumattakaan menetystä maineesta ja mahdollisesti jopa sertifioinneista.
Toki tuo projekti oli sveitsiläiselle firmalle joten ehkä Suomessa hommat vedetään perseelleen mutta veikkaan että eiköhän täällä ole about samat regulaatio paineet.

Minkään ison toiminallisuuden ei muutenkaan pitäisi olla missään projektissa yhden koodarin takana. Sitä voi pilkkoa pienemmiksi palasiksi ja käyttää muita tekemään pieniä palasia. Lisäksi nyt mietin, että kuinka paljon QA:ta on käytetty ja onko ne edes olleet Suomesta? VR:n lippujärjestelmässäkin unohtivat vaan kokonaan kaikki kunnon kuormitustestit ja järjestelmä skaalautui yhtä huonosti kuin IO-Tech Jimm'sin valvojaisten aikaan.

Mutta eihän noissa esimerkeissä puhuta mistään isoista toiminnallisuuksista. Kyseessä on one-liner virheistä, niin toteutuksen kuin testauksen osalta. Toinen on yksittäisen UI-komponentin eventtihanskaus ja toinen on yhden ikkunan yksi property.
Tai siis mahdollisesti, kerta ei ole sorsia tuosta softasta niin ei voi muuta kuin spekuloida.

VR lippujärjestelmä taas onkin täysin eri skaalan juttu kuin nuo tuon artikkelin pari esimerkki bugia.

Taitaa taas ketterä kehitys olla kaunis sertifikaatti seinällä ja tuote ei oikeasti valmistu sprinteissä, jossa raakileesta kasvaa täysin toimiva tuote ajan kanssa, kuitenkin niin, että koko ajan asiakas voi testata ainakin osaa toiminnallisuudesta - ja jopa käyttää tuotetta kehitystyön ajan.

Tässä on pari ongelmaa. Eka on se että sä oletat että asiakas haluaa tehdä tuota pilotointia.

Toinen on se että sä oletat että asiakas pystyy tekemään tuota pilotointia. Koska kyseessä on medical projekti niin se vaatii aivan vitusti paperityötä ja erilaisia verifikaatioita ja auditteja ja regulatory checkkejä ennen kuin sitä voi käyttää oikeisiin potilaisiin. Sun devausprosessit voi olla niin agileja ja devopsattuja kuin haluaa mutta sillä ei ole kovin paljon väliä asiakkaan kannalta jos kestää se pari kolme kuukautta per software rellu jotta saat hyväksynnän FDA:lta ja/tai EMA:lta käyttää sitä softaa.

Kolmanneksi, sanoisin että on aika optimistista olettaa että nuo kaksi esimerkki bugia löydettäisiin helposti vaikka prosessit olisi ideaalit. Ne on molemmat bugeja jotka vaatii tietynlaisen käyttöpatternin softalle joka ei ole mikään ilmiselvä. Lisäksi ne molemmat vaativat sen että käyttäjä tajuaa että virhe on tapahtunut ja missä se on tapahtunut.

*edit* Niin joo ja ennen kuin joku alkaa teorisoimaan, en ole töissä Tiedolla, en ole koskaan ollut töissä Tiedolla ja mulla ei ole mitään erityisempiä suhteita Tietoon. Olen tosin ollut muutaman vuoden erittäin ison softakonsultointi/alihankinta firman palkkalistoilla joten kokemusta tuollaisista projekteista on kertynyt. Mutta en ole enää senkään firman listoilla.

 

[mystikkogames]

Hyvän ja huonon koodarin ero on se: Kummatkin tekevät virheitä, mutta vain hyvä koodari oppii niistä.

NASAlla on systeemit rakettien koodaukseen äärimmäisen tarkat. Loopeilla fixed loppu: Ei while (TRUE)... Ei mallocia missään. Ei varoituksia. Siellä on pelissä 1 000 000 000$ raketti ja ihmishenkiä niin mitään bugia ei voi olla.

Yleensäkin näistä tiedon ja muiden softapuljujen jutuista kun pelaa Buzzword Bullshit bingoa. Niin siitä saa jo hyvän kuvan kuinka paskaa niiden softankehitys on. Mitä useampi kokki sitä paskempi soppa... Machine learning, agile methods, neural networks, design patterns, deep learning...

 

[JCSH]

Hyvän ja huonon koodarin ero on se: Kummatkin tekevät virheitä, mutta vain hyvä koodari oppii niistä.

No niin no, hyvät koodarit toki oppii virheistään mutta se ei tarkoita että ne eivät enää tee niitä.
Lisäksi hyvät koodarit usein tekevät enemmän virheitä kuin huonot ihan puhtaasti sen takia että hyvät koodarit pystyy tuottamaan koodia paljon nopeammin. Jolloin myös virheitä tapahtuu enemmän.

NASAlla on systeemit rakettien koodaukseen äärimmäisen tarkat. Loopeilla fixed loppu: Ei while (TRUE)... Ei mallocia missään. Ei varoituksia. Siellä on pelissä 1 000 000 000$ raketti ja ihmishenkiä niin mitään bugia ei voi olla.

Juu on. Siitä huolimatta NASA on onnistunut brickkaamaan tai vetämään pillunpäreiksi useiden satojen miljoonien taalojen edestä luotaimia ja sateliitteja softabugeilla.

 

[David ":DA" Imodium]

Tiedon tuotoksissa ei loppupeleissä ole kyse koodarien tasosta vaan sisäisen laadunvalvonnan puutteesta ja täydellisestä kyvyttömyydestä itsekritiikkiin. Niin ylimielistä organisaatiota ei Suomessa toista ole. Tai no, jos ei eduskuntaa lasketa.

 

[Paapaa]

Tiedon tuotoksissa ei loppupeleissä ole kyse koodarien tasosta vaan sisäisen laadunvalvonnan puutteesta ja täydellisestä kyvyttömyydestä itsekritiikkiin. Niin ylimielistä organisaatiota ei Suomessa toista ole. Tai no, jos ei eduskuntaa lasketa.

Mä luulen, että Tiedon surkeutta korostaa se, että se osallistuu niin usein isoihin julkisiin hankkeisiin. Mokia tapahtuu kaikkien muidenkin softatalojen tuotoksissa, mutta ne eivät ikinä saa samanlaista julkisuutta, sillä ne on ostettu yksityisellä rahalla ja eivät koske niin isoa ihmismassaa. Ja osa ongelmaa on myös sen ostavan tahon puolella. Huono ja vesiputousmallinen speksaus, tiukat aikataulut ja puutteelliset resurssit testaukseen aiheuttavat varmasti ongelmia. Tieto toki ottaa aina tietoisen riskin, että julkisuutta tulee ja usein negatiivista. Mutta ei välttämättä kyse ole siitä, että sinne nyt olisi pesiytynyt sysipaskoja koodareita ja projareita. Tiedon liikevoittoprosentti 9% ei ole mikään tähtitieteellinen, mutta kyllä se tulosta tekee.

Toisaalta muut firmat myös jättävät julkisen puolen hankkeet sivuun. Niissä on isoja riskejä, vaativat ihan omaa juridisen puolen osaamista että menestyy kilpailutuksissa ja negatiivinen maine voi jättää ison tahran. Tietoisia valintoja puolin ja toisin.

 

[hsalonen]

Jos kyse on medical hommasta niin siellä on kyllä se QA ja ne testaajat. Olen kerran elämässäni tehnyt päätoimisesti vuoden ajan QA hommia ja se oli juurikin medical projektissa ja voin kertoa että QA noissa hommissa hoidetaan kyllä aika perusteellisesti. Aikataulut voi paukkua, ja usein paukkuukin, mutta QA:n kohdalla ei oiota mutkia koska siinä puhutaan oikeasti vitun suurista sakoista jos kärähtää auditeissa. Puhumattakaan menetystä maineesta ja mahdollisesti jopa sertifioinneista.
Toki tuo projekti oli sveitsiläiselle firmalle joten ehkä Suomessa hommat vedetään perseelleen mutta veikkaan että eiköhän täällä ole about samat regulaatio paineet.

Itsekin olen ollut QA:ssa kerran ja minulla oli tiimissä muitakin testaajia tekemässä sitä testausta. Kyllä siinä aika nopeasti tuli semmoinen fiilis, että tuotantoon asti pääsevät virheet on minun epäonnistumisiani testipäällikkönä osittain. 100% kattavuus on täysi mahdottomuus, mutta perustoiminnallisuus testattiin useamman kerran teknisten kavereiden kanssa ja sen jälkeen liiketoiminnan kanssa vedettiin testikierroksia suunnilleen samoista asioista. Oli paljon pienempi projekti, eikä käyttäjiä ollut kuin kymmeniä, mutta kyllä olisi jotain kasvanut otsaan, jos niitä 5x testattuja perusworkflowta ei saisi asiakas sitten vedettyä läpi tuotannossa.

Ei ollut medical, vaan finance. Ja siellä oli suurempi huoli deadlinen lipsumisesta kuin testauksen listojen tyhjentämisestä. Ei vaan voinut laittaa omaa hyväksyntää alle mihinkään paperiin, ennenkuin ne pienetkin virheet oli korjattu pois tai niistä on joku ottanut vastuun ja se ei ole enää minun ongelmani.

Mutta eihän noissa esimerkeissä puhuta mistään isoista toiminnallisuuksista. Kyseessä on one-liner virheistä, niin toteutuksen kuin testauksen osalta. Toinen on yksittäisen UI-komponentin eventtihanskaus ja toinen on yhden ikkunan yksi property.
Tai siis mahdollisesti, kerta ei ole sorsia tuosta softasta niin ei voi muuta kuin spekuloida.

Kyllä. Ongelma on siinä, että nuo tulisi esille päivittäisessä työssä, uskoisin. Tämä on spekulaatiota.
Yksi asiakkaan edustaja olisi oikeassa työympäristössä tehnyt näitä asioita, niin aika suurella todennäköisyydellä ainakin hiirenrullabugi olisi havannoitu. Arvelisin.
Tuonkokoisen softan sorsat on niin kuitenkin sitä kokoluokkaa, että niitä ei voi kaikkia käydä testauksessa läpi, vaan satunnaisia pistokoeauditteja vain. Mietin vaan, että toiminallisuus olisi katettu testicaseilla, jotka olisivat jotenkin todellista työtä vastaavia.

Tässä on pari ongelmaa. Eka on se että sä oletat että asiakas haluaa tehdä tuota pilotointia.

Toinen on se että sä oletat että asiakas pystyy tekemään tuota pilotointia. Koska kyseessä on medical projekti niin se vaatii aivan vitusti paperityötä ja erilaisia verifikaatioita ja auditteja ja regulatory checkkejä ennen kuin sitä voi käyttää oikeisiin potilaisiin. Sun devausprosessit voi olla niin agileja ja devopsattuja kuin haluaa mutta sillä ei ole kovin paljon väliä asiakkaan kannalta jos kestää se pari kolme kuukautta per software rellu jotta saat hyväksynnän FDA:lta ja/tai EMA:lta käyttää sitä softaa.

Kolmanneksi, sanoisin että on aika optimistista olettaa että nuo kaksi esimerkki bugia löydettäisiin helposti vaikka prosessit olisi ideaalit. Ne on molemmat bugeja jotka vaatii tietynlaisen käyttöpatternin softalle joka ei ole mikään ilmiselvä. Lisäksi ne molemmat vaativat sen että käyttäjä tajuaa että virhe on tapahtunut ja missä se on tapahtunut.

Se olisi koko medical alalle parempi, että saisi piloitoida pienessä mittakaavassa. Silloin ei käy näin: mennään tuotantoon ja kerralla riski koskee kymmeniätuhansia (ellei enemmän ihmisiä). Joku pieni joukko ihmisiä ja Tieto ottaa vastuun, jos joku kuolee

Ja en ole ollut medicalilla, mutta noihin viranomaistarkastuksiin olen kyllä törmännyt. Yhdessä projektissa (5+ vuotta sitten) oli viranomainen mukana ja siitä oli tavallaan suuri hyöty. Viranomainen torppasi pari ominaisuutta softassa, jotka eivät olisi menneet säädöksistä läpi, niin ne jäi suunnittelupöydälle ja firma säästi rahaa, kun ei tehnyt niitä loppuun. Tämä sääntö-Suomessa, kaikilla oli vakaa usko, että jossain muussa maassa olisi saanut näin tehdä ja ne vaan kiusasivat meitä.

*edit* Niin joo ja ennen kuin joku alkaa teorisoimaan, en ole töissä Tiedolla, en ole koskaan ollut töissä Tiedolla ja mulla ei ole mitään erityisempiä suhteita Tietoon. Olen tosin ollut muutaman vuoden erittäin ison softakonsultointi/alihankinta firman palkkalistoilla joten kokemusta tuollaisista projekteista on kertynyt. Mutta en ole enää senkään firman listoilla.

En ole minäkään töissä Tiedolla, mutta teen heidän kanssaan yhteistyötä, kun he ovat syvällä suomalaisessa yhteiskunnassa. Heidän järjestelmiään on kaikkialla, heillä on ylläpidossa suuri osa yritysten ja julkisten yhteisöjen palvelinympäristöistä - ja en edes pääse bussilla mihinkään käyttämättä Tiedon tuotteita..

Tuskin kukaan on nykyinen Tiedon työntekijä, joka tänne kommentoi. Isoilla firmoilla on oma sosiaalisen median työryhmä ja "yksi suu", joka kertoo somessa totuuden. Yksittäinen Tiedon työntekijä todennäköisesti tekisi enemmän vahinkoa kuin hyvää, jos kommentoisi yhtään mitään, jota tietoa ei ole lehdissä. Olen 95% varma, että kaikki somekommentointi on heiltä kielletty ja jos esim. täällä alkaa levitä suoranaisia valheita Tiedosta, heidän edustajansa tulee tänne kommentoimaan ja vie sitten törkeimmät ylilyönnit jonnekin oikeusasteeseen, että saadaan kulut katettua hänen työstään.

--

..ja Suomessa on ainakin pari Tiedon kokoista firmaa, jotka tekee samoja asioita. Ne eivät vaan ole otsikoissa niin useasti, niin voisi melkein sanoa, että Tiedolle tapahtuu näitä iloisia pikku onnettomuuksia enemmän kuin muille.

 

[hsalonen]

Mä luulen, että Tiedon surkeutta korostaa se, että se osallistuu niin usein isoihin julkisiin hankkeisiin. Mokia tapahtuu kaikkien muidenkin softatalojen tuotoksissa, mutta ne eivät ikinä saa samanlaista julkisuutta, sillä ne on ostettu yksityisellä rahalla ja eivät koske niin isoa ihmismassaa. Ja osa ongelmaa on myös sen ostavan tahon puolella. Huono ja vesiputousmallinen speksaus, tiukat aikataulut ja puutteelliset resurssit testaukseen aiheuttavat varmasti ongelmia. Tieto toki ottaa aina tietoisen riskin, että julkisuutta tulee ja usein negatiivista. Mutta ei välttämättä kyse ole siitä, että sinne nyt olisi pesiytynyt sysipaskoja koodareita ja projareita. Tiedon liikevoittoprosentti 9% ei ole mikään tähtitieteellinen, mutta kyllä se tulosta tekee.

Toisaalta muut firmat myös jättävät julkisen puolen hankkeet sivuun. Niissä on isoja riskejä, vaativat ihan omaa juridisen puolen osaamista että menestyy kilpailutuksissa ja negatiivinen maine voi jättää ison tahran. Tietoisia valintoja puolin ja toisin.

Kaikki julkiset hankkeet kilpailutetaan. Taitaa kilpailutuksen raja olla 30 000€, joka tulee hyvin nopeasti vastaan, jos tehdään yli kuukausi ihan mitä tahansa. Voit sinäkin tarjota töitäsi, mutta yksi ihminen ei tee isoa järjestelmää.

Tiedän ihan faktana, että ei ne firmat mitään hankkeita jätä väliin. Se olisi järjettömän tyhmää - miten voit edes ajatella noin?

Firmat tekee tarjouksen ja siinä tarjouksessa on heidän asiantuntijoidensa palkka ja hieman voittoa leivottuna. Ja "paras tarjous" voittaa. Tässä on usein se ongelma, että "paras" on se, joka on halvin ja kaikki löytyy samalta luukulta. Niinpä Tieto tarjoaa halvemmalla, kuin muut ja voittaa näitä useasti.

Sitten hinta on laitettu niin alas, ettei ole varaa käyttää niitä suomalaisia huippuosaajia, kun ne on liian kalliita. Sitten projektipäälliköt , hankejohtajat ja muut miettii, miten saadaan toimitettua sopimuksen sisältö minimikustannuksin. Sitten karsitaan koodaajien laadusta (offshore), testauksesta ja pidetään niitä kalliita henkilöitä (softa-arkkitehti, testaaja, jopa proj.päällikkö) projektissa osa-aikaisesti , vaikka pelkästään muutama päivä kuukaudessa ja niitä kuormitetaan kymmenellä muulla projetilla. Sitten kiireessä ja jopa kunnon laadunvalvonnan puutteessa tulee pari pientä virhettä. Joskus mietin, optimoidaanko näitä, tyyliin "virheen takia tuli väärät lääkkeet ja se yksi jannu kuoli, mutta virheen korjaaminen olisi ollut 40htp testauksineen, niin annettiin olla".

 

[akse]

Softa Olkiluodossakin kusi.

Tal oikeastaan softan suunnittelu. Aiheutti jonkun 5v viivästyksen ennen kuin pääsivät edes tekemään softaa

Toki rakentamisessakin puutteita.

 

[Poppamies]

Itse ollut Tiedolla. Hyvä työnantaja. Suurin moka silloin oli julkisten tietojen luettelo mikä meni väärillä tiedoilla ulos. Eli verotiedot jne.

Sen muistan että meistä laskutettiin asiakkaalta ihan huikea tuntiveloitus. En tiedä miksi se edes kerrottiin meille.

 

[Kautium]

Sen muistan että meistä laskutettiin asiakkaalta ihan huikea tuntiveloitus. En tiedä miksi se edes kerrottiin meille.

Miksipä sitä olisi piiloteltukaan, kun se selviää joka tapauksessa jotain kautta.

 

[Poppamies]

Miksipä sitä olisi piiloteltukaan, kun se selviää joka tapauksessa jotain kautta.

Lienee 3 eri asiaa:

Kertoa aloitteellisesti
Jättää kertomatta
Piilotella tietoa.

Onko se nyt niin helppoa kaivaa joku veloitus jostain projektista vrt että sanoisin tässä että se on xxx€.

 

[Paapaa]

Tiedän ihan faktana, että ei ne firmat mitään hankkeita jätä väliin. Se olisi järjettömän tyhmää - miten voit edes ajatella noin?

Ilmaisinkohan itseäni epäselvästi. Ainakin Helsingissä on isoja konsulttitaloja, jotka eivät osallistu (kaikkiin) julkisiin kilpailutuksiin pitkälti siksi, että 100-150e keskituntilaskutuksella niihin ei yksinkertaisesti ole mitään asiaa jos haluaa, että viivan alle jää jotain eikä tule overruna. Kilpailutukseen osallistuminen voi syödä todella paljon resursseja isoissa hankkeissa, joten sitä ponnistusta ei tehdä, jos ei oikeasti haluta sitä projektia. Ja mitään intiaulkoistuksia ei näiden talojen kannata miettiä. (Eikä tämä tarkoita, etteikö intiasta tulisi kovia koodareita/designereita).

 

[akse]

Noi softabugit on muuten vaan jäävuoren huippu.

Tuon Lifecaren käytettävyys on aivan järkyttävän paska verrattuna aikaisempiin järjestelmiin. Näin vaimon suusta kuultuna, joka niitä työssään käyttää.

Menee kuulemma vähintään kaksi kertaa aikaa kirjata tietoja tuolla kuin aiemmalla. ( Pegasos (potilastietojärjestelmä) – Wikipedia ) WM-Data nykynen CGI, tehny sen. Veikkaan kyllä että tuo vanhakin on aika järkyttävä, mutta ehkä sallittakoon kun väsätty varmaan joskus 2000-luvun alussa.

// hieman offtopic
"Pegasos on vuosien varrella saanut osakseen kritiikkiä mm. hitaudesta. Toimintaa onkin useissa käyttöpaikoissa saatu huomattavasti nopeammaksi käyttämällä Pegasosta Citrixin avulla"
Meillä on duunissa joku tuotannonohjausjärjestelmä minkä tuo CGI(tai wm-data aika vanha softa sekin) myös tehnyt.. jotenkin kuulostaa tutulta tuo hitaus. Ja meilläkin on Citrix, minkä kautta se toimii ihan hyvin.

Ilmeisesti tää softa lataa koko käyttöliittymän jostain palvelimelta.. kuvina tms. Huomaa hyvin jos on hidas yhteys niin prosessin muistin kulutus kasvaa about samaa vauhtia kuin mikä on yhteyden nopeus. Sitten jossain vaiheessa käyttöliittymä avautuu ellei tule jotain timeouttia Sitten ku vaihtelee eri valikkoihin niin aina kestää ladata se uusi sivu.

Hienoja toteutuksia.
//

Tuossa Lifecaressa taitaa olla myös ongelmia laskutuksen kanssa, eli tietylle henkilölle kohdennetut laskut(vai toimenpiteet ei mene laskutukseen?) eivät mene perille. Täälläpäin on ollut paljon juttua, että ei näy eikä kuulu laskuja ja sitten alkaa tulla perinnästä kirjettä.

En tiedä onko itelläkin joku tuollainen keissi menossa. Kävin viisaudenhampaan poistamassa 2.2 eikä ole mitään laskua vieläkään näkynyt.

 

[Kautium]

Ilmaisinkohan itseäni epäselvästi. Ainakin Helsingissä on isoja konsulttitaloja, jotka eivät osallistu (kaikkiin) julkisiin kilpailutuksiin pitkälti siksi, että 100-150e keskituntilaskutuksella niihin ei yksinkertaisesti ole mitään asiaa jos haluaa, että viivan alle jää jotain eikä tule overruna. Kilpailutukseen osallistuminen voi syödä todella paljon resursseja isoissa hankkeissa, joten sitä ponnistusta ei tehdä, jos ei oikeasti haluta sitä projektia. Ja mitään intiaulkoistuksia ei näiden talojen kannata miettiä. (Eikä tämä tarkoita, etteikö intiasta tulisi kovia koodareita/designereita).

Juuri näin. Varsinkin juuri julkishallinnon vaatimusmäärittelyt ovat usein sellaisia monisivuisia taivaita tavoittelevia järjettömien toiveiden listauksia, että jo kilpailutusvaiheessa tietää ettei ole mitään mieltä osallistua, kun projekti tulee nielemään loputtomasti aikaa ja vaivaa, eikä viivan alle jää lopulta välttämättä mitään. Pelkästään kilpailutusvaihe on usein oma kuukausia kestävä projektinsa, jossa käydään kaiken maailman kuulemisia puolin ja toisin.

Siksi siellä onkin kilpailujen "voittajina" useimmiten vain näitä Tietoja sun muita isoja lafkoja, jotka saavat ujutettua projektiin harjoittelijansa tuottamaan/koodaamaan paskaa. Voittaja oli lainausmerkeissä, kun ainoaa osallistujaa on vaikea nimittää voittajaksi.

 

[Ryydike]

Noi softabugit on muuten vaan jäävuoren huippu.

Tuon Lifecaren käytettävyys on aivan järkyttävän paska verrattuna aikaisempiin järjestelmiin. Näin vaimon suusta kuultuna, joka niitä työssään käyttää.

Menee kuulemma vähintään kaksi kertaa aikaa kirjata tietoja tuolla kuin aiemmalla. ( Pegasos (potilastietojärjestelmä) – Wikipedia ) WM-Data nykynen CGI, tehny sen. Veikkaan kyllä että tuo vanhakin on aika järkyttävä, mutta ehkä sallittakoon kun väsätty varmaan joskus 2000-luvun alussa.

// hieman offtopic
"Pegasos on vuosien varrella saanut osakseen kritiikkiä mm. hitaudesta. Toimintaa onkin useissa käyttöpaikoissa saatu huomattavasti nopeammaksi käyttämällä Pegasosta Citrixin avulla"
Meillä on duunissa joku tuotannonohjausjärjestelmä minkä tuo CGI(tai wm-data aika vanha softa sekin) myös tehnyt.. jotenkin kuulostaa tutulta tuo hitaus. Ja meilläkin on Citrix, minkä kautta se toimii ihan hyvin.

Ilmeisesti tää softa lataa koko käyttöliittymän jostain palvelimelta.. kuvina tms. Huomaa hyvin jos on hidas yhteys niin prosessin muistin kulutus kasvaa about samaa vauhtia kuin mikä on yhteyden nopeus. Sitten jossain vaiheessa käyttöliittymä avautuu ellei tule jotain timeouttia Sitten ku vaihtelee eri valikkoihin niin aina kestää ladata se uusi sivu.

Hienoja toteutuksia.
//

Tuossa Lifecaressa taitaa olla myös ongelmia laskutuksen kanssa, eli tietylle henkilölle kohdennetut laskut(vai toimenpiteet ei mene laskutukseen?) eivät mene perille. Täälläpäin on ollut paljon juttua, että ei näy eikä kuulu laskuja ja sitten alkaa tulla perinnästä kirjettä.

En tiedä onko itelläkin joku tuollainen keissi menossa. Kävin viisaudenhampaan poistamassa 2.2 eikä ole mitään laskua vieläkään näkynyt.

Mitä helvettiä??? Lataa koko käyttöliittymän netin yli???

Eikö kaverit ole kuulleet VNC tms. etätyöpöytä protokollista?

 

[akse]

Mitä helvettiä??? Lataa koko käyttöliittymän netin yli???

Eikö kaverit ole kuulleet VNC tms. etätyöpöytä protokollista?

Veikkaisin, että joku purkkaviritys. Tuon softan käyttöliittymä oli vanhassa versiossa (mitä en nähnyt), joku dos pohjainen merkkisysteemi. Voisi kuvitella että pellin alla sama softa ja päälle luotu GUI jollain virityksellä.

 

[SampoTexaa]

No niin no, hyvät koodarit toki oppii virheistään mutta se ei tarkoita että ne eivät enää tee niitä.
Lisäksi hyvät koodarit usein tekevät enemmän virheitä kuin huonot ihan puhtaasti sen takia että hyvät koodarit pystyy tuottamaan koodia paljon nopeammin. Jolloin myös virheitä tapahtuu enemmän.



Juu on. Siitä huolimatta NASA on onnistunut brickkaamaan tai vetämään pillunpäreiksi useiden satojen miljoonien taalojen edestä luotaimia ja sateliitteja softabugeilla.

Yksikin mars? luotain laskeutui rinteeseen ja vieri rotkon pohjalle tuhannen pillun päreiksi. Oli mennyt metrit ja imperiaalit sekaisin.

Tämä IT on hauskaa alue. Joka hemmetin kirvesmies, sairaanhoitaja, yritysjohtaja, taksikuski ja muut kadunmiehet tietää MITEN näitä IT järjestelmiä tehdään.

Mutta auta armias jos joku menee neuvomaan heitä heidän omassa työssä. "Älä sä tule neuvomaan kun et tajua näistä hommista mitään"

Itse jos koodaisin LifeCare tyyppisiä sovelluksia niin Citrix tyyppinen ratkaisu olisi ainoa vaihtoehto koska kunnissa on jos jonkin näköistä työasemaviritystä.

 

[havukka-aho]

Veikkaisin, että joku purkkaviritys. Tuon softan käyttöliittymä oli vanhassa versiossa (mitä en nähnyt), joku dos pohjainen merkkisysteemi. Voisi kuvitella että pellin alla sama softa ja päälle luotu GUI jollain virityksellä.

Usein tuollaiset vanhat dinosaurustaustajärjestelmät pyörivät Cobolilla, ja tuo mainitsemasi merkkipohjainen UI kuulostaa juuri sellaiselta. Näihin törmää tänäkin päivänä vielä yllättävän usein (vähenemään päin kuitenkin järjestelmäuudistusten myötä) juurikin terveydenhuollossa, pankki- ja vakuutusalalla ja erinäisissä isoissa kunnallisissa/valtiollisissa systeemeissä. Ovat ruksuttaneet jo kymmeniä vuosia.

 

[hsalonen]

@Paapaa @Kautium

Menee jo OT:n puolelle, mutta jokaiseen julkiseen kilpailutukseen kannattaa osallistua vaikka vähän kalliimmalla tarjouksella. Muuten Tieto (tai yleensäkin kilpailijat) voivat hinnoitella itsensä miten haluavat ja voittaa hyviä, kalliita sopimuksia käytännössä tekemättä mitään. Pahimmassa tapauksessa kyseessä on puitesopimus, tyyliin "tilaan kaikki IT-projektit Tiedolta" ja sovittu on vaan tuntilaskutus. Silloin pääsee ns. vuolemaan kultaa.

Vaatii kuitenkin tietyn kokoluokan firman, että tällaista pystyy tarjoamaan ihan jokaiseen kilpailutukseen. Tieto kuitenkin itse on sitä kokoa, että eivät varmasti jätä yhtäkään suurta kilpailutusta väliin, varsinkaan mainesyistä, eivätkä myöskään puuttellisten määrittelyjen ja asiakkaan vision puuttumisen vuoksi:
Poliisi sai tarpeekseen uuden tietojärjestelmän viivästymisestä – sopimus Tiedon kanssa purettiin
(esimerkki järjestelmästä, jossa asiakas ei ehkä tiennyt, mitä oli tekemässä)

 

[SampoTexaa]

@Paapaa @Kautium

Menee jo OT:n puolelle, mutta jokaiseen julkiseen kilpailutukseen kannattaa osallistua vaikka vähän kalliimmalla tarjouksella. Muuten Tieto (tai yleensäkin kilpailijat) voivat hinnoitella itsensä miten haluavat ja voittaa hyviä, kalliita sopimuksia käytännössä tekemättä mitään. Pahimmassa tapauksessa kyseessä on puitesopimus, tyyliin "tilaan kaikki IT-projektit Tiedolta" ja sovittu on vaan tuntilaskutus. Silloin pääsee ns. vuolemaan kultaa.

Vaatii kuitenkin tietyn kokoluokan firman, että tällaista pystyy tarjoamaan ihan jokaiseen kilpailutukseen. Tieto kuitenkin itse on sitä kokoa, että eivät varmasti jätä yhtäkään suurta kilpailutusta väliin, varsinkaan mainesyistä, eivätkä myöskään puuttellisten määrittelyjen ja asiakkaan vision puuttumisen vuoksi:
Poliisi sai tarpeekseen uuden tietojärjestelmän viivästymisestä – sopimus Tiedon kanssa purettiin
(esimerkki järjestelmästä, jossa asiakas ei ehkä tiennyt, mitä oli tekemässä)

Tällaisista sopimuksista kannattaa syyttää ihan jotain mutta tahoa kuin myyjää.

 

[Kvarkki]

Menee ehkä vähän näsäviisastelun puolelle, mutta ilmeisesti kun puhutte qa:sta, niin oikeasti tarkoitatte qc?

 

[nnaku]

En tiedä olikohan tästä jo puhetta? Mutta SQLi like a 1999

 

[hsalonen]

Menee ehkä vähän näsäviisastelun puolelle, mutta ilmeisesti kun puhutte qa:sta, niin oikeasti tarkoitatte qc?

Quality Assurance tai Quality Control, rakkaalla lapsella on monta nimeä. Tarkoitan ainakin itse sitä, että on testausprosessi ja ihmisiä mukana pelkästään testaajan rooleissa. Jos testaaja=koodari ja hän testaa vain oman koodinsa - niin tottakai se toimii ja virheitä ei löydy.

@nnaku

'; DELETE FROM USERS; --

 

[Paapaa]

Menee jo OT:n puolelle, mutta jokaiseen julkiseen kilpailutukseen kannattaa osallistua vaikka vähän kalliimmalla tarjouksella.

Ööö, ei kannata. Kyllä mä uskon, että 20v alalla toimineet konsulttitalot tietävät, mihin niiden kannattaa osallistua ja mihin ei kannata. Se on ihan tietoinen valinta, ettei edes palkata sellaista osaamista, joita isot julkiset hankkeet vaativat. Eikä laiteta senttiäkään resursseja niiden valmisteluun.

Muuten Tieto (tai yleensäkin kilpailijat) voivat hinnoitella itsensä miten haluavat ja voittaa hyviä, kalliita sopimuksia käytännössä tekemättä mitään.

Se on kilpailutuksessa usein ongelmana, että kilpailutuksen ehdot rajaavat pienet tekijät heti kättelyssä ulkopuolelle. Mutta ei Tieto ainoa tekijä ole, eikä näin ollen voi hintoja määritellä mielivaltaisesti.

 

[JCSH]

Ööö, ei kannata. Kyllä mä uskon, että 20v alalla toimineet konsulttitalot tietävät, mihin niiden kannattaa osallistua ja mihin ei kannata. Se on ihan tietoinen valinta, ettei edes palkata sellaista osaamista, joita isot julkiset hankkeet vaativat. Eikä laiteta senttiäkään resursseja niiden valmisteluun.

No niin no, isot talot kuten Tieto kyllä ottavat osaa lähes jokaiseen isomman julkisen hankkeen kilpailutukseen.
Noita projekteja ei kuitenkaan ole hirveän paljon ja kerta noista kilpailee Suomessa aina vähintään se about 4-6 isompaa softataloa niin yksittäisen firman chanssit voittaa kilpailutus on karkeasti siellä 20% paikkeilla. Eli jokaista voitettua projektia vasten tarvii ottaa osaa viiteen kilpailutukseen.

 

[Paapaa]

No niin no, isot talot kuten Tieto kyllä ottavat osaa lähes jokaiseen isomman julkisen hankkeen kilpailutukseen.

Juuri näin, puhuinkin niistä muista taloista. Tiedolla tunnetaan julkisten hankkeiden kilpailutuksen kiemurat joten totta kai sen kannataakin niihin osallista. Pointtini on, että talot erikoistuvat osallistumaan eri markkinoille, eikä kaikkien kannata tavoitella julkisia jättihankkeita. Tiedon varmasti kannatta - siitäkin huolimatta, että se on saanut paljon paskaa julkisuutta.

 

[JCSH]

Juuri näin, puhuinkin niistä muista taloista. Tiedolla tunnetaan julkisten hankkeiden kilpailutuksen kiemurat joten totta kai sen kannataakin niihin osallista. Pointtini on, että talot erikoistuvat osallistumaan eri markkinoille, eikä kaikkien kannata tavoitella julkisia jättihankkeita. Tiedon varmasti kannatta - siitäkin huolimatta, että se on saanut paljon paskaa julkisuutta.

No aikalailla ne kaikki isot talot ottaa osaa noihin kilpailutuksiin jos projekti on tarpeeksi iso. Tieto ei tuolta osin eroa muista.
Tieto, CGI, Capgemini, Accenture, Fujitsu ja mitä näitä muita nyt onkaan

 

[Paapaa]

No aikalailla ne kaikki isot talot ottaa osaa noihin kilpailutuksiin jos projekti on tarpeeksi iso. Tieto ei tuolta osin eroa muista.
Tieto, CGI, Capgemini, Accenture, Fujitsu ja mitä näitä muita nyt onkaan

Mä taidan kirjoittaa epäselvästi. En ole mistään tästä eri mieltä vaan totesin, että Suomessa on lukuisia (ei edes pieniä) konsulttutaloja, jotka eivät ikinä ota osaa noihin kilpailutuksiin ja se on ihan perusteltu valinta.

 

[JCSH]

Mä taidan kirjoittaa epäselvästi. En ole mistään tästä eri mieltä vaan totesin, että Suomessa on lukuisia (ei edes pieniä) konsulttutaloja, jotka eivät ikinä ota osaa noihin kilpailutuksiin ja se on ihan perusteltu valinta.

Joo varmaan on mutta valtaosa noista ei kuitenkaan pystyisi kilpailemaan samoista projekteista kuin firmat kuten Tieto, Accenture, CGI ja Capgemini.

Projektin pitää olla tarpeeksi iso että se herättää noiden firmojen mielenkiinnon. Mutta siinä vaiheessa kun projekti on tarpeeksi iso niin siitä nopeasti putoaa kaikki nuo pienemmät firmat, kuten esimerkiksi Vincit, Reaktor, Futurice jne., pois koska noilla firmoilla ei ole kykyä irroittaa tarpeeksi työvoimaa projektiin jos ne voittaa sen.

Toki siellä on se keskiväli jossa nuo voisivat kilpailla samoista projekteista, ja varmaan osittain kilpailevatkin, mutta pääsääntöisesti isoihin projekteihin tarvitaan iso firma.

 

[nnaku]

Suuri ongelma on myös se että suomalainen "virkamies" ei osaa tilata softaa. Halutaan aina se helvetin monoliitti jossa koko paska on käärittynä yksiin kuoriin ja mielellään jotkut aivan järkyttävät lisensit/ylläpito sopparit päälle.

 

[Kautium]

Suuri ongelma on myös se että suomalainen "virkamies" ei osaa tilata softaa. Halutaan aina se helvetin monoliitti jossa koko paska on käärittynä yksiin kuoriin ja mielellään jotkut aivan järkyttävät lisensit/ylläpito sopparit päälle.

Ei se haluamisesta ole kiinni. Jos olisi kokonaisuutena kustannustehokkaampaa hankkia 20 täysin erillistä "ketterää" järjestelmää ja naittaa ne juttelemaan yhteen ja ylläpitää sitä sekasotkua koko systeemin elinkaaren ajan, niin varmasti niin myös tehtäisiin.

Lisenssisotkut taas eivät ole koskaan asiakkaasta kiinni, eli niiden osalta syyllinen on toimittajissa.

 

[Kvarkki]

Quality Assurance tai Quality Control, rakkaalla lapsella on monta nimeä. Tarkoitan ainakin itse sitä, että on testausprosessi ja ihmisiä mukana pelkästään testaajan rooleissa. Jos testaaja=koodari ja hän testaa vain oman koodinsa - niin tottakai se toimii ja virheitä ei löydy.

Eli QC:ta. Onko ohjelmistopuolella erikseen QA:ta, joka huolehtisi laatuprosessien suunnittelusta? Ainakin omalla toimialalla ero QA ja QC välillä on selvä. Kärjistäen QA määrittää muusta organisaatiosta irrallaan laatutavoitteet ja -prosessit, QC tarkastaa lopputuloksen osana tekijäorganisaatiota.

 

[JCSH]

Eli QC:ta. Onko ohjelmistopuolella erikseen QA:ta, joka huolehtisi laatuprosessien suunnittelusta? Ainakin omalla toimialalla ero QA ja QC välillä on selvä. Kärjistäen QA määrittää muusta organisaatiosta irrallaan laatutavoitteet ja -prosessit, QC tarkastaa lopputuloksen osana tekijäorganisaatiota.

Riippuu täysin organisaation koosta ja rakenteesta. Mutta ainakin itse olen tottunut siihen että termi QA kattaa nuo molemmat sun mainitsemat kuvaukset ja sitten se miten tuo käytännössä toteutetaan organisaatiotasolla vaihtelee erittäin paljon.

 

[Kautium]

Tällainen helmi tuli vastaan aiheeseen liittyen -->

Lähde

 

[David ":DA" Imodium]

Tällainen helmi tuli vastaan aiheeseen liittyen -->

Lähde

Jummijammi. Tein ihan samat kämmit ekassa foorumisoftassani. Mitähän se oli, v. 2001 ja ikää just ja just jonnen verran.

 

[mystikkogames]

Se NASA juttu on redditissä. Ihan mielenkiintoista lukemista mitä on C-koodaus avaruusraketeille. Kriteerit on ihan toista mitä joillekin hötömölö - tulostimille.

En kyllä ymmärrä tuota redditin touhuakaan. Postasin linkin peliini. Se sai lyhyessä ajassa 133 pistettä. Kaikki pitivät pelistä. Ja oli JavaScript osaston #1 paikalla pitkän aikaa. Ja sitten se poistettiin, koska postasin linkin peliini? Ilmeisesti pitää tästäedes käyttää mustaa magiaa/voodoota tiedottaakseen muillekin pelistä.

 

[Bladekill]

Ei se haluamisesta ole kiinni. Jos olisi kokonaisuutena kustannustehokkaampaa hankkia 20 täysin erillistä "ketterää" järjestelmää ja naittaa ne juttelemaan yhteen ja ylläpitää sitä sekasotkua koko systeemin elinkaaren ajan, niin varmasti niin myös tehtäisiin.

Ei se valitettavasti ihan noin mene. Suomalaiset virkamiehet demonstroidusti eivät toimi lähtökohtaisesti järkevästi IT-hankinnoissa.
Nämä hankinnat ovat tapauskohtaisia, mutta ei se ylihinnoiteltu monoliittiripulikaan aina tule halvaksi osoittautuessaan käyttökelvottomaksi ja kun kaupanpäälle virkamiehet menivät vendorlockaamaan itsensä tälle paskatoimittajalle. Versus mikropalveluarkkitehtuuri missä paskoja komponentteja voidaan helposti tappaa pois ja korvata kohtuullisella kustannuksella.

Lisenssisotkut taas eivät ole koskaan asiakkaasta kiinni, eli niiden osalta syyllinen on toimittajissa.

Ei nnaku tainnut tarkoittaa mitään lisenssisotkua, vaan ihan vaan sitä kuinka nämä IT-toimittajat kusettavat julkisen sektorin jamppoja älyttömillä sopimuksilla.

Nimim. olin itse muutama vuosi sitten suomalaisessa hiukan pienemmässä IT-firmassa, jonka liiketoiminta perustuu pääosin julkisen sektorin kusettamiseen. Projektit devataan järkyttävän huonon proprietary sotkun päälle, jonka käytössä devaajilla menee n. 90% ajasta järjestelmän kanssa tappeluun ja hackaroundien tekemiseen. Sitten kun projekti on päätetty ja asiakkaat ovat maksaneet kehitystyöstä (josta 90% on mennyt hukkaan), saavat he vielä kunnian maksaa 50 000e vuosilisenssit tämän järjestelmän kehittäneelle säätiölle.

 

[Kautium]

Ei se valitettavasti ihan noin mene. Suomalaiset virkamiehet demonstroidusti eivät toimi lähtökohtaisesti järkevästi IT-hankinnoissa.

Olen tästä hieman eri mieltä. Sen verran monessa kokouspöydässä olen istunut, että väittäisin tahtotilan järkevälle toiminnalle olevan korkea, mutta varsinkin mm. historian painolasti ja erilaiset byrokraattiset syyt tekevät hankinnoista hankalia. Ja on siellä seassa toki sellaisiakin tahoja, jotka tuntuvat järjestelmällisesti kusevan kaiken, mutta en kuitenkaan yleistäisi näitä yksittäistapauksia kaikkialle.

Nämä hankinnat ovat tapauskohtaisia, mutta ei se ylihinnoiteltu monoliittiripulikaan aina tule halvaksi osoittautuessaan käyttökelvottomaksi ja kun kaupanpäälle virkamiehet menivät vendorlockaamaan itsensä tälle paskatoimittajalle. Versus mikropalveluarkkitehtuuri missä paskoja komponentteja voidaan helposti tappaa pois ja korvata kohtuullisella kustannuksella.

Joo, eivät ne monoliitit halpoja ole, varsinkaan jos ne eivät toimi halutulla tavalla. Tässä suhteessa hankinnat epäonnistuvat aivan liian usein sekä tilaajan, että toimittajan puolelta.

Tieto varsinkin on kunnostautunut jättimäisten käyttökelvottomien bugikasojen tuottamisessa. Jännä juttu, kun eivät tunnu siellä osaavan edes käyttöliittymäsuunnittelun perusteita, vaan joka systeemissä keksitään pyörä uudestaan ja kantikkaitahan niistä tulee tuolla menolla.

Ei nnaku tainnut tarkoittaa mitään lisenssisotkua, vaan ihan vaan sitä kuinka nämä IT-toimittajat kusettavat julkisen sektorin jamppoja älyttömillä sopimuksilla.

Sitähän minäkin tarkoitin. Ei siitä oikein voi asiakasta syyttää, jos toimittajat tarjoavat vain erilaisiin kusetuksiin perustuvia lisensointimalleja. Toki tilaajan pitäisi osata ottaa nämäkin huomioon jo kilpailutusvaiheessa, mutta porsaanreikiä on olemassa vähän siellä sun täällä, eikä kaikkea kuitenkaan ole mahdollista huomioida etukäteen.

 

[nnaku]

Tällainen helmi tuli vastaan aiheeseen liittyen -->

Lähde

Tieto OyJ

 

[Kautium]

Tieto OyJ

Jos tuossa postauksessasi on joku kuva, niin se ei näy. Tai näkyy, mutta näin -->

Tuo johtuu siitä, että useiden kuvanjakopalveluiden hotlinkkaus on estetty io-techissä. Kiertotienä voi esim. imgurin osalta käyttää http-linkitystä https:n sijaan.