5 tapaa ajaa äppiprojekti metsään

1. Ostat vain tiimin resursseja / osaajia

Sinulla on tarve ohjelmistokehitykselle ja haluat ostaa projektin toteutuksen. Joten haluat tehdä sen niin kuin aina on tehty. Pitää löytää ohjelmistoyritys, jolta löytyy projektipäällikkö ja sopivan kokoinen lauma koodaajia. Toisaalla sinulla on mainostoimisto, joka tuottaa graafista materiaalia. Olet tehnyt itse sovelluksesta kuvauksen ja mahdollisesti ostanut jo käyttöliittymäsuunnittelun ja nyt etsit vain sopivaa toteuttajaa, joka kasaa sovelluksen pystyyn. Ei näin.Varsinkin, jos olet Startup-yrittäjä tai teet jonkinlaista ReStartup -projektia isomman yrityksen sisällä, niin todennäköisesti sinulla on kovastikin seuraavanlaisia rajoitteita:

• Budjetti

• Aikataulu

• Tavoite

• Toiminnallisuudet

Siinä missä ostettu tiimi keskittyy näistä asioita kolmeen, niin mielestäni oikea tapa on keskittyä yhteen. Ja se on TAVOITE. Tavoite todennäköisesti summaa jollain tavalla kaikki muut rajoitteet, mutta mikäli tavoite ei ole selkeästi tiedossa valitulla toimittajalla ja keskitytään vain budjettiin, toiminnallisuuksiin ja aikatauluun, niin todennäköisesti vähintään yksi näistä menee pieleen ja näin projektin tavoitekin jää saavuttamatta. Sen sijaan, tiimi, joka tietää tavoitteen (sekä tietenkin budjetin, aikataulun ja halutut toiminnallisuudet) pystyy keskittymään siihen, että yhteinen tavoite projektille on se, johon on PAKKO PÄÄSTÄ. Tällöin tavoitteen ympärille saadaan aikaan keskustelu, jonka kautta voidaan yhteisymmärryksessä säätää kolmea muuta tekijää niin, että projekti voidaan katsoa onnistuneeksi ja sen päälle voidaan alkaa rakentaa (liike-)toimintaa.

2. Et kerro kaikkea

Luottamuspula tai "eihän tämä nyt liity tähän projektiin millään tavalla" on yksiä suurimpia kiistan- ja ongelmanaiheuttajia projekteissa. Otetaan esimerkkeinä vaikka aikataulu- ja budjetti.

Aikataulu

Olet kertonut softakumppanille, että sovelluksen pitäisi olla valmiina tammikuussa 2020. Mutta se, mitä jätät kertomatta on se, että helmikuun 2. päivä on alkamassa kansainväliset messut, joissa sovelluksen tulisi olla yksi vetonauloista osana uutta tuotelanseerausta. Tiimi ei tiedä asiasta mitään ja mahdollisesti epäselvästä viestinnästä tai sairaspoissaoloista johtuen projektin priorisointi painottuu enemmän toiminnallisuuksiin ja budjettiin.Näissä tapauksissa projektissa viestinnästä alkaa tulla tulehtunutta ja ehkä hakataan jopa nyrkkiä pöytään ja ollaan tyytymättömiä. Samaan aikaan tiimi on ihmeissään, koska projektin sisältö ja budjetti ovat erittäin hyvin hallinnassa. Lopulta palaverin jälkeisellä lounaalla yhdessä tiiminvetäjän kanssa tulee puheeksi, että "niin kun nämä messutkin on viikon päästä ja ei tästä nyt tule mitään.."Joten: Kerro mielummin liikaa kuin liian vähän. Ja jos se hirvittää, niin salassapitosopimuksia luodaan juuri sitä varten, että kaikkein sensitiivisin tieto on varmasti turvassa ja sen voi avata huoletta kumppanille.

Budjetti

Rahasta on tyypillisesti vaikea puhua, varsinkin jos ne ovat kyseessä on on rahaa tai yritys, jonka varoja käytät, on vastuullasi. Projektissa voi olla ikävää keskustella siitä, että homma pyörii vahvasti sijoittajien tai esim. julkisen rahoittajan tuella ja projektin tietyt vaiheet sekä onnistumiset ovat kriteereinä lisärahoitukselle tai maksatuksille.Usko tai älä, voin väittää, että minulla on kokemusta lähes kaikista näistä keisseistä ja ymmärrän erittäin hyvin tilanteen, jossa esim. ELY-keskuksen tai Business Finlandin maksatukset ovat myöhässä. Mutta se, mikä alkaa hiertään minua ja toisaalta myös projektia on se, että tehdystä työstä ei tule maksua ja selittely alkaa siinä kohtaa, kun ollaan jo parin laskun verran myöhässä.Älä siis pidä projektin budjettia tai rahoitusta myöskään salassa, koska hyvältä kumppanilta löytyy varmasti ymmärrystä ja myös neuvoja. Esim. projektin toiminnallisuuksista voidaan valita ensin ne, jotka vaikuttavat eniten rahoituksen jatkumiseen tai käyttäjien saamiseen sovellukseen.Mutta muista myös se, että harvalla softafirmalla on varaa toimia kenenkään pankkina.

3. Julkaisukammo

Uskomusteni mukaan kirjailijoilla on usein sellainen olo, että kirja ei ole koskaan valmis. Samaa asennetta löytyy myös sovellusten tilaajilta, aina pitäisi vähän viilata jotain pikseliä tai "ei tätä voi ainakaan ilman tätä ominaisuutta julkaista", vaikka asiasta ei olisikaan mitään faktoihin perustuvaa tietoa.Suosittelemmekin usein hankkimaan luotettavia testausryhmiä (oikeita käyttäjiä), joiden kanssa voidaan kokeilla sovellusta jo varsin aikaisessa vaiheessa ja sitä kautta selvittää, onko sovelluksesta jo hyötyä käyttäjille. Jos on, niin SHIP IT!Hyödyn jälkeen toki pitää päästä siihen vaiheeseen, että sovellus tuottaa liikevaihtoa, tavalla tai toisella.Ja mikäli asiakkaana haluat olla varmempi siitä, mitä käyttäjät oikeasti haluavat, niin kannattaa tehdä heti projektin alussa käyttäjätestausta esim. prototyypeillä sekä haastatella juuri niitä tulevia käyttäjiä.

4. Etsitään syyllisiä

Aina paras tapa pilata mikä tahansa suhde, on lähteä syyttelemään. Esimerkiksi: "Kyllä tämä ennen toimi, tää on teidän vika, en todellakaan maksa tästä mitään", on oiva tapa saada kitkaa aikaa tiimin osaavien kehittäjien kanssa, kun unohdetaan samalla sellainen sivuseikka, että järjestelmään on tullut esimerkiksi kymmeniä miljoonia rivejä dataa sen jälkeen, kun ensimmäinen versio oli testattu toimivaksi 20 000 rivillä.

Asioista toki pitää puhua oikeilla nimillä ja selvittää, mistä mahdolliset ongelmat johtuvat. Ja joskus alaa syvemmin tuntematta tiedon lisääntyminen järjestelmässä ei tunnu isolta asialta. Samaan aikaan kehittäjistä voi tuntua siltä, että asiakas kiusaa, koska pakkohan hänen on ymmärtää, että tiedon määrä vaikuttaa kaikkeen toiminnallisuuteen, varsinkin kun siihen ei olla osattu varautua.Lisäksi useat järjestelmät nykyään käyttävät ulkopuolisia palveluja ja/tai koostuvat useasta erillisjärjestelmästä, joissa on sekä toiminnallisuuksia ja tietoa. Näin ollen, jos yksikin palveluista ei toimi tai muuttuu niin ettei siitä informoida kaikkia osapuolia, niin ei pitäisi lähteä etsimään syyllisiä vaan rakentavasti keskustelemaan siitä, mitä on tapahtunut ja mikä on saattanut aiheuttaa havaitun ongelman.

5. Ei panosteta markkinointiin

Yhteenkään sovellukseen tai palveluun ei ole tullut käyttäjiä ilman markkinointia. Ja miten enemmän ja ammattimaisemmin markkinoit niin sitä parempiin tuloksiin todennäköisesti pääset. Omassa toiminnassamme meillä ei ole paljoakaan eväitä ammattimaiseen markkinointiin tai esim. kasvuhakkerointiosaamista, mutta omista verkostoista sitä löytyy runsaasti ja pyrimmekin aina auttamaan ohjaamalla asiakkaamme oikeanlaisten kumppanien luo.Itse ennemmin lähtisin tekemään juuri sellaista tuotetta, joka näyttää hyvältä, tarjoaa perusominaisuudet ja tuottaa lisäarvoa tai liikevaihtoa brändille ja heti kun tuotteen pystyy julkaisemaan, niin käynnistäisin siihen markkinointitoimenpiteet, koska ilman käyttäjiä millään sovelluksella ei ole arvoa, mutta ei myöskään suuntaa. 

Näin täytät saavutettavuusvaatimukset

Kuvaus siitä kuinka WCAG:n suosituksista tulee osa Suomen lainsäädäntöä. Ensiksi suosituksista tulee osa eurooppalaista standardia EN 301 549, joka astuu voimaan kun se mainitaan Euroopan virallisen lehden liitteissä. Saavutettavuuslainsäädännössä on maininta Virallisen lehdestä josta standardi päätyy vaatimukseksi lakiin.

Web content accessibility guidelines WCAG eli verkkosisällön saavutettavuussuositukset eivät ole uusi surinasana, vaan ovat juuri nyt suurennuslasin alle nouseva käsite. Ensimmäinen versio näistä suosituksista on julkaistu jo vuonna 1999, kun taas versio 2.0 on julkaistu 2008 ja versio 2.1 vuonna 2018. Suurennuslasin alle saavutettavuussuositukset ovat nousemassa nyt hallituksen esityksen takia, joka toteutuessaan tarkoittaa pähkinänkuoressa sitä, että kaikkien julkisten tahojen tuottamien digitaalisten palvelujen tulee olla saavutettavia. Tarkemmin lakiesityksestä olemme kirjoittaneet kirjoituksessa Vaikeinta saavutettavuudessa on reklamointi.

Maailmassa on arvioitu olevan yli miljardi ihmistä, joilla on jokin vamma, joka haittaa palvelun saavuttamista. Tämä on n. 15 % maailman ihmismäärästä eli Suomen mittakaavassa vajaa miljoona ihmistä. Verkkosisällön saavutettavuussuositusten noudattaminen tekee palveluista myös muulla tavoin käytettävämpiä, sillä ne pakottavat suunnittelijat, kehittäjät ja sisällöntuottajat miettimään asioita käyttäjäkeskeisen suunnittelun näkökulmasta. Monet saavutettavuusongelmat pystyttäisiinkin korjaamaan tekemällä palvelut käyttäjäkeskeisen suunnittelun metodien avulla. Olemme käsitelleet saavutettavuutta myös ohjelmistokehityksen näkökulmasta artikkelissamme “Saavutettavuus ohjelmistokehityksessä”.

Käyttäjäkeskeinen suunnittelu kuitenkin pyrkii miettimään lähinnä pääasiallisia käyttäjäryhmiä, joka julkisten palvelujen osalta harvoin on vammaiset ihmiset. Lakiesityksen mukaan saavutettavuusvaatimukset määritellään Euroopan unionin virallisessa lehdessä, jossa ainoastaan viitataan noudatettavaan standardiin. Lakiesityksen yksityiskohtaisissa perusteluissa viitataan eurooppalaiseen standardiin EN 301 549 V1.1.2. Standardissa viitataan W3C:n WCAG 2.0 saavutettavuussuosituksiin. Samoissa perusteluissa mainitaan myös, että W3C olisi laatimassa uutta versiota WCAG-suosituksista, jolloin eurooppalainen standardi ja lain edellyttämät saavutettavuusvaatimukset muuttuisivat.

WCAG 2.1:sta on tullut W3C:n suositus kesäkuussa 2018 ja eurooppalainen standardi  EN 301 549 on päivitetty elokuussa 2018 versioon 2.1.2. Käytännössä lain noudattaminen vaatii siis W3C:n WCAG 2.1 -suosituksen noudattamista verkkosisältöjen osalta. W3C on Tim Berners-Leen vuonna 1994 perustama organisaatio, joka vastaa internetin standardoinnista. WCAG tulee sanoista web content accessibility guidelines, eli suomeksi verkkosisällön saavutettavuussuositukset.Koska WCAG on kokoelma vain verkkosisältöihin liittyviä suosituksia, ei sitä voida soveltaa suoraan mobiilisovelluksiin. Saavutettavuutta koskeva eurooppalainen standardi sisältää kuitenkin mobiilisovellusten saavutettavuutta koskevat saavutettavuusvaatimukset.

WCAG 2.1

WCAG 2.1 on standardi, joka tähtää siihen, että verkkosisällöt ovat saavutettavia laajemmalle kohderyhmälle. Tähän kohderyhmään kuuluvat ihmiset, joilla on esimerkiksi luki- tai oppimishäiriö, kuulo-, näkö- tai kehitysvamma. Myös näiden yhdistelmät sekä fyysiset vaivat, jotka hankaloittavat palvelun käyttöä luetaan samaan. Näistä riippumatta, käyttäjän pitäisi saada asiansa hoidettua digitaalisissa palveluissa.Nämä saavutettavuussuositukset eivät ole uusi surinasana, vaan omat juuri nyt suurennuslasin alle nouseva käsite. Ensimmäinen versio näistä suosituksista on julkaistu jo vuonna 1999, kun taas versio 2.1 on julkaistu 2018. Suurennuslasin alle saavutettavuussuositukset ovat nousemassa nyt hallituksen lakiesityksen takia, joka toteutuessaan tarkoittaa pähkinänkuoressa sitä, että kaikkien julkisten palvelujen tulee olla saavutettavia. Tarkemmin lakialoitteesta olemme kirjoittaneet kirjoituksessa Vaikeinta saavutettavuudessa on reklamointi. Kuitenkin esimerkiksi perustuslaki on vaatinut omilla sanamuodoillaan saavutettavuutta jo ennen nykyistä lakia.

Ketään ei saa ilman hyväksyttävää perustetta asettaa eri asemaan sukupuolen, iän, alkuperän, kielen, uskonnon, vakaumuksen, mielipiteen, terveydentilan, vammaisuuden tai muun henkilöön liittyvän syyn perusteella.Perustuslaki, 6 §, toinen momentti

Käytännössä

Saavutettavuussuositukset eivät ole päänsärky, jonka voi heittää suoraan sovellustoimittajien hartioille. Saavutettavuuteen pystyy vaikuttamaan jokainen ihminen, luo mitä tahansa sisältöä, jota kuka tahansa muu kuluttaa. Esimerkiksi videoiden, tekstien ja kuvien tuottaminen on työtä, jossa saavutettavuus on otettava huomioon. Erilaisten sisältöjen käyttäminen on edelleen suositeltavaa, sillä niillä on suuri vaikutus palvelujen käyttäjäkokemukseen. WCAG:n tavoite ei siis ole rajoittaa videoiden, tekstien, kuvien tai muiden sisältöjen käyttämistä, vaan varmistaa, että kaikilla käyttäjillä on mahdollisuus päästä käsiksi sisältöjen tarjoamaan informaatioon.Tämä ei myöskään tarkoita sitä, että jokaisen käyttäjän tulee pystyä käyttämään sivustoa yhtä nopeasti tai samalla tavalla, sillä eri modaliteettien avulla sivuston käyttäminen on erilaista, jolloin esimerkiksi puhesyntetisaattorilla sivuston sisällön kuluttaminen on hitaampaa.Eurooppalainen standardi, johon lakiesityksen vaatimukset perustuvat, vaatii että verkkopalvelun saavutettavuuden tulee olla vähintään WCAG 2.1 -suosituksen AA-tasolla. Koska WCAG sisältää tasot A, AA ja AAA, lain saavutettavuusvaatimusten täyttäminen ei tarkoita, että palvelut olisivat kaikille saavutettavat.Seuraavassa esitetään joitain keskeisempiä WCAG 2.1:n saavutettavuusvaatimuksia. Saavutettavuusvaatimuksiin kannattaa kuitenkin tutustua kokonaisuudessaan, jotta palvelusta voidaan tehdä mahdollisimman saavutettava.

Tekstit

Tekstimuotoisella sisällöllä tulee olla tarpeeksi suuri kontrasti suhteessa taustaan. Kontrastin tulee olla vähintään 4,5:1. Jos teksti on fonttikooltaan yli 18 pt tai lihavoituna 14 pt, kontrastin tulee olla vähintään 3:1. Jos teksti on kuvana, tekstillä on samat kontrastivaatimukset. Logoissa olevissa teksteissä ei ole kontrastivaatimusta. Jos teksti on koristeena, ei näy kenellekään tai on osana kuvaa, jossa on merkittävästi muutakin visuaalista sisältöä, kontrastivaatimusta ei ole. Tekstin kokoa pitää myös pystyä muuttamaan 200 % ilman avustavia teknologioita siten, että toiminnallisuudet tai sisältö eivät häviä.

Ei-tekstimuotoinen sisältö

Kaikelle ei-tekstimuotoiselle sisällölle pitää tarjota vaihtoehtoiset tekstit. Jos ei-tekstimuotoinen sisältö on vain koristeena tai auttaa muotoilussa, se pitää implementoida niin, että avustavat teknologiat kuten ruudunlukijat voivat jättää ne käsittelemättä.

Aikariippuvaiset mediat

Lakiesitys ja WCAG puhuvat aikariippuvaisesta mediasta (time-based media), joka tarkoittaa videoita ja ääntä. WCAG:n mukaan sekä tallennetut että livenä julkaistavat sisällöt tulee tekstittää. Lakiesityksen mukaan tallenteina palvelusta löytyvät sisällöt tulee olla tekstitettynä viimeistään kaksi viikkoa julkaisun jälkeen. Lakiesitys kuitenkin jättää vaatimuksen ulkopuolelle livesisällön, ellei se tule myöhemmin tallenteena palveluun, jolloin se pitää viimeistään tekstittää.

Kuvat

Esimerkiksi olennaista sisältöä ei enää saa olla kuvissa, sillä kuvia ei voida lukea tekstiksi. Tietenkin kuvituskuvien, logojen ja muiden käyttö on edelleen sallittua ja oikein suotavaa, mutta esimerkiksi kuva vaikkapa lomakkeesta tai tapahtuman tiedoista ei saa sisältää sellaista tietoa, jota ei pystytä esimerkiksi ruudunlukuohjelmalla lukemaan näytöltä.

Navigointi

Jos järjestelmän näkymissä on elementtejä tai osioita, jotka toistuvat useissa näkymissä, ne pitää pystyä ohittamaan tarvittaessa. Esimerkiksi nettisivujen navigaation ohi pitää pystyä hyppäämään ruudunlukijaa käytettäessä.Jokaisella järjestelmän sivulla tulee olla otsikko, joka kuvaa sisällön aiheen ja tarkoituksen. Samoin sisällön otsikoiden ja lomakkeen kenttien nimien täytyy olla kuvaavia.

Semanttiset Html-elementit

Elementtien käyttäminen oikein vaikuttaa mahdollisesti positiivisesti hakukonetuloksiin, sillä robotti, joka tutkii verkkosivujen semanttisuutta ja niiden käyttöä on ikään kuin ‘sokea käyttäjä’, sillä se ei näe miten tieto jäsentyy visuaalisesti, vaan tietää mihin elementtiin tieto liittyy. Sama robotti rankaisee semanttisten elementtien väärin käyttämisestä laskemalla hakutulosten vastaavuutta.

Käytettävä

Järjestelmän pitää olla käytettävissä pelkkää näppäimistöä käyttäen tiettyjä poikkeuksia lukuunottamatta. Esimerkiksi siveltimen vetoja vaativan piirustusohjelman on poikkeus sääntöön. Näppäimistöä käytettäessä käyttäjä ei saa päätyä umpikujaan, josta ei pääse pois näppäimistöä käyttämällä. Jos elementtien järjestyksellä on merkitystä, niin esimerkiksi näppäimistöltä käytettäessä elementistä toiseen siirryttäessä siirtymisjärjestyksen pitää säilyttää tämä merkitys.Jos sisällön käyttämiseksi on olemassa aikaraja, käyttäjän pitää pystyä ottamaan se pois päältä, säätämään sitä tai siirtämään sen täyttymistä. Poikkeuksena ovat reaaliaikaiset järjestelmät, joissa aikarajalle ei ole vaihtoehtoa, esimerkiksi huutokaupat. Poikkeuksena pidetään myös tilannetta, jossa aikaraja on olennainen osa järjestelmän toimintaa.

Ymmärrettävä

Sisällön informaatio, rakenne ja keskinäiset suhteet, jotka näkyvät sisällön esitystavassa tulee olla määritettävissä ohjelmallisesti tai niiden pitää olla saatavilla tekstinä. Myös sisällön oikea lukemisjärjestys tulee olla ohjelmallisesti määritettävissä. Sisällön ymmärtäminen ei saa perustua ainoastaan aistittaviin ominaisuuksiin kuten muotoon, väriin, kokoon tai sijaintiin näkymässä.

Saavutettavuus ja käytettävyys

Kun lukee WCAG:n suosituksia, huomaa paljonkin päällekkäisyyksiä käytettävyyden vaatimusten kanssa. Esimerkiksi osan saavutettavuusvaatimuksista täyttää jo sillä, että sisältö ja toiminnallisuudet ovat Nielsenin heuristiikkojen mukaiset.