Käyttökokemus ratkaisee – panosta siihen fiksusti

Verkkopalveluiden muutospaineet keskittyvät usein ulkoasuun ja toiminnallisuuteen. Kuluttajakaupassa rahaa ei tehdä tietorakenteilla ja taustajärjestelmillä, vaikka ne ovatkin kriittinen osa kokonaisuutta.

Jos kauppa ei tao verkossa tulosta, kutsuu järkevä asiakas paikalle tuskan määrästä riippuen joko palvelumuotoilijan tai käyttöliittymäsuunnittelijan. Verkkopalvelun pintaa sitten hierotaan, kunnes sen käyttökokemus on kohdillaan ja kassavirta kasvaa toivotulle tasolle.

Käyttöliittymä ja taustajärjestelmä erillään

Perinteinen ohjelmistokehitysmalli kytkee käyttöliittymän ja sen taustajärjestelmän tiukasti toisiinsa. Jos toiseen koskee, joudutaan muokkaamaan toistakin. Tuplatyö on hidasta ja molemmat pitää tietenkin testata huolellisesti, jotta homma ei karahda karille heti palvelun julkaisun jälkeen. Kehityksen hitaus ja kalleus summaa oivasti sen, minkä takia usein tyydytään keskinkertaiseen käyttökokemukseen eikä palveluihin uskalleta koskea enää julkaisun jälkeen.

Meidän ratkaisumme on erottaa käyttöliittymä ja taustajärjestelmä erillisiksi kokonaisuuksiksi, jotka kuitenkin pelaavat yhteen. Näin vältämme tuplatyön, kehitystyö sujuu näppärästi eikä korkea hintalappu säikäytä asiakasta. 

Suunnittelu ja toteutus yhdessä

Suunnittelu on projektin tärkein osuus, jossa tekniikka ja tunteet nidotaan yhteen. Näin syntyy loppuasiakkaan käyttökokemus. Kuten kaikki myyjät tietävät, on kaupanteko myös tunnepeliä. Siksi positiivinen erottautuminen perusverkkokaupasta tai ajanvarausjärjestelmästä palkitaan varmasti. Meillä designerit ovat aina osa toteutustiimiä, sillä projekteja toteutetaan ketterästi vaiheittain ja tiivis kommunikaatio koodaajaporukan kanssa on välttämätöntä.

Tekniikan kehittymisen myötä käyttöliittymien suunnittelu ja toteutus on erikoistunut omaksi taiteenlajikseen, ja niinpä meilläkin on monia siihen erikoistuneita osaajia.

Käyttöliittymän toteutustekniikka valitaan aina asiakastarpeen mukaan. Frontend-puolella pinnalla olevat tekniikat vaihtuvat viikoittain ja muotivirtausten huipulla pysyminen on kallista ja turhauttavaa. Onkin järkevää valita vakiintuneita ja luotettavia ratkaisuja, jotka todennäköisesti ovat tuettuja vielä parinkin vuoden päästä.

Taustajärjestelmänä käytämme useimmiten Drupalia sen joustavuuden ja valmiiden komponenttien takia. Drupal on laajoihin kokonaisuuksiin tarkoitettu avoimen lähdekoodin sisällönhallintajärjestelmä.

Se on helppo saada keskustelemaan muiden asiakkaan käytössä olevien järjestelmien, kuten autentikointipalveluiden, tilausjärjestelmien tai markkinointiautomaatiosoftien kanssa. Valmistuote taustajärjestelmänä säästää aikaa ja mahdollistaa keskittymisen käyttökokemuksen kehittämiseen. Palvelu saadaan nopeasti markkinoille, minkä jälkeen sen käyttökokemusta on helppo viilata käyttäjiltä saadun palautteen perusteella.

Onko palvelusi käyttöliittymä myyvä?

Kuluttaja käyttää palveluita onnellisen tietämättömänä taustajärjestelmän hienouksista. Hän on kuitenkin yhä vaativampi ja valikoivampi palveluiden tarjoaman kokemuksen suhteen. Yhä useammin juuri palvelun käyttökokemus ratkaisee, ostaako kuluttaja vai ei. Jos ostoaie ei realisoidu, voimme yhdessä asiakkaamme kanssa kehittää käyttöliittymää myyvemmäksi aiempaa helpommin ja nopeammin.

Ota yhteyttä ja kerro meille haasteistasi, niin etsitään niihin yhdessä ratkaisut.

Drupalgeddon 2 – bugi ja kuinka se korjattiin

28.3.2018: “Kriittinen haavoittuvuus Drupal -sisällönhallintaohjelmistossa. Päivitä viipymättä!”

Eräänä kevättalvisena iltana ohjelmistokehittäjämme Jasper Mattsson selaili työpäivänsä päätteeksi Drupal-julkaisujärjestelmän uusimman version lähdekoodia perehtyäkseen sen ominaisuuksiin ja selvittääkseen, kuinka päivityksen tuomia ominaisuuksia voisi hyödyntää omassa työssään sekä tutkiakseen samalla järjestelmän mahdollisia haavoittuvuuksia.

“Homma lähti siitä, että halusin opetella Drupal kasia. Luin sen lähdekoodia läpi ja aloin miettiä, että voisivatko jotkin asiat aiheuttaa tietoturvaongelmia. Sitten aloin etsimään ja purkamaan muutamaan eri asiaan liittyviä ongelmia. Tässä vaiheessa minulla ei ollut edes Drupalia asennettuna tätä varten – kaikki etsiminen tapahtui lähdekoodia lukemalla.”

Kokeneelle ohjelmistokehittäjälle muiden kirjoittaman koodin tutkiminen on rutiininomainen keino tutkia, kuinka muut ovat ratkaisseet tiettyjä ongelmia ja siten syventää myös omaa osaamistaan. Käytäntöä voisi verrata minkä tahansa teknisen laitteen purkamiseen ja erillisten osien sekä niiden välisten kytkentöjen tutkimiseen. Yleensä osia ja kytkentöjä – tässä tapauksessa koodia – tutkimalla ei löydy juuri käytännön pikkuniksejä ihmeellisempää, mutta tuona iltana tilanne oli toinen.

Bugi löytyy

“Kiinnitin huomiota tapaan, jolla joissain lomakkeissa käsiteltiin käyttäjän syöttämiä arvoja ja aloin sen perusteella etsiä kohtia, joissa tästä voisi seurata tietoturvaongelmia.”

Jasper huomasi, että ohjelmointivirheen avulla Drupal oli mahdollista saada käsittelemään käyttäjän lomakkeelle syöttämiä arvoja ohjelmakoodina. Tämän avulla hyökkääjä voi esimerkiksi ajaa omaa haittakoodiaan Drupalissa. Näin on esimerkiksi onnistuttu asentamaan kryptovaluuttojen mainaukseen tarkoitettuja ohjelmia palvelimelle sivuston ylläpitäjän tietämättä. Hyökkäyksiä tehdään automatisoidusti – hakkeroidut sivustot valjastetaan hyökkäämään muihin päivittämättömiin sivustoihin. Ovelimmat automaattisista hyökkäyksistä asentavat Drupaliin tietoturvapäivityksen päästyään sisään, jotta kilpailevat hyökkääjät eivät pääse palvelimelle.

Itse bugiin liittyi kaksi puolta; vahingollisen syötteen saaminen Drupaliin sisään ja se, että Drupalin sai suorittamaan sen koodina. Mikäli satunnainen lähdekoodia tutkiva henkilö olisi löytänyt vain toisen näistä ongelmista, hän ei välttämättä olisi ajatellut kyseessä olevan tietoturvaongelma. On varsin todennäköistä, joskin täysin spekulatiivista, että molemmat yksittäiset ongelmat ovat olleet joidenkin toimijoiden tiedossa, sillä haavoittuvuus oli ehtinyt ollut Drupalissa ainakin vuonna 2011 julkaistusta 7-versiosta lähtien, sekä mahdollisesti jossain muodossa jo vuonna 2008 julkaistussa Drupal 6:ssa. Kahden satunnaisen pikkuongelman havaitsemisen lisäksi erityisen ratkaisevaa tässä tapauksessa oli kuitenkin ongelmien välisten syy-seuraussuhteiden ja niiden yhdessä muodostaman riskin vakavuuden ymmärtäminen.

Korjaustoimenpiteet

Ensimmäisestä huomion herättäneestä havainnosta bugiepäilyn vahvistamiseen kului aikaa vain muutamia tunteja. Ongelman havaittuaan Jasper raportoi bugin Drupalin tietoturvatiimille ja ilmoitti havaintonsa tueksi esimerkkitilanteen (Proof of Concept), jossa haavoittuvuus oli hänen koneellaan ilmennyt. Tarvittavien tietojen raportoimiseen kului aikaa muutama päivä, tosin esimerkkitilanteen toistamisessa oli alkuvaikeuksia.

Hyvin pian vapaaehtoisista ja luotettaviksi todetuista Drupal-kehittäjistä koostuva tietoturvatiimi pääsi kuitenkin tekemään korjauksia. Myös Jasper osallistui niiden testaamiseen, mahdollisten uusien aukkojen etsimiseen ja korjausehdotuksiin liittyvään keskusteluun.

“Drupalin tietoturvatiimi kehitti korjauksia nopealla tahdilla ja hyvällä yhteistyöllä – keskustelun ja korjauksien testaamisen tahdissa ei meinannut pysyä mukana”.

Kehittämiseen vierähti muutama viikko ja useampi iteraatiokierros ennen kuin päivitys oli saatu riittävälle tasolle julkaisua varten.

Kun tietoturvatiimillä oli aukko tiiviisti tilkittynä, he tiedottivat korjauspäivityksen julkistamisajankohdan. Tässä vaiheessa itse haavoittuvuuden yksityiskohdat pidettiin luonnollisesti vielä tiukasti salassa ja kerrottiin vain, että kyseessä on kriittinen tietoturva-aukko. Myös päivitysversion korjaukset koordinoitiin ja toteutettiin siten, ettei päivityksen koodista pystyisi helposti päättelemään mistä tietoturva-aukko tarkemmin löytyisi.

Välttämättömät korjaukset paikkaava päivitys julkaistiin pääsiäistä edeltävänä keskiviikkona 28.3. jolloin Druidilla sekä muissa Drupal-taloissa oltiin valmiudessa päivittämään sivustot. Drupal.org kaatui hetkellisesti suuren kävijämäärän vuoksi kehittäjien ladatessa sivua uudelleen malttamattomina.

Ennen päivitystä pelättiin, että päivityksen perusteella saattaisi huolellisista varotoimista huolimatta olla mahdollista päästä tietoturva-aukon jäljille ja että sitä hyödyntävää haittakoodia voisi olla tarjolla hyvinkin pian päivityksen julkaisun jälkeen. Näin oli käynyt ensimmäisen Drupalgeddon-haavoittuvuuden kanssa vuonna 2014. Ensimmäiset haavoittuvuutta käyttävät hyökkäykset huomattiin kuitenkin vasta 11.4., joten sivustojen ylläpitäjillä oli lähes kaksi viikkoa aikaa päivittää sivustonsa.

Mikäli sivustosi jäi Drupalgeddonin jalkoihin tai tarvitset luotettavaa kumppania pitämään huolta verkkopalveluistasi, ota meihin yhteyttä!

Kuinka visualisoida sprintin tila JIRAssa?

Valittu projektimalli on usein ratkaisevassa asemassa projektin onnistumisen kannalta. Siksi me Druidilla vannomme ketteryyden ja Scrumin nimeen. Scrum edellyttää, että kaikki tehtävä työ kasataan yhteen paikkaan, jotta sitä voidaan hallinnoida järkevästi. Vaikka tämä onnistuisi ihanan hipsteristi seinällä ja paperilapuilla, olemme päätyneet käyttämään insinöörimäisempää JIRA-projektinhallintaohjelmistoa. Se mikä hipsteriydessä hävitään, voitetaan monin verroin takaisin erilaisilla näkymillä, kattavalla raportoinnilla ja muilla hyödyllisillä ominaisuuksilla.

Vakioasetuksilla JIRA luo Scrum-projektille kaksi näkymää: backlog-näkymän sekä näkymän aktiiviseen sprinttiin. Lisäksi työnkulku on yksinkertaisesti mallia “To Do → In progress → Done”. Monille tämä riittää…vai riittääkö? Testataanpa.

Backlog-näkymässä luodaan tarinoita, annetaan pisteet, kasataan sprintti ja käynnistetään se. Tarinoille lisätään (tekniset) alitehtävät. Toistaiseksi kaikki on kunnossa. Näkymä vaihdetaan aktiivisen sprintin puolelle. Otan yhden tarinoista tekoon. Näen helposti, mitä alitehtäviä tarinalla on ja missä tilassa ne ovat. Yksi kerrallaan alitehtävät valmistuvat, kunnes kaikki on tehty. Story on valmis!

Eipäs kun hetkinen… Pitäähän valmistunut tarina kierrättää vertaisarviossa, jotta työn tekninen laatu voidaan varmistaa. Ja toki tuoteomistaja haluaa tarkastaa erillisessä testausympäristössä, että tarinan vaatimukset täyttyvät ennen hyväksymistä. Hmm… Pitäisikö näistä tehdä erilliset alitehtävät? Jokaiselle tarinalle? Kuulostaa toistuvalta käsityöltä.

Oikea ratkaisu on noudattaa hyvän ohjelmistoarkkitehtuurin kultaista sääntöä: luo mallinnettava kokonaisuus järjestelmän tarjoamilla ominaisuuksilla, jolloin järjestelmä “ymmärtää”, mitä olet tekemässä. Tässä tapauksessa tarkoituksena on mallintaa tarinoiden matka alusta loppuun, joten ensimmäinen askel on laajentaa JIRA-projektin työnkulku kattamaan kaikki mahdolliset vaiheet. Tarvittavat askeleet vaihtelevat projekteittain. Tässä yksi esimerkki:

• Sprint Backlog (Kehitystyötä ei aloitettu)
• In progress – Frontend (Frontend-kehitystyö käynnissä)
• In progress – Backend (Backend-kehitystyö käynnissä)
• Development Done (Kehitystyö valmis)
• Peer Review & Deployment (Toisen kehittäjän vertaisarviointi)
• Acceptance testing (Tuoteomistajan hyväksymistestaus)
• Done (Story tehty ja hyväksytty)

Tässäkin asiassa kannattaa toimia ketterästi. Ensimmäinen versio tehdään parhaan tiedon mukaan ja sen jälkeen vaiheita muutetaan saadun kokemuksen perusteella. (Pro tip: Projektin workflowksi kannattaa valita “Simplified Workflow”, jolloin muutosten tekeminen on helpompaa.)

Kun työnkulku on kunnossa, tehdään taikuuksia näkymille. Aktiivisen sprintin näkymän tulee edelleen toimia kuin aiemminkin, jotta kehittäminen sujuu mahdollisimman helposti. Siksi näkymässä ei tarvita kuin neljä ensimmäistä askelta (Sprint Backlog–Development Done). Sen lisäksi luodaan uusi näkymä, joka kulkee meillä nimellä Review. Review-näkymän tehtävänä on näyttää sprintin tila yhdellä silmäyksellä sekä mahdollistaa työn käsittely tarinatasolla, jota putken loppupäässä tarvitaan. Lisäksi haluamme niputtaa ensimmäiset neljä askelta (Sprint Backlog–Development Done) yhteen sarakkeeseen nimeltä Develop, sillä siellä työskennellään alitehtävien parissa ja nyt olemme kiinnostuneita itse tarinoista.

Katso tarkemmat asennusohjeet videosta:

Lopputuloksena tarinoiden kulku on mallinnettu JIRAan, eikä niiden tiloja tarvitse enää arvuutella tai muistella. Lisäksi kaikkien – jopa projektin ulkopuolisten tahojen – on helppo tarkistaa, miten sprintti menee.

Visualisointi auttaa myös hahmottamaan pullonkauloja: jos esimerkiksi nähdään, että tarinoita kertyy jatkuvasti vertaisarviointisarakkeeseen, kehitysprosessia tulee muuttaa vertaisarviointia suosivaan suuntaan. Poikkeuksia tapahtuu, mutta jatkuvat sumat kielivät yleensä puutteellisesta prosessista. Onneksi Scrumiin sisäänrakennetuissa retrospektiiveissä asia voidaan nostaa esille ja korjausehdotusta on helppo lähteä kokeilemaan. Näkymät näyttävät suoraan, onnistuiko kokeilu vai ei.

Pari tunnettua ongelmaa:

– Sprintin päätteeksi tarinat ovat Done-tilassa, mutta niiden alitehtävät jäävät Development Done -tilaan. Ennen sprintin sulkemista alitehtävät on käytävä siirtämässä Done-sarakkeeseen. Homman voi hoitaa kerralla kaikille alitehtäville etsimällä ne Issue Navigatorilla ja muuttamalla tila Bulk edit -työkalulla. Korjauksen voi myös hoitaa ohjelmallisesti JIRAn omalla skriptikielellä, mutta emme ole vielä menneet niin pitkälle.

– Review-näkymässä pitää erikseen painaa Only stories -filtteri päälle. Jos klikkailu ärsyttää, pikaratkaisuna näkymän voi lisätä selaimen kirjanmerkkeihin ja tuoda kirjanmerkkityökaluriville. Me kehittäjät käytämme Grease Monkey -skriptejä, jotka ohjelmallisesti lisäävät oikeanlaiset linkit selaimiimme.