Production
Digitaalisella tuotteella voidaan tarkoittaa mitä tahansa ohjelmistoa, jolla on määritelty tarkoitus. Lopputulos heijastaa sitä, missä yhteydessä tuotetta käytetään ja mitä tavoitteita sen kehittäjillä on ollut.
Onnistuneen digitaalisen tuotteen luominen vaatii monipuolista ammattitaitoa. Tarvittavia osaamisalueita ovat tyypillisesti palvelumuotoilu, digitaalinen suunnittelu, ohjelmistokehitys, testaus, analytiikka ja markkinointi.
Lopputuloksena voi olla mobiilisovellus, verkkopalvelu tai ohjelmisto. Mahdollisuudet eri alustojen ja käyttötapausten suhteen ovat rajattomat.
Digitaaliset kehityshankkeet ovat hyvin vaihtelevia paitsi kokonsa, myös tavoitteidensa puolesta. Esimerkiksi: vakiintuneen tuotteen suorituskyvyn parantaminen on hyvin erilainen projekti kuin uusi sovellus, jonka tarkoitus on luoda uudenlainen, toimialaa mullistava liiketoimintamalli.
Jokainen projekti vaatii juuri oikeanlaista työtehtävien ja taitojen yhdistelmää. Työn jakautuminen osaajien välillä vaihtelee projektin aikana.
Kehitysfilosofiamme on designlähtöinen. Tämä lähestymistapa on punainen lanka kaikkien tässä oppaassa esitettyjen ajatusten taustalla.
Designlähtöisyys tarkoittaa, että loppukäyttäjä on huomion keskipisteenä alusta alkaen. Tämä periaate ohjaa projektin kaikkia vaiheita. Digitaalisen tuotteen on palveltava yhtä lailla sekä liiketoimintatavoitteita että käyttäjiä.
Yksinkertainen on kaunista ja tehokasta. Uskomme, että designlähtöisyys on ylivoimaisesti kustannustehokkain tapa luoda laadukkaita digitaalisia tuotteita.
Maailma on tulvillaan digitaalisia tuotteita, joiden tuottama lisäarvo vaihtelee suuresti. Meidän periaatteenamme on, että emme tuota digitaalista jätettä. Laadukkaalla digitaalisella tuotteella on selkeä syy olla olemassa: se palvelee käyttäjiensä tarpeita ja sen luoneen organisaation tavoitteita.
Laatu tarkoittaa myös intuitiivista käyttökokemusta, jonka mahdollistaa vahva tekninen toteutus. Tyylikkyys on seurausta siitä, kun monimutkaiset ongelmat muutetaan yksinkertaisiksi ja kauniiksi ratkaisuiksi.
Laadunvarmistus ei ole muusta tekemisestä irrallinen vaihe: sen on syytä kulkea mukana koko projektin ajan. Laadukkaat lopputulokset saavutetaan, kun oikeat ihmiset käyttävät oikeita prosesseja ja työkaluja – riittävän budjetin tuella.
Tämän julkaisun tarkoituksena on kuvata laadukkaiden digitaalisten tuotteiden peruspilarit. Lopulta laadun tärkein edellytys on kaikkien osallisten sitoutuminen. Tämän tulee heijastua niin pieniin kuin suuriinkin valintoihin.
Siinä, miten ketteryys ymmärretään ja miten sitä sovelletaan varsinaiseen työhön, on jonkin verran vaihtelua. Meille ketteryyden tärkein periaate on palautteen kerääminen eri muodoissa jokaisessa kehitysvaiheessa – sekä halu ja kyky muuttaa suuntaa sen perusteella.
Suunnittelussa tämä tarkoittaa ideoiden validointia haastatteluilla ja prototyypeillä sekä muilla palvelumuotoilun työkaluilla ja menetelmillä. Teknisessä toteutuksessa ilmenemismuotoja ovat vertaisarvioinnit ja tarkasti määritellyt testausprosessit. Analytiikka auttaa meitä keräämään ja arvioimaan dataa käyttäjien toiminnasta.
Onnistunut digitaalinen projekti alkaa aina kontekstin määrittämisestä, tavoitteiden ja käytettävissä olevien resurssien arvioinnista sekä rajoitteiden ymmärtämisestä. Nämä tekijät on syytä kommunikoida koko tekijätiimille.
Projektin muut vaiheet voidaan aloittaa vasta tämän määrittelytyön jälkeen. Periaate on sama hankkeen koosta riippumatta – ja yksi tärkeimmistä onnistumisen edellytyksistä.
Tiimin koko ja kokoonpano määräytyvät sekä projektin että projektivaiheen mukaan. Mikäli mahdollista, suosimme työpareja: jokaisella tiimin jäsenellä on hyvä olla joku tukemassa heidän työskentelyään.
Projektille valitaan asiakasta edustava tuoteomistaja, joka voi tehdä päätöksiä määriteltyjen ylemmän tason tavoitteiden tueksi. Projektipäällikkö vastaa hankkeen etenemisestä ja lopputuloksesta. Muut tiimin jäsenet valitaan tarvittavan osaamisen perusteella.
Onnistuneessa projektissa on samat rakennuspalikat kuin missä tahansa ihmissuhteissa: keskinäinen kunnioitus, luottamus, avoimuus sekä halu pitää yllä motivaatiota ja neuvotella.
Alusta asti on varmistettava, että viestintä on sujuvaa ja toimii kaikkien osallisten välillä.
Digitaalinen tuotekehitys on monialaista työtä. Optimaalinen tiimi on tasapainoinen yhdistelmä eri osaamisalueita. Yksittäisillä tiimin jäsenillä voi olla useita rooleja.
Tuoteomistaja edustaa asiakkaan näkökulmaa projektissa. Hänellä on syvällistä tietoa asiakkaan liiketoiminnasta ja siitä, mikä digitaalisen tuotteen rooli on kokonaisuudessa.
Projektipäällikkö valvoo koko projektia. Hän vastaa deadlineista, KPI-mittareista, raportoinnista ja kunkin projektitiimin jäsenen työn seurannasta.
Palvelumuotoilija vastaa käyttäjätutkimuksesta ja siitä, että tuotteen suunnittelu noudattaa käyttäjälähtöisyyden periaatteita.
UX/UI-suunnittelija muuttaa tutkimus- ja liiketoimintatavoitteet intuitiivisiksi ja selkeiksi käyttökokemuksiksi. Hän tekee jatkuvaa yhteistyötä kehittäjien kanssa varmistaakseen, että käyttökokemus (UX) on teknisen toteutuksen mukainen.
Front end -kehittäjä työskentelee käyttäjärajapinnan teknisen toteutuksen parissa. Kaikki, mitä loppukäyttäjä voi nähdä, koskettaa tai klikata on rakennettava niin, että se toimii sujuvasti ja että käyttöliittymään voidaan tarvittaessa tehdä muutoksia mahdollisimman joustavasti.
Back end -kehittäjä on arkkitehti, joka määrittää, mitä tapahtuu digitaalisen tuotteen pellin alla. Tuotteen toiminta palvelimien ja ohjelmointirajapintojen (API) kanssa on ratkaisevan tärkeää – ja usein myös monimutkaista.
Oikean datan kerääminen kertoo meille, miten hyvin olemme onnistuneet ja millaisia muutoksia seuraavissa iteraatioissa on tehtävä.
Laadukas sisältö vaikuttaa ratkaisevasti käyttökokemuksen selkeyteen, äänensävyyn ja tuotteesta saatavaan yleisvaikutelmaan.
Markkinointi auttaa tuotetta saavuttamaan kohdeyleisön ja kasvattamaan sitä ajan myötä. Työ voi olla sekä tekstuaalista että visuaalista ja edellyttää markkinointialustojen syvällistä tuntemusta.
Testauksella varmistetaan, että ratkaisussa ei ole suuria virheitä ja se täyttää kaikki toiminnalliset vaatimukset. Myös turvallisuuden testaaminen on monessa ratkaisussa olennainen prioriteetti.
Kyky tehdä päätöksiä on ensiarvoisen tärkeä onnistumisen kannalta. Projektin aikana tehdään jatkuvasti suuria ja pieniä päätöksiä, joista kaikkien on tuettava kokonaisvisiota. Valtaosan päätöksistä tulisi perustua tiimin yhteistyöhön.
Viimeinen sana kuuluu kuitenkin sille, joka kantaa viime kädessä vastuun. Viisas kapteeni osaa kuitenkin osallistaa, sitouttaa ja innostaa tiimiläisiään parhaan työpanoksen varmistamiseksi.
Työkokonaisuuksien hierarkia määräytyy tavoitteiden laajuuden mukaan. Nimityskäytännöt vaihtelevat, mutta eri tasoista voidaan käyttää esimerkiksi nimityksiä etappi > epic > tehtävä
Työ jakautuu sprintteihin. Sprintti on ennalta määritelty kiinteä kalenteriajan tai työpanoksen määrä. Tyypillinen sprintti voi kestää esimerkiksi 2–10 viikkoa.
Sprinttiin sisältyy aina suunnittelma tuloksista, jotka sen aikana tulisi saavuttaa – ja niihin liittyvät työtehtävät. Projektissa voi olla myös useita samanaikaisesti käynnissä olevia sprinttejä. Sprinttisuunnitelmat ja niihin liittyvät aikataulut muodostavat korkean tason projektisuunnitelman.
Kick off on projektin ensimmäinen palaveri. Sitä on usein edeltänyt tarjouspyyntö- ja tarjouskierros tai sisäisten liiketoimintasuunnitelmien laatiminen. Tavoitteena on tutustua muihin projektiin osallistuviin ja oppia ymmärtämään projektin kontekstia ja tavoitteita – sekä saada projekti käyntiin.
Tyypillinen kick off voi kestää muutamasta tunnista kokonaiseen työpäivään. Sen aikana sovitaan myös seuraavat vaiheet ja alustava aikataulu.
Yrityksen esittely
Asiakkaan liiketoiminnan esittely
Projektitiimin esittely
Toimittajan ja asiakkaan roolit ja henkilöstö, vastuut ja yhteyshenkilöt, toimittajan projektitiimin jäsenten ansioluettelot ja projektin kannalta olennaiset referenssit
Projektin esittely
Alustava suunnitelma siitä, mitä olemme tekemässä
Tavoitteet
Mitä tavoittelemme ja mittaamme onnistumista?
Rutiinien suunnittelu
Viikkopalaverit, viestintä, dokumentointi, versionhallinta
Aikataulu
Projektisuunnitelma ja aikataulu
Perussäännöt
Sopimus, budjetti, vastuut, resurssit
Jatkotoimenpiteet
Seuraavat tapaamiset, tehtävät jne.
Riskit
Riskien tunnistaminen ja luokittelu todennäköisyyden ja seurausten perusteella
Suunnittelussa on kyse ratkaisun syvimmän olemuksen, sekä sen toiminnallisen ja esteettisen olemuksen määrittelystä. Hyvään suunnitteluun panostaminen mahdollistaa kustannustehokkuuden, sillä sen avulla lopputuotteeseen valikoituvat ainoastaan olennaisimmat elementit. Digitaalisten tuotteiden yhteydessä suunnittelun ja toteutuksen välillä ei ole selkeää rajaa.
Winston Churchill tiivisti olennaiseen keskittymisen filosofian seuraavasti: ”Jos haluat minun puhuvan kaksi minuuttia, minulta menee kolme viikkoa valmisteluihin... Jos haluat minun puhuvan tunnin ajan, olen valmis heti.”
Suunnitteluprosessimme on saanut paljon vaikutteita sekä Design Thinking- että Lean-menetelmistä.
Meille Design Thinking tarkoittaa ratkaisukeskeisyyttä – suunnittelun tärkeimpänä tehtävänä on aina kartoittaa todellisia ongelmia ja etsiä niihin ratkaisuja.
Lean-ajattelussa meihin vetoaa eniten asiakkaiden ja loppukäyttäjien osallistaminen iteraatio- ja testausprosessiin.
Yhteissuunnittelutyöpajat ovat keskeinen osa prosessiamme. Niiden avulla varmistamme, että jaamme asiakkaan kanssa saman vision. Lisäksi hyödymme siitä, että asiakas tuntee oman liiketoimintaympäristönsä parhaiten.
Ensimmäisissä työpajoissa määrittelemme kohderyhmät, tuotteen tavoitteet ja hypoteesit – ja käymme läpi siihen mennessä esille nousseet mahdolliset esteet. Tämän jälkeen siirrymme tyypillisesti käyttäjäprofiilien ja käyttäjäpolkujen luomiseen.
Yhteissuunnittelutyökalut ovat tehokas tapa saavuttaa yhteinen käsitys tuotteesta ja tehdä jaettuun ymmärrykseen perustuvia päätöksiä tuotteen suunnittelusta.
Lean Business Model Canvas on yksi laajimmin käytetyistä ideointityökaluista, joka auttaa kokoamaan projektin perusasiat yhteen helppolukuiseen malliin.
LBMC kerää yhteen tuotteen peruslähtökohdat (liiketoimintamahdollisuus, ratkaisu, kilpailijat, arvolupaus, keskeiset mittarit). Se auttaa vahvistamaan digitaalisen ratkaisun tarkoitusta, tavoitteita ja haasteita.
Käyttäjäpersoonat antavat paremman käsityksen ihmisistä, jotka tulevat käyttämään tuotetta. Persoona voi muodostua esimerkiksi seuraavien tietojen kuvauksista: demografiset tiedot, taloudelliset tiedot, siviilisääty, elämäntapa, käyttötilanteiden kuvaukset sekä palvelun käyttöön liittyvät tavoitteet, toiveet ja pelot.
Käyttäjäpolut visualisoivat käyttäjien vuorovaikutuksen palvelun kanssa ajan mittaan. Niihin voi sisältyä kuvauksia käyttäjäpolun eri vaiheista, toteutetuista toimista ja erilaisten tunteiden ja tilanteiden mahdollisesta vaikutuksesta kokemukseen.
Priorisointimatriisi on projektin eri ominaisuuksien arviointiin tarkoitettu työkalu, joka selkeyttää fokusalueita.
Trigger-kortit ovat luova ideointiväline, joka voi auttaa tiimiä etenemään ideointivaiheessa erilaisten ”mitä jos” -kysymysten avulla.
UX-suunnittelu eli käyttökokemuksen suunnittelu on prosessi, jossa tietoa kerätään, priorisoidaan ja esitetään muodossa, joka tarjoaa käyttäjälle sujuvan kokemuksen. Usein parhaat käyttökokemukset ovat niin intuitiivisia, että ne ovat lähes huomaamattomia.
Tyypillisesti UX-suunnittelu alkaa tietoarkkitehtuurin luomisesta (mitä tietoa tarvitaan ja miten se tulisi jäsentää) ja etenee rautalankamalleihin (wireframe) ja prototyyppeihin, jotka visualisoivat palvelun kulkua. Näiden työkalujen avulla tuotetta voidaan testata käyttäjien ja muiden sidosryhmien kanssa ennen kuin joudumme kirjoittamaan ensimmäistäkään koodiriviä.
UX-työkalut herättävät suunnittelun ja ideat eloon, oli kyse sitten informaatioarkkitehtuurista tai interaktiivista prototyypeistä.
Informaatioarkkitehtuurissa on kyse siitä, miten ja mitä tietoa käyttäjälle esitetään. Sujuvan UX-suunnittelun keskeinen osa on sen selvittäminen, mitkä tiedot ovat tuotteelle välttämättömiä ja miten ne järjestetään niin, että käyttäjä voi liikkua niiden välillä intuitiivisesti.
Palvelusuunnitelma on laajempi kuvaus siitä, mitä tuote tekee ja mitä palvelussa pitäisi tapahtua eri tasoilla käyttäjäpolun aikana.
Käyttäjätestauksen ei tulisi juolahtaa mieleen vasta viime tingassa: se kannattaa ottaa mukaan suunnitteluprosessiin mahdollisimman varhaisessa vaiheessa. Todellisilta käyttäjiltä saatava data kertoo oikein jäsenneltynä luottettavasti, olemmeko tekemässä oikeita suunnitteluvalintoja.
Rautalankamalli (wireframe) on kuvaus palvelun eri näkymien välisistä siirtymistä. Se on tehokas työkalu, jonka avulla voi selvittää, noudattaako palvelun sisällä liikkuminen selkeää logiikkaa: käyttäjän ei pitäisi koskaan jäädä jumiin tai eksyä.
Erilaisten prototyyppityökalujen avulla palvelusta voidaan luoda klikkailtavia versioita ennen tuotantoon siirtymistä. Testauksen aikana tehdyt löydökset ovat arvokkaita, sillä tässä vaiheessa käyttöliittymään on paljon nopeampaa ja edullisempaa tehdä radikaalejakin muutoksia verrattuna jo koodattuun versioon.
Meille palvelumuotoilu on erottamaton osa suunnittelua. Keräämme perusteellisempaa tietoa havainnoinnin ja kenttätutkimusten avulla kunkin projektin tarpeiden mukaan. Tyypillisesti teemme haastatteluja ja kyselyjä saadaksemme selkeämmän käsityksen käyttäjien tarpeista ja haasteista.
Myös käyttäjätestaus on normaali osa prosessiamme ja auttaa meitä sekä validoimaan isompia ideoita että tuomaan esiin yksittäisiä ongelmia käyttäjäpoluissa.
Projekteihin voi kuulua myös palveluauditointeja, joissa tutkimme ja testaamme tuotteen käytettävyyttä tai saavutettavuutta.
UI-suunnittelu eli käyttöliittymän suunnittelu on paljon muutakin kuin rautalankamallien visualisointia. Nykyaikaiset käyttöliittymät on rakennettu komponenttien ja dynaamisten tyylien avulla.
Design-systeemit ovat paljon enemmän kuin komponenttikirjastoja – niiden suunnittelufilosofia mahdollistaa yhdenmukaisemman asiakas- ja brändikokemuksen kaikissa digitaalisissa kanavissa, joita asiakas käyttää nyt tai tulevaisuudessa.
UI-suunnittelussa eniten käyttämämme työkalu on Figma, jonka olemme valinneet sen yhteistyöominaisuuksien ja joustavuuden ansiosta. Vuosien varrella olemme rakentaneet alustalle omaan käyttöömme räätäöityjä lisäosia, joilla voidaan luoda edistyneitä prototyyppejä ja kääntää tyylejä ja komponentteja suoraan uudelleenkäytettäväksi koodiksi.
Digitaalinen tuote on aina sen teknisen toteutuksen ilmentymä – ja päinvastoin. Toteutusta ja suunnittelua ei voi erottaa toisistaan. Molempien on oltava mukana alusta alkaen.
Tekninen toteutus voidaan toteuttaa monin eri tavoin erilaisia teknologioita tai lähestymistapoja hyödyntäen. Jotkut vaihtoehdot kuitenkin sopivat tarkoitukseen paremmin kuin muut.
Valitut menetelmät ovat aina kompromissi useiden eri tekijöiden välillä. Valinnat on tehtävä siten, että ne kestävät aikaa ja niitä on helppo päivittää tosielämän käytöstä saatavan palautteen perusteella.
Yksinkertainen on kaunista
UX-työkalut herättävät suunnittelun ja ideat eloon, oli kyse sitten tietoarkkitehtuurista tai vuorovaikutteisista prototyypeistä.
Suoraviivainen on tyylikästä
Ylisuunnittelu on yleinen sudenkuoppa. Vältä turhaa monimutkaisuutta. Älä yritä ratkaista ongelmia, joita sinulla ei ole.
Uudelleenkäyttö on fiksua
Pyörän keksiminen uudelleen ei ole tehokasta eikä taloudellista. Asioiden tekeminen kerralla oikein maksaa itsensä takaisin.
Vakaa teknologia on parempi kuin trendikäs
Tuotannossa ei kannata luottaa uusimpiin villityksiin. Perusvarma, monissa liemissä testattu vaihtoehto on lähes aina oikea valinta.
YAGNI (You Ain’t Gonna Need It)
Rakenna sitä, mitä tarvitaan juuri nyt – älä sitä, mitä saatetaan tarvita tulevaisuudessa. Lähesty toteutusta skaalautuvasti, jotta sitä on helppo laajentaa myöhemmin.
Valitse kevyt ja epämuodollinen (enimmäkseen) raskaan ja muodollisen sijaan
Ellei kyse ole ihmishengistä, laajamittaista muutostenhallintaa tai hankalia laadunvalvontaprosesseja ei todennäköisesti tarvita. Maalaisjärjellä ja koodikatselmuksilla pääsee jo pitkälle.
Teknistä arkkitehtuuria suunniteltaessa on otettava huomioon useita näkökohtia. Seuraavassa esitellään työhömme sovellettavia periaatteita.
Käyttäjävaatimuksista riippuen ongelman ratkaisemiseksi on useita mahdollisia tapoja, joista jokaisella on omat hyötynsä ja haittansa.
Pyrimme käyttämään tehtävään parhaiten soveltuvia työkaluja ja vain tarvittavan määrän perusrakennuspalikoita. Riippuvuudet ovat riskejä, joten suhtaudumme niihin varovaisesti.
Asiakkaalla saattaa olla käytössä oma teknologiastackinsa – pyrimme aina sopeutumaan siihen ja sisällyttämään omat valitsemamme työkalut mahdollisuuksien mukaan.
Jos yhteensopivuusongelma on liian suuri, on vastuumme olla asian suhteen rehellisiä ja mahdollisesti jättää projekti väliin kokonaan.
Projektitiimin osaaminen ja vahvuudet tulee aina ottaa huomioon teknologiapinon valinnassa.
Kaikkien teknologiavalintojen tulee olla realistisia suhteessa budjettiin. Jos budjettirajoitukset ovat merkittiä, noudatamme periaatetta ”testaa manuaalisesti ja luo hyvä tuote” sen sijaan, että yrittäisimme sovittaa yksikkö- ja integraatiotestauksen liian tiukkaan budjettiin.
Back-endin suhteen pyrimme olemaan hyvin konservatiivisia – käytämme VPS:ää, automatisoimme Ansiblella ja pidämme asiat mahdollisimman yksinkertaisina ja riippumattomina. Useimmissa ratkaisuissa on myös hyvä olla riippumaton pilvipalveluntarjoajasta.
Useimmat palvelut toimivat yleensä hyvin skaalaamalla “vertikaalisesti” tarpeen mukaan: käytännössä tämä tarkoittaa tehokkaampien tietokoneiden hankkimista sen sijaan, että rakennettaisiin heti klusteri. Ensimmäinen vaihtoehto toimii useimmissa tapauksissa myös pitkällä aikavälillä – jälkimmäinen taas tuo lisää monimutkaisuutta, mikä ei välttämättä ole perusteltua.
Taisteella on sujuvasti toimiva automaatio palveluiden käyttöönotolle Ansiblella, jossa perustietoturvaperiaatteet ovat sisäänrakennettuina. Näiden työkalujen käyttö tarkoittaa, että asiat ovat alusta alkaen varsin turvallisia.
Oikeiden algoritmien käyttö ja tietokantataulujen indeksointi vievät pitkälle. Emme yritä optimoida ennen kuin tiedämme, missä kehitteillä olevan järjestelmän pullonkaulat tulevat olemaan.
Pyrimme luomaan klustereita VPS:n avulla ja tarjoamme luotettavuutta hajautettujen järjestelmien perusperiaatteiden mukaisesti.
Pyrimme käyttämään komponentteja, jotka ovat jo laajalti käytössä ja toimivat odotetusti. Luonnollisesti on myös projekteja, joissa uusien komponenttien kokeilu on pienempi riski.
Paras tapa olla joustava on noudattaa mahdollisimman tarkasti parhaita käytäntöjä annetussa frameworkissa.
Kun luomme uusia abstraktioita, emme tee sitä esimerkiksi siksi, että olemme "tyytymättömiä siihen, miten asiat ovat Djangossa” – se on pystyttävä perustelemaan käsillä olevan ongelman näkökulmasta. Valitsemissamme työkaluissa pysyttäytyminen on sen arvoista, vaikka se vaatisikin joskus pieniä uhrauksia.
Jotkut projektit mahdollistavat rohkeammat ja kokeellisemmat lähestymistavat. Tällaisissa tapauksissa on ensiarvoisen tärkeää varmistaa, että kaikki osalistujat ymmärtävät valitun lähestymistavan mahdolliset hyödyt ja sudenkuopat ennen tällaisten päätösten tekemistä.
Kaikkien projektien perussuunnittelussa on yleensä tiettyjä yhteisiä piirteitä. Pyrimme löytämään ratkaisuja, joissa jaamme järjestelmän autonomisiin yksiköihin, jotka pystyvät toimimaan osatehtävässä mahdollisimman itsenäisesti.
On tärkeää ymmärtää alusta asti sekä dataa että järjestelmän tiedonkulkumalleja. Tämä auttaa mallintamaan loputkin ratkaisusta tämän tiedon ympärille.
Suosittelemme käyttämään relaatiotietokantaa tietojen säilytyskerroksena. Jos taas on suuri tarve offline-käytölle, jossa useat käyttäjät käyttävät samaa tietojoukkoa, valitsisimme mieluummin PouchDB-/CouchDB-pohjaisen ratkaisun.
Jos tarvitaan useita palveluita, prosessien välinen viestintä rakentuu pääosin viestijonojen abstraktioiden ympärille, kuten RabbitMQ tai Redis. Joissakin tapauksissa käytämme myös HTTP REST APIa liikennekerroksena – mutta vain sellaisissa tapauksissa, joissa API-rajapintaa käyttävät myös muut asiakkaat eikä jonopohjaista ratkaisua pystytä toteuttamaan selvällä tavalla.
Tarpeen mukaan arvioimme ainakin asiakkaan ja back end palveluiden välisen vuorovaikutuksen selvittääksemme, kannattaako valita REST- vai GraphQL-pohjainen ratkaisu.
Luomme ympäristön yleensä jonkin aiemman projektimme pohjalta. Olemme kokeilleet mallipohjien luomista, mutta huomanneet, että niiden avulla on vaikea toteuttaa kustannustehokkaita ja yleispäteviä ratkaisuja.
Koska olemme toteuttaneet satoja projekteja, meillä on referenssiprojekteja useimpiin tarpeisiin. Ymmärrämme luonnollisesti, että tämä ei silti päde kaikkiin tapauksiin. Olemme myös aina kiinnostuneita tutkimaan muita, mahdollisesti juuri sinun projektiisi sopivia vaihtoehtoja.
Suuremmissa projekteissa toteutamme työn aina Kanban-tyyppisenä ketteränä prosessina. Sprintti suunnitellaan ja tarinat luodaan Shortcutissa, jonka sisäisesti rakennettu integraatio GitLabiin pitää huolen niiden synkronoinnista.
Suosittelemme antamaan arvion mahdollisista ongelmista Shortcutissa. Jos työ kestää yli neljä päivää, on hyvä idea jakaa se useampaan ongelmaan, jotta tehtävästä saadaan parempi ymmärrys.
Kehitysjono on asetettu tärkeysjärjestykseen – devaajan tarvitsee vain valita luettelon ensimmäisenä oleva tehtävä saatuaan edellisen valmiiksi.
Kun kehittäjä valitsee tärkeysjärjestyksessä ensimmäisenä olevan ongelman toteutettavaksi, työ aloitetaan uudessa haarassa, joka voidaan luoda automaattisesti GitLabissa.
Sen jälkeen kehittäjä jatkaa toteutusta ja pyytää työn edetessä palautetta tai neuvoja projektitiimin jäseniltä, asiakkaalta tai kollegoilta. Toteutuksen päätyttyä ongelmalle määritetään katselmoija ja tehdään koodikatselmus. Kun havainnot on ratkaistu, koodi yhdistetään asianomaiseen haaraan ja CI/CD-putki huolehtii käyttöönotosta.
Budjetin salliessa ehdotamme aina vähintään ratkaisun tärkeimpien osa-alueiden yksikkö- ja integrointitestausta. Yhdistettynä hyvään manuaalisen testauksen suunnitelmaan tämä riittää useimpiin pieniin projekteihin.
Jos päätetään luoda UI-testejä, on aina parempi toteuttaa ne silloin, kun käyttöliittymä on lähes valmis.
Projektille on määritettävä vähintään perustason jatkuva integraatio (CI) esim. GitLabissa, jotta työ varmasti pakataan, tarvittaessa testataan ja otetaan käyttöön ympäristöissä asianmukaisesti. Meillä on hyvä valikoima CI-konfiguraatioita, jotka voidaan sisällyttää uusiin projekteihin ja jotka ovat ehdottomasti investoinnin arvoisia.
Lisäämme back end palveluihin myös perusmittareita ja seurantaa sekä Sentryn ja muita työkaluja, joiden avulla ongelmat ja järjestelmävirheet voidaan löytää ennakoivasti ennen kuin käyttäjät edes huomaavat niitä.
Sekä back endin että front endin seuranta ja virheraportointi mahdollistavat nopean reagoinnin tuotannossa ilmeneviin virheisiin.
Kerättävä ja seurattava tietokokonaisuus määräytyy palvelun mukaan. Teknisestä näkökulmasta se tulee valita sen perusteella, mikä auttaa meitä parhaiten pysymään ajan tasalla mahdollisten ongelmien ehkäisyssä ja käsittelyssä. Tietyt mittarit, kuten keskusyksikön ja muistin käyttö, instanssin kuormitus ja onnistuneiden pyyntöjen määrä ovat aina olennaisia.
Kun CD-putket on luotu, järjestelmää on helppo päivittää ongelman tunnistamisen jälkeen.
Testaus on olennainen osa jokaista digitaalisen kehityksen vaihetta. Mikään ohjelmisto ei ole virheetön, mutta luotettavuutta koskevat vaatimukset vaihtelevat: virheiden sieto on aivan erilainen esimerkiksi ilmailualan ohjelmistossa kuin mobiilipeleissä.
Vaatimusten ja testausprosessin määrittely on välttämätöntä, jotta voidaan saada aikaan kaikkien osapuolten odotukset täyttäviä tuloksia. Yksi testauksen keskeinen osa-alue on ongelman havaitseminen digitaalisen tuotteen käyttöönoton jälkeen.
Testaussuunnitelmalla määrittelemme testauksen säännöt ja tavoitteet projektiin parhaiten sopivalla tavalla.
Rajaamme mitä testauksen piiriin kuuluu ja mitä ei, kuka vastaa eri testausalueiden organisoinnista ja toteuttamisesta, mitkä ympäristöt meidän on otettava huomioon testauksessa ja miltä testausaikataulu näyttää.
Aika ja budjetti rajoittavat aina testausta. Testaussuunnitelman tulee heijastaa yhteistä ymmärrystä siitä, mitä laatu tarkoittaa kyseisessä projektissa.
Mobiilisovelluksia testattaessa on otettava huomioon suuri määrä käyttöjärjestelmien ja laitteiden yhdistelmiä. Verkkosovelluksissa sama pätee selaimiin ja selainversioihin.
Laitteiden ja käyttöjärjestelmien testimatriisit (mobiilisovelluksille) sekä laitteiden ja selainten testimatriisit (verkkosovelluksille) auttavat määrittämään, mitkä käyttötapaukset on tärkeää priorisoida.
Ajankohtaisten markkinatietojen ja kunkin tuotteen yksilöllisten vaatimusten perusteella luomme kartan todennäköisistä käyttöjärjestelmien, laitteiden ja versioiden yhdistelmistä. Näitä voidaan sitten priorisoida ajan ja budjetin perusteella.
Prosessit, vastuut, tavoitteiden määrittely ja laatu. Excel/Numbers-asiakirja käyttäjän toiminnasta ohjelmistossa. Sisäisen testiryhmän muodostaminen.
Testausohjeet
Testausohjeasiakirjan laatiminen ja jakelu. Tiedossa olevien ongelmien luettelointi.
Jakelu asiakkaalle
Asiakkaan testiryhmän muodostaminen. Jakelu valitulla prototyyppityökalulla ja sen käytön opettaminen asiakkaalle.
Toiminnallisuustestaus
Päästä päähän
Testaustulosten dokumentointi
Testauksesta tehdyn transkription luominen ja päivittäminen.
Ongelmien siirto GitLabiin
Ongelmien korostaminen ja lisääminen GitLabiin.
Yhteensopivuustestaus
Erilaiset laitteet, selaimet, käyttöjärjestelmät jne.
Syvällinen perehtyminen analytiikkaan ei kuulu tämän oppaan aihepiiriin. Seuraavaa checklist on kuitenkin yleispätevä lähtökohta, jota voidaan laajentaa kulloisenkin projektin tarpeiden mukaan.
Syitä tietojen keräämisen:
Tärkein dataan liittyvä sääntö on, että keräämättä jäänyttä dataa ei saa enää koskaan takaisin. Siksi tuote on integroitava heti oikeisiin analytiikkatyökaluihin.
Kun dataa kertyy pidemmältä ajanjaksolta, sitä voidaan hyödyntää myöhemmin monimutkaisempiin käyttötarkoituksiin. Kun siis alat vastaanottaa dataa muista lähteistä (esim. digitaalisesta markkinoinnista), muista integroida se myös käyttämääsi analytiikkaan.
Teknisellä puolella on ratkaisevan tärkeää kerätä virhelokeja, joiden avulla voidaan korjata virheitä ja käytettävyysongelmia myöhemmässä vaiheessa.
Analytiikkaratkaisun luomisen tulisi alkaa keskustelemalla siitä, mitkä ovat käytettävät KPI-mittarit. Miten mittaamme käyttötapoja? Mitkä toimet lasketaan konversioiksi? Voimmeko linkittää markkinointikanavat analytiikkaamme ja mitata siten kampanjoidemme onnistumista?
Yleisimmin käytetyissä analytiikka-alustoissa (esim. Google Ads, Localytics) riittää ominaisuuksia lähes kaikkiin tarpeisiin, mutta käyttäjän on varmistettava, että asetukset ja integraatiot toimivat niin kuin on tarkoitus.
Kun perusanalytiikan asetukset ovat valmiit, tärkeimmät mittarit on hyvä sisällyttää koontinäyttöön, josta niitä on helppo käyttää.
Digitaaliseen projektiin liittyy aina riskejä, joista osa on todennäköisempiä kuin toiset. Riskit voivat olla sisäisiä tai ulkoisia. Useimmissa ohjelmistoissa on integraatioita muihin palveluihin, ja ne ovat alttiita tällaisten kolmansien osapuolten tuotteiden mahdollisille ongelmille.
Riskien kontrollointi sisältää valmistautumisen ongelmien ilmenemiseen ja toimintatavat niiden hoitamiseksi. Yhdysvaltain ilmavoimien alun perin kehittämä OODA-loop on erittäin tehokas riskienkäsittelytyökalu. Se sisältää neljä vaihetta, jotka vastuullisen organisaation on toteutettava.
Havainnointi (Observation)
Ongelman havainnointi, mieluiten etukäteen
Tilanteen arviointi (Orientation)
Ongelman vakavuuden ja laajuuden määrittäminen
Päätös (Decision)
Asianmukaisten päätösten tekeminen
Toiminta (Action)
Asianmukaisten tehtävien suorittaminen
Uhka- ja turvallisuusanalyysi auttaa sekä lieventämään näitä vaaroja että varmistamaan, että olemassa on suunnitelma siltä varalta, että jotain menee pieleen. Valmistautuminen ja varasuunnitelmat ovat olennaisen tärkeitä näiden uhkien välttämiseksi.
Kolmansiin osapuoliin liittyvät riskit voivat vaihdella tilapäisistä käyttökatkoista tietojen turmeltumiseen. Nämä vältetään parhaiten hajauttamalla palvelu useille palveluntarjoajille ja pitämällä yksityisiä varmuuskopioita kriittisistä tiedoista (jos mahdollista). Myös kolmansien osapuolten palvelut ovat alttiita muutoksille.
Tekninen arkkitehtuuri kannattaa usein rakentaa siten, että se ei ole liian riippuvainen minkään yksittäisen kolmannen osapuolen tuotteen toteutuksen yksityiskohdista.
Palvelunestohyökkäykset, tietovarkaudet ja niihin liittyvä rikollinen toiminta ovat aina mahdollisia. Tämän torjumiseksi on aina vältettävä ”kaikki yhden lukitun oven takana” ilmiötä varmistamalla, että kaikkialla on käytössä ainutlaatuiset ja turvalliset määritykset.
Kehitystiimissä on hyvä olla turvallisuuteen liittyvää DevOps-osaamista. Usein on välttämätöntä salata arkaluonteiset tiedot ja pitää tietokantoja erillisillä, tavallista turvallisemmilla palvelimilla.
Yksikkö- ja integrointitestit ovat välttämättömiä, koska ne mahdollistavat muutosten tekemisen ja jatkokehityksen niin, että yksittäisen komponentin tai tuotteen rikkoutumisen riski on pienempi. Ongelmien välttämiseksi tämä tulee aina ottaa huomioon myös budjetissa.
Lisäksi koskaan ei saa syntyä tilannetta, jossa vain yksi henkilö todella tuntee koodin. Tämä voidaan välttää yhteistyöhön perustuvilla vertaiskatselmuskäytännöillä kehitystiimissä.
Sosiaalisia riskejä ovat muun muassa henkilösuhteisiin liittyvät ongelmat, avainhenkilöiden poistuminen yrityksistä sekä työkulttuurin ongelmat. Digitaalisissa projekteissa ei kannata olla rocktähtiä vaan tiimejä, jotka työskentelevät yhdessä yksikköinä ja dokumentoivat työnsä tavalla, joka helpottaa uusien ihmisten mukaantuloa.
Kulttuurin kannalta avainasemassa on tiimin hyvinvoinnin mahdollistaminen ja seuranta sekä avoimen keskustelun edistäminen. Sosiaalisiin suhteisiin liittyvät ongelmat tulee aina hoitaa pikaisesti, ja tulee keskittyä toimiin, jotka auttavat välttämään tällaisten tilanteiden syntymistä.
Force majeure -tilanteet eli ylivoimaiset esteet, kuten onnettomuudet, ilkivalta, sota ja ympäristökatastrofit, vaikuttavat myös ohjelmistokehitykseen.
Maailma voi olla arvaamaton. Siksi on tärkeää luoda prosessi, jonka avulla luodaan varmuuskopioita yrityksen tilojen ulkopuolella sijaitsevaan paikkaan ja pidetään ne aina ajan tasalla sekä huolehditaan fyysisten tilojen turvatoimista.
Tietoja voi hävitä vioittuneiden tiedostojen tai fyysisten vaurioiden vuoksi. Kun tiedot ovat saatavilla useissa (turvallisissa) paikoissa sekä digitaalisesti että fyysisesti, tiimi voi nukkua yönsä rauhassa.
Onnistuneen digitaalisen tuotteen tärkeimmät osa-alueet ovat selkeät tavoitteet, oikea osaaminen, kunnolliset työkalut – ja viimeisenä muttei todellakaan vähäisimpänä: yhteistyö.
Kun nämä osa-alueet ovat kunnossa, digitaalinen projekti voi olla inspiroiva matka ideasta valmiiksi tuotteeksi.
Autamme digitaalisen tuotekehityksen kaikissa vaiheissa. Ota yhteyttä ja keskustellaan lisää.
Liiketoiminnan kehityspäällikkö
henri.ranki@taiste.com+358 44 500 1364Onko sinulla projekti, josta haluaisit keskustella?
Liiketoiminnan kehitys-päällikkömme Henri on hyvä henkilö sparraamaan tarpeitasi.
Toimistokoordinaattori
vilma.merikanto@taiste.com+358445568459Onko sinulla kysyttävää tapahtumista, yhteistyöstä jne.?
Toimistokoordinaattorimme Vilma auttaa mielellään.
Harkitsetko hakemista töihin Taisteen? Henkilöstöpäällikkömme Laura voi auttaa sinua kaikissa kysymyksissäsi.
