Virheidenhallinta kuntoon säännöllisillä kokouksilla
Ihmiset tekevät virheitä – se vain on fact of life. Myös ohjelmistotuotekehityksessä näin tapahtuu. Tuotekehitystiimeillä ja projekteilla kannattaakin olla jonkinlainen virheiden johtamiskäytäntö sen varmistamiseen, että asiat on priorisoitu oikein ja oikeat asiat etenevät.
Virheidenhallinta on tärkeää!
On tietenkin myös huomattava, että tuotekehitysorganisaation pitää pyrkiä parempaan laatuun. Tähän voi olla monia keinoja, esimerkiksi parempi asiakasymmärrys tai paremmat suunnittelu ja katselmuskäytännöt. Virheiden suhteen, tavoitteena pitäisi olla tehdä pienempiä virheitä ja kehittää mekanismeja, että tehdyt virheet havaitaan aikaisemmin. Virheistä pitää myös pystyä puhumaan avoimesti ja niiden tilan pitäisi olla läpinäkyvästi kaikkien tiedossa tai näkyvissä. Virheitä ei saa piilotella! Jos organisaatiossa on kulttuuri, että kaikkia virheitä ei raportoida tai niistä ei kerrota, on syytä kaivautua tämän käytöksen juurille – miksi näin toimitaan? Onko kyseessä hankala työkalu virhehallintaan? Vai onko joku muu syy, kuten hankala virheiden raportointiprosessi tai joku muu. Tämä tilanne pitää ymmärtää ja korjata: virheet on pakko saada avoimesti näkyviin ja työkaluun, jotta niitä voidaan aktiivisesti hallita ja korjata.
Tämän blogin aiheena on kuitenkin virheiden johtamis- tai hallintakäytäntö. Olen kokemuksesta oppinut, että on hyvä, jos isommissa kehityshankkeissa on säännöllinen kokous, joka on fokusoitunut virheiden hallintaan. Tässä on muistilista mitä kannattaa pitää mielessä, kun järjestätte tällaista kokousta!
Miksi virhehallintakokous?
Miksi virheidenhallinta vaatii erillisen kokouksen virhetilanteen seurantaan? Tähän on seuraavia syitä.
Kokouksella tavoitellaan:
- virheiden laatukontrolli
- prioriteetin varmistaminen
- kriittisten asioiden seuranta
- päätösten tekeminen
- tiedon ja ymmärryksen jakaminen virheistä ja kokonaisvirhetilanteesta
Hyvä virhe sisältää paljon tietoa. Kovin usein tilanne on se, että organisaatio laiskistuu, ja virheet alkavat sisältää vähemmän ja vähemmän tietoa, kunnes ne typistyvät vain kryptiseksi otsikoksi ilman kuvausta. Kuulostaako tutulta? Tähän pitää tehdä stoppi. Hyvälaatuinen virhe sisältää:
- hyvän ja selkeän otsikon
- prioriteetti tai vakavuus
- tietoa millä buildilla vika on ensin löydetty
- tietoa mitkä muut buildit on tarkistettu, että onko vika siellä
- millaisessa ympäristössä vika löytyy
- mitkä esistepit (preconditions) pitää ajaa, että virhe toistuu
- millä stepeillä virhe toistuu
- mikä on actual ja expected käytös (eli virheen tulos)
- mitä muita käyttäjän toimia on kokeiltu – ja toistuuko virhe niissäkin, vai eikö toistu
- missä buildeissä, ympäristöissä tai käyttöskenaarioissa virhe ei toistu
toistuuko virhe, kuinka usein?
- kuka on alkuperäinen virheen löytäjä
Tietoa voi olla paljon muutakin, ja tietenkin asiaankuuluvat logit, tracet ja muut pitää myös liittää mukaan. Tarkoitus on siis, että tässä vaiheessa virheen raportointia annetaan tarkka kuva siitä, millainen ja miten vakava ongelma on kyseessä, ja miten sen voi toistaa. Tällä tiedolla on paljon helpompi ensinnäkin tehdä oikea prioriteettipäätös ja päättää korjauksen kiireellisyydestä ja target releasesta, ja toisaalta virhettä korjaavan henkilön on helpompi alkaa yrittää itse toistaa ongelmaa ja alkaa selvittää ongelman juurisyytä. Erityisesti tieto siitä missä virhe toistuu ja missä se ei toistu on todella tärkeä.
Jos näitä tietoja ei ole, ne pitää hankkia. Suurta hukkaa syntyy siitä, jos puutteellisin tiedoin varustettu virhe päästetään korjattavaksi. Kehittäjä toimii silloin sokkona, yrittää etsiä “neulaa heinäsuovasta” ja turhautuu helposti. Tällainen tilanne johtaa helposti ping pong virheisiin, jotka kimpoilevat organisaation eri tahojen välillä, tai vääriin päätöksiin “ei se toistu meillä, sen täytyy olla harvinainen vika tai pelkästään yksittäistapaus”.
Tarpeeksi tietoa virheessä onkin perusjuttuja, ja virhehallintakokous (muitakin keinoja on) on yksi keino varmistaa se, että organisaatio oppii täyttämään nämä tiedot virheisiin. Jos tietoja ei ole, on testaajan yleensä helpompi etsiä ja hankkia ne kuin devaajan.
Oikea prioriteetti
Kun virheessä on tarpeeksi tietoa, on helpompi varmistaa onko prioriteetti tai vakavuus oikea. Tähän kannattaa ottaa mukaan tuoteomistaja. Kun virheessä on tarpeeksi tietoa loppukäyttäjän ongelmasta ja tuskasta, tuoteomistaja voi tehdä päätöksen onko tämä virhe tarpeeksi paha, jotta se saa “critical” -tason leiman, vai riittääkö “major”. Yleensä kannattaa pyrkiä siihen, että kaikki virheet korjataan, mutta joskus se ei ole mahdollista. Silloin tietenkin pitää taas pyrkiä siihen, että vakavat virheet korjataan ensin. Organisaatioilla on myös yleensä sääntöjä siitä, millaisia tiedossa olevia virheitä myyntireleasessa saa olla. Esimerkiksi ei sallita yhtään critical-tason virhettä, mutta majoreita saa olla tietty määrä.
Virhekokous voi myös auttaa virhestatistiikan seurannassa, vaikka se ei olekaan kokouksen päätavoite. Kokouksen päätavoite on varmistaa virheiden laatu ja oikea vakavuuspäätös. Mutta kun nyt ollaan sopivalla porukalla koossa, voidaan hyvin myös katsoa mikä on virhe-inflow ja kokonaisstatistiikka. Näin varmistetaan, että kaikilla on sama käsitys nykytilasta. Tämä voi auttaa esimerkiksi sen huomaamiseen, pitääkö enemmän voimia suunnata virheiden etsimiseen ja korjaamiseen, ja vähemmän uuden tekemiseen.
Lisäksi kokous voi myös olla avuksi kiireellisten korjausten seurannassa, jos tälle ei ole muuta seurantamekanismia sovittu. Virheet, jotka pitää korjata nopeasti, voidaan vaikkapa leimata jollain tietyllä leimalla, ja kokous voi varmistaa, että nämä virheet ovat etenemässä mahdollisimman suurella nopeudella.
Päätösten tekeminen
Virheiden osaltakin pitää joskus tehdä päätöksiä. Korjataan / ei korjata. Critical / Major. Major / Minor. Korjataan nyt / seuraavassa releasessa. Tämä on mahdollista, kun on tarpeeksi tietoa virheestä ja oikeat päätöksentekijät paikalla. Kokous on hyvä paikka tällaiseen. Lisähyöty on se, että kokouksessa on myös yleisöä, joten päätökset ovat kaikkien tiedossa ja myös niiden perustelut on mahdollista kertoa.
Tiedon ja ymmärryksen jakaminen
Virhekokous on myös tilaisuus keskustella ja ymmärtää. Usein virheet saattavat olla niin spesifisiä, että vaikka ne koetettaisiin kuvata kuinka hyvin, niin ne ovat hankala ymmärtää. Keskustellessa niiden impakti on kuitenkin helppo kertoa muille. Tällöin koko organisaatio voi vakuuttua siitä, että joku asia on pakko korjata nyt. Usein myös tietoisuus jostain virheestä voi johtaa siihen, että testausta tai muita laadunvarmistuskeinoja kuten katselmointeja päätetään lisätä, tai kohdentaa johonkin uuteen alueeseen. Keskustelu parantaa organisaation oppimista. Olisihan tavoitteena se, että ei toisteta samoja virheitä monta kertaa. Miten voitaisiin siis välttää samanlaisia virheitä tulevaisuudessa?
Muiden edessä annetut lupaukset toimenpiteistä jäävät myös ihmisten mieleen ja ne toteutetaan varmemmin.
Virhehallintakokouksen pitää olla säännöllinen
Hyvä frekvenssi kokoukselle on mielestäni kaksi kertaa viikossa, mutta kerrankin viikossa saattaa riittää. Frekvenssi riippuu paljon projektin tavoiteaikataulusta ja error inflowsta. Jos päivässä tulee useampia uusia bugeja, saattaa olla parempi pitää kokous pari kertaa viikossa, niin siinä ehditään kaikki tärkeät bugit käsitellä ilman että kokous venyy liian pitkäksi.
Olisi myös hyvä, jos joku, jolla on riittävästi aikaa, järjestää kokousta. Tuoteomistaja voi tehdä sen pienemmissä projekteissa, vähän isommissa paras ihminen on ehkä testaus lead- tai testipäällikkö. Vieläkin isommissa kannattaa ehkä jo harkita oikein virhehallintaroolia (Error manager).
Paljasta patternit
Virhehallintakokous voi myös auttaa organisaatiota paljastamaan tiettyjä patterneja. Onko tietyntyyppisiä virheitä liikaa? Miksi? Pitääkö jotain tiettyä testausta lisätä? Pitääkö kehittäjien muuttaa toimintatapojaan, jotta jotain tietyntyyppistä virhettä ei tulisi jatkossa enää niin paljon? Näihin asioihin kokouksen keskustelu ja tiedon jakaminen voi tuoda apua.
Kokous voi toimia myös muutosagenttina
Virhehallintakokous toimii myös tiimille ja organisaatiolle tietynkaltaisena seremoniana, missä virhetilanne hyväksytään. Tämä on tilanne missä olemme nyt – me voimme yhdessä päättää, mihin haluamme mennä. Virhekokous voi auttaa organisaatiota muuttamaan kulttuuria virheiden osalta. Jos on piilotteleva kulttuuri, kokouksen keskusteluilla voidaan ehkä alkaa muuttamaan kulttuuria suuntaan missä virheistä voidaan puhua avoimemmin. Kun huomataan, että virheiden tuominen päivänvaloon ei olekaan niin tuskallista, ja itse asiassa muillakin on virheitä, piilottelusta voidaan ehkä päästä hitaasti eroon.
Tietyllä tavalla tehdyt ja perustellut prioriteetti- ja korjataan/ei korjata päätökset myös opettavat organisaation eri tahoja siihen, mitkä virheet pitää korjata, ja mitkä ei. Ehkä osa virheistä voidaan korjata jo aikaisemmin, kun kaikille on selvää, että tätä ei ainakaan voi päästää tuotantoon.
Ajantasainen virhetieto mahdollistaa oikeat päätökset, ja hyvälaatuiset virheet on mahdollista korjata tehokkaasti ja nopeasti. Tämän takia tehokas virhehallintakokous on tavoittelemisen arvoinen.
On tietenkin myös huomattava, että tuotekehitysorganisaation pitää pyrkiä parempaan laatuun. Tähän voi olla monia keinoja, esimerkiksi parempi asiakasymmärrys tai paremmat suunnittelu ja katselmuskäytännöt. Virheiden suhteen, tavoitteena pitäisi olla tehdä pienempiä virheitä ja kehittää mekanismeja, että tehdyt virheet havaitaan aikaisemmin. Virheistä pitää myös pystyä puhumaan avoimesti ja niiden tilan pitäisi olla läpinäkyvästi kaikkien tiedossa tai näkyvissä. Virheitä ei saa piilotella! Jos organisaatiossa on kulttuuri, että kaikkia virheitä ei raportoida tai niistä ei kerrota, on syytä kaivautua tämän käytöksen juurille – miksi näin toimitaan? Onko kyseessä hankala työkalu virhehallintaan? Vai onko joku muu syy, kuten hankala virheiden raportointiprosessi tai joku muu. Tämä tilanne pitää ymmärtää ja korjata: virheet on pakko saada avoimesti näkyviin ja työkaluun, jotta niitä voidaan aktiivisesti hallita ja korjata.
Tämän blogin aiheena on kuitenkin virheiden johtamis- tai hallintakäytäntö. Olen kokemuksesta oppinut, että on hyvä, jos isommissa kehityshankkeissa on säännöllinen kokous, joka on fokusoitunut virheiden hallintaan. Tässä on muistilista mitä kannattaa pitää mielessä, kun järjestätte tällaista kokousta!
Miksi virhehallintakokous?
Miksi virheidenhallinta vaatii erillisen kokouksen virhetilanteen seurantaan? Tähän on seuraavia syitä.
Kokouksella tavoitellaan:
- virheiden laatukontrolli
- prioriteetin varmistaminen
- kriittisten asioiden seuranta
- päätösten tekeminen
- tiedon ja ymmärryksen jakaminen virheistä ja kokonaisvirhetilanteesta
Virheiden laatu
Hyvä virhe sisältää paljon tietoa. Kovin usein tilanne on se, että organisaatio laiskistuu, ja virheet alkavat sisältää vähemmän ja vähemmän tietoa, kunnes ne typistyvät vain kryptiseksi otsikoksi ilman kuvausta. Kuulostaako tutulta? Tähän pitää tehdä stoppi. Hyvälaatuinen virhe sisältää:
- hyvän ja selkeän otsikon
- prioriteetti tai vakavuus
- tietoa millä buildilla vika on ensin löydetty
- tietoa mitkä muut buildit on tarkistettu, että onko vika siellä
- millaisessa ympäristössä vika löytyy
- mitkä esistepit (preconditions) pitää ajaa, että virhe toistuu
- millä stepeillä virhe toistuu
- mikä on actual ja expected käytös (eli virheen tulos)
- mitä muita käyttäjän toimia on kokeiltu – ja toistuuko virhe niissäkin, vai eikö toistu
- missä buildeissä, ympäristöissä tai käyttöskenaarioissa virhe ei toistu
toistuuko virhe, kuinka usein?
- kuka on alkuperäinen virheen löytäjä
Tietoa voi olla paljon muutakin, ja tietenkin asiaankuuluvat logit, tracet ja muut pitää myös liittää mukaan. Tarkoitus on siis, että tässä vaiheessa virheen raportointia annetaan tarkka kuva siitä, millainen ja miten vakava ongelma on kyseessä, ja miten sen voi toistaa. Tällä tiedolla on paljon helpompi ensinnäkin tehdä oikea prioriteettipäätös ja päättää korjauksen kiireellisyydestä ja target releasesta, ja toisaalta virhettä korjaavan henkilön on helpompi alkaa yrittää itse toistaa ongelmaa ja alkaa selvittää ongelman juurisyytä. Erityisesti tieto siitä missä virhe toistuu ja missä se ei toistu on todella tärkeä.
Jos näitä tietoja ei ole, ne pitää hankkia. Suurta hukkaa syntyy siitä, jos puutteellisin tiedoin varustettu virhe päästetään korjattavaksi. Kehittäjä toimii silloin sokkona, yrittää etsiä “neulaa heinäsuovasta” ja turhautuu helposti. Tällainen tilanne johtaa helposti ping pong virheisiin, jotka kimpoilevat organisaation eri tahojen välillä, tai vääriin päätöksiin “ei se toistu meillä, sen täytyy olla harvinainen vika tai pelkästään yksittäistapaus”.
Tarpeeksi tietoa virheessä onkin perusjuttuja, ja virhehallintakokous (muitakin keinoja on) on yksi keino varmistaa se, että organisaatio oppii täyttämään nämä tiedot virheisiin. Jos tietoja ei ole, on testaajan yleensä helpompi etsiä ja hankkia ne kuin devaajan.
Oikea prioriteetti
Kun virheessä on tarpeeksi tietoa, on helpompi varmistaa onko prioriteetti tai vakavuus oikea. Tähän kannattaa ottaa mukaan tuoteomistaja. Kun virheessä on tarpeeksi tietoa loppukäyttäjän ongelmasta ja tuskasta, tuoteomistaja voi tehdä päätöksen onko tämä virhe tarpeeksi paha, jotta se saa “critical” -tason leiman, vai riittääkö “major”. Yleensä kannattaa pyrkiä siihen, että kaikki virheet korjataan, mutta joskus se ei ole mahdollista. Silloin tietenkin pitää taas pyrkiä siihen, että vakavat virheet korjataan ensin. Organisaatioilla on myös yleensä sääntöjä siitä, millaisia tiedossa olevia virheitä myyntireleasessa saa olla. Esimerkiksi ei sallita yhtään critical-tason virhettä, mutta majoreita saa olla tietty määrä.
Seuranta
Virhekokous voi myös auttaa virhestatistiikan seurannassa, vaikka se ei olekaan kokouksen päätavoite. Kokouksen päätavoite on varmistaa virheiden laatu ja oikea vakavuuspäätös. Mutta kun nyt ollaan sopivalla porukalla koossa, voidaan hyvin myös katsoa mikä on virhe-inflow ja kokonaisstatistiikka. Näin varmistetaan, että kaikilla on sama käsitys nykytilasta. Tämä voi auttaa esimerkiksi sen huomaamiseen, pitääkö enemmän voimia suunnata virheiden etsimiseen ja korjaamiseen, ja vähemmän uuden tekemiseen.
Lisäksi kokous voi myös olla avuksi kiireellisten korjausten seurannassa, jos tälle ei ole muuta seurantamekanismia sovittu. Virheet, jotka pitää korjata nopeasti, voidaan vaikkapa leimata jollain tietyllä leimalla, ja kokous voi varmistaa, että nämä virheet ovat etenemässä mahdollisimman suurella nopeudella.
Päätösten tekeminen
Virheiden osaltakin pitää joskus tehdä päätöksiä. Korjataan / ei korjata. Critical / Major. Major / Minor. Korjataan nyt / seuraavassa releasessa. Tämä on mahdollista, kun on tarpeeksi tietoa virheestä ja oikeat päätöksentekijät paikalla. Kokous on hyvä paikka tällaiseen. Lisähyöty on se, että kokouksessa on myös yleisöä, joten päätökset ovat kaikkien tiedossa ja myös niiden perustelut on mahdollista kertoa.
Tiedon ja ymmärryksen jakaminen
Virhekokous on myös tilaisuus keskustella ja ymmärtää. Usein virheet saattavat olla niin spesifisiä, että vaikka ne koetettaisiin kuvata kuinka hyvin, niin ne ovat hankala ymmärtää. Keskustellessa niiden impakti on kuitenkin helppo kertoa muille. Tällöin koko organisaatio voi vakuuttua siitä, että joku asia on pakko korjata nyt. Usein myös tietoisuus jostain virheestä voi johtaa siihen, että testausta tai muita laadunvarmistuskeinoja kuten katselmointeja päätetään lisätä, tai kohdentaa johonkin uuteen alueeseen. Keskustelu parantaa organisaation oppimista. Olisihan tavoitteena se, että ei toisteta samoja virheitä monta kertaa. Miten voitaisiin siis välttää samanlaisia virheitä tulevaisuudessa?
Muiden edessä annetut lupaukset toimenpiteistä jäävät myös ihmisten mieleen ja ne toteutetaan varmemmin.
Virhehallintakokouksen pitää olla säännöllinen
Hyvä frekvenssi kokoukselle on mielestäni kaksi kertaa viikossa, mutta kerrankin viikossa saattaa riittää. Frekvenssi riippuu paljon projektin tavoiteaikataulusta ja error inflowsta. Jos päivässä tulee useampia uusia bugeja, saattaa olla parempi pitää kokous pari kertaa viikossa, niin siinä ehditään kaikki tärkeät bugit käsitellä ilman että kokous venyy liian pitkäksi.
Olisi myös hyvä, jos joku, jolla on riittävästi aikaa, järjestää kokousta. Tuoteomistaja voi tehdä sen pienemmissä projekteissa, vähän isommissa paras ihminen on ehkä testaus lead- tai testipäällikkö. Vieläkin isommissa kannattaa ehkä jo harkita oikein virhehallintaroolia (Error manager).
Paljasta patternit
Virhehallintakokous voi myös auttaa organisaatiota paljastamaan tiettyjä patterneja. Onko tietyntyyppisiä virheitä liikaa? Miksi? Pitääkö jotain tiettyä testausta lisätä? Pitääkö kehittäjien muuttaa toimintatapojaan, jotta jotain tietyntyyppistä virhettä ei tulisi jatkossa enää niin paljon? Näihin asioihin kokouksen keskustelu ja tiedon jakaminen voi tuoda apua.
Kokous voi toimia myös muutosagenttina
Virhehallintakokous toimii myös tiimille ja organisaatiolle tietynkaltaisena seremoniana, missä virhetilanne hyväksytään. Tämä on tilanne missä olemme nyt – me voimme yhdessä päättää, mihin haluamme mennä. Virhekokous voi auttaa organisaatiota muuttamaan kulttuuria virheiden osalta. Jos on piilotteleva kulttuuri, kokouksen keskusteluilla voidaan ehkä alkaa muuttamaan kulttuuria suuntaan missä virheistä voidaan puhua avoimemmin. Kun huomataan, että virheiden tuominen päivänvaloon ei olekaan niin tuskallista, ja itse asiassa muillakin on virheitä, piilottelusta voidaan ehkä päästä hitaasti eroon.
Tietyllä tavalla tehdyt ja perustellut prioriteetti- ja korjataan/ei korjata päätökset myös opettavat organisaation eri tahoja siihen, mitkä virheet pitää korjata, ja mitkä ei. Ehkä osa virheistä voidaan korjata jo aikaisemmin, kun kaikille on selvää, että tätä ei ainakaan voi päästää tuotantoon.
Ajantasainen virhetieto mahdollistaa oikeat päätökset, ja hyvälaatuiset virheet on mahdollista korjata tehokkaasti ja nopeasti. Tämän takia tehokas virhehallintakokous on tavoittelemisen arvoinen.
Lisätietoja
Tagit
Liiketoimintaprosessi
 |
Tuotekehitys ja suunnittelu |
Erikoisosaaminen
 |
Ketterät menetelmät |
 |
Ohjelmistokehitys |
Toimialakokemus
 |
IT |
Tarjonnan tyyppi
 |
Konsultointi |
 |
Koulutus |
Omat tagit
virheidenhallinta
kokous
Contribyte - Asiantuntijat ja yhteyshenkilöt
Premium-profiilia ei ole aktivoitu. Aktivoi premium-profiili näyttääksesi tässä lisäämäsi 3 asiantuntijaa.
Contribyte - Muita referenssejä
Tilaaja suosittelee!
Contribyte - Muita bloggauksia
Löydä sopivimmat it- ja ohjelmistoyritykset liiketoiminnan kehityskumppaneiksi
-
Microsoft
-
SAP
-
IBM
-
Toiminnanohjaus ERP
-
HR
-
Markkinointi
-
Taloushallinto
-
Tuotekehitys ja suunnittelu
-
BI ja raportointi
-
Pilvipalvelut / SaaS
-
Integraatiot
-
Ohjelmistokehitys
-
Webkehitys
-
Mobiilikehitys
-
Paikkatieto GIS
-
Tietoturva
-
Verkkokaupparatkaisut
-
Asiakkuudenhallinta CRM
-
Käyttöliittymäsuunnittelu
-
IoT
-
WordPress
-
Drupal
-
Salesforce
-
Amazon Web Services
-
PHP
-
Javascript
-
React
-
Lisätty todellisuus ja VR
-
Tekoäly (AI) ja koneoppiminen
ite wikin yrityshaku »It- ja ohjelmistoalan työpaikat
- Laura - Java-kehittäjä
- Laura - Systems Specialist, ajoneuvot
- IsoSkills Oy - Open application: Data Engineer, Finland
- Nordea - Sr IT Analyst - Adobe/SAS Marketing Automation
- Nordea - Senior IT / Business Analyst with technical background - Finland, Nordea Payments
- Nordea - Senior IT Analyst, Finnish language required
- Laura - DevOps Engineer
Kaikki it-alan työpaikat »Premium-asiakkaiden viimeisimmät referenssit
- Advania Finland Oy - Turun kaupunki valjastaa digitaaliset ratkaisut palvelemaan strategiaansa
- Sulava Oy - Fondia vahvistaa tekoälyn hyödyntämistä Microsoft Copilotilla
- Druid Oy - International House Turku: Ajanvarauspalvelu
- Symbio - Taxi Point Oy
- Valve - Helsingin yliopiston ylioppilaskunnan verkkopalvelun siirto WordPressiin
- Valve - Eezy Valmennuskeskuksen verkkokauppa-uudistus
- Valve - Danonen Nutricia ja Aptaclub -brändien sivustot
ite wikin referenssihaku »Tapahtumat & webinaarit
- 06.11.2024 - Webinaari: Future-Proof Your Data Infrastructure with Azure
- 13.11.2024 - Rakettiwebinaari: ohjelmistotestaus ja sen tulevaisuus
- 13.11.2024 - Miten palvelumuotoilu poistaa epävarmuutta digi-investoinneista?
- 14.11.2024 - RoimaDay 2024
- 14.11.2024 - Verkkolaskufoorumin syysseminaari 2024
- 19.11.2024 - The Future of Software - Embracing Collaboration in an AI-Powered World
- 19.11.2024 - Tehokkuutta ja säästöjä low-code-ratkaisuilla
Kaikki it-alan tapahtumat »Premium-asiakkaiden viimeisimmät bloggaukset
- Innofactor Oyj - Tunnista ja digitalisoi hiomattomat prosessit Power Platformin avulla
- SD Worx - Oletko etuoikeutettu työskentelemään jonkin asian parissa, jolla on todellinen tarkoitus ja merkitys?
- SD Worx - HR ja tekoäly – usein kysytyt kysymykset
- Timeless Technology - Verkon luotettavuuden varmistaminen: Ota käyttöön Perle Systemsin teollisuustason 4G ja 5G reitittimet!
- Efima Oyj - Hyvästi turhat klikkailut: Näin moderni järjestelmä tehostaa myyntityötä erikoistavarakaupassa
- SC Software Oy - SC Softwaren uratarinat: Joel Ollikainen, konsultti
- Softlandia Oy - Sovelletun tekoälyn insinöörien esiinmarssi ja tekoälyosaamisen muutos
ite wikin julkaisuhaku »
|
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |
