Voitaisko antaa potkut sovellusten kehittäjille?
Perjantaina oli paremmin toimiva sovellus käytössä ja tänään kun aloin sovellusta käyttää, oli toimintoja muutettu. Lennosta täytyisi taas alkaa käyttää uudella tavalla! Edellinen käytössä ollut versio oli huonompi kuin joitakin kuukausia sitten käytössä ollut! Ja taas muutoksia, hetken rauhaa ei saa!
Lisäkikkailut eivät ole kivoja silloin kun tahtoo käyttää jotain arkensa työkaluna! Potkut näille turhille ja ylläpitäjät ja yksinkertaistajat jääkööt! Kun vain olisi yhteisymmärrys vielä siitä, että mikä on kenellekin yksinkertaisinta.... ellei sitten muuttumattomuus.
Näihin käytetään veronmaksajien varoja ja veronmaksajana olen koko ajan entistä tyytymättömämpi. Uusi hallitus voisi puuttua tähän rahojen tuhlaamiseen, kun mikään ei enää toimi ja ei riitä rahat ruohonjuuritasolla työtä tekeville, joiden työkaluiksi näitä sovelluksia kehitetään! Valta työni sujumisesta on luisutettu vääriin käsiin!
Kommentit (22)
Tiiätkö että ne sovelluskehittäjät kehittää asiakkaan toiveiden mukaan sitä sovellusta. Asiakkaan pitää hyväksyä muutokset ja vasta sitten ne viedään tuotantoon. Niin että se syyllinen löytyy sieltä sun omasta organisaatiosta. Kannattaa antaa palaute sinne ja ihan konkreettisesti, jotta ne kehittäjät tietävät missä kohtaa loppukäyttäjällä on ongelmia. Se että yleisesti haukut ei auta.
Vierailija kirjoitti:
Tiiätkö että ne sovelluskehittäjät kehittää asiakkaan toiveiden mukaan sitä sovellusta. Asiakkaan pitää hyväksyä muutokset ja vasta sitten ne viedään tuotantoon. Niin että se syyllinen löytyy sieltä sun omasta organisaatiosta. Kannattaa antaa palaute sinne ja ihan konkreettisesti, jotta ne kehittäjät tietävät missä kohtaa loppukäyttäjällä on ongelmia. Se että yleisesti haukut ei auta.
Kehittäjien tulisi tietää, että heitä ei tarvita tekemään mitään muutoksia/viimeinen muutos voisi olla palauttaa vuosia sitten ollut yksinkertainen ja toimiva sovellus.
ap
Kuten jo sanottu, asiakkaiden palautteen mukaan ne muutokset tehdään. Ei auta irtisanoa kehittäjiä kun ongelma on asiakkaan päässä. Joko pyydetään typeriä muutoksia tai hyväksytään väärin tehdyt muutokset. Sama kuin et voi syyttää bussikuskia reittimuutoksista, ei se kuski niitä päätä.
Vierailija kirjoitti:
Vierailija kirjoitti:
Tiiätkö että ne sovelluskehittäjät kehittää asiakkaan toiveiden mukaan sitä sovellusta. Asiakkaan pitää hyväksyä muutokset ja vasta sitten ne viedään tuotantoon. Niin että se syyllinen löytyy sieltä sun omasta organisaatiosta. Kannattaa antaa palaute sinne ja ihan konkreettisesti, jotta ne kehittäjät tietävät missä kohtaa loppukäyttäjällä on ongelmia. Se että yleisesti haukut ei auta.
Kehittäjien tulisi tietää, että heitä ei tarvita tekemään mitään muutoksia/viimeinen muutos voisi olla palauttaa vuosia sitten ollut yksinkertainen ja toimiva sovellus.
ap
Edelleen, kehittäjät ei koodaa riviäkään ilman toimeksiantoa ja tilausta. Eivätkä he voi "palauttaa" sovellusta vanhaan versioon, kun asiakas (eli se sun oma organisaatio) eivät sitä halua. Ehdottaa toki voi, mutta viimeisen sanan sanoo aina asiakas :)
Vierailija kirjoitti:
Tiiätkö että ne sovelluskehittäjät kehittää asiakkaan toiveiden mukaan sitä sovellusta. Asiakkaan pitää hyväksyä muutokset ja vasta sitten ne viedään tuotantoon. Niin että se syyllinen löytyy sieltä sun omasta organisaatiosta. Kannattaa antaa palaute sinne ja ihan konkreettisesti, jotta ne kehittäjät tietävät missä kohtaa loppukäyttäjällä on ongelmia. Se että yleisesti haukut ei auta.
Tämä. Ja valitettavan usein "asiakas" on ihan muu henkilö kuin ne, jotka softaa työssään joutuvat käyttämään. Voi miten joskus kaipaankaan aikaa vuosituhannen alussa, kun sain kehittää softaa yhdessä loppukäyttäjien kanssa. Nyt hyvin usein jonkun muutoksen tehdessäni vaan mietin, että onneksi mun ei tarvitse itse käyttää tuota softaa. Ja säälin niitä, jotka joutuvat. Onneksi ei ole enää kovin montaa vuotta eläkepäiviin.
Vierailija kirjoitti:
Kuten jo sanottu, asiakkaiden palautteen mukaan ne muutokset tehdään. Ei auta irtisanoa kehittäjiä kun ongelma on asiakkaan päässä. Joko pyydetään typeriä muutoksia tai hyväksytään väärin tehdyt muutokset. Sama kuin et voi syyttää bussikuskia reittimuutoksista, ei se kuski niitä päätä.
No jos tämä on jotain näitä Terveyskeskusten verorahoilla rahooitettuja appeja, niin tasan tarkkaan ei tehdä. Eihän Helsingissä voi edes maksaa palkkoja, ja terveyskeskusten tietojärjestelmät menee vaan huonompaan suuntaan. Uusi floppeja tulee vaan entisten lisäksi, ja mikään ei toimi. Omakanta ehkä ainut, mikä jotenkin pelaa jos on hyvä tuuri ja joku muistaa päivittää tiedot sinne myöhässä.
Vierailija kirjoitti:
Vierailija kirjoitti:
Kuten jo sanottu, asiakkaiden palautteen mukaan ne muutokset tehdään. Ei auta irtisanoa kehittäjiä kun ongelma on asiakkaan päässä. Joko pyydetään typeriä muutoksia tai hyväksytään väärin tehdyt muutokset. Sama kuin et voi syyttää bussikuskia reittimuutoksista, ei se kuski niitä päätä.
No jos tämä on jotain näitä Terveyskeskusten verorahoilla rahooitettuja appeja, niin tasan tarkkaan ei tehdä. Eihän Helsingissä voi edes maksaa palkkoja, ja terveyskeskusten tietojärjestelmät menee vaan huonompaan suuntaan. Uusi floppeja tulee vaan entisten lisäksi, ja mikään ei toimi. Omakanta ehkä ainut, mikä jotenkin pelaa jos on hyvä tuuri ja joku muistaa päivittää tiedot sinne myöhässä.
Tasan tarkkaan tehdään. Yksikään _kehittäjä_ ei ala, eikä voi, itse päättää tekevänsä asiakkaan ohjelmaan muutoksia. Sinä et nyt ymmärrä ettei se _loppukäyttäjä_ ole asiakas josta tässä puhutaan. Asiakas on se taho joka antaa ohjelmistokehittäjälle muutoslistan ja hyväksyy ne. Ei useinkaan sama kuin loppukäyttäjä.
Ohjelmistokehittäjä ei päätä yhdestäkään muutoksesta itse, eikä siten kehittäjän irtisanominen paranna ohjelmaa millään lailla, kun se seuraavakin joutuisi tekemään täsmälleen samat määrätyt (huonot) muutokset.
Keskustelu on malliesimerkki siitä kuinka öyhötetään asiasta josta ei itse ymmärretä mitään, eikä sitten edes suostuta kuuntelemaan kun selitetään miten prosessi oikeasti toimii.
Reipas ja tunnollinen lammas kirjoitti:
Vierailija kirjoitti:
Tiiätkö että ne sovelluskehittäjät kehittää asiakkaan toiveiden mukaan sitä sovellusta. Asiakkaan pitää hyväksyä muutokset ja vasta sitten ne viedään tuotantoon. Niin että se syyllinen löytyy sieltä sun omasta organisaatiosta. Kannattaa antaa palaute sinne ja ihan konkreettisesti, jotta ne kehittäjät tietävät missä kohtaa loppukäyttäjällä on ongelmia. Se että yleisesti haukut ei auta.
Tämä. Ja valitettavan usein "asiakas" on ihan muu henkilö kuin ne, jotka softaa työssään joutuvat käyttämään. Voi miten joskus kaipaankaan aikaa vuosituhannen alussa, kun sain kehittää softaa yhdessä loppukäyttäjien kanssa. Nyt hyvin usein jonkun muutoksen tehdessäni vaan mietin, että onneksi mun ei tarvitse itse käyttää tuota softaa. Ja säälin niitä, jotka joutuvat. Onneksi ei ole enää kovin montaa vuotta eläkepäiviin.
Hyvin usein organisaatiolla ja loppukäyttäjällä on hyvin erilaiset intressit järjestelmän käyttöön. Käyttäjä haluaa käyttää minimiajan datan syöttämiseen systeemiin, mutta organisaatio haluaa maksimimäärän dataa ulos analysoitavaksi.
No, selvitä se henkilö ensin, joka on tehnyt päätöksen kehittää sitä sovellusta. Ja pyydä selvitystä, miksi sitä on kehitetty uuteen suuntaan. Ja jos sulla on mahdollisuus, niin anna sille potkut, jos se on tehnyt huonoja päätöksiä!
Poliittinen taho voisi jäädyttää rahoituksen näiltä uudistuksilta. Kun vanha toimii, ei uutta. Kehittäjät tekemään niitä töitä, joita he tähän asti ovat hankaloittaneet.
Vierailija kirjoitti:
Vierailija kirjoitti:
Tiiätkö että ne sovelluskehittäjät kehittää asiakkaan toiveiden mukaan sitä sovellusta. Asiakkaan pitää hyväksyä muutokset ja vasta sitten ne viedään tuotantoon. Niin että se syyllinen löytyy sieltä sun omasta organisaatiosta. Kannattaa antaa palaute sinne ja ihan konkreettisesti, jotta ne kehittäjät tietävät missä kohtaa loppukäyttäjällä on ongelmia. Se että yleisesti haukut ei auta.
Kehittäjien tulisi tietää, että heitä ei tarvita tekemään mitään muutoksia/viimeinen muutos voisi olla palauttaa vuosia sitten ollut yksinkertainen ja toimiva sovellus.
ap
Joo 80-luvun "käyttöliittymät" takasin....
Paskaa syntyy kun autistivajakit etätöissä väsää ja samaan aikaan kollega myy ihan kaiken mitä paskaa autisti on väsännyt. Asiakas luottaa.
Kun näkee mitä nämä koodaajat ihan itse itselleen tekevät, niin täyttä paskaa ja sutta se on.
No täällä on yksi sellainen sovelluskehittäjä. Harvoinpa se vika meissä ruohonjuuritason tekijöissä on, jos on isoja ongelmia käytettävyydessä. Me teemme mitä meille speksataan, testaajat testaa että se toimii, toki joskus voi joku bugi tuotantoversioonkin päästä mutta nämä hotfixataan äkkiä.
Aika usein ne on ne toiminnalliset speksit, mitkä menee vikaan jos isompi epäonnistuminen tulee. Melko usein ne tulee tilaajalta valmiina tai melko valmiina, ja sitten toteuttajafirmalta pyydetään tarjousta mitä sellaisen toteuttaminen kustantaisi. Jos niissä spekseissä ei ole tajuttu käyttäjävaatimuksia, niin me koodarit voidaan sille aika vähän mitään. Toisinaan toki on dynaamisempia projektejakin, joissa jo varhaisessa vaiheessa käyttäjätestataan ja kehitetään palautteen mukaan, myös devaajia kuunnellaan jne. Mutta varsinkin julkisella puolella on usein aika jäykkää touhua, jossa koodarin pitää pysyä lestissään ja koodata mitä käsketään, eikä hyvällä katsota jos alkaa palautteineen hyppiä määrittelijöiden nenille.
Vierailija kirjoitti:
Paskaa syntyy kun autistivajakit etätöissä väsää ja samaan aikaan kollega myy ihan kaiken mitä paskaa autisti on väsännyt. Asiakas luottaa.
Näinhän tämä ei mene yleensä ainakaan minkään yritysten tai julkisyhteisöjen sovellusten kanssa (jos otat jonkun hauskan laskurin tai vedenjuonnin seuranta-appsin sovelluskaupasta, niin sitten voi olla toki niin että joku nörtti on itsekseen vaan kehittänyt ja laittanut tarjolle).
Vaan ensin asiakkaalta, joka voi olla julkisyhteistö tyyliin Väylävirasto tai Liikennevirasto, tai yksityinen yritys, tulee IT-yrityksille tarjouspyyntö sovelluskehityksestä. Siinä on hahmoteltu, millaista sovellusta pitäisi kehittää, jotta IT-talot osaa antaa tarjouksen projektista ja siihen tarvittavista asiantuntijoista. Ei me "autistit" kehitetä mitään omasta päästämme ja katsota tuleeko jotain myyntiin kelpaavaa, vaan me teemme jo asiakkaille myytyihin projekteihin kehitystä, jossa kehitettävät ominaisuudet eli sovelluksen liiketoiminnalliset vaatimukset määrittelee joku ihan muu. Yleensä isommissa epäonnistumisissa juuri tuossa vaatimusmäärittelyprosessissa on ne isoimmat ongelmat, ei siinä etteikö koodarit osaisi koodata.
Itsehän antaisin potkut AP alasta riippumatta.
Vierailija kirjoitti:
No täällä on yksi sellainen sovelluskehittäjä. Harvoinpa se vika meissä ruohonjuuritason tekijöissä on, jos on isoja ongelmia käytettävyydessä. Me teemme mitä meille speksataan, testaajat testaa että se toimii, toki joskus voi joku bugi tuotantoversioonkin päästä mutta nämä hotfixataan äkkiä.
Aika usein ne on ne toiminnalliset speksit, mitkä menee vikaan jos isompi epäonnistuminen tulee. Melko usein ne tulee tilaajalta valmiina tai melko valmiina, ja sitten toteuttajafirmalta pyydetään tarjousta mitä sellaisen toteuttaminen kustantaisi. Jos niissä spekseissä ei ole tajuttu käyttäjävaatimuksia, niin me koodarit voidaan sille aika vähän mitään. Toisinaan toki on dynaamisempia projektejakin, joissa jo varhaisessa vaiheessa käyttäjätestataan ja kehitetään palautteen mukaan, myös devaajia kuunnellaan jne. Mutta varsinkin julkisella puolella on usein aika jäykkää touhua, jossa koodarin pitää pysyä lestissään ja koodata mitä käsketään, eikä hyvällä katsota jos alkaa palautteineen hyppiä määrittelijöiden nenille.
Vaikka ei olisi "isoa ongelmaa", niin ymmärrätkö, että iso ongelma on pelkästään jo muutokset eli se että teette töitä edelleen? Teistä se on ehkä hauskaa ja rahakasta, kun jokin muuttuu, kun muutatte, mutta käyttäjille muutokset ovat rasitteita.
Älkää muuttako toimivia systeemejä. Keskimäärin vanhat olivat toimivampia kuin uudet. Täytyisi palata ajassa taaksepäin. Ei visuaalista paskaa lisää, vaan selkeyttä, helppoutta ja nopeutta.
Se on aina huononnus, jos tarvitaan kaksi klikkausta entisen yhden sijaan tai viisi klikkausta entisen kolmen sijaan. Ylimääräinen liike, sormilla vedettävät zoomaukset, karkailevat sivut välillä ja et tiedä, että mitä edes teit väärin. Se että sovellus ei toimi yhtä nopeasti kuin ajatus ja näppis.
Vierailija kirjoitti:
Vierailija kirjoitti:
No täällä on yksi sellainen sovelluskehittäjä. Harvoinpa se vika meissä ruohonjuuritason tekijöissä on, jos on isoja ongelmia käytettävyydessä. Me teemme mitä meille speksataan, testaajat testaa että se toimii, toki joskus voi joku bugi tuotantoversioonkin päästä mutta nämä hotfixataan äkkiä.
Aika usein ne on ne toiminnalliset speksit, mitkä menee vikaan jos isompi epäonnistuminen tulee. Melko usein ne tulee tilaajalta valmiina tai melko valmiina, ja sitten toteuttajafirmalta pyydetään tarjousta mitä sellaisen toteuttaminen kustantaisi. Jos niissä spekseissä ei ole tajuttu käyttäjävaatimuksia, niin me koodarit voidaan sille aika vähän mitään. Toisinaan toki on dynaamisempia projektejakin, joissa jo varhaisessa vaiheessa käyttäjätestataan ja kehitetään palautteen mukaan, myös devaajia kuunnellaan jne. Mutta varsinkin julkisella puolella on usein aika jäykkää touhua, jossa koodarin pitää pysyä lestissään ja koodata mitä käsketään, eikä hyvällä katsota jos alkaa palautteineen hyppiä määrittelijöiden nenille.
Vaikka ei olisi "isoa ongelmaa", niin ymmärrätkö, että iso ongelma on pelkästään jo muutokset eli se että teette töitä edelleen? Teistä se on ehkä hauskaa ja rahakasta, kun jokin muuttuu, kun muutatte, mutta käyttäjille muutokset ovat rasitteita.
Älkää muuttako toimivia systeemejä. Keskimäärin vanhat olivat toimivampia kuin uudet. Täytyisi palata ajassa taaksepäin. Ei visuaalista paskaa lisää, vaan selkeyttä, helppoutta ja nopeutta.
Se on aina huononnus, jos tarvitaan kaksi klikkausta entisen yhden sijaan tai viisi klikkausta entisen kolmen sijaan. Ylimääräinen liike, sormilla vedettävät zoomaukset, karkailevat sivut välillä ja et tiedä, että mitä edes teit väärin. Se että sovellus ei toimi yhtä nopeasti kuin ajatus ja näppis.
Montako kertaa sulle pitää kertoa, ettei niitä muutoksia tehdä huvikseen vaan KOSKA ASIAKAS TILAA NE. Ei koodaaja voi sanoa että en tee.. tai voi, mutta saa potkut kieltäydyttyään tekemästä töitään, ja joku muu tekee ne tilatut muutokset.
Fiksuin teko olisi kyllä antaa potkut näille!