29. joulukuuta 2017

Katsaus Tieturin vuoteen 2017

Vuosi 2017 lähestyy loppuaan, ja uusi vuosi odottaa jo ihan nurkan takana. On siis aika muistella mennyttä vuotta sekä suunnata katseet tulevaan. Kulunut vuosi oli Tieturilla melkoisen tapahtumarikas. Vahvistimme DevOps-tarjontaa, solmimme uusia kumppanuuksia, toimme tarjolle uutuuksia heijastamaan markkinoilla tapahtuneita muutoksia.

Aloitimme kuluneena vuonna entistä kiinteämmän yhteistyön ruotsalaisen sisaryhtiömme Informatorin kanssa. Vuosi 2017 käynnistyi yhteisellä kick-offilla, jossa keskityimme pohtimaan yhteisiä arvojamme ja tavoitteitamme. Kick-offista kuvia Instagramissamme www.instagram.com/p/BPcZ3c1hBxq/?taken-by=tieturioy

Teemme tuotekehitystyötämme yhteispohjoismaisesti, ja tämä näkyy asiakkaillemme laajempana tarjontana sekä Informatorilla että Tieturilla. Keväällä julkistimme uudistetut arvomme. Sitoutuminen, rohkeus ja luottamus ohjaavat päivittäistä työntekoamme ja näkyvät vahvasti arjessamme. Kesäkuussa saimme arvojemme mukaiset kahvimukit ja ne pääsivät mukaan toimistokuvaan www.instagram.com/p/BVXPyAHlf5y/?taken-by=tieturioy.

Palkitsemme joka kuukausi yhden tieturilaisen arvojen mukaisesti toiminnasta. Vuoden lopussa kiitimme Tieturin Pasia, Penttiä ja Jania vahvasta arvotyöstä www.instagram.com/p/Bcmen5HF_7y/?taken-by=tieturioy

Vuoden aikana toimme tarjolle useita uusia kursseja. Osa jo tuttujen kumppaneidemme kanssa, osan toteutamme uusien kumppanien kanssa. Etsimme jatkuvasti uusia, tuoreita koulutusaihioita asiakkaidemme tarpeeseen. Tavoitteenamme on taata Suomen asema johtavana IT-maana, ja työskentelemme päivittäin sen eteen.

DevOps-alueella tarjontamme laajentui vuoden 2017 aikana runsaasti. Syksyllä ryhdyimme tekemään yhteistyötä Eficoden kanssa, ja toimme samalla asiakkaillemme laajan valikoiman DevOps-koulutuksia. Kerroimme tästä blogissamme blog.tieturi.fi/2017/10/tervetuloa-eficode.html

Toukokuussa 2018 EU:n tietosuoja-asetusta GDPR:ää ryhdytään soveltamaan kansallisesti. Tästä johtuen GDPR-koulutukset kuuluvat vuoden 2017 uutuuksiin. GDPR:n tuomiin muutoksiin jo olemassa oleviin tietosuojakäytäntöihin keskittyvä EU:n tietosuoja-asetus GDPR käytännössä -koulutuksessa käydään läpi GDPR:n olennaiset kohdat, sen tuomat muutokset ja konkreettiset vaikutukset. Lisäksi Tietosuojan perusteita -koulutuksemme ottaa GDPR:n huomioon.

Kehitämme koulutusten sisällön lisäksi koko ajan myös koulutustapoja. Kevään aikana laajensimme digitaalista kurssitarjontaamme PragmatIQn kanssa (lue lisää tiedotteestamme). Kesäkuussa tieturilaiset kävivät haistelemassa uusia tuulia Blended Learning -konferenssissa Tukholmassa (kurkkaa kuva LinkedInistä). Solmimme myös yhteistyösopimuksen Clanedin kanssa, ja tarjoamme tulevaisuuden AI-pohjaista digioppimista jo nyt asiakkaillemme (lue lisää tiedotteestamme).

Vahva perusosaamisemme yhdistettynä uusimpien muutosten seuraamiseen auttaa meitä varmistamaan koulutustemme ajantasaisuuden ja vaikuttavuuden. Ajatuksenamme on aina, että meillä käytyäsi pääset suoraan viemään saamasi opit käytäntöön työssäsi ja pystyt toimimaan entistä tehokkaammin.

Jatketaan samalla mallilla vuonna 2018.

Hyvää uutta vuotta! Tapaamisiin taas vuonna 2018.



Anna Sahinoja
tuoteryhmäpäällikkö


Anna vastaa Tieturilla ohjelmointi-, infrastruktuuri- ja toimistotyökalukoulutuksista. Hän uskoo vahvasti, että kiky muodostuu päivittäisessä työssä myös työkalujen hallinnasta.

20. joulukuuta 2017

Tieturi toivottaa rauhaisaa joulun aikaa

Haluamme toivottaa rauhaisaa joulun aikaa asiakkaillemme, yhteistyökumppaneillemme ja kaikille tieturilaisille. Lämmin kiitos kuluneesta vuodesta. Nyt on aika rentoutua ja nauttia joulun pyhistä kukin omalla tyylillään.

Suuntasitpa sitten maalle lumiseen maisemaan, etelän lämpöön tai kotiin ystävien ja perheen kanssa joulua viettämään, toivotamme sinulle rauhaisaa ja rentouttavaa joulun aikaa.

Tänä jouluna me Tieturilla tuemme avun tarpeessa olevia lapsia SOS-lapsikylän kautta.

Hyvää joulua!



19. joulukuuta 2017

Tietoturvaa ja tietosuojaa – mikä on tärkeätä?

Viime aikoina keskustelu tietosuoja-asetuksen (GDPR) ympärillä on käynyt varsin kuumana, ja jopa pientä hysteriaa on ollut havaittavissa. Monet pohtivat koulutusbudjettinsa kohdistamista, kouluttaako tietosuojaa vai tietoturvallisuutta. Tässä ”tietosuojahysteriassa” on kuitenkin hyvä palata takaisin perusasioiden äärelle.

Hyvin toteutettu tietoturvallisuus jo sinänsä palvelee tietosuoja-asetuksen vaatimuksia. Tietosuoja-asetuksen vaatimuksia ei voi täyttää, jos tietoturvallisuus ei ole kunnossa. Näkökulmaa tarvitaan siis kumpaankin seikkaan, eikä vain toiseen.

Niiden organisaatioiden osalta, joiden tietosuojat asiat ovat jo aiemmin olleet kunnossa, ei tietosuoja-asetus tuo kovinkaan paljon uutta. Toki monille, jotka ovat vältelleet asioiden kuntoon saattamista, on uusi asetus kiusallinen yllätys.

Kohu tietosuoja-asetuksen ympärillä keskittyy usein mahdollisiin sanktioihin. Se ei kuitenkaan johda parannuksiin. Vain parantamalla sopimuksia, järjestelmiä, prosesseja ja osaamista voi saada tuloksia aikaan. Jotta parannuksia saa aikaan, on oltava osaamista, tahtoa ja resursseja.

Tulee väkisinkin mieleen, ovatko organisaatiot vasta tietosuoja-asetuksen myötä heränneet tietoturvallisuusasioiden hoitamiseen. Tuo herääminen olisi siunaukseksi koko tietoturvallisuusajattelulle ja palvelee tietoturvatietoisuutta laajemminkin.

Liiketoimintasuhteessa olevat organisaatiot ovat viime aikoina alkaneet kiinnostua siitä, miten heidän kumppaninsa hoitavat tietoturvallisuusasioita. Tietoturvallisuutta koskevia vaatimuksia on jo sisällytetty moniin sopimuksiin ja toimittajilta vaaditaan yhä useammin jokin dokumentti tai sertifikaatti, jolla osoittaa toimivansa vastuullisesti myös tietoturvallisuusasioissa.

Tietoturvatietoisuudesta on vähitellen muotoutumassa ammatillinen osa-alue, joka jokaisen työntekijän on hallittava vähintäänkin omien tehtäviensä osalta. Enää ei voi ajatella, että tietotuvallisuus on vain asiantuntijoiden työtä, vaan se on ja tulee olemaan osa meidän jokaisen työstä.

Termi ”tietoturvatietoisuus” tarkoittaa sitä, että tulemme tietoiseksi ja ymmärrämme ympärillämme olevat tietoturvallisuuden riskit ja riskien mahdollisesti toteutuessa niistä aiheutuvat ongelmat. Tietoturvatietoisuutta voi parantaa ja kehittää hankkimalla koulutusta, seuraamalla asiaan liittyvää viestintää verkosta, kirjoista ja lehdistä. Kaikki lähtee tietoturvallisuuden merkityksen ymmärtämisestä ja siihen ei ole oikoteitä, meidän on tehtävä se itse.

Hannu Jaakonhuhta

Hannu vetää Tieturilla mm. seuraavia koulutuksia:

Tietosuojan perusteita >>
Tietoturvatyön johtaminen >>
Tietoturvallisuuden hallinta >>
Teknisen tietoturvan perusteet >>


18. joulukuuta 2017

Itseohjautuvat tiimit – kokeilukelpoinen ratkaisu vai ideaalimaailman utopiaa?



Ilmapalloja, punainen ilmapallo korkeammalla kuin valkoisetOlemme yhtä mieltä siitä, että elämme murroskautta, joka haastaa ajatteluamme ja toimintatapojamme kaikkialla. ”Digitalisaatio” on termi, jota käytämme nyt tapahtuvalle muutokselle. Ytimessä on kyky siirtää enemmän ja laadukkaampaa tietoa helpommin ja nopeammin. Tämä mahdollistaa nopeita päätöksiä, ja niistä seuraavia mullistavia muutoksia.

Myös tapa johtaa organisaatioita on muuttumassa. Yhä enenevässä määrin puhumme itseohjautuvuudesta, ajatuksesta, että emme enää tarvitse johtajia ohjaamassa työn suorittamista.

Tunnetuin moderni ”klassikko”, jossa kuvataan organisaatiomuutosta tosi pitkällä syklillä, on Fredrik Laloux´n kirjoittama ”Reinventing Organizations”. Kirjassaan Laloux korostaa, että elämme nyt johtamisen evolutionääristä vaihetta. Tärkeinä tekijöinä ovat ihmislähtöisyys. Yksilö pyrkii tunnistamaan asiat, jotka tuntuvat ”oikeilta”. Hän haluaa saavuttaa tasapainon elämässään ja toimii kokeellisesti virheistä oppien. Organisaatioiden, jotka kykenevät toimimaan tässä kehitysvaiheessa, tulisi korostaa itseohjautuvuutta (self-management), yksilön tarvetta kokonaisvaltaisuuteen (wholeness) ja työn merkityksellisyyttä (evolutionary purpose).

Itse ymmärrän ja allekirjoitan ne tekijät, jotka ovat johtaneet tähän evolutionääriseen vaiheeseen. Ajatus hierarkisesta johtajuudesta, jossa päätökset tehdään ns. ”pyramidin huipulla” on vanhentumassa. Tässä johtamismallissa eri organisaatiotasoilla on omat vastuunsa, mutta ylimmällä tasolla pitää aina vahvistaa tärkeimmät päätökset. Ongelmiksi muuttuvat mm. tiedon laajuudesta ja monimutkaisuudesta johtuvat päätöksenteon vaikeudet, johtajien ajanpuute ja heidän henkinen kestävyytensä sekä työntekijöiden motivointi ja sitouttaminen.

Kaikkia asioita ei saada päätöstasoon asti tai sitten ne, jotka on sinne viety, ovat vanhentuneet tai ovat laadultaan huonoja. Digitalisaation mahdollistama nopeus ei siis heijastu organisaation päätöksenteossa ja toiminnassa. Kun tietoa matkan varrella tiivistetään ja jalostetaan johdon käsittelyä varten, jää etäisyys lattiatasolle liian pitkäksi. Kuva todellisuudesta vääristyy, ja ihmisten tunne siitä, että tämä on aidosti ”minun omistamani ja toteuttamani asia” häviää. Kun ihminen etääntyy omasta työstään, ei hän enää pidä sitä tärkeänä, ei jaksa innostua sen tekemisestä eikä pitkällä juoksulla viihdy töissä.

Organisaatioiden johtamisessa emme ota riittävästi huomioon työn merkityksellisyyden tärkeyttä. Jokaiselle ihmiselle on tähdellistä, että se, mitä hän tekee, johtaa tulokseen ja että tulos luo myönteisiä vaikutuksia ympäröivään yhteiskuntaan. Itseohjautuvuudessa korostuu jokaisen ihmisen osaamisen, kykyjen, innon ja kokemuksien hyödyntäminen arjen työssä. Itseohjautuvuus on sukua aiemminkin usein käytetylle termille, mahdollistavalle johtamiselle. Tämän näkemyksen mukaan organisaatio menestyy, kun johtaminen perustuu ihmisten tehokkaan toimimisen organisointiin. Johtaminen luo puitteet hyvään työskentelyyn, mutta ei juurikaan ohjaa tekemisen sisältöä. Johtamisessa luodaan tarvittavia mekanismeja ja rakenteita, mutta ei juurikaan tehdä työn muihin ratkaisuihin liittyviä päätöksiä.

Kaikki tämä kuulostaa hienolta, eikö? Mutta toimiiko tämä isoissa pörssilistatuissa teollisuusyrityksissä? Tiedä häntä. Kysyin kerran seminaarissa Supercellin perustajalta, Ilkka Paanaselta, miten heidän konseptinsa (mm. itseohjautuvat tiimit), voisi viedä menestyksellisesti malliksi myös muihin yrityksiin. Seurasi lyhyt hiljaisuus ja kommenttina ”kiitos hyvästä kysymyksestä”. Hän kiteytti asian kolmeen toteamiseen. 1. Tulimme juuri oikeaan aikaan uuteen kehittyvään liiketoiminta-alueeseen. 2. Saimme rakentaa organisaatiomme puhtaalta pöydältä. 3. Nykyisten organisaatioiden on vähennettävä ja poistettava raportointitasoja. Kolmas väite onkin organisaatioita kehittävien johtajien haaste. Kuka haluaa tai pystyy poistamaan itsensä organisaatiokaaviosta eli antamaan itselleen potkut? 

Niklas Reuter

Tieturin verkostokouluttaja, yrittäjä, valmentaja, konsultti, Projnik (www.projnik.fi)
Fasilitaattori (www.hyveettyossa.fi), puheenjohtaja, EBEN Suomi (www.eben-net.fi)

Niklas koulutttaa meillä mm. seuraavissa koulutuksissa:

Taitavan projektipäällikön leadership-taidot >>

Projektipäällikön keskeiset taidot >>

Muutoksen toteuttaminen onnistuneesti hankkeen kautta >>

10. marraskuuta 2017

Lukuruutu näppärästi käyttöön - Outlook 2016 -vinkki

Kollegani Anna kirjoitti pari perjantaita sitten liitetiedostojen lisäämisestä Microsoft Outlookin viesteihin. Tällä kertaa voisimme tarkastella saapuneita viestejä. Oletusarvoisesti Outlookin kansioissa on viestien "esikatselu" eli Lukuruutu käytössä. Tällöin viestin sisältö näkyy yleensä oikean reunan (tai alareunan) ruudussa, valinnan mukaan. Tämä lukuruutu ärsyttää, jos ei halua viestien sisällön näkyvän. Lukuruutu on mahdollista kuitenkin ottaa näppärästi "satunnaiskäyttöön".

Jos lukuruutu on näkyvissä, saat sen suljettua napsauttamalla Näytä | View -välilehteä ja valitsemalla Lukuruutu–Poissa käytöstä | Reading Pane–Off. Koska lukuruutu on kuitenkin toisinaan kätevä toiminto, voit lisätä sen Pikatyökaluriville | Quick Access Toolbar. Tällöin voit tarvittaessa helposti ottaa lukuruudun käyttöön ja sulkea pois ilman, että sinun tarvitsee napsautella Näytä | View -välilehteä.

Näin lisäät Lukuruutu-painikkeet pikatyökaluriville:

Napsauta Lukuruutu | Reading Pane -kuvaketta, ja sitten hiiren kakkospainikkeella Oikea | Right -kuvakkeen päällä ja valitse Lisää pikatyökaluriville | Add to Quick Access Toolbar. Voit tietysti valita myös Ala | Bottom -kuvakkeen, jos haluat lukuruudun viestin alapuolella. Lisää vielä samalla tavalla lukuruudun poistava kuvake Poissa käytöstä | Off.























Nyt sinulla on molemmat kuvakkeet pikatyökalurivillä ja voit kätevästi "esikatsella" viestien sisältöä lukuruudulla napsauttamalla lisäämiäsi kuvakkeita vuorotellen.










Ylläolevista kuvista ehkä huomasitkin, että olen lisännyt omalle pikatyökalurivilleni myös avoimen kirjekuoren lukuruutu-kuvakkeiden viereen. Kyseessä on Aloitus | Home -välilehden Lukematon/luettu | Unread/Read -kuvake, jolla saan viestin nopeasti kuitattua luetuksi tai lukemattomaksi. Saat toiminnon toki myös näkyviin napsauttamalla hiiren kakkospainikkeella viestin päällä ja valitsemalla valikosta vastaavan komennon. Jos maltat lukea kuvakkeen vihjeen, huomaat, että viestin voi kuitata luetuksi myös näppäinyhdistelmällä Ctrl + Q ja lukemattomaksi Ctrl + U.

Näppäinyhdistelmillä säästät hiirikättä (näistä on kirjoittelua aiemmissa blogeissa), mutta viestien selaaminen ja siivoaminen sujuvat kätevästi hiirellä ja näppäimistöllä. Avaa lukuruutu, napsauta viestiä, jotta se näkyy lukuruudussa, kuittaa se luetuksi (tai lukemattomaksi) hiirellä pikatyökalurivin kuvakkeella (tai poista viesti painamalla Delete-näppäintä tai napsauttamalla Poista-rastia). Selaa seuraava tai edellinen viesti painamalla näppäimistöllä nuoli ylös tai alas -painikkeita (tai napsauta viestiä hiirellä).

Itse käytän hiirtä vasemmalla kädellä, jolloin vasen käteni hoitaa hiirellä näytön vasemman reunan toimintoja ja oikean käden sormilla painelen näppäimistöllä Deleteä ja nuolia. Palaan tähän hiiri-vasenkätisyyteen ja sen etuihin myöhemmin blogissamme.

Lukuruudun asetuksissa kannatta myös sammuttaa kaksi ensimmäistä vaihtoehtoa (Merkitse… ja Merkitse…). Näin viestin lukeminen lukuruudussa ei kuittaa viestiä luetuksi, jos haluat lukea viestin myöhemmin uutena viestinä.












Lopuksi vielä ehkä se paras juttu tässä toiminnossa: lukuruutu toimii myös kalenterissa, ihmisissä (yhteystiedoissa), tehtävissä ja muistilapuissa. Kun haluat vilkaista kalenterimerkintäsi tarkempaa sisältöä, älä turhaan avaa merkintää kaksoisnapsauttamalla, vaan avaa lukuruutu ja lue merkinnän sisältö (tai vastaavasti yhteystiedon, tehtävän tai muistilapun sisältö).



Jorma Järvinen, seniorikonsultti

Jorma kouluttaa Tieturilla mm. Microsoft Office -aluetta, ja on pitkän linjan ammattilainen tässä(kin) asiassa.

6. marraskuuta 2017

Lär Excel förstå svenska

Till äran av Svenska dagen ska vi lära ditt Excel program att förstå svenska (eller något annat språk). En del av Excel användare i Finland har säkert i regionala inställningar finska. Det här påverkar t.ex. hur Excel skapar serier.

Klicka i någon cell i Excel, skriv marraskuu (eller förkortad marras), dra i fyllningshandtaget åt höger eller ner (eller vänster eller upp om du har utrymme och inte skrev månaden i första cellen). När du drar utvidgar Excel serien med joulukuu, tammikuu o.s.v. oberoende av användargränssnittets språk som du kan t.ex. på engelska.

Du kan skapa egna serier (Excel kallar dom anpassade listor | Custom List) t.ex. produktlistor o.s.v. som du behöver dagligen. I stället för att alltid skriva dom om och om skapa dom i serier. Importera svenska och engelska månader och veckodagar så här.

Kopiera först här under de färdigt skrivna listorna till Excel på något tomt kalkylblad.


JanuariJanMåndagMånJanuaryJanMondayMon
FebruariFebTisdagTisFebruaryFebTuesdayTues
MarsMarOnsdagOnsMarchMarWednesdayWed
AprilAprTorsdagTorAprilAprThursdayThu
MajMajFredagFreMayMayFridayFri
JuniJunLördagLörJuneJunSaturdaySat
JuliJulSöndagSönJulyJulSundaySun
AugustiAugAugustAug
SeptemberSepSeptemberSep
OktoberOktOctoberOct
NovemberNovNovemberNov
DecemberDecDecemberDec

TammikuuTammiMaanantaiMa
HelmikuuHelmiTiistaiTi
MaaliskuuMaalisKeskiviikkoKe
HuhtikuuHuhtiTorstaiTo
ToukokuuToukoPerjantaiPe
KesäkuuKesäLauantaiLa
HeinäkuuHeinäSunnuntaiSu
ElokuuElo
SyyskuuSyys
LokakuuLoka
MarraskuuMarras
JoulukuuJoulu

Klicka sedan Tiedosto-Asetukset-Lisäasetukset | Arkiv-Alternativ-Avancerat | File-Options-Advanced och rulla ned till rubriken (med grå bakgrund) Yleiset | Allmänt | General och klicka där Muokkaa omia luetteloita… | Redigera anpassade listor… | Edit Custom Lists… Klicka sedan på pilen vänster om ordet Tuo | Importera | Import (dialogrutan krymper) och markera (välj) i kalkylbladet en lista i gången t.ex. svenska månaderna, klicka på pilen igen (dialogrutan förstoras) och det markerade områdets cellreferens visas i textrutan vänster on pilen. Klicka på Tuo | Importera | Import.

Gör det här på nytt med följande lista (t.ex. svenska veckodagar) tills du har alla listorna importerade. Stäng dialogrutan med OK.





Om du vill skapa andra egna listor kan du också importera dom (bara de finns färdigt i kalkylbladet) eller klicka på UUSI LUETTELO | NY LISTA | NEW LIST och skriv listan i högra rutan en post per rad, tryck Enter efter varje post så att de är på skilda rader och till sist Lisää | Lägg till | Add.

Testa listorna i Excel. Skriv något ord av de listorna du importerade (t.ex. november) och dra i fyllningshandtaget. Ordet november (också andra månader) finns i både svenskan och engelskan (och i tyskan) så Excel tycks utvidga den lista som är senast importerad. Notera också att skriva första ordet i serien med VERSALER eller gemena eller bara Första Bokstaven Med Stort påverkar listans utseende.






Jorma Järvinen, senior konsult

Jorma kör Excel kurser hos oss på Tieturi.

3. marraskuuta 2017

Mitä jos tiimityön keskipiste ei olekaan enää SharePoint?

Office 365 -alusta on mullistanut sen, mihin työpaikat ovat satsanneet vuosikausia aikaa ja rahaa: työ on haluttu siirtää pois verkkolevyiltä SharePoint-työtiloihin. Osa yrityksistä on onnistunut tässä täysin, osa puolittain. Satsaus SharePointiin on kyllä kannattanut. Dokumentit eivät enää ole hukassa ihmisten sähköpostilaatikoissa ja tietokoneen kovalevyllä. Mikä parasta, dokumenteista syntyy automaattiset versiot versiohistoriaan, joten samasta dokumentista ei enää löydy eri nimellä tallennettuja versioita. Vielä parempaa on se, että kaikki asianosaiset voivat muokata samaa dokumenttia yhtä aikaa.

Mutta miksi väitän, ettei SharePoint enää ole tiimityön keskipiste? 


Office 365 alkoi nakertaa työtiloihin keskittynyttä dokumenttienhallintaa jo vuosia sitten, kun käyttöön tuli OneDrive for Business. Konsepti pysyi kuitenkin selkeänä: omat dokumentit OneDriveen, tiimin dokumentit työtilaan.

Isompi muutos tapahtui vuonna 2017, kun Teams tuli mukaan O365-sovelluksiin. Se on antanut mahdollisuuden miettiä tilannetta uusiksi. En väitä, että SharePoint-työtiloista pitäisi luopua, koska selkein dokumenttienhallinta on edelleen työtilamaailmassa, jossa tiimit voivat luokitella dokumentteja metatietosarakkeiden avulla ja luoda tarvitsemansa kirjastot eri käyttöoikeuksilla. Moderneissa O365-työtiloissa dokumenttikirjastojen muokkaus on vieläpä miellyttävän intuitiivista, mikä on pitkän linjan SharePoint-käyttäjille mukava yllätys! Enää ei tarvita päivän pääkäyttäjäkoulutusta, jotta työtilaan osaisi luoda uuden metatietosarakkeen tai näkymän.

Mikä sitten on Teams ja miksi se uhkaa viedä tärkeimmän työkalun manttelin SharePointilta?


Teams on ryhmächat-tyyppinen keskustelutyökalu, joka tarkoitettu työpaikan tiimien ja projektien sisäiseen viestintään. Tiimien keskustelu voidaan sen avulla siirtää pois sähköpostista modernimpaan työkaluun, jossa tiimin viestintä saadaan luokiteltua aiheiden mukaan eri kanaviin. Teams tekee tiimin keskustelusta samalla kertaa avointa mutta helposti suodatettavaa. Kenenkään ei tarvitse seurata keskustelua, joka ei kosketa itseä, mutta siihen on aina tarpeen tullen mahdollisuus. Keskusteluun voi milloin tahansa vetää mukaan henkilön, joka ei tavallisesti seuraa kanavaa mainitsemalla hänet nimeltä, esim. ”tiedätkö sinä tästä @Heidi Selkäinaho”.

Teams sopii keskustelukanavaksi sähköpostia paremmin, kun keskustelunavaus ja siihen tulleet vastaukset niputtuvat mukavaksi nipuksi. Sähköpostilaatikossa 10 vastausta herättänyt keskustelu tarkoittaisi kymmentä erillistä sähköpostia ja kymmentä keskeytystä työpäivään. Teams sopii tiimin keskusteluun paremmin myös siksi, että tiimille syntyy yhteinen keskusteluhistoria, eikä jokaisen käyttäjän tarvitse arkistoida sähköpostejaan erikseen. Etuja on monia.

Parasta Teamsissa on, että se ei ole vain keskustelualusta. Teamsin jokaiseen kanavaan voi lisätä helposti välilehtiä, joissa voidaan näyttää tiimin muita työkaluja kuten Planneriin luodun tehtävälistan ja SharePoint-dokumenttikirjastoja. SharePointin saa siis luontevasti Teams-keskustelujen rinnalle. Toisinpäin sama ei ole mahdollista, eli Teams-keskusteluja ei voi näyttää SharePoint-työtilassa.

Koska tiimityö on enimmäkseen keskustelua ja toissijaisesti dokumenttien ja tehtävien hallintaa, Teams on tällä hetkellä ehdottomasti paras keskipiste tiimityölle työpaikoilla, joissa on käytössä O365. Teamsin kautta tiimit voivat myös aloittaa nopeasti Online-kokouksia tai privaatteja chat-keskusteluja tiimin jäsenten kanssa. Tulevaisuudessa Teamsin Online-kokoukset ja chat-toiminto yhdistyvät Skype for Businekseen, joten Teamsia ajetaan Microsoftinkin puolelta kaiken tiimityön keskipisteeksi.

Taustalla SharePoint pitää edelleen pintansa parhaana paikkana tiimien dokumenttien hallintaan. Yksittäisen tiimin jäsenen ei silti välttämättä tarvitse pomppia Teamsin ja SharePointin välillä, vaan hän voi muokata ja lukea dokumentteja Teamsin kautta. Riittää, että tiimin pääkäyttäjä luo tarvittavat dokumenttikirjastot SharePointiin ja tuo ne Teamsin välilehdille näkyville.

Teams-pohjainen työskentely on miestäni suositeltavin malli tiimityöhön, mutta toki joustava O365 tarjoaa myös muita vaihtoehtoja. Erilaisia malleja esittelen Tieturin koulutuksessa Office 365 tiimityössä 16.11.2017 ja 31.1.2018. Tervetuloa mukaan pohtimaan, mikä malli sopisi parhaiten teidän työpaikallenne!


Heidi Selkäinaho, työyhteisöviestinnän konsulti, Somepoint Oy

Heidi kouluttaa Tieturilla Office 365 tiimityössä -kurssiamme.  Heidi opastaa yrityksensä Somepoint Oy:n kautta  työpaikkoja uudenlaisen työn tekemisen ja työyhteisöviestinnän tapoihin. Hänellä on pitkä kokemus SharePointista ja Office 365:stä työskenneltyään edelliset 7 vuotta SharePoint-intranet-konsulttina.






31. lokakuuta 2017

Continuous Requirements Engineering part 2/2

This is the second part of a two part blog by Bogdan Bereza. Read the first part here >

Test analysis helps the requirements process

Testers have complained for a long time that testing starts too late in projects. It is much more than just a testing problem, though, because it means, that huge potential, which test analysis and design have for radically improving requirements, is not used.

Asking uncomfortable question


By asking uncomfortable questions, which testers should remember to do even after midnight , unless they want to be co-dependent , even high-level, vision-related requirements can sometimes be contested. “Why on earth would anyone ever want to do this?” – an exasperated tester may ask and, being the first person to really use an implemented system, discover that some assumed system goals are impossible and wrong.

Re-defining stakeholders


Test execution – as our exploratory colleagues often righty stress – is a perfect opportunity for designing more test cases. This of course entails asking many “what if” questions. What if an unauthorized person gains access to this data? What if the receiving system is down? What is an infant presses this button not once, but many times? Both test design and test execution – including test result evaluation – provide ample opportunities for discoveries, for re-defining stakeholders, system and system context boundaries.

Exploratory requirements elicitation


What is misleadingly called "exploratory testing", is really exploratory requirements engineering plus requirements-based testing.

Crazy idea? Not at all. Initially, exploratory testing was invented to cope with situation where requirements were poor, or missing altogether. The main techniques promoted by exploratory testing are creative guesswork concerning what the tested software should do, finding out stakeholders’ real priorities, finding quality attributes most important in a given context, where testing takes place. It is requirements elicitation on the fly, followed by a fast analysis in order to do best testing possible – isn’t it?

Well, it is. Exploratory approach is really great, when there are no requirements, or they are not trustworthy, or not complete.

The clinching evidence is HTSM (Heuristic Test Strategy Model), created by James Bach to help exploratory testers choose the right strategy fast and correctly. Like its more comprehensive predecessors, ISO 9126, FURPS and ISO/IEC 25010:2011, HTSM is first of all a list of quality attributes – or requirements types - to be taken into account. Of course, this is necessary, for an exploratory requirements process.

Discovering forgotten requirements


Designing test cases, additional “what if?” questions are asked. To some of them, there is no answer ready – you have to go and ask someone. This is a very powerful motive for finding more requirements. For psychological, technical and social reasons, such stubborn asking and questioning comes naturally while preparing tests, but can be judged pushy and somehow illicit in the early stages of requirements elicitation. It is therefore obvious that test analysis and test case design should be done simultaneously with requirements work, not later nor much later, which is still common in IT projects.

Requirements analysis, modelling and breakdown


Requirements elicitation, analysis, modelling and specification are not four distinct process stages, performed sequentially, but rather four small steps, performed many times on the way from some mumbled stakeholder’s comment to the final, well-formulated, validated and accepted full-fledged requirement. Even in sequential development, requirements engineering is iterative. You hear some vague statement, you put it down hastily, go back home, give it a thought, draw a simple picture of what you think it means, go back to the stakeholder, or to another stakeholder, to ask again, many times, until you are really sure. This may include prototyping, or any other form of iterative/agile activity. An important element of this process is formulating your thinking along the following lines: do you really understand what the stakeholder means? How can you check that the implemented system fulfils this requirement?

Controlling requirement’s testability is the single most important criterion for breakdown process: if you do not know how to test it, you need to break it down further.

Requirements verification and consolidation


To verify and validate systems, you test them (dynamic testing). You do not want to test too much, because it costs time and money, but you are not willing to risk testing too little, because it increases the risk of failures in operation. To be able to test as little as possible without risking too many and too serious failures, you need to build systems from good requirements, following a reliable development process.

Whatever the right amount of testing, you do not want many bugs – whether caused by wrong requirements or by implementation mistakes - to make their way to testing, because removing them after testing is more expensive, often much more expensive, then avoiding them or finding them in requirements stage (yes, this is Boehm’s curve).
When building a bridge, you prefer finding bugs in its blueprint, to crashing the whole reinforced concrete construction during load test a week before admitting traffic to it. The same applies to software.

That means, testing requirements is the most effective way of both not needing to test the system build from them too much, and not having too many bugs in it, either.
Professional testers, who have special testing skills, should be involved in requirements verification just as they are involved in dynamic testing. It is today generally accepted that testers help programmers test software, so consequently, it is time to promote the idea that testers should help requirement engineers test requirements.

Designing test cases from requirements (the test cases to be used in the future, during dynamic system test), the design process itself is a very effective way of testing requirements. In other words: designing dynamic tests from requirements is a great way to perform static requirements testing. Increasing the amount of time spent on testing requirements, you decrease the time required for system testing, which is – up to some level – an extremely profitable deal.

Through testing towards new requirements


Whether you work iteratively or sequentially, development projects are just steps in IT product’s lifecycle, which is always iterative and incremental, whether you have chosen this or not. Market research, and operational monitoring and maintenance are main sources of new business ideas and therefore new requirements; testing is the second main source. Testing generates a lot of new ideas and improvement suggestions, which are often wasted, unless you treat testing as requirements elicitation for the next project, and find ways to gather new ideas and use them later.

Requirements engineering is not a project phase, but a never-ending lifecycle activity, and the activities traditionally classified as testing really belong to it.

Bogdan Bereza

Book your course on one of Bogdan's courses!

26. lokakuuta 2017

Liitteet helposti sähköpostiin Microsoft Outlook 2016 -versiossa


Outlookin 2016-versiossa liitteiden lisääminen sähköpostiviestiin on tehty äärimmäisen helpoksi. Nyt Liitä tiedosto -painikkeen alta löytyvät valmiiksi kaikki ne tiedostot, joita olet käsitellyt hetki sitten. Liitä tiedosto -painike löytyy sähköpostiviestiä laatiessasi sekä Viesti- että Lisää-välilehdiltä.








Kun napsautat Liitä tiedosto -painiketta, saat näkyviin listan viimeisimmistä käyttämistäsi tiedostoista. Listassa näkyvät kaikki tiedostot, riippumatta siitä, mihin ne on tallennettu.
















Jos olet tallentanut tiedoston yhteiseen pilvipalveluun tai vaihtoehtoisesti omalle OneDrivellesi, tarjoaa Outlook mahdollisuutta liittää tiedosto linkkinä tai kopiona. Pääset valitsemaan liittämistavan tiedoston nimeä napsautettuasi.


Näistä toki huomattavasti järkevämpi vaihtoehto on jakaa linkki. Näin vastaanottajilla on aina käytössään viimeisin versio tiedostosta, ja tehdyt muutokset ovat saman tien myös muiden viestin saajien näkyvillä.


(Toinen tarina onkin sitten, onko töissä oikeastaan mitään tiedostoja, jotka kuuluvat OneDriveen jaettavaksi, vai kuuluuko kaikki johonkin yhteiseen paikkaan, vaikkapa SharePointin työtiloihin. Siihen toisella kertaa.)








Anna Sahinoja
Tuoteryhmäpäällikkö, ICT

Anna uskoo vankasti, että kiky muodostuu päivittäisessä työssä myös työkalujen hallinnasta.

25. lokakuuta 2017

Tervetuloa Eficode!

Ilolla ilmoitan, että Tieturin asiakkaat pääsevät jatkossa nauttimaan myös Eficoden asiantuntijoiden osaamisesta. Eficode on suomalainen design- ja teknologiayritys, jonka visiona on rakentaa yli 200 asiantuntijan voimin tulevaisuuden ohjelmistokehitystä ja digitaalisia palveluita. Eficodella on toimistot Helsingissä, Tampereella sekä Kööpenhaminassa, Tukholmassa ja Göteborgissa.

Olen itse erityisen innoissani siitä, että saamme näin vahvaa osaamista mukaan jo ennestään vahvaan asiantuntijajoukkoomme. Etsimme jatkuvasti uusia koulutuskumppaneita taataksemme asiakkaillemme parhaat mahdolliset ajantasaiset koulutukset. Eficoden osaaminen on vakuuttavaa, ja yritys on edelläkävijä erityisesti DevOpsin alueella.

Tieturin tavoitteena on varmistaa Suomen vahva IT-osaaminen myös tulevaisuudessa. Tähän missioomme Eficoden asiantuntemus sopii enemmän kuin hyvin. Teimme aluksi Eficoden kanssa yhteistyötä asiakaskohtaisissa koulutuksissa, ja yhteistyön sujuessa päätimme yhdessä laajentaa sitä. Ihan ensimmäiseksi lisäämme valikoimiimme Eficoden erikoisosaamisalueista DevOps-koulutuksia.

Eficoden asiantuntijoita tullaan näkemään myös ohjelmistokehityspuolellamme, ihan ensimmäisenä ensi viikolla (30.10.2017) järjestettävällä Java ohjelmointi -kurssillamme.

Tervetuloa siis mukaan, Eficode!








Anna Sahinoja
Tuoteryhmäpäällikkö, ICT

24. lokakuuta 2017

Osaatko sittenkään johtaa ketteryyttä?

Ketteryyden suosion jatkuminen ja kasvu on tuonut konsultointi- ja valmennusmarkkinoille uusia tuulia. Perinteistä ja vanhaa on yhdistetty. On ketterää projektipäällikköä, ketterää testaajaa, SAFe agististia ja onpa Prince 2:kin mukana. Kanban ja Devops ovat pohjimmiltaan vanhojen Lean-periaatteiden uusia tuotteistuksia. Johtamisessa on vaikea keksiä enää mitään todella uutta, mutta ketterä johtajuus, palveleva johtaja ja valmentava johtajuus ovat olleet ahkerasti esillä.

Myllerryksen keskellä kannattaa palauttaa ydinasiat jälleen mieleen ja ymmärtää, mikä on todella tärkeää ja mikä markkinointiviestintää.

Organisaatiokulttuuri


”Me olemme vain töissä täällä”-asenteella ei menesty vaativassa aivoja vaativassa työssä. Tarvitaan innostusta ja uskoa oman työn mielekkyyteen. Perinteiset organisaatiot halvaantuvat, koska vallankäyttö tuhoaa aloitteellisuuden. Henkilöstö tunnistaa manipuloinnin helposti eivätkä asiakkaat usko kauniiseen markkinointiviestintään.

Sisäinen motivaatio ei ole ihmisen ominaisuus. Se syntyy organisaatiossa, jossa henkilöstö saa toteuttaa omia tavoitteitaan asiakkaiden kanssa. Hierakkisessa byrokratiassa toiminta näivettyy nopeasti. Henkilö, jolle annamme potkut, voikin muuttua tähdeksi kilpailijan palveluksessa.  

Matala organisaatio


Nykypäivän monitaitoiset tiimit pystyvät hoitamaan asiakkaansa ilman moniportaista ja äärimmilleen erikoistunutta hallintoa. Päätökset menevät oikein, kun ne tehdään lähellä asiakasta. Syntyy säästöjä, kun sisäisen työn määrä pienenee olennaisesti.

Erityisesti tuoteomistajarooli on osoittautunut vaikeaksi. Se on haluttu jakaa useammalle eri sidosryhmää edustavalle henkilölle. Tai sitten, tuoteomistajan lisäksi on erillinen projektipäällikkö. Yleistä on myöskin jakaa työ liiketoimintaa edustavalle tuoteomistajalle ja tekniselle tuoteomistajalle. Puhumattakaan vieläkin monimutkaisemmista hallintohimmeleistä. 

Kokeile ensin


Ketteryyteen siirtymisen vaikeus näkyy myös tavassa suunnitella ja rahoittaa muutoshankkeet isoina projekteina. Visiosta ja tiekartasta tulee helposti projektisuunnitelma, jonka pysymistä aikataulussa ja budjetissa valvotaan perinteiseen tapaan. Suunnitteluun käytetään aivan liikaa aikaa ja se tehdään aivan liian aikaisin. Tarkempi suunnittelu ei poista monimutkaisten hankkeiden luontaista epävarmuutta. 

Ketterä tuotekehitys vaiheistuu suunnilleen seuraavasti:

1. Ensimmäinen kokeilu (proof of concept)
2. Sisäinen versio
3. Alfa-versio
4. Beta-versio
5. Ensimmäinen tuotantoversio
6. Seuraavat tuotantoversiot

Jokaisessa vaiheessa kerätään palautetta, jonka pohjalta tehdään päätös mahdollisesta jatkosta ja sen rahoittamisesta. On myös täysin luonnollista, että työtä ei jatketa. 

Uskalla muuttaa suuntaa


Epäonnistu nopeasti (fail fast) on usein kuultu periaate, jonka toteuttaminen on vaikeaa, mm. koska emme tiedä, mitä onnistuminen on. Meillä ei ole siihen mittareita. Hyvä, kun tiedämme, miksi alun perinkään lähdimme hankkeeseen. 

Uponneet kustannukset ja henkinen sitoutuminen hankkeeseen mutkistavat asioita. Kehitystiimien omat kehitysjonot lisäävät niiden henkistä muutosvastarintaa. Täyttä vauhtia liikkuvan junan suunnanmuutos on tunnetusti hankalaa. Julkaisujunan aikataulun ja julkaisun sisällön muuttaminen on vastaavaan tapaan vaikeaa. Ongelmista yleensä kerrotaan vasta pakottavista syistä ts. kun todellinen tuotanto on alkamassa.

DevOps-maailmassa, jossa julkaisuja on useita päivässä, haasteet ovat toisenlaiset. Sielläkin pitää aika ajoin pysähtyä miettimään koko työn järkevyyttä. 

Pentti Virtanen, Tieturi
FT, Certified Scrum Trainer

Tutustu ainakin näihin koulutuksiin:

Ketteryyttä johdolle >>

Ketterä johtajuus - agile leadership >>

Scrum valmennus uusiutuu

Scrum Allianssi on uusimassa valmennuksiaan. Scrumin perusteet irtoavat Certified ScrumMasterista ja Certified Scrum Product Ownerista ja nämä keskittyvät enemmän ko. roolin tehtäviin ja vastuisiin. 

19. lokakuuta 2017

Koulutusta ajan hermolla, asiakas edellä

Tieturi on jo kunnolla aikuinen yritys, olemme olleet olemassa vuodesta 1983 alkaen. Ihan meitä ei vielä keski-ikäiseksi voi kutsua, mutta kiitettävästi on kertynyt ikää jo yrityksenä! Ensi vuonna juhlimme 35-vuotissyntymäpäiviämme.

Jo alusta lähtien olemme olleet vahvasti mukana tukemassa suomalaisten työelämän taitoja. Matkan varrella kehitys on mennyt huimasti eteenpäin, vuosi vuodelta nopeammin. Itse tulin työelämään Tieturin ollessa 12-vuotias, vuonna 1995. Eli ihan yhtä jalkaa en ole valitettavasti päässyt teknistä kehitystä kokemaan. Omissa muistoissani 1995 oli vielä VAX-aikaa, sähköpostikin kulki VAX-meilinä, eivätkä käyttöliittymät aina olleet WYSIWYGiä nähneet.

Kaikkien näiden vuosien ajan Tieturi ja tieturilaiset ovat kulkeneet ajan hermolla, usein aikaansa edellä. Jotta voimme palvella asiakkaitamme niin kuin haluamme, pidämme oman osaamisemme tiukasti tässä ajassa. Laaja kouluttajaverkostomme mahdollistaa syvän osaamisen kaikilla osa-alueilla ja sen ansiosta pystymme tarjoamaan laajan valikoiman ajantasaisia koulutuksia asiakkaillemme.

Niin valmentajamme ja kuin tuotevalikoimastamme vastaavat tuoteryhmäpäällikkömme seuraavat jatkuvasti, mitä uutta tietotekniikassa tapahtuu. Oli sitten kyseessä ohjelmistokehitys, testaus, toimistotyökalut tai muut työntekoa helpottavat tekniikat, voit olla varma siitä, että uusimmat tuulet uivat koulutussisältöihimme. Juuri nyt seuraamme mm. Microsoftin Skype for Busineksen (pikaviestin ja verkkokokousalusta) siirtymistä Microsoftin Teamsiin (keskusteluihin keskittyvä työtila Office 365:ssä). Ihan vielä se ei ole täällä, mutta kohta on – ja valikoimissamme siksi myös ihan kohta. Samoin Java 9 on jo uinut Java-alueen koulutuksiimme.

Olemme olleet täällä ATK-ajoista lähtien, eläneet mukana muutoksessa ja koko matkamme ajan ennen kaikkea kuunnelleet asiakkaidemme tarpeita. Meidän missiomme on taata Suomen asema tietotekniikan kärkimaana. Siitä pidämme huolen vielä ainakin seuraavat 35 vuotta!

Anna Sahinoja
Tuoteryhmäpäällikkö, Tieturi

18. lokakuuta 2017

Architects beware: 60 years since Dartmouth

Originally posted on Infromator's blog by Milan Kratochvil. See the original here >>

Many R&D-intensive industries experienced an initial period of teething troubles, about six decades between their seminal events and their commercial breakthrough, followed by exponential growth. Last summer, 60 years had passed since the 1956 Dartmouth Artificial Intelligence Conference. 


History...

In 1887, Ernst Mach, a physics professor at the Charles University in Prague, established the principles of supersonics and the Mach number relating velocity to the velocity of sound (thus inspiring his faculty successor Albert Einstein’s theory of relativity). Exactly 60 years after, test pilot Chuck Yeager reached the magical speed of Mach 1, breaking the soundbarrier, with the Bell X-1 rocket plane.

From there, Mach numbers skyrocketed to NASA’s Apollo missions, taking humans to the Moon and back. In aerospace, “the sky is the limit” applied to turnover figures as well.

In 1865, the scientific community (including Charles Darwin) missed the importance of Gregor Mendel’s research in Brno into inheritance in plants, but rediscovered Mendel’s Laws in the 20th century. Mendelian genetics and Darwin's natural selection finally merged in the 1930s, as evolutionary biology. Six decades later (1990-2003) the Human Genome Project HGP, the world's largest collaborative biological project so far, sequenced 92% of the human genome.

Genetics became a fast-grower with applications in diagnostics, forensics, archaeology, and more.

…repeats itself…


In 2016 (well, guess how many years after the Dartmouth AI conference) , the accuracy of Machine Learning (ML) systems started to outperform humans in extreme tasks, previously regarded as “out of reach” for AI. Some recent milestones are the games of Go and Poker , the latter by Mach’s and Einstein’s faculty heirs in Prague, and the University of Alberta Computer Poker Research Group in Edmonton.
AI delivers, which attracts brains and funds into the field. With the usual 60 years of teething in mind, we might call this the end of the beginning. AI departments of large US corporations in a variety of industry sectors are hiring AI experts by hundreds.
Yet the technical progress looks less dramatic when compared to the pace of both corporate and social change it catalyzes. A Forrester prediction last fall said 16% of US jobs will be lost to intelligent systems in the near future, and only partly compensated by 9% new jobs created by them (notably, jobs rather different from those that are vanishing).

…with an impact on architectural roles & landscape:


1. Much more IT(A) in Enterprise Architecture
EA will benefit from a stronger technical background. EA roles, architecture groups, and entire corporations who are used to absorbing new technology and have a strong background in IT including AI, have a competitive edge.

2. More tech leadership in management
That’s what built industries such as Scania, ABB, Volvo AB, and their modular configure-to-order tradition (C2O). The current shift in IT is more manageable in cultures with a clear context and clear ideas of what they need forefront tech for. After decades of custom-tailored complex manufacturing, people in these organization can come up with tangible proposals about leveraging for example, BI and CI (customer insight) downstream: in bidding, sales, pricing, assembly planning, flexible automation solutions, or within the product itself, e.g. in autonomous vehicles.

3. Robotics outcompete offshoring
I argued ten years ago that robots and automation offered a more long-term profitable solution. Everybody continued to rush offshore anyway, although the underlying figures weren’t convincing. Now (guess how many years after the Dartmouth AI conference… ) , AI has triggered a U-turn in corporate sentiment. By 2018, the number of manufacturing jobs moving from Sweden is going to equal the number of jobs moving back. The driving force: robotics and automation.

4. Architecture business as usual…
Architects often work with fancy tech within nearly medieval organizations under nearly stone-age governments. AI 2.0 might therefore feel painstaking. Intelligent robots can result in perpetual reorganizations (process innovators Michael Hammer and B. E. Willoch likened them to reshuffling the deck chairs aboard Titanic), and governments in high-tech countries, socialist and conservative alike, can spend billions on “creating very simple jobs” which is like herding cats: the simpler the jobs, the faster they jump (offshore, as some Swedish trade-union economists point out). Not to mention creating not-so-simple robot taxes that can push offshore the industries of an entire country or continent.
Architects aren’t enthusiastic about the mismatch they had to live with for a long time: a surplus of complexity and information, but a shortage of cognition; in data as well as in society…

5. New flavors of Architecture Patterns
For example, the Layered pattern, typical of business systems (UI, business logic, Object-Relational mapping, and DB) has siblings in deep-learning systems with layers of artificial neural networks trained for a key task each: perception (input parsing), pattern recognition, reasoning (pattern classification and selection of steps to take), and either autonomous action (“vehicle brakes on”, for example) or interaction (e.g. voice generation, or calls to other systems).

6. Ever-bigger data versus custom-fit learning strategies
Accurate fast learning from small data has an architectural savings potential, rarely mentioned in the big-data buzz. Two routes can take you there:

a)  pre-trained neural networks off the shelf (nowadays, you find those even in Matlab) to solve a certain category of problems, and ready to be extra-trained just for the “delta” i.e. the specifics of yours. Largely 90+ percent of the precision, at a fraction of the training time and cost.

b) cross-breeds of several AI techniques, as indicated by Poker systems where an innovative adaptation of a well-proven algorithm made DeepStack run quite fast on a laptop, no longer requiring extreme searches running on supercomputers.

7. Auditability, comprehensibility, V&V, reviews by humans
This category of ML challenges would be worth an entire blogsite. The tradeoff between quality (accuracy of output) and auditability (comprehensibility of machine-made internal logic) grew trickier generation by generation of ML technologies.

To cut a long story short, it’s easier to test that the “sub-symbolic” logic works accurately, than to see why or how.
   

Summing up

Neither Enterprise nor IT Architecture is exempt from AI’s impact on business processes and technology. Machine learning affects systems, organizations, and society, from the way an architect can tweak a plain pattern, and up to the way policymakers can get things plain wrong…

Milan Kratochvil
Trainer, senior modelling and architecture consultant. 

Publications:
UML Extra Light (Cambridge University Press) and Growing Modular (Springer),
Advanced UML2 Professional (OCUP cert level 3/3).

IT-arkkitehtuuri koulutukset >

TOGAF -koulutukset >

11. lokakuuta 2017

Continuous Requirements Engineering part 1/2

This is the first part of a two part blog by Bogdan Bereza.

Test cases complement requirements

Test design as requirements elicitation

Test design makes assumptions that complement requirements elicitation (Lu-Tze)
Every test case adds something to the requirement, specified or assumed, from which it is derived. Yes, you’re right: I do mean that all tests are requirements-based, even those called – very misleadingly - “structure-based”, because even those test cases which check single source-code statements, verify conformance with “what should be”, i.e. the requirements.

Let us ponder a simple example. There is a requirement stating that a given function accepts users aged between 20 and 70. A test analyst, using equivalence partitioning, designs the following test cases: 19, 20, 21, 50, 69, 70, 71, then adds some more tests (how would you call this technique?) with age values -1, 0, “hallo, world” and 20.000.000.000.

The tester actually elicits additional requirements, more detailed than the original requirement, defining correct, expected system behaviour for some special values. Test design techniques are therefore generic requirements elicitation methods. For example, equivalence partitioning states that, wherever you have requirements that define intervals, you can automatically add to them more requirements, defining system behaviour on the boundaries and outside the interval.

Another example: a requirements states that all record field values can be edited and changed. Test analyst creates a number of test cases, attempting various combinations of field changes, using a number of different values. The test cases make the initial requirement more detailed, by eliciting – using common sense, business knowledge or test design techniques – detailed examples of the requirement.

In agile scrum, there is a method, which is a very obvious and conspicuous example that test design is actually the continuation of requirements elicitation under another name: specification by example.

A requirement, specified as a user story, is described more in detail using examples (acceptance scenarios, acceptance criteria), which are added to it, and later used as acceptance test cases. Nice, wise and really good. You do not need to use agile scrum to adopt this method: it suits sequential development equally well. And you save much money avoiding expensive and time-consuming requirements tracing tools, since requirements and test cases are together from the start, stored in the same document or tool. 

All this is not only an academic or intellectual curiosity: this is of prime practical importance. The separation - traditional and still prevalent today - of requirements elicitation and test design procedures, makes no sense, because it artificially separates two similar activities, which for all practical purposes belong together. If they were closely connected in projects, and performed in co-operation, system development would be better: more effective and more efficient.

Test design as requirements modelling

I first learned how to model system behaviour using state diagrams not for requirements engineering, but for testing purposes. I needed a framework to help me understand complex system behaviour better than chaotic, wordy requirements spec written in natural language could do. Besides, having a model was handy for designing test cases, for keeping track of my test coverage, and even for having fresh test ideas: a look at my state graph, or a glimpse of empty cells in my state transition matrix, often put my mind into very exploratory, creative state of mind.

However, making this model was not easy: I spent a lot of time developing it, and some more time making sure it was really right. And, uh, I did find some ambiguities in the initial natural-language description. Making the guys who had written it talk to me was not easy, either. You know, they were VIP: business analysts, rubbing their shoulders with CEO and with CIO, and I was just a humble tester. When I discovered their description was not only ambiguous, but downright wrong here and there, my time investment became greater still.

Whose job was I doing then? A tester who goes into debugging is rightly said to spend her or his time doing developer’s job. A tester analysing requirements documents and making models from them, then improving the initial requirements, spends time doing requirements engineer’s job.

I do not mean to say that testers are diligent and good, while requirements engineers are lazy and bad, because this is definitely not the case, nor the issue either. The issue is, a lot of requirements analysis, modelling and verification work is performed for test design purposes, so – like in the previous section – my conclusion is that the separation of these two activities is very wrong and ineffective. Dealing with the same work twice separately, by different people, and often at different time, is wasteful. We should change it and start working together, requirements engineers and testers.

Default requirements

Testing adds a number of universal default, generic requirements to other requirements. We are often not conscious about them. They should not be written down, because they are too many, and too obvious to justify wasting ink and paper on them. For example, imagine there is a requirement, defining that the system must in certain situations display a rose triangle in the upper left-hand corner of the screen. Why would you test it many times, with different data values, instead of just once or a few times? Because what’s actually being tested is the implicit default requirement, which is “and it must work for all such situations, and never is the system allowed to crash”.

Another such implicit, generic requirement, which complements explicit requirements during test execution, is “and nothing else should happen, unless it is really trivial”. If, besides the required rose triangle, sometimes a little yellow dot appears as well, you may choose to ignore it, but if instead of a little, harmless dot you get (mind, the rose triangle is there as well, as it should!) a 2-minutes long film presentation, you may choose to report an incident.

The practical importance if this is again significant. Pretending that all, really all requirements can and should be written down is futile – and wasteful. Knowing that there are many generic, commonly accepted, implicit requirements, used for testing, that are not written, helps you handle them more effectively.

End of part 1/2

Bogdan Bereza

Book your course on one of Bogdan's courses!

29. syyskuuta 2017

Gruppering i Excel

Har du någon gång undrat hur du kan gruppera personer i åldersgrupper i Excel?

Pivot tabellerna ger dig inte tillräcklig flexibilitet i detta. Du måste använda funktioner.
Flesta kommer kanske att tänka på funktionerna ANTAL, ANTAL.OM och ANTAL.OMF (COUNTA, COUNTIF, COUNTIFS).

Det fungerar visserligen. Nedan ett exempel på gruppering.

Utgångsdata



















Åldern i C-kolumnen har beräknats med funktionen DATEDIF enligt följande: =DATEDIF(B3;$B$1;"y")

Jag vill nu räkna hur många personer som ingår i följande åldersgrupper:











Om jag gör det med funktionerna ANTAL.OM och ANTAL.OMF blir villkoren och formlerna följande:








Du kan göra det en aning smartare med FREKVENS -funktionen (FREQUENCY). (Frekvensfunktionen anger hur ofta värden uppträder i en mängd värden).

Uppställningen och formlerna blir följande:









Formeln med FREKVENS-funktionen måste anges som en matris formel. Det vill säga, markera området G3 till G7, skriv formeln =FREKVENS($C$3:$C$12;$F$3:$F$7) tryck Ctrl+Shift+Enter.
I kolumnen F har jag angett gränsvärden för funktionen.

(Du hittar mera information om ifrågavarande funktioner i Excels hjälp).



Boris Isaksson

Boris har arbetat med Excel ända sedan de första versionerna utkom och kör Excel kurser hos oss på Tieturi.

27. syyskuuta 2017

Kuulumisia Microsoft Ignite 2017 -tapahtumasta

Microsoft Ignite on Microsoftin suurin vuotuinen teknologiakonferenssi, joka pidetään tänä vuonna Orlandossa (Florida, USA). Vielä viikkoa ennen tapahtumaa seminaarin toteutuminen oli epävarmaa, koska Irma-hurrikaani oli hetkeä aiemmin iskenyt Floridaan todella raskaasti. Miljoonat ihmiset olivat sen jäljiltä ilman sähköä, vettä ja polttoainetta. Orlando itse säästyi suurilta tuhoilta, mutta antoi tilapäismajoitusapua monille, jotka joutuivat lähtemään kotoaan. Asiat kuitenkin järjestyivät, ja seminaari pääsi alkamaan ajallaan.

Seminaarissa on 24 000 osallistujaa, ja mikäli mukaan lasketaan samaan aikaan täällä pidettävän päättäjien Microsoft Envision 2017 osallistuja on meitä yhteensä yli 30 000. Voit kuvitella, miten 24 000 osallistujaa esimerkiksi lounastaa 1,5 tunnin aikana – melkoinen haaste. Jotain seminaaripaikan mittasuhteista kertoo, että tänään kuljin sisäisellä bussilla konferenssikeskuksen alueella, koska luento oli alueen toisessa päässä. Luentojen valinta on periaatteessa helppoa, koska niitä on seminaarissa yli 1600. Ongelma onkin siinä, että löytää itselleen oikean luennon ja ehtii sinne ajoissa.

Kirjoitan tätä seminaarin toisen päivän aamuna paikallista aikaa, joten jonkinlainen kuva on muodostunut tässä vaiheessa siitä, missä Microsoft, kumppanit ja asiakkaat menevät seuraavan 2-3 vuoden aikana. Mikään yllätys ei liene, että Azure ja Office 365 ovat täällä pääosassa. Merkille pantavaa on, että niihin tulleet uudet ominaisuudet ovat käyttäjäorganisaatioiden kannalta huomattavia parannuksia. Kaikessa täällä näkyy, että pilvi on oleellinen osa tietojärjestelmien kokonaisuutta.

Azuren osalta Microsoft esitteli monia uusia uudistuksia. Teknisesti odotettu uudistus oli Hyper-V virtualisoinnin mahdollistaminen Azuressa. Tietoturvan kannalta Security Centerin laajennukset tuovat Azuren valvonnan ja ylläpidon uudelle tasolle. Azuren hallinnolliset uudistukset mahdollistavat 70 % säästön virtuaalikoneiden hinnoissa ja tuovat mahdollisuuden kustannusten valvontaan

Windows Server 2016 -tuotteesta esiteltiin seuraava build, jossa yksi merkittävä uudistus on mahdollisuus ajaa Linux-ympäristöä Windows Containerissa. Ominaisuus demottiin ensi kertaa kaksi vuotta sitten ja on nyt käytettävissä itse tuotteessa.

Microsoft on monella tavalla avoimempi kuin aiemmin. Tämä näkyy vahvana päätelaitetukena sovelluksissa ja kehitystyökaluissa sekä iOSille että Androidille. En olisi vielä odottanut näkeväni päivää, jossa Linux olisi näin vahvasti näkyvissä tuotteissa ja demoissa – ja sehän on vaan hieno asia.
Ignite 2017 on mielenkiintoinen ikkuna tietotekniikan tulevaisuuteen, jossa mennään yhä enemmän digitalisaation maailmaan. Suomessa oli viikonloppuna poikkeuksellinen helleaalto, mutta täällä helleaalto kestää 365 päivää.

Ignite 2017 terveisin Kari Kuosa

Microsoft Ignite 2017 pidetään 25.-29.9.2017 Floridassa. Löydät tapahtuman keynotet ja muita tapahtuman esityksiä täältä: www.microsoft.com/en-us/ignite

Kari Kuosa kouluttaa Tieturilla Microsoftin Infrastruktuuri -koulutuksia. Löydät ICT infrastruktuuri-koulutuksemme täältä: www.tieturi.fi/koulutukset/ict-infrastruktuuri

Kurkkaa Tieturin GO! -koulutukset: GO! - koulutus alkaa varmasti! >>

22. syyskuuta 2017

Esittelyssä uusi Microsoft Office -kouluttajamme Jorma Järvinen


Tänään olen erityisen iloinen päästessäni esittelemään uuden Microsoft Office -alueesta vastaavan kouluttajamme Jorma Järvisen. Jorma aloitti Tieturilla muutama viikko sitten, syyskuun puolessa välissä. Hän on pitkän linjan koulutusalan ammattilainen, ja olimme hyvin tyytyväisiä hänen valitessaan juuri meidät. 

Jorma on innostava kouluttaja, jonka osaamisalue ulottuu Microsoft Office -tuotteiden ulkopuolellekin. Hän tuntee Excelin kuin omat taskunsa, työstää Word- ja PowerPoint-mallipohjat tarvittaessa, opastaa ja auttaa sisään ohjelmien tehokkaaseen käyttöön. Jorma kouluttaa suomen lisäksi myös englanniksi ja ruotsiksi, ja keskittyy meillä myös blended learning -ratkaisujemme kehittämiseen.

Te, rakkaat asiakkaamme tulette varmasti tapaamaan Jorman jatkossa sekä kuulemaan Jorman vinkkejä Microsoftin Office -ohjelmien käyttöön täällä blogissamme.


Tervetuloa mukaan, Jorma! 

Anna Sahinoja
Tuoteryhmäpäällikkö

19. syyskuuta 2017

Aika on rahaa ja Linux pelastaa


Sanonta 'Aika on rahaa' pitää erityisen hyvin paikkansa, kun yrityksen IP-verkossa ilmenee liiketoimintaa haittaava vika/ongelma, joka on ratkaistava mahdollisimman nopeasti. Mieluiten heti.

Vian havaitsemisen jälkeen se pitää tietenkin ensin paikallistaa, sitten mahdollisesti eristää ja lopuksi vielä korjata. Linuxin verkkotyökalupakki on nykyisin niin laaja, että vian löytämiseen ei kulu suuremmin aikaa, kun oikeat työkalut ovat käden ulottuvilla ja niitä osataan myös käyttää.

ping-komennon vivut

ICMP (Internet Control Message Protocol) -protokollan kaiutusviestit ovat mahdollisesti sinullekin tuttu juttu ping- tai traceroute-komennoista: 'ping www.tieturi.fi' tai 'traceroute www.tieturi.fi'. Nämä komennot kätkevät sisäänsä monia käteviä vipuja, joiden hallitseminen voi nopeuttaa vian löytymistä merkittävästi. Esimerkiksi jos verkon MTU (maximum transmission unit) on konfiguroitu väärin, niin pelkkä 'ping www.tieturi.fi' ei auta, vaan avuksi tarvitaan ping-komennon tarjoamia vipuja: 'ping -c1 -M do -s 8000 www.tieturi.fi'.

nmap työkalu käyttöön

Myös sovellustason ongelmien etsimiseen löytyy monia sopivia työkaluja. Oma ehdoton suosikkini on nmap (Network Mapper). Sitä käytetään usein myös verkon tietoturvaan liittyvissä analyyseissä, kuten palomuurin tutkimisessa. Verkossa olevan palvelimen sovellustason portit voidaan tutkia yksinkertaisesti komennolla 'nmap test.tieturi.fi' tai omassa sisäverkossa NAT:n (network address translation) takana komennolla 'nmap 192.168.0.1'. Kun avuksi otetaan vielä nmap-työkalun vivut ja mahdollisesti tehdään skipti edellä mainittujen työkalujen ympärille, on tuloksena arvokas apu verkko-ongelmien selvitykseen ja korjaukseen.

Ja kaukaa viisas tietenkin automatisoi verkon valvonnan, jotta vika myös havainnoidaan heti kun se ilmenee eikä vasta kun verkon käyttäjän tuska saavuttaa verkon ylläpitäjän.

Aika on rahaa ja Linux pelastaa.

Jani Koski, Datarocks

Jani kouluttaa Tieturilla Linuxin hallintaan liittyviä kursseja Linuxin käyttöönotto ja hallinta sekä Linuxin vaativa hallinta

11. syyskuuta 2017

DevOps on palautteen vahvistamista

DevOps-menetelmiä kehitettäessä kokonaisuuden hallinnan ja systeemiajattelun ohella keskiöön nousee palautteen ja takaisinkytkentöjen (feedback loops) vahvistaminen. Nopeat, ajantasaiset ja valvotut takaisinkytkennät mahdollistavat ohjelmistokehityksen ohjaamisen yksilön, tiimin ja koko organisaation ja tuotteen tasoilla.

Purjehtijana osaan arvostaa autopilottia yli kaiken. Nopeisiin köysimanöövereihin riittää, että ratin kiristää navastaan kiinteään asentoon sillä aikaa, kun pikaisesti justeeraa purjeita. Vene ei ehkä pysy 100 % kurssissaan, mutta kymmeneksi sekunniksi ohjauskäden uskaltaa irrottaa. Jos matkan päällä täytyy tehdä isompia operaatioita sillä välin, kun muu miehistö/naisisto laiskottelee säältä suojasta, kytketään autopilotti. Autopilotti seuraa kurssia kompassia tai GPS:ää käyttäen, ja kun ohjausyksikkö huomaa, että kurssi uhkaa poiketa halutusta, se lähettää peräsimen työyksikölle käskyn muuttaa peräsinkulmaa. Korjauksen jälkeen ohjausyksikkö vertailee tulosta haluttuun, ja tarvittaessa jatkaa pienien säätöjen tekemistä, jopa useita kertoja sekunnissa.

Ohjelmistokehityksen ohjaaminen ilman takaisinkytkentöjä on kuin kiristäisi ratin paikalleen matkan alettua ja toivoisi, että samalla ohjauskulmalla osutaan puolen vuorokauden päästä kohteeseen.

Ohjelmistokehityksen takaisinkytkennät alkavat millisekuntien mittaisista ihmisen ja koneen vuorovaikutustapahtumista ja päättyvät ehkä useiden kuukausien mittaiseen asiakaspalautesykliin. DevOps-asiantuntija osaa tunnistaa mahdolliset takaisinkytkennät ja vahvistaa niitä niin, että sekä yksilö- että tiimitason työssä tekijä saa mahdollisimman nopeasti palautetta työnsä tuloksista. Prosessi lähtee ihan perushygieniasta – työkalujen tulee olla siinä kunnossa, että ruudulle ilmestyy merkki samalla, kun näppäintä painetaan. Käytössä olevan ohjelmistoympäristön olisi hyvä havaita selvät kirjoitusvirheet ja jopa tarjota oikeaa vaihtoehtoa.

Perusasioista edetään sitten laajempiin takaisinkytkentöihin kuten kääntäjän virheviesteihin, yksikkötesteihin, integraatiotesteihin ja niin edelleen. Jokaisella tasolla DevOps-asiantuntija etsii mahdollisuuksia nopeuttaa palautteen saamista, vahvistaa takaisinkytkennän signaalia ja muokata prosessia niin, että palaute on automaattista ja siihen reagointi osa normaalia työn etenemistä.

Samaan aikaan DevOps-asiantuntija osaa myös ottaa huomioon aiemmin keskustellun kokonaiskuvan. Myös palaute ja takaisinkytkennät ovat osa prosessia kokonaisuutena, ja niillä voi olla vaikutus rinnakkaisiin prosesseihin ja muihin toimijoihin. Tästä syystä toiminnan kehittäminen on jatkuvaa tasapainoilua ja joskus myös on tehtävä kompromisseja.

Kuten autopilotitkin, myös ohjelmistokehityksen takaisinkytkennät voivat mennä rikki, tai niiden teho saattaa osoittautua riittämättömäksi. Tästä syystä myös toiminnan kehittäminen tarvitsee omat takaisinkytkentänsä.

DevOps-kurssilla keskustelemme takaisinkytkennöistä käytännön tasolla ja yritämme löytää tapoja tunnistaa hyödyntämätöntä palautetta. Tervetuloa!

Sami Lempinen
Opero

Sami kouluttaa Tieturilla DevOps pähkinänkuoressa >> . 

Tutustu myös näihin:


Kaikki Tieturin DevOps-koulutukset: DevOps-koulutukset >>


23. elokuuta 2017

Viisi tapaa parantaa tiimin viestintää Office 365:n avulla


Väitän, että jokaisen tiimin menestymisen kannalta tärkein asia on viestintä. Yksin tekemiseen verrattuna tiimityön onnistumisen ratkaisee se, miten hyvin tieto kulkee ihmiseltä toiselle ja miten hyvin saadaan hyödynnettyä tiimin yhteistä ajatteluvoimaa ja yhdessä innostumista.

Ei ole samantekevää, millä tavalla viestit kulkevat tiimien sisällä, projekteissa ja hankkeissa. On tärkeää, että viestintä on osa luontevaa työn tekemistä eikä ylimääräinen vaihe. On tärkeää, ettei kenenkään ajattelutyötä keskeytetä turhaan, eikä kenenkään tarvitse seurata hänelle epäolennaista viestintää, jotta arvokasta aikaa säästyy työn tekemiseen. On tärkeää, että määrämuotoinen tieto jaetaan määrämuotoisena.

Tiimityön arkiset viestintäkäytännöt ja kanavat kannattaa sopia jokaisessa tiimissä, hankkeessa ja projektissa yhtä suurella prioriteetilla kuin esimerkiksi tavoitteet ja tehtävät. Jos työpaikallasi on käytössä Office 365, on luonnollista kurkistaa sen suuntaan: miten O365 voisi tukea tiimityötämme?

Käyn seuraavassa läpi viisi parasta tapaa, miten Office 365 tukee viestinnän eri alueita tiimityössä.

1. Työtila tiimin identiteetin luojana

Tiimin identiteetin kannalta on tärkeää, että tiimillä on kotipesä. Office 365:n moderni työtila on visuaalisesti miellyttävä ja aiempia SharePoint-työtiloja helppokäyttöisempi. Työtilan tärkein asia ovat dokumentit, joiden yhteismuokkausmahdollisuus ja automaattinen versiointi ovat välttämättömiä työn sujuvuuden kannalta.

Moderneissa työtiloissa on mahdollista julkaista näyttäviä uutisia, joten tiimi voi halutessaan hyödyntää työtilaa myös tiimin tiedottamiseen sekä tiimin jäsenille että ulkopuolisille.

2. Yhteishenki syntyy päivittäisessä keskustelussa

Pelkkä työtila ei riitä sitomaan porukkaa tiiviisti yhteen. Jos tiimi ei istu koko ajan naamatusten, yhteen hioutumiseen tarvitaan luonteva viestintäkanava.

Tunnetason sitoutuminen tiimin tai projektin tavoitteeseen ja porukan yhteen hioutuminen ei tapahdu aloituspalaverissa kertaluontoisena tapahtumana, vaan syntyy pikkuhiljaa päivittäisen keskustelun kautta. Keskustelukanava kannattaa valita siten, että se aiheuttaa mahdollisimman epätasa-arvoa tiedon saannissa ja vain vähän keskeytyksiä tiimiläisten päivään. Oikeudenmukaisuus, läpinäkyvyys ja vaikutusmahdollisuus ovat työhyvinvointia ja sitoutumista lisääviä tekijöitä ja niihin voidaan vaikuttaa vain onnistuneen viestinnän kautta.

O365 tarjoaa viestintäkanaviksi monta eri vaihtoehtoa: Teams-ryhmächat, Yammer, Skype for Business ja sähköposti. Näistä lisää seuraavassa kohdassa.

3. Työn häiriöttömyyden varmistaminen Teams-chatissä

Miten sitten valitaan oikea kanava tiimin työntekoon? Neuvon unohtamaan sähköpostin kokonaan, koska se ei sovellu keskusteluun alkuunkaan vaan aiheuttaa vain turhia keskeytyksiä jokaiselle tiimin jäsenelle. Skypenkin unohtaisin muutoin paitsi online-kokousten osalta. Skype for Business on nopea tapa kommunikoida, mutta se synnyttää turhia siiloja tiimin jäsenten keskuuteen.

Tiimin keskustelun siirtäisin kokonaan Teams-chattiin, koska se mahdollistaa eri aihepiirien jakamisen omiin kanaviin, jolloin tiimiläiset voivat valikoida vain itselleen tärkeät kanavat. Tarvittaessa voi silti hypätä kanaviin, joita ei seuraa aktiivisesti ja selata myös keskusteluhistoriaa. Tämä luo läpinäkyvyyttä, mutta on kuitenkin samalla levollista viestintää verrattuna sähköpostiin tai vaikkapa nykyisin työelämässäkin suosittuun WhatsAppiin. Teams on käytössä myös puhelimen kautta.

Teamsin avulla ongelmien ratkomisesta ja asioiden eteenpäin viennistä tulee osa työpäivää, eikä kukaan jää yksin pohtimaan asioita liian pitkäksi aikaa. Turhilta kokouksilta vältytään.

4. Viestintä naapuritiimien ja projektien kanssa Yammerissa

Miten sitten kommunikoidaan tiimin ulkopuolisten kanssa? On tärkeää, ettei yksikään yrityksen projekti tai tiimi siiloudu täysin erilleen muista, koska yleensä jokaisella projektilla ja tiimillä on riippuvuuksia muiden kanssa.

Ihannetilassa yrityksessäsi on jalkautettu Yammer koko yrityksen yhteiseksi viestintäkanavaksi ja kaikki käyttävät sitä aktiivisesti. Tällöin jokaisen tiimin on tärkeää pitää aktiivisena ryhmää Yammerissa. Projektipäällikön tai tiiminvetäjän roolina on viestiä aktiivisesti ryhmässä tilannekatsauksia. Ryhmän kautta voi jakaa tiimin työtilassa julkaistuja pidempiä uutisia. Toki myös intranetin uutispalsta toimii tiedottamisessa, jos se on teillä aktiivisempi kuin Yammer.

Yammerin käyttö koko organisaation kanssa kommunikointiin vähentää varmasti projektipäällikön, hankepäällikön tai tiiminvetäjän työtä. Ilman avointa viestintäkanavaa kysymykset ja kommentit kohdistuvat yleensä päällikölle, ja pahimmillaan päällikön koko päivä menee asioiden selvittämiseen. Mikä parasta, Yammer toimii crowdsourcing-alustana, eli tiimin ei tarvitse tyytyä vain omiin ideoihinsa vaan voi käyttää koko yrityksen ajatteluvoimaa, kun suunnitellaan esimerkiksi uutta palvelua tai tuotetta yritykselle.

5. Määrämuotoinen viestintä määrämuotoiseksi 

Osa tiimin viestinnästä vaatii määrämuotoisuutta. Tällaisia asioita ovat ainakin aikataulut, riippuvuudet ja tehtävät. O365-palveluista Planner on luotu tähän tarkoitukseen. Planner on moderni tehtäväpalsta, johon voi luoda luokiteltuja tehtäviä eri tarkoituksiin. Tehtäviä voi nimetä henkilöille, ja kullakin henkilöllä on koottu lista omista tehtävistä. Projektipäällikkö voi seurata tehtävien edistymistä visuaalisista näkymistä.

Tehtävien lisäksi tiimeillä voi olla muutakin määrämuotoista sisältöä. Monet ovat kokeneet hyödylliseksi kokousasioiden käsittelyn luettelomuotoisena työtilassa. Tämä säästää erillisiltä muistioilta ja agendoilta. Työtilaan voi luoda joka tarpeeseen sopivan luettelon datan yhteiseen keräämiseen ja käsittelyyn, ja luettelosta  on helppo luoda erilaisia suodatettuja näkymiä. Mainio korvike excelille, kun työskennellään porukalla saman luettelon kimpussa.

Yhteenvetona voi todeta, että Office 365 tarjoaa tiimeille kaiken sen, mitä moderni tietotyöläinen tarvitsee: ajasta ja paikasta riippumatonta työntekoa, online-kokouksia ja mahdollisuuden hyödyntää koko organisaation voimaa jokaisen tiimin ja projektin päivittäisessä työssä. O365 muuttaa työnteon varmuudella paremmaksi, kunhan uudet työskentelytavat omaksutaan osaksi arkipäivää. Tärkeintä on muistaa, ettei viestintä ole irrallinen osa tiimityötä, vaan se on tiimityön tärkein osa ja ansaitsee tulla suunnitelluksi.

Heidi Selkäinaho, työyhteisöviestinnän konsulti, Somepoint Oy

Heidi on kouluttajana Tieturin kurssilla Office 365 tiimityössä.  Heidi opastaa yrityksensä Somepoint Oy:n kautta  työpaikkoja uudenlaisen työn tekemisen ja työyhteisöviestinnän tapoihin. Hänellä on pitkä kokemus SharePointista ja Office 365:stä työskenneltyään edelliset 7 vuotta SharePoint-intranet-konsulttina.















Suositut tekstit