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 - Mobiilikehittäjä, Android
- Laura - Ohjelmistoarkkitehti, Tampere/Oulu
- Laura - Development Team Manager, Sports Games
- Taito United Oy - Senior Full Stack -kehittäjä
- Webscale Oy - Head of Sales, Cloud Services
- Laura - Hankinta-asiantuntija, tietohallinto
- Laura - Development Manager, Operations
Kaikki it-alan työpaikat »Premium-asiakkaiden viimeisimmät referenssit
- SD Worx - Kehitystyö SD Worxin kanssa takaa Clas Ohlsonille parhaat palkanmaksun prosessit kasvun tiellä
- Digiteam Oy - Case Esperi Care Oy: Ketterä kumppanuus vei Esperin verkkosivu-uudistuksen maaliin sujuvasti ja aikataulussa
- Kisko Labs Oy - Howspace Hub - Mukautuva oppimisen hallintajärjestelmä kasvaviin oppimisalustavaatimuksiin
- Kisko Labs Oy - Sanoma Pro: Multimediasisältöjen hallinnan uudistaminen
- Kisko Labs Oy - Svean helppokäyttöinen palvelu asiakkaan verkko-ostosten hallintaan
- Kisko Labs Oy - Yhtenäinen käyttöliittymä luovien alojen ammattilaisille
- Codemate - Digitaalisen murroksen nopeuttaminen Flutterin avulla
ite wikin referenssihaku »Tapahtumat & webinaarit
- 27.11.2024 - Green ICT -ekosysteemitapaaminen III: Ohjelmistojärjestelmien virrankulutuksen mittaaminen ja kasvihuonepäästöjen arviointi
- 27.11.2024 - Digitaalisen asiakaskokemuksen uusi aikakausi
- 28.11.2024 - Webinaari: Keskity myyntityön laatuun!
- 28.11.2024 - Copilot-webinaari – Mielekkäämpää tietotyötä turvallisesti
- 04.12.2024 - Kuinka oikea matka- ja kululaskujärjestelmä tehostaa prosesseja?
- 05.12.2024 - Green ICT VICTIS -hankkeen kick off -tilaisuus
- 15.01.2025 - Datavastuullisuuden valmennus: hanki valmiudet vastuulliseen datan ja tekoälyn hyödyntämiseen
Kaikki it-alan tapahtumat »Premium-asiakkaiden viimeisimmät bloggaukset
- Kisko Labs Oy - Heroku: Millaisiin projekteihin se sopii ja mitkä ovat sen todelliset hyödyt ja haitat?
- Zimple Oy - Pipedrive vai Hubspot? Kumpi kannattaa valita?
- SC Software Oy - Jatkuvat palvelut – asiakaslähtöistä kumppanuutta projekteista ylläpitoon
- Timeless Technology - Ohjelmoitavat logiikat (PLC): Ratkaisevat työkalut automaatioon ControlByWebiltä.
- Kisko Labs Oy - Heroku: Ohjelmistokehittäjän ykköstyökalu skaalautuvien sovellusten rakentamiseen
- SD Worx - Näin luot vakuuttavan Business Casen palkkahallinnon ulkoistukselle
- Timeless Technology - Kyberriskien tunnistaminen Profitap IOTA verkkoanalysaattorin avulla.
ite wikin julkaisuhaku »
|
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |
