Lue keskustelun säännöt.
Millaiset IT-alan työt ovat parhaita?
Kommentit (146)
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Onko Scrum nyt vaikea kenenkään sisäistää? Lopulta todella yksinkertainen menetelmä, mutta ahdistava ja ihmistä kontrolloimaan pyrkivä. Kaikki eivät vaan pidä siitä.
Sinä et selkästi ole sisäistänyt sitä...
Koska itse koen Scrumin noin, niin en mielestäsi ole sisäistänyt sitä?
Niin. Tai kerro nyt sitten ihan omin sanoin miten se pyrkii kontrolloimaan ihmistä? Tai mikä siinä ahdistaa, toki nykypäivän uniikkeja perhosia ahdistaa lähtökohtaisesti jo ihan kaikki, mutta jos ihan jotain oikeita syitä olisi heittää?
Turhia palavereita, joita pidetään vain, koska ne kuuluvat Scrumiin ja koska seremonioiden vetäjien mielestä ne on tosi tarpeellisia. Sata kertaa tärkeämpää on, että tekijöillä on kompetenssia, he tekevät pro-aktiivisesti yhteistyötä, ja he tietävät mitä tekevät. Siihen ei Scrum auta. Asiat voi suunnitella ja pilkkoa sprintteihin ilman Scrumiakin. Myös se on tärkeää, että keskeytyksiä, esim. kriittisiä vikoja tuotannossa osataan korjata nopeasti. Siihenkään Scrumilla ei ole mitään annettavaa.
Kerro sinä nyt, mikä tekee menetelmästä niin mahtavan, ja miten keskinkertaiset tekijät tekevät vaikeasta softasta hyvän sen avulla?
No ainakin jos tulisin sinun tiimiisi uutena scrum olisi ennestään tuttu toimintamalli. Jos tavat ovat sattumanvaraisia ja perustuvat yksittäisten ihmisten vaihteleviin päätöksiin koodareita ei voi helposti vaihtaa projektissa. Lisäksi lyhyitä projekteja on hankala tehdä jos henkilöt vaihtuvat js tiimille ei ole selkeää miten tehdään. Kaikki koodaus ei ole vuosien tuotekehitystyötä. Kommunikaatiosta unohtuvat helposti ei ydintiimiin tai ikävästi sanottuna klikkiytyneet pitempään talossa olleet tyypit. Eli vaikka sinusta tuntuu, että saat tietoa niin onko teillä varmistettu, että tieto kulkee kaikille tasapuolisesti? Millä tavalla arvioit muut koodarit keskinkertaisiksi? Rutiinit nimenomaan poistavat sitä ajanhukkaa mikä aiheutuu kaaoksesta ja epävarmuudesta kun kaverit sopivat keskenään. Se ei tue skaalautuvuutta. Tuotannossa olevaa koodia voidaan jatkokehittää scrumilla ja valita sopiva menetelmä kriittisten vikojen korjaamiseen. Maalaisjärjen käyttö on ihan sallittua.
Nyt voisit sitten kertoa mikä on se parempi menetelmä ja vähän perusteluita kehiin.
Kuten alussa totesin "Scrum on todella yksinkertainen menetelmä" eli ei ole vaikeaa omaksua. Oleellista siinä on hommien suunnittelu tietyllä intervallilla ja niiden pilkkominen pienempiin osiin. Sitten seurataan edistystä. Siinäpä se.
Ne hommat, joissa itse olen ollut, vaativat pitkään käytännön tekemistä, että ymmärtää kokonaisuuden ja kuinka asiat liittyvät toisiinsa. Sisältäen frontendia, backendia, tietokantoja ja infran tuntemusta. Kukaan tulokas ei ole nopeasti kyennyt tulemaan niin osaavaksi, että voisi kommentoida muiden koodia kunnolla tai ylipäätään suunnitella taskeja. Edes arkkitehtitason tyypit yhtä lukuunottamatta. Nämä hommat ovat vaatineet jokaiselta käytännön työtä pitkään ja sitä kautta oppimista. Eli Scrum ei sinänsä ole tuonut mitään lisää, vaan olisimme voineet pitää suunnittelun esim kerran parissa viikossa, "dailyn" tapaisen vaikka kolme kertaa viikossa ja demon vain joskus, jos on oikeasti jotain demottavaa. Ei mitään retrospektiivejä, mutta kehitysideoita voisi kerätä jollain metodilla välillä. Tämä antaisi enemmän tilaa vapaalle ajattelulle ja luovuudelle, eikä tuputtaisi jatkuvasti Scrum-seremonioita. Myös keskeytykset tuotannosta ovat aina olleet riesa. Kun sanot, että maalaisjärjen käyttö on sallittua, niin sitähän tässä juuri käytän. Kaikki turha pois Scrumista.
Enkä myöskään ole ollut niin onnellisessa asemassa, että tietoa tarvitsisi lisää. Sitä tulee liikaa. Eli on joka tapauksessa suodatettava liika informaatio pois, että saa keskityttyä oleelliseen.
Olet sitten todella onnellisessa asemassa jos ei koskaan tarvitse keskustella sprintin aikana muiden koodareiden kanssa mistään ja kaikki on päivänselvää pässinlihaa. Muistathan ettei asia välttämättä näyttäydy samoin työkaveriesi näkökulmasta. Scrum on nimenomaan projektin hallinnan väline eikä tietenkään kiveen kirjoitettu ja jokainen firma soveltaa sitä omalla tavallaan, koska se sallii paljon vapauksia päälinjausten lomassa. En missään vaiheessa väittänyt, että aloittelevat koodarit osaisivat määritellä tikettejä tai ymmärtäisivät esim. webbipalvelun monimutkaista arkkitehtuuria, mutta heille sitten annetaan taskit tai miksikä ikinä niitä kutsutkaan oman tasonsa mukaan ja kehittyvät matkalla. Oleellista on, että saavat olla mukana ja saavat vähitellen lisää vastuuta. Tiedonvaihto on koodareiden välistä ja itseäni auttaa, että on rutiiniaika jolloin kuulen mitä muut ovat tehneet ja voidaan tarvittaessa lisätä tai yhdistellä töitä joustavasti. Tarvittaessa myös parikoodataan ja suunnitellaan lisää jos sitä tarvitaan. Ei scrum sitä kiellä. En suhtaudu asiaan niin jäykästi eli ehkä minulla on sitten käynyt hyvä tuuri ja olen saanut scrumista vain positiivisia kokemuksia. Review luo painetta saada aikaan jotain ja se ohjaa tekemään vain oleellisia asioita ja se on johdon tapa seurata, että homma edistyy. Siitä olen samaa mieltä, että kehitettäviä asioita voisi kerätä sprintin aikana vähitellen eikä missään yksittäisessä retrossa. Toisaalta on hyvä varata erillinen aika, jossa voi rauhassa keskittyä vain prosessin ja muiden pullonkaulojen kehittämiseen ja siihen liittyvien asioiden läpikäymiseen sekä vähän taputella toisia selkään, että vedettiin taas hyvä sprintti ja mennään oluelle tai virtuaalibisselle. Hyvä jos olet saanut kehitettyä menetelmän joka ajaa saman asian ja jos se lopulta ohjaa arkea eikä ole kaoottista supersankarikoodarien keulimista. Meille muille, jotka eivät jaksa keksiä omaa menetelmää, scrum ja muut agilet standardit menetelmät luovat varsin toimivan projektiarjen.
Sisältö jatkuu mainoksen alla
Sisältö jatkuu mainoksen alla
Miten voi päästä tietohallinto päälliköksi?
Vierailija kirjoitti:
Miten voi päästä tietohallinto päälliköksi?
Ensimmäinen kriteeri on osata yhdyssanat!
Vierailija kirjoitti:
Vierailija kirjoitti:
Miten voi päästä tietohallinto päälliköksi?
Ensimmäinen kriteeri on osata yhdyssanat!
Ei välttämättä. Päälliköiden kuuluu enimmäkseen osata puhua paljon paskaa ja olla ns. "hyviä tyyppejä".
Vierailija kirjoitti:
Mitä ne valtion ”IT työt” voisi olla?kuntapuolen tajuan...
No aloitetaan puolustusvoimista, onko se kunnallinen vai?
Entäpä ministeriöt?
ei jaksa enempää
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Miten voi päästä tietohallinto päälliköksi?
Ensimmäinen kriteeri on osata yhdyssanat!
Ei välttämättä. Päälliköiden kuuluu enimmäkseen osata puhua paljon paskaa ja olla ns. "hyviä tyyppejä".
Nooh on se suoravaa, tosin word ja se näpsäkkä assari korjaa virheet.
Enemmän mä kirjoitin tekstiä kuin puhuin paskaa ollesssani päällikkö-tasolla.
Slidewaren ja -softan myyjät tienaa toiseksi parhaiten. Firman perustajat ja omistajat eniten, mikäli firma joskus ostetaan. Jos ei osteta, niin omistajien stressi on pahin.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Oma mies on peruskoodaaja, ei siis mitään esimiesvastuita, vaan jäsen tiimissä. Palkka 10000€/kk ja viime vuonna tuli osakepalkkiojärjestelmän kautta vielä palkkaa enemmän. On töissä firmassa, jolla on omat tuotteet ja joita kehitellään vuosikausia. Näin sivusta katsottuna tuo vaikuttaa paljon mukavammalta puuhalta kuin olla konsulttina, joka tekee tilaustöitä eri firmoille nopealla sykkeellä, joka projektissa vähän eri teknologiat ja ohjelmointikielet käytössä. Mies on vääntänyt C-kieltä varmaan viimeiset 20 vuotta. Osaa varmaan muutakin, mutta tuolla tehdään pääosa hommista.
Ajattelisin, että joku iso firma, jolla on omat tuotteet, olisi hyvä. Iso siksi, että voi ehkä talon sisällä vaihdella hommia. Ja että on sitä palkanmaksukykyä vähän eri tavalla kuin startupeilla.
Kannattaa myös katsoa, että firmassa pidetään työntekijöistä hyvää huolta. Palkka pitää olla kohdillaan, että voi keskittyä työntekoon eikä tarvitse murehtia raha-asioita. Mutta pitää olla lisäksi joustavat työajat ja mahdollisuus tehdä etätöitä. Työajanseuranta on vähän old school. Jos jotain tällaista kyttäysjärjestelmää on, niin sitä pitäisin hälytysmerkkinä. Espressokone on must, kuntosali ja sauna plussaa. Jos ei firmassa ole työntekijöille saunaa, niin ehkä katselisin muita työpaikkoja.
Työajan seuranta on laissa pakollinen. Itse olen kyllä pitänyt ohjelmointihommista ja nimenomaan tuotebisneksestä enemmän kuin ns. takapuolen myynnistä konsulttina. Kokemusta samat 20 vuotta, mutta 10k palkoista en ole suomessa kuullutkaan. Pitää olla jo todellinen kersantti Rokka rivikoodaaja, sinun miehesi.
Kyllä 10k miehillä on jo "Director" tai "President" tittelissään, vähintään "Architect" superstar.
Koodauksesta en tiedä mutta jos menee vendoreille niin 10k on saavuteettavissa helposti myös teknisille.
Toki pitää olla suht hyvä että Microsoft tai Cisco sinut palkkaa johonkin muuhun kuin sales-rooliin
Vierailija kirjoitti:
Poikani aloitti 3 v sitten opinnot aallossa.Tekee koodsrina lisätöitä ja palkka kk-tasoisena n 5000e. Koodareista on pulaa.
Hyvää läppää... Jonne kertoo omaa fantasiaansa mitä hän tienaisi jos oli päässyt aaltoon...
Ei, koodareista ei ole pulaa.
Kokeneista koodareista on pulaa.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Onko Scrum nyt vaikea kenenkään sisäistää? Lopulta todella yksinkertainen menetelmä, mutta ahdistava ja ihmistä kontrolloimaan pyrkivä. Kaikki eivät vaan pidä siitä.
Sinä et selkästi ole sisäistänyt sitä...
Koska itse koen Scrumin noin, niin en mielestäsi ole sisäistänyt sitä?
Niin. Tai kerro nyt sitten ihan omin sanoin miten se pyrkii kontrolloimaan ihmistä? Tai mikä siinä ahdistaa, toki nykypäivän uniikkeja perhosia ahdistaa lähtökohtaisesti jo ihan kaikki, mutta jos ihan jotain oikeita syitä olisi heittää?
Turhia palavereita, joita pidetään vain, koska ne kuuluvat Scrumiin ja koska seremonioiden vetäjien mielestä ne on tosi tarpeellisia. Sata kertaa tärkeämpää on, että tekijöillä on kompetenssia, he tekevät pro-aktiivisesti yhteistyötä, ja he tietävät mitä tekevät. Siihen ei Scrum auta. Asiat voi suunnitella ja pilkkoa sprintteihin ilman Scrumiakin. Myös se on tärkeää, että keskeytyksiä, esim. kriittisiä vikoja tuotannossa osataan korjata nopeasti. Siihenkään Scrumilla ei ole mitään annettavaa.
Kerro sinä nyt, mikä tekee menetelmästä niin mahtavan, ja miten keskinkertaiset tekijät tekevät vaikeasta softasta hyvän sen avulla?
Juuri näin. Srcumin avulla vendor kontrolloi sekä omaa porukkaansa että pitää asiakkaan mahdollisimman pienessä roolissa. Asiakkaan (yksi) asiantuntija valitaan product owneriksi, jolloin scrum-ryhmä voi helposti pelata hänet sivuraiteelle, pois häiritsemästä hyvin toimivaa laskutusta.
Asiakkaan product owner on yleensä tarinan aasi, joka ihastuu uuteen titteliinsä, nielee scrum-ryhmän typerät selitykset eikä tajua pelaavansa koko ajan omaa työntantajaansa vastaan.
Yli 20 vuoden kokemuksella vesiputousmallista ja erilaisista ketteristä menetelmistä voin sanoa, ettei scrum tarjoa ratkaisua mihinkään muuhun kuin kontrollointiin ja epäpätevän toteuttajaporukan sisäänajoon. Asiakasfirman kannalta sillä ei ole mitään hyviä puolia.
Olen insinöörihommissa valtiolla (ei IT) ja hyvä, että tauot ehtii pitää. Silti kaikkea työtä ei kerkeä tehdä. Se on se valtion tuottavuusohjelma.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Onko Scrum nyt vaikea kenenkään sisäistää? Lopulta todella yksinkertainen menetelmä, mutta ahdistava ja ihmistä kontrolloimaan pyrkivä. Kaikki eivät vaan pidä siitä.
Sinä et selkästi ole sisäistänyt sitä...
Koska itse koen Scrumin noin, niin en mielestäsi ole sisäistänyt sitä?
Niin. Tai kerro nyt sitten ihan omin sanoin miten se pyrkii kontrolloimaan ihmistä? Tai mikä siinä ahdistaa, toki nykypäivän uniikkeja perhosia ahdistaa lähtökohtaisesti jo ihan kaikki, mutta jos ihan jotain oikeita syitä olisi heittää?
Turhia palavereita, joita pidetään vain, koska ne kuuluvat Scrumiin ja koska seremonioiden vetäjien mielestä ne on tosi tarpeellisia. Sata kertaa tärkeämpää on, että tekijöillä on kompetenssia, he tekevät pro-aktiivisesti yhteistyötä, ja he tietävät mitä tekevät. Siihen ei Scrum auta. Asiat voi suunnitella ja pilkkoa sprintteihin ilman Scrumiakin. Myös se on tärkeää, että keskeytyksiä, esim. kriittisiä vikoja tuotannossa osataan korjata nopeasti. Siihenkään Scrumilla ei ole mitään annettavaa.
Kerro sinä nyt, mikä tekee menetelmästä niin mahtavan, ja miten keskinkertaiset tekijät tekevät vaikeasta softasta hyvän sen avulla?
Juuri näin. Srcumin avulla vendor kontrolloi sekä omaa porukkaansa että pitää asiakkaan mahdollisimman pienessä roolissa. Asiakkaan (yksi) asiantuntija valitaan product owneriksi, jolloin scrum-ryhmä voi helposti pelata hänet sivuraiteelle, pois häiritsemästä hyvin toimivaa laskutusta.
Asiakkaan product owner on yleensä tarinan aasi, joka ihastuu uuteen titteliinsä, nielee scrum-ryhmän typerät selitykset eikä tajua pelaavansa koko ajan omaa työntantajaansa vastaan.
Yli 20 vuoden kokemuksella vesiputousmallista ja erilaisista ketteristä menetelmistä voin sanoa, ettei scrum tarjoa ratkaisua mihinkään muuhun kuin kontrollointiin ja epäpätevän toteuttajaporukan sisäänajoon. Asiakasfirman kannalta sillä ei ole mitään hyviä puolia.
Täysin samaa mieltä! Myös 20 vuoden kokemus minullakin. Scrum luo mukavan ja valheellisen tyytyväisyyden tunteen kontrollista kaikille niille, jotka eivät ole sen itse toteutuksen ytimessä. Teoriahan on kiva, että inkrementaalisesti tuotetaan mukavia demoja ja painetaan sprintti kerrallaan täysillä. Asiakas helposti ohjailee tuotteen suuntaa ja lopulta saadaan ihana tuote aikataulussa ja juuri oikeanlaisena valmiiksi. No, käytäntö ei nyt vaan mene noin.
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Miten voi päästä tietohallinto päälliköksi?
Ensimmäinen kriteeri on osata yhdyssanat!
Ei välttämättä. Päälliköiden kuuluu enimmäkseen osata puhua paljon paskaa ja olla ns. "hyviä tyyppejä".
Väärin. Päällikön on suotavaa johtaa ja saada yksikkönsä taloudellisesti kannattavaksi. Ei koske julkista sektoria. Siellä pitää tehdä mahdollisimman paljon näennäistöitä ja puhua potaskaa. Muuten turhautuu ja palaa loppuun tai turhautuu ja vaihtaa yksityiselle.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Miten voi päästä tietohallinto päälliköksi?
Ensimmäinen kriteeri on osata yhdyssanat!
Ei välttämättä. Päälliköiden kuuluu enimmäkseen osata puhua paljon paskaa ja olla ns. "hyviä tyyppejä".
Väärin. Päällikön on suotavaa johtaa ja saada yksikkönsä taloudellisesti kannattavaksi. Ei koske julkista sektoria. Siellä pitää tehdä mahdollisimman paljon näennäistöitä ja puhua potaskaa. Muuten turhautuu ja palaa loppuun tai turhautuu ja vaihtaa yksityiselle.
Tuo on olennainen ero: yksityisellä sektorilla vaatimukset thp:lle yleensä kovat, julkisella työ lähinnä vitsi poislukien jotkut kuntayhtymäpaikat, joissa voi olla kai paljon vastuitakin. Olen ollut ko työssä sekä kunnassa että yksityisellä. Valtiolla nimike on kaikkea muuta kuin ”päällikkö”😭. Pölyyntynyt jättöhomma,jossa palkka sen mukainen.Tosin 3500-4000 on aivan liikaa sellaisesta hörhöilystä.Valtiolla tehtävä ei edes välttämättä liity IT-osaamiseen!
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Miten voi päästä tietohallinto päälliköksi?
Ensimmäinen kriteeri on osata yhdyssanat!
Ei välttämättä. Päälliköiden kuuluu enimmäkseen osata puhua paljon paskaa ja olla ns. "hyviä tyyppejä".
Väärin. Päällikön on suotavaa johtaa ja saada yksikkönsä taloudellisesti kannattavaksi. Ei koske julkista sektoria. Siellä pitää tehdä mahdollisimman paljon näennäistöitä ja puhua potaskaa. Muuten turhautuu ja palaa loppuun tai turhautuu ja vaihtaa yksityiselle.
Tossa on yks poikkeus joka on PV.Olen kuullut että valtiolla PV kai ainoita paikkoja joissa ihan hyvää IT osaamista.Valtio on kärsinyt aiempaakin enemmän inflaation jota jumalaton konsulttien käyttö ei paljo paranna.Konsultit vois pyörittää kaiken.
Ja sit on se että yksityiselle ei pääse jos jää pitkäksi jaksoksi puhumaan palturia valtion suojiin (nimenomaan suojatyöhön)
Vierailija kirjoitti:
Vierailija kirjoitti:
Poikani aloitti 3 v sitten opinnot aallossa.Tekee koodsrina lisätöitä ja palkka kk-tasoisena n 5000e. Koodareista on pulaa.
Hyvää läppää... Jonne kertoo omaa fantasiaansa mitä hän tienaisi jos oli päässyt aaltoon...
Ei, koodareista ei ole pulaa.
Kokeneista koodareista on pulaa.
Ei kai aaltoon ole vaikea päästä...joku tuta voi olla vaikea ja sieltä tulee harvemmin koodareita...
Olen konsulttina, jossa työ on liukumassa arkkitehtuurituesta yleisiin tehtäviin. Olen kahden vaiheilla mihin suuntautua. Palkka on 5100, mutta en ole mikään ykköstykki.
Varmaan jonkun pornosivun ylläpito tms.
Heiluttelen käsiä IT-alalla. Palkka yli 5k. Vaativinta mitä teknisesti itse teen on excelin ja powerpointtien pyörittely. Satunnaiset visual basicit et saa excelit pyörimään helpommin. Teknologioiden ymmärtäminen on työssä se helppo osuus, ihmisten halujen ja tarpeiden ymmärtäminen se haastavampi et saa hommia eteenpäin.
Kuten alussa totesin "Scrum on todella yksinkertainen menetelmä" eli ei ole vaikeaa omaksua. Oleellista siinä on hommien suunnittelu tietyllä intervallilla ja niiden pilkkominen pienempiin osiin. Sitten seurataan edistystä. Siinäpä se.
Ne hommat, joissa itse olen ollut, vaativat pitkään käytännön tekemistä, että ymmärtää kokonaisuuden ja kuinka asiat liittyvät toisiinsa. Sisältäen frontendia, backendia, tietokantoja ja infran tuntemusta. Kukaan tulokas ei ole nopeasti kyennyt tulemaan niin osaavaksi, että voisi kommentoida muiden koodia kunnolla tai ylipäätään suunnitella taskeja. Edes arkkitehtitason tyypit yhtä lukuunottamatta. Nämä hommat ovat vaatineet jokaiselta käytännön työtä pitkään ja sitä kautta oppimista. Eli Scrum ei sinänsä ole tuonut mitään lisää, vaan olisimme voineet pitää suunnittelun esim kerran parissa viikossa, "dailyn" tapaisen vaikka kolme kertaa viikossa ja demon vain joskus, jos on oikeasti jotain demottavaa. Ei mitään retrospektiivejä, mutta kehitysideoita voisi kerätä jollain metodilla välillä. Tämä antaisi enemmän tilaa vapaalle ajattelulle ja luovuudelle, eikä tuputtaisi jatkuvasti Scrum-seremonioita. Myös keskeytykset tuotannosta ovat aina olleet riesa. Kun sanot, että maalaisjärjen käyttö on sallittua, niin sitähän tässä juuri käytän. Kaikki turha pois Scrumista.
Enkä myöskään ole ollut niin onnellisessa asemassa, että tietoa tarvitsisi lisää. Sitä tulee liikaa. Eli on joka tapauksessa suodatettava liika informaatio pois, että saa keskityttyä oleelliseen.