Yhteisöpalvelut ja testaustyö

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.