Arkisto: tammikuu 2010



Yhteisöpalvelut ja testaustyö

26. tammikuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 4

Erilaiset yhteisötyökalut ovat osa nykyaikaista Internetiä. On Facebookia, Twitteriä, Erilaisia Wikejä, Sumplia ja Etherpadia. Valtavat määrät erilaisia ja oikeasti varsin hyödyllisiä työkaluja. Yhteisöpalvelut käyttävät jatkuvasti paremmin hyödykseen menetelmiä, jotka ovat muodostuneet käyttäjäyhteisöiden tarpeista ja niiden ehdoilla. Vain loppukäyttäjän näkökulmasta hyvät ja toimivat ratkaisut jäävät eloon.

Ammattilaisorganisaatioissa kuitenkin käytetään hyvin paljon välineitä, joiden toteutustavat ja menetelmät poikkeavat merkittävästi yhteisöpalveluista. Ammattilaisjärjestelmien pitäisi olla hinnan, monipuolisuuden ja tulosvastuun perusteella merikittävästi harrastejärjestelmiä parempia. Tästä huolimatta uusien tapojen ja tekniikoiden omaksuminen tapahtuu pääasiassa yhteisöpalvelujärjestelmistä ammattilaisjärjestelmiin.

Kuinka usein sinä olet nähnyt esimerkiksi tutkivan testauksen raporttia blogitekstin muodossa tai rss-feediä testitulosraporteista? Milloin viimeksi olet törmännyt testitapausten asiasanalajitteluun tai vaikkapa projektin sisäiseen pikaviestinkanavaan? Onko teillä joskus käytetty koko kehittäjätiimin(yhteisön) mielipidettä virheraporttien vakavuuden arviointiin? Itselläni ei kyllä tule kovin montaa hyvää esimerkkiä mieleen edellä mainituista.

Pienten mutta oikeasti toimivien ratkaisuiden tuominen matkaan ei tietenkään ole helppoa. Se vaatii työkaluilta paljon valmiuksia ja avoimuutta. Kaupalliset sovellukset valitettavasti tarjoavat pelivaraa uusien temppujen kehittelyyn varsin vähän. Mitä kaikkea oikeasti toimivaa ja tehokasta saisikaan aikaan, jos loppukäyttäjälle tarjottaisiin vähän lisää aseita omien työkalujen kustomointiin ja pelikentän paranteluun.

Tietohallintojen strategiat ja ohjeistukset harmillisen usein blokkaavat tai vähintäänkin hidastavat tarpeettomasti hyviä paikkoja parantaa toimintaa. Avoimuus ja toiminnan vapaus veisivät komuunikaatiotakin roimasti eteenpäin.

Tein vuosi takaperin puhelinprojektia, jossa oli mullistavasti otettu Wiki käyttöön projektinsisäisen tiedon jakamisessa. Idea oli hyvä ja innostuin toki itsekin. Kuitenkin ensimmäisen kerran yrittäessäni ediotoida dokumenttia johon itselläni oli testipäällikkönä inputtia, huomasin että käyttöoikeuksia dokumenttien päivittämiseen ei ollut annettu kuin muutamille projektin henkilöille. Jätin siis sivun päivittämättä ja laitoin kaikille mailia aiheesta. Wiki unohtui vähitellen koko projektista kun kukaan ei sitä päivittänyt. Ne kenellä oikeuksia oli eivät ehtineet ja ne kenellä annettavaa olisi ollut eivät voineet. Wikistä tuli työlään käyttöönoton jälkeen käyttäjäoikeuksin rajattu paikka jonne informaatio meni vanhenemaan ja lopulta kuolemaan. Kylläpä kannatti.

Väitän että tässäkin projektissa kontrollista löysääminen ja käyttäjäoikeuksien vapauttaminen olisi nostanut dokumentoinnin ja ryhmätyön tason aivan uudelle tasolle. Suurimmat ongelmat meillä nimittäin tuli lopulta tiedon versionhallinnassa. Vaatimusmäärittelydokumentteja oli useissa formaateissa ja wordifilejen versioissa. Omassa versionhallintajärjestelmässä oli yksi kopio ja loppuasiakkaan järjestelmässä toinen kopio. Lisäksi sähköpostissa läheteltiin kolmansia kopioita katselmointia varten. Ne eivät koskaan olleet synkassa. Työaikaa haaskaantui versiohistorioiden kiinni juoksemiseen ja dokumenttien vertailuun kohtuuttomia määriä. Ei ollut kivaa mutta kyllä siitä jotain jäi käteenkin.

Ensikerralla kannattaa luottaa omiin asiantuntijoihin enemmän. Laajentaa tiimin oikeuksia informaatioon ja sen muokkaamiseen. Kehittäjäyhteisön älykkyys ja sosiaalisen verkoston tukeminen vähentää paitsi inhimillisten virheiden riskiä, myös tarpeetonta dokumentaatiokuormaa, aikaa ja hermoja.


Osto-osaamisen tärkeydestä

18. tammikuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 2

Osto-osaaminen on tärkeää. Kun ohjelmistoratkaisuja ostetaan on oltava asiantuntemusta asettaa vaatimukset oikein, arvioida tarjotun järjestelmän ominaisuuksia ja ostopäätöksen jälkeen toimitetun järjestelmän laatua. Ja tietysti hintaa suhteessa näihin.

Julkisella sektorilla kilpailutus toimii erinomaisesti. Järjestelmäratkaisuille asetetaan vaatimukset, niiden perusteella seulotaan tarjoajista parhaat ja valitaan halvin. Homma toimii ja ongelmia ei ole… Eihän?

Professori Matti Pohjola on eri mieltä:

Pallo on täysin hukassa

Eri hallintoalat tuottavat omat tietotekniikkapalvelunsa, kun valtiolle riittäisi yksi Googlen kaltainen palvelukeskus. Näin saataisiin tietotekniikan mittakaavaedut hyödynnettyä.

Mielestäni tässä on nimenomaan kyse vääränlaisesta vaatimustenasettelusta.

Maailmalta löytyy kasa tekstinkäsittelyohjelmia. On Word, OpenOffice, Google Docs ja muutama muu. Tietokoneita lienee lähes 1,5 miljardia. Jokaiselle tekstinkäsittelyohjelmalle pitäisi siis löytyä varsin asiallinen markkinaosuus kappalemäärissä mitattuna vaikka aivan jokaisessa koneessa ei tekstiä käsitelläkään.

Sitten Suomeen. Suomessa kunnilla ja lääkäripalveluita tarjoavilla yrityksillä on erilaisia potilastietojärjestelmiä lähes saman verran kuin tekstinkäsittelyohjelmia koko maailmassa. Effica, Pegasos ja Uranus vain muutamia mainitakseni. No huhhuh.

Potilastietojärjestelmien käyttäjäkunta on tasan kansallinen terveydenhuollon väkimäärä. Järjestelmät eivät tietenkään keskustele keskenään ja hankintavaiheen jälkeen jatkokehityshankkeita on mahdotonta kilpailuttaa. Järjestelmien rajapinnathan ovat suljettuja. Lisäksi järjestelmätoimituksissa on lyhyt huomautusaika ja tämän jälkeen löytyvät virheet korjataa tuntitaksalla.

Eikö olisi ollut järkevämpää heti hankintavaiheen alussa määritellä vaatimuksiin muutama lisäpykälä ja huolehtia että ne täyttyvät. Eikö voisi vaatia että rajapinnat ovat avoimet ja että rajapintakuvaukset jäävät työn tilaajalle. Jos toimittajia ei löydy, niputetaan usemman kunnan ja yrityksen vaatimukset yhteen. Kun potti kasvaa, niin kyllä ne tekijät löytyvät.

Panosta osto-osaamiseen. Huolehdi että tiimistäsi löytyy ainakin teknologia-, testaus- ja  talousammattilaiset. Jos oma kompetenssi ei riitä, pyydä ammattilaista apuun.

Kenen työtä kannattaa tehostaa?

11. tammikuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 7

Talouselämän ”Minä Väitän” osastolla NSN:n johtajat puivat Suomen kilpailukykyä. Avainsanana tässäkin tapauksessa komeili tuottavuus. Teksissään Ilkka Lakaniemi ja Anne Larilahti nimittäin väittävät että suomalaisten yritysten kyvyssä ottaa käyttöön ja hyödyntää tietotekniikkaan on vielä paljon tekemistä.

Olen heidän kanssaan samaa mieltä. Uskallan jopa väittää että usein päätökset pitäytyä vanhoissa menetelmissä tai työkaluissa syntyvät mukavuuden halusta. Toiminnan kehittämishankkeiden ja järjestelmämuutosten lykkäämistä tai hylkäämistä on helppoa perustella vaikkapa taloudellisilla näkökohdilla, mutta väitän että todellisuus on toinen.

Muutos on työlästä, muutoksesta aiheutuu riskejä ja joku kantaa myös vastuun. Oikeastaan vastuukaan ei ole sitä suurinta herkkua. Kaikkein mukavinta olisi pysyä tutulla ja turvallisella maaperällä. Mukavuusalueella. Onhan se toiminut tähänkin asti ! ?

Entäpä sitten kun uskallus ja innostus on lopulta saatukin riittämään muutokseen? Uusi tietotekninen ratkaisu on valittu työskentelyn tehostajaksi ja on käyttöönoton aika. Käyttäjiä alkaa ahdistaa ja muutosvastarintaan käydään ennen kuin työkalut ovat edes koulutusvaiheessa. Johdon esittelemät muutokset aiheuttavat lähes poikkeuksetta vastareaktoita henkilöstön keskuudessa. Mistä tämä johtuu?

Lakaniemi ja Larilahti esittivät että olisi tärkeää hankkia valmiuksia teknologian käytön laajentamiseen yritysten sisällä.

Tämän tulisi tapahtua niin, että tietotekniikka tehostaa koko henkilöstön toimintaa, ei pelkästään johdon tai tiettyjen asiantuntijaryhmien.

Johtuisiko vastarinta siis tottumuksesta? Työntekijä on tottunut siihen että tietotekniikka ei tehostakaan oman pelikentän toimintaa vaan se saattaa jopa työllistää lisää. Valitettavasti useimpien työkalu-uudistusten voittajana selviää ainoastaan johtaja joka saa kätevät raportit ja hyvät seurantatyökalut. Ratkaisun myyjä (*) on siis tehnyt työnsä hyvin kohderyhmässä. Tässäpä siis haaste:

Uskalla vaatia enemmän kun ensi kerralla käynnistätte toiminnan tehostamishankkeen! Vaadi ensimmäisenä että valitsemasi ratkaisu oikeasti tehostaa koko käyttäjäkunnan työskentelyä. Lopulta huomaat että myös muutosvastarinta vähenee ja organisaatiosi uskaltaa opetella uutta.

(*) Myyjällä tarkoitetaan tässä tapauksessa sitä tahoa joka on onnistuneesti ajanut uuden ratkaisun käyttöönottopäätöksen läpi. Ajatuksen myyjä voi siis tulla myös organisaatiosi sisältä.

Kimppakyydissä

4. tammikuuta, 2010 | Kirjoittaja: Jussi Niittyviita
Kommentit: 4

Minkälaisella autolla ajat? Pidätkö siitä, että ohjaamossa on ainoastaan polkimet, vaihdekeppi ja ratti vai vaaditko elektronisia ajotietokoneita ja hilavitkuttimia joka lähtöön? Oletko ihminen, jolle auto on ainoastaan keino päästä paikasta A paikkaan B vai onko autosi sinulle mukavuustekijä?

Kuvitellaanpa tilanne, jossa autoon ahtautuu kokonainen testaustiimi. Suurena herrana testimanageri istuu ensimmäisenä ohjaajan pallille, jonka jälkeen pienet testaajat sulloutuvat muille vapaille paikoille. Tilanne on tukala. Liikkuminen tuottaa yllättäviä vaikeuksia ja viime hetkellä havaitaan, että autossa ei ole edes turvavöitä ja ainoa turvallisuustekijä äkkipysähdyksen varalle on muutamaan otteeseen uusitut airbagit kuskin paikalla. Sekalainen porukka lähtee liikkeelle jo ennen kuin viimeinen ovi saadaan edes kiinni. Kuulostaako tilanne tutulta projektielämästä?

Selvennyksenä tähän väliin, tässä tekstissä vertaan edellisten kappaleiden perusteella testauksenhallintatyökalua geneeriseen autoon painottaen peruslaatukriteereihin. Kimppakyyti voi siis alkaa.

Ensimmäisenä autoon istuessa on tärkeätä löytää sopiva ajoasento sekä kuljettajalle että matkustajille. Autossa on siis oltava tilaa liikkua ja penkkien on oltava säädettävissä jokaisen ruumiinrakenteelle sopivaksi. Tämä heijastuu testauksenhallintatyökalun käytössä perustestaajan mahdollisuuksiin vaikuttaa testauksen etenemiseen. Harmillisen monesti työkalun käyttöoikeudet ovat rajoitettu execute-tasolle, jolloin pieni testaaja ei voi kuin istua paikallaan kädet kahlittuna käsinojiin (mikäli niitä mukavuutena on autoon lisätty) ja päätyä tasan sinne minne testimanageri ajaa. Perillä kahleita irrotettaessa todetaan, että testaajan oma-aloitteisuus ei ollut toivottua tasoa. Kehitystä on siis tapahduttava.

Palataan kuitenkin ajassa takaisin matkan päälle. Automatkassa kiistämättä tärkein asia on nähdä mihin ollaan menossa. Tämä seikka on hyvin löyhästi riippuvainen käytetystä testauksenhallintatyökalusta. Tärkeämpää työkalun kannalta on nähdä taustapeileistä millaista jälkeä maantiellä auton takana on. Näkyykö verissäpäin makaavia jalankulkijoita ja hollywoodista tuttuja räjähdyksiä vai normaaliin tapaan eteenpäin soljuvaa liikennettä? Tästä saadusta informaatiosta kuljettajan paikalla istuva testimanageri voi päätellä jo pitkälle ovatko hänen hätäpäissään tekemänsä ratkaisut olleet matkan etenemisen kannalta järkeviä samalla kun takapenkiltä kuuluu jatkuvaa narinaa ”Ollaanko jo perillä? Kauanko vielä? Missä mennään?”. Ihannetilanteessa kaikkien matkustajien ikkunan vieressä on omat taustapeilinsä, joista he näkevät sen pienen osan tilanteesta joihin heillä on ollut mahdollisuus vaikuttaa, ja ehkä vielä enemmänkin.

Matkaan kuuluu luonnollisesti myös kyytiläisten mukaan hakeminen. Näin ollen perusoletuksena heillekin täytyy olla tilaa. Projektimanageri soittaa kuljettajalle kesken matkan tarvitsevansa kyytiä paikasta A paikkaan B. Hänelle täytyy luonnollisesti olla paikka varattuna etupenkiltä siten, ettei hän herrasmiehenä joudu katselemaan nahistelevaa testaajalaumaa takapenkillä, vaan näkee selkeästi mistä tullaan ja mihin mennään. Kyyti onnistuu hyvin kun testauksenhallintatyökalusta löytyy tarvittavat tiedot ilman suurempia tuskallisia oikeusprosesseja. Projektimanaageri poistuu kyydistä hymyssä suin ja kiittää kauniista näköalareitistä. Tällainen ominaisuus on työkalun käytössä harvinaista herkkua.

Yhtenä tekijänä autojen hankinnassa arvostetaan niiden ympäristöystävällisyyttä. Eihän kukaan tee työkalullakaan mitään jos se saastuttaa ja tuhoaa ympäristöään. Tämä on melkoisen kärjistetysti sanottu, mutta kyseisenlaisia työkaluja todellakin on olemassa. Jopa suurista alaa hallitsevista nimistä löytyy sellaisia työkaluja, joiden käyttöä kartetaan mahdollisimman pitkään koska ne hidastavat testausprosessia ja tekevät työnteosta kaikkea muuta kuin mielekkään. Ympäristöystävällisyyden kannalta on otettava huomioon myös polttoaineenkulutus. Hankintavaiheessa jokaisen auton ja testauksenhallintatyökalun maksaminen kirpaisee, mutta ensishokin jälkeen 3,5l/100km dieseliä juova mukavan rennosti pörräävä auto on niiden kaikkien kymmenien tai satojen tuhansien kilometrien jälkeen kannattavalta tuntuva hankinta. Tämän huomaa myös testimanageri kuljettajan penkillä ajotietokoneen kattavia valikkoja selatessaan.

Millä saataisiin autosta sitten juuri sellainen kuin halutaan? Auton varustelu on monelle omistajalle tärkeä tekijä matkustusmukavuuden kannalta. Samalla tavalla kuin autosta on valittavissa perus- ja lisävarusteet myös testauksenhallintatyökalu voi olla räätälöitävissä tarkoitukseen sopivaksi.

Miksi työkalun pitäisi ohjata testausprosessi tietyille raiteille, kun työkalun voi myös ohjata testausprosessin raiteille?