Digitaalisten tuotteiden suunnittelulla on verrattain lyhyt historia. Graafisten käyttöliittymien yleistyttyä 80-luvulla ja tietokoneiden tultua suuren yleisön saataville, on digitaalisten tuotteiden suunnittelussa keskitytty niiden käyttäjiin niiden toteuttajien, eli koneiden, sijaan. Alaa ovat ohjanneet suunnilleen viimeiset 40 vuotta käyttäjäkeskeisen suunnittelun periaatteet. Mutta onko käyttäjäkeskeisen suunnittelun aikakausi nyt ohi?

Tässä blogitekstissä kerron kestävästä UX-suunnittelusta, ja siitä miksi meidän olisi syytä siirtyä käyttäjäkeskeistä kestävään suunnitteluun. Avaan myös esimerkkien avulla mitä se tarkoittaa käytännön tasolla.

Mitä on kestävä UX-suunnittelu?

Digitaalisten tuotteiden vaikutusta ympäristöön on hankalampi tiedostaa, kuin fyysisten tuotteiden. Meille kaikille on selvää, että t-paidan tuottamiseen tarvitaan puuvillaa, jonka viljelyyn puolestaan kuluu valtavasti vettä. Mutta tulemmeko ajatelleeksi, kuinka paljon energiaa tarvitaan lataamaan verkkokauppa, josta t-paidan tilaamme? Tai mikä merkitys on sillä, tilaammeko paidan suoraan kotiovellemme vai lähimpään pakettiautomaattiin? Yksittäisellä latauksella on ehkä mitättömältä tuntuva vaikutus, mutta silloin kun puhutaan jopa kymmenistä tuhansista päivittäisistä vierailijoista sivustolla, on energiankulutus merkittävää.

…the internet – including data centres, telecoms networks, and end user devices like phones and laptops – uses a lot of electricity. In fact, if you add it all together, the internet uses roughly the same amount of electricity as the UK, one of the world’s largest economies.
– Tom Greenwood, Wholegrain Digitalin perustaja ja Sustainable Web Design kirjan kirjoittaja

European Climate Pact -sivustolla väitetään, että EU:ssa digitaalisten teknologioiden päästöt ovat verrattavissa jopa lentoliikenteen päästöihin. Keskittyessämme tyydyttämään käyttäjien tarpeet olemme kenties ylenkatsoneet suunnittelemiemme tuotteiden vaikutusta laajemmin.

Kestävästä UX-suunnittelusta puhutaan, kun suunnitteluprosessissa otetaan huomioon tuotteen vaikutukset ympäristöön ja ihmisiin (siis muihinkin, kuin tuotteen käyttäjiin). Siinä missä käyttäjäkeskeisellä suunnittelulla pyritään vastaamaan käyttäjien tarpeisiin mahdollisimman hyvin ja luomaan käyttäjille miellyttäviä kokemuksia, kestävällä suunnittelulla pyritään luomaan tuotteita, jotka kuormittavat ympäristöä mahdollisimman vähän sekä ovat oikeudenmukaisia ja reiluja käyttäjiä kohtaan. Kestävässä suunnitteluprosessissa ympäristövaikutukset, oikeudenmukaisuus ja reiluus painavat vaakakupissa enemmän, kuin käyttäjien tarpeisiin vastaaminen ja heidän mieltymyksiinsä vastaaminen. Onneksi nämä eivät välttämättä poissulje toisiaan, vaan voivat edesauttaa toistensa toteutumista.

Saavutettavuus ja oikeudenmukaisuus ovat osa kestävää designia

Kestävässä UX-suunnittelussa otetaan ympäristövaikutusten lisäksi huomioon yhteiskunnalliset vaikutukset. Periaatteisiin kuuluu, että tuotteet ovat paitsi saavutettavia, myös tasa-arvoisia, ja eettisiä – toisin sanoen ne pistävät käyttäjien ja kaikkien ihmisten hyvinvoinnin yrityksen tuloksen edelle. Kestävän suunnittelun rinnalla voitaisiinkin puhua vastuullisesta suunnittelusta.

Digitaalisten tuotteiden ei tulisi tehdä epäoikeudenmukaisia oletuksia tai vahvistaa olemassa olevia stereotypioita ja ennakkoluuloja. Suunnittelija voi vaikuttaa tähän jo aivan prosessin alusta asti esimerkiksi rekrytoimalla käyttäjätutkimukseen osallistujia, jotka edustavat taustoiltaan erilaisia ihmisryhmiä. Käyttöliittymiä suunnitellessaan suunnittelijan tulee kiinnittää huomiota esimerkiksi käyttämiinsä kuvituksiin ja ikoneihin. Tarvitseeko esimerkiksi kädenpuristus-ikonissa välttämättä olla kalvosinnapeilla varustettuja hihoja?

Eettisesti suunniteltu tuote priorisoi käyttäjien hyvinvoinnin yrityksen tavoitteiden edelle. Onko esimerkiksi tavoittelemisen arvoista suunnitella tuotetta, jonka parissa käyttäjät viettävät mahdollisimman paljon aikaa? Vai voiko sillä olla vaikutusta käyttäjien mielenterveyteen tai unen laatuun? Konversioiden kasvattaminen on usein yritysten tavoitteena, mutta se saattaa kannustaa suunnittelijoita käyttämään niin sanottua harhauttavaa suunnittelua (deciptive tai dark patterns). Harhauttava suunnittelu nimensä mukaisesti harhauttaa käyttäjiä toimimaan yrityksen etujen mukaisesti esimerkiksi manipuloimalla käyttäjän tunteita tai tarkoituksella vaikeuttamalla yritykselle epäedullisen valinnan tekemistä. Siinä missä tällaiset tavat voivat tuntua tehokkailta esimerkiksi konversioiden lisäämisessä, ne kostautuvat usein pitkässä juoksussa käyttäjien tyytymättömyytenä ja huonona suhtautumisena brändiin.

Ympäristötietoinen design

There are always additional actors (human and non-human) involved besides our users — directly or indirectly. We must stop designing solely for our users and instead always understand and review our work within the systemic context.
– Thorsten Jonas, Sustainable Design Networkin perustaja

Digitaaliset tuotteet “elävät” aina jossakin kontekstissa ja niiden vaikutus ulottuu käyttäjiään laajemmalle. Vastuullinen suunnittelija ottaa huomioon myös tekemiensä päätösten epäsuorat vaikutukset niin käyttäjiin kuin muihinkin vaikutukselle alttiisiin tekijöihin. Otetaan esimerkeiksi Uber ja Bolt. Millainen vaikutus näiden sovellusten käytön yleistymisellä on esimerkiksi julkisen liikenteen käyttöön ja sitä kautta päästöihin? Miten käyttäjiä voisi kannustaa ympäristöystävällisempiin valintoihin, kuten sähköautoiluun tai kimppakyyteihin? Tai kuinka suuri merkitys on sillä, että kuskit pitävät autojaan tyhjäkäynnillä odotellessaan kyytiläisiä? Suunnittelija ei voi pohtia tuotteiden vaikutuksia loputtomasti, sillä hänen on saatava myös jotain valmista aikaiseksi. Suunnittelijalle on silti keskeistä omata kyky kyseenalaistaa asioita. Designpäätösten vaikutus ulottuu lopulta ympäristön lisäksi myös yhteiskuntaan.

Luultavasti itsestään selvin tapa parantaa digitaalisen tuotteen ympäristöystävällisyyttä on vaikuttaa tuotteen energian kulutukseen ja sen kuluttaman energian alkuperään. Voimme esimerkiksi suosia uusiutuvalla energialla toimivia palvelinkeskuksia. Tuotteen energiankulutukseen puolestaan voi vaikuttaa mm. värien käytöllä, fonttivalinnoilla ja tehokkaalla designilla, joka vaatii vähemmän serveripyyntöjä ja suurten datamäärien käsittelyä. Yleisesti ottaen tummat värit kuluttavat vähemmän energiaa kuin kirkkaat värit. Tämä tosin pätee vain moderneilla OLED-näytöillä, ja niilläkin suurin vaikutus saadaan kun näytön kirkkaus on säädetty maksimiin. ZDNETin artikkelin mukaan Google on tutkinut asiaa ja raportoi mm. Google Mapsin yötilan vähentäneen näytön virrankulutusta 63 prosenttia verrattuna normaaliin tilaan.

Suunnittelija voi edesauttaa tuotteen vastuullisuutta merkittävästi myös ohjaamalla käyttäjiä tekemään vastuullisempia valintoja. Tämä voi yksinkertaisimmillaan olla tiedon jakamista käyttäjälle. Aiemmin esittelemässäni verkkokauppatilausesimerkissä ympäristöystävällisimmän toimitustavan voisi määrittää oletusvalinnaksi kaikille käyttäjille.

Vielä yksi keino ympäristöystävällisyyden varmistamiseen on pohtia laitteita, joilla digitaalista tuotetta käytetään. Nyrkkisääntönä on suunnitella tuotteita, jotka toimivat myös vanhoilla laitteilla, jolloin emme ainakaan myötävaikuta elektroniikkajätteen syntyyn.

Tekoäly ja vastuullisuus

Erityisesti tässä hetkessä, kun tutustumme tekoälyn tuomiin mahdollisuuksiin digitaalisten tuotteiden suunnittelussa, on vastuullisuuteen ja kestävyyteen tärkeä kiinnittää huomiota. Tekoälyn tiedetään kärsivän harhoista ja tekevän vääriä johtopäätöksiä tulkitessaan historiallista dataa. Meidän on aktiivisesti toimittava korjataksemme tällaiset eettiset haasteet. Tekoälyn avulla voidaan parantaa monen alan, kuten maatalouden ja rakennusalan, energiatehokkuutta ja pienentää ympäristölle koituvaa haittaa. Tästä huolimatta tekoälyn käyttö itsessään vaatii huomattavasti energiaa, joten siihen perustuvien ominaisuuksien sisällyttämistä tuotteisiin tulee harkita huolella.

Käytetty, mutta ehdottoman arvokas esimerkki suunnittelupäätösten haitallisista seurauksista erityisesti tekoälyn suhteen, on sosiaalisen median sovellukset. Elämme polarisoituneessa yhteiskunnassa, jossa ihmisten on vaikea sietää edes hieman omistaan poikkeavia näkemyksiä. Sosiaalisessa mediassa käytetyt sisältöä suosittelevat algoritmit kietovat käyttäjät aina vain tiiviimmin omien kupliensa sisään.

Erottaudu kilpailijoista kestävällä UX-suunnittelulla

Kestävään suunnitteluun panostaminen voidaan nähdä myös bränditekona. Kuten mainittu, saavutettavuuden huomioiminen on osa kestävää suunnittelua ja saavutettavat tuotteet ovat laajemman yleisön käytettävissä kuin ei-saavutettavat tuotteet. Kestävästi suunnitellut tuotteet ja prosessista kertominen voivat vedota erityisesti ympäristötietoisiin käyttäjiin, jolloin brändin asema heidän mielissään vahvistuu. Sama pätee niihin käyttäjiin, jotka arvostavat oikeudenmukaisuutta ja tasa-arvoisuutta.

Käyttäjäkeskeisyys UX-suunnittelussa on edelleen tärkeää, eikä siihen liittyviä periaatteita tule unohtaa. Olemme kuitenkin alkaneet Identiolla kiinnittää enemmän huomiota suunnittelemiemme tuotteiden kestävyyteen ja vastuullisuuteen. Design-periaatteisiimme on kirjattu kohta “Vastuullisuus” ja suunnittelijamme ovat luoneet työnsä tueksi vastuullisen suunnittelun tarkistuslistan. Haluamme osaltamme myötävaikuttaa kestävämmän ja paremman digitaalisen tulevaisuuden rakentamiseen, ja uskomme kestävyyden olevan monelle asiakkaallemme myös tärkeä arvo sekä valttikortti markkinoilla menestymiseen.

Lähteet:
Tom Greenwood – 20 ways to make your website more energy efficient – Wholegrain Digital
European Climate Pact – Going digital – good or bad for the climate?
Thorsten Jonas – The 11 principles of Sustainable UX – SUX – The Sustainable UX Network
Emilyann Gachko – Sustainable UX Design: Principles and Practices for Eco-Friendly Digital Products
Nielsen Norman Group – Deceptive Patterns in UX: How to Recognize and Avoid Them
World Economic Forum – AI and energy: Will AI reduce emissions or increase demand?

Lue myös: UI ja UX – mitä eroa niillä on?

Minimum Lovable Productia (MLP) käsittelevän blogisarjan viimeisessä osassa sukellamme digitaalisen tuotteen elinkaarivaiheeseen. Nyt olemme siinä vaiheessa, että ”vähimmäinen” on jo saavutettu ja tuote tulisi julkaista ja sitä pitää jatkokehittää ja/tai ylläpitää.

Kun MLP-tuote on valmis ja ehkä jo käytössä, on seuraava askel laajentaa sen ominaisuuksia kohti viimeistellympää kokonaisuutta. Tällöin keskitymme teknisen vakauden parantamiseen ja niiden lisäominaisuuksien toteuttamiseen, jotka jätimme alkuvaiheessa pois.

Tuotteesta riippuen tavoite voi olla joko varmistaa, että kertaluontoinen tuote on vakaa ja helposti ylläpidettävä sen koko elinkaaren ajan, tai kuten useimmissa tapauksissa – jatkaa kehitystä ja rakentaa entistä parempaa tuotetta rakastettavan perustan päälle.

Tuotteen julkaisu

Jos luit tämän blogisarjan aikaisemmat osat, niin tiedät, että alkuvaiheen kehitysprosessi on toteutettu tiiviissä yhteistyössä eri käyttäjäryhmien kanssa. Rakastettavan tuotteen myötä nämä alkuvaiheen käyttäjät voivat toimia ohjelmistosi parhaimpina lähettiläinä. Tämä voi näkyä esimerkiksi tuotteen laajempana käyttöönottona yritysympäristössä tai kuluttajasovelluksen varhaisina omaksujina.

Vaikka moni päätös tässä vaiheessa on tekninen, erityisesti skaalautuvuuteen kannattaa kiinnittää huomiota. Jos tuotteesi menestyy, joudut ratkaisemaan infrastruktuuriin liittyviä haasteita. ”Konepellin alla” olevat ongelmat, kuten kuormantasauksen tarpeet ja lisääntyvät datamäärät, voivat hidastaa vasteaikoja ja heikentää käyttökokemusta, joka aiemmissa testiryhmissä teki tuotteestasi rakastettavan. Nämä ovat yleisiä ohjelmistokehityksen haasteita, mutta vältettävissä rakastettavuuteen panostamalla. Pienetkin käyttöliittymän häiriöt voivat vahingoittaa mainettasi tärkeiden alkuvaiheen käyttäjien silmissä. Huonot ensivaikutelmat ovat erityisen vaikeita korjata hyviksi jälkeenpäin, olipa kyse sanallisesta palautteesta tai käyttäjän suorasta kokemuksesta.

On myös mahdollista, että käyttäjätestaus joka johti rakastettavaan lopputulokseen, on sisältänyt jotain huomaamatonta, joka ei välttämättä heijastu todellisiin käyttäjäryhmiin. Silloin on tärkeää selvittää, edustaako testausvaiheen käyttäjäryhmä todellista käyttäjäkuntaa vai onko tarpeen miettiä uutta suuntaa. Mitkä ovat tuotteesi rakastettavat ja vähemmän rakastettavat ominaisuudet? Mitä kannattaa säilyttää ja mistä kannattaa luopua?

Rakastettavan tuotteen ylläpitäminen ja sen jatkokehittäminen

Rakastettavuus on kontekstisidonnainen ominaisuus. Kun ohjelmisto saavuttaa elinkaarensa ylläpitovaiheen, pitäisi olla selvää, mihin rakastettavuus oikeastaan perustuu. Se voi tarkoittaa esimerkiksi ”konepellin alla” olevia teknisiä asioita, kuten nopeita vasteaikoja, jotka edellyttävät erityistä huomiota infrastruktuurin ylläpidossa ja skaalautuvuudessa.

Tekninen velka on hankala asia, joka voi hallitsemattomana kasvaa eksponentiaalisesti ja muodostua kehityksen esteeksi. Tämä voi johtaa siihen, ettei uusia päivityksiä ja ominaisuuksia pystytä toimittamaan halutussa aikataulussa. Tässä vaiheessa on tärkeää ymmärtää, mikä tekee tuotteestasi rakastettavan: missä tuotannon alkuvaiheessa otetut oikopolut alkavat kostautua merkittävästi? Esimerkiksi nopea ja huolimaton tietokantaratkaisu saattaa olla järkevää päivittää hajautettuun ja skaalautuvaan järjestelmään, jos se estää rakastettavan tuotteen kaatumisen siinä vaiheessa, kun ohjelmisto saavuttaa alkuperäistä laajemman käyttäjäkunnan. Toisaalta rakastettava tuote voi houkutella innokkaita käyttäjiä, jotka vaativat uusia ominaisuuksia – ja viivästykset taas saattavat turhauttaa heitä. Esimerkkejä tällaisista tilanteista löytyy usein peliteollisuudesta.

Usein kuitenkin käyttäjäkokemus (UX) käy läpi muutoksia jatkuvan kehityksen myötä. Jatkuvasti kehittyvän ohjelmiston kohdalla on houkutus lisätä yhä uusia ominaisuuksia eri käyttötarkoituksiin tai liittää ohjelmisto eri ulkoisiin palveluihin. Tällainen ylimääräinen kuorma voi kuitenkin heikentää käyttäjäkokemuksen rakastettavuutta, muuttaen yksinkertaisen ja selkeän käyttöliittymän sekavaksi ja raskaaksi kokonaisuudeksi. Toisaalta lisäominaisuudet voivat olla juuri sitä mitä käyttäjät haluavat tai tarvitsevat. Voimme kuitenkin integroida uusia elementtejä rakastettavuutta vaarantamatta. Tapauskohtaisesti tämä voi tarkoittaa esimerkiksi muokattavaa käyttöliittymää käyttäjän tarpeisiin tai harvemmin käytettyjen ominaisuuksien siirtämistä erillisiin näkymiin.

Vaikka houkutus lisätä uusia ominaisuuksia on suuri, on tärkeää miettiä, voimmeko toteuttaa ne rakastettavasti. Jos tuotteen pääominaisuudet on tehty huolella ja rakkaudella, kömpelö ominaisuus erottuu samalla tavalla kuin tahmea välilyöntinäppäin näppäimistössä. Toisaalta liiketoiminnallisia päätöksiä on pakko tehdä: ovatko ominaisuudet kömpelyyden arvoisia? Monissa tapauksissa vahva ydintuote ja sujuvat peruskäyttötapaukset tekevät tuotteesta käyttökelpoisen, vaikka mukana olisi joitakin harvoin käytettyjä mutta hieman vaivalloisia ominaisuuksia.

Tie eteenpäin

Usein MLP-tuotteet tähtäävät kasvuun. Kasvun saavuttamiseksi on monia keinoja, mutta jokaisella vaihtoehdolla on omat sudenkuoppansa ja vaatimuksensa. Sovelluksen rakastettavuuden säilyttäminen on itsessään liiketoimintapäätös, joka sisältää kustannuksia, mutta saattaa samalla auttaa säilyttämään kilpailuedun. Tapauksissa, joissa ohjelmistoa kehitetään ennalta määrättyyn käyttötarkoitukseen, kuten joukkoliikenteen lippu- ja reittipalvelu, päätös korostaa rakastettavuutta ja helppokäyttöisyyttä jatkuvassa kehityksessä vaikuttaa suoraan käyttäjien elämään. Tämä voi puolestaan toimia parhaana mahdollisena referenssinä työnne laadusta.

Lopuksi

Rakastettavien tuotteiden rakentaminen vaatii aikaa ja työtä. Monet kehittäjät saattavat väittää, että MLP:n tulisi olla jokaisen ohjelmistotuotteen lähtökohta, sillä miellyttävien asioiden rakentaminen on monille kehittäjille innostavampaa.

Totuus on kuitenkin se, että joskus nopeat ja ei niin viimeistellyt ratkaisut voivat olla tehokkain vaihtoehto esimerkiksi tilanteissa, joissa käyttäjät eivät välitä käyttöliittymän ulkoasusta, vaan haluavat vain saada työnsä tehdyksi. MLP ei ole ratkaisu jokaiseen ohjelmistoon, jonka aiotte rakentaa, mutta aina kun tavoitteena on voittaa käyttäjät puolelleen ja pitää heidät, ajattelutavan muuttaminen rakastettavan tuotteen rakentamiseen saattaa olla oikea valinta.

Toivomme, että olemme tarjonneet näkemyksiä tehokkaasta tuotekehityksestä rakastettavalla tavalla.

Kiinnostuitko? Kerromme mielellämme lisää miten me Identiolla voisimme auttaa teitä luomaan jotain rakastettavaa käyttäjillenne.

Osa 1: Näin rakennamme Minimum Lovable Productin vuonna 2025 – ymmärryksen saavuttaminen
Osa 2: Näin rakennamme Minimum Lovable Productin vuonna 2025 – sovelluksen kehittäminen
Osa 3: Näin rakennamme Minimum Lovable Productin vuonna 2025 – tuotteen julkaisu

Yksi investointien kannalta keskeisimmistä, ja sen myötä myös yleisimmistä ohjelmistokehitykseen liittyvistä kysymyksistä on “Mitä ohjelmistokehitys maksaa?” Se on tietysti yksi ratkaisevimmista tekijöistä, kun yrityspäättäjät tarkastelevat digitaalisten järjestelmiensä nykytilannetta ja tulevaisuuden tarpeita.

Järjestelmiin liittyviä yleisimpiä haasteita ovat esimerkiksi seuraavat tilanteet:

yrityksen käyttämät digitaaliset palvelut ovat kokonaan tai osittain vanhentuneita,
järjestelmät vastaavat vain osittain yrityksen liiketoiminnallisia tarpeita tai
käytössä olevat digitaaliset järjestelmät eivät mahdollista liiketoiminnan skaalaamista.

Digitaaliset palvelut, kuten verkkosovellukset tai mobiilisovellukset ovat siis parhaimmillaan avain liiketoiminnan skaalaamiseen ja siihen liittyvien tavoitteiden saavuttamiseen. Kun puhutaan ohjelmistokehityksestä, on liiketoiminnallinen hyöty myös aina meidän prioriteettimme. Suhtaudumme vakavasti siihen, että asiakkaamme saavat aitoa arvoa kehittämistämme järjestelmistä.

Meille liiketoiminnallinen arvo tarkoittaa sitä, että haluamme jo ennen yhteistyön aloittamista kattavan kuvan asiakkaasta, heidän tarpeistaan sekä kehitettävästä järjestelmästä, asiakkaasta, ratkaistavasta ongelmasta ja tuotteen tai palvelun käyttäjistä on siis tärkeä lähtökohta yhteistyölle. Näin varmistamme, että tuote tai palvelu vastaa aitoon tarpeeseen, mikä taas on tärkeä lähtökohta investoinnin tekemiselle.

Tässä artikkelissa perehdymme siihen, mitä ohjelmistokehitys maksaa. Koska jokaisen yrityksen tarpeet ovat erilaisia ja kehitystä tehdään hyvin erilaisten yhteistyömallien kautta, emme voi antaa tässä tekstissä kovin tarkkaa arviota ohjelmiston kehityskustannuksista. Pyrimme kuitenkin vastaamaan tähän kysymykseen ylätasolla ja toivomme, että pääsemme keskustelemaan tarpeistanne vielä tarkemmin antaaksemme tarkemman arvion työn hinnasta.

Mikä vaikuttaa ohjelmistokehityksen hintaan?

Ohjelmistokehityksen hintaan vaikuttavat monet asiat. Keskeisimmät vaikuttavat tekijät ovat työn vaativuus ja projektin laajuus eli se, kuinka kompleksista järjestelmää kehitämme. Tähän vaikuttavat mm. kehitettävien ominaisuuksien määrä, kolmansien osapuolten taustajärjestelmien määrä sekä erilaiset teknologiaratkaisut. Muita hintaan vaikuttavia asioita ovat tiimin koko ja kehittäjien kokemustaso sekä kehitystyön aikataulu.

Kehitystiimin koko ja yhteistyömalli

Tiimin koko eli ohjelmistokehittäjien ja UX-suunnittelijoiden määrä on tietysti yksi keskeisimmistä tekijöistä hinnoittelussa. Ohjelmistokehityksen tuntihinta voi vaihdella 70-150 euron välillä riippuen mm. konsultin osaamisesta. UX-suunnittelun tuntihinta liikkuu yleensä 80–100 euroa.

Keskeinen hintaan vaikuttava tekijä on myös yhteistyömalli, jonka valitsemme yhteistyömme pohjaksi.

Jos asiakasyrityksellämme on oma kehitystiimi, johon he tarvitsevat apukäsiä tai tiettyä täsmäosaamista, Idention ohjelmistokehittäjä työskentelee silloin osana tätä kehitystiimiä. Tällaista “lisäresurssia” on helppo hyödyntää tarpeiden mukaan oman ohjelmistokehittäjän rekrytoinnin sijaan. Usein lisäresursseille on tarvetta, jos omasta tiimistä ei löydy teknologiaosaamista, joka vastaa projektin tarpeita tai jos projektissa halutaan prototyypata uusien teknologioiden sopivuutta asiakkaan käyttöön. Muita tilanteita konsulttien hyödyntämiseen voivat olla työn tehostaminen deadlinen lähestyessä tai esimerkiksi kehitystyön jatkuvuuden varmistaminen loma-aikoina. Tämä on yleisin yhteistyömallimme ja usein tällaisessa tapauksessa pätee tuntipohjainen hinnoittelu.

Lisäksi tarjoamme kaksi erilaista lähestymistapaa, joissa Idention oma kehitystiimi toteuttaa kokonaan uutta järjestelmää asiakkaan tarpeiden mukaan. Ensimmäisessä näistä työskentelemme läheisessä yhteistyössä asiakkaan kanssa ja toinen on enemmän avaimet käteen -tyylinen ratkaisu. Tiiviissä yhteistyössä voimme panostaa tiedon ja osaamisen siirtymiseen asiakasorganisaatioon valmentavan ohjelmistokehityksen kautta. Avaimet käteen -ratkaisussa puolestaan kehitämme asiakkaalle ennalta määritellyn tuotteen tai palvelun itsenäisemmällä otteella, jolloin asiakkaan rooli pysyy kevyempänä. Tämä malli soveltuu tilanteisiin, joissa tavoitteet ovat selkeät ja kehitystiimi ja asiakas ovat samalla sivulla kehitettävästä järjestelmästä.

Hinnoittelu voi näissä molemmissa malleissa olla tuntiperusteista tai perustua kiinteään hinnoitteluun. Tällöin sovimme yhdessä asiakkaan kanssa hintahaarukan, jonka sisällä sitoudumme pysymään.

Muita ohjelmistokehityksen hintaan vaikuttavia tekijöitä

Ohjelmistokehityksen kustannuksiin vaikuttaa myös useat muut tekijät, jotka on hyvä huomioida projektin budjettia suunniteltaessa. Ensimmäinen huomioon otettava asia on projektin laajuus. Rakennammeko kevyen MVP:n (Minimum Viable Product), MLP:n (Minimum Lovable Product) vai kokonaisvaltaisempaa ohjelmistokokonaisuutta? Pienemmät projektit ovat luonnollisesti edullisempia, mutta laajempien kokonaisuuksien suunnittelu, toteutus ja testaus vaativat enemmän resursseja.

Myös käytetyt teknologiat ja alustat vaikuttavat kustannuksiin: jotkut teknologiat edellyttävät erikoisosaamista, mikä voi nostaa projektin hintalappua. Tiimin kokoonpano, aikataulun tiukkuus ja julkaisun jälkeiset ylläpito- ja jatkokehityskulut ovat muita keskeisiä muuttujia, joita ei kannata unohtaa budjettia suunnitellessa. Nämä tekijät yhdessä määrittävät, minkälainen budjetti ohjelmistokehitykseen kannattaa varata.

Miten tehdä ohjelmistokehitystä kustannustehokkaasti?

Ohjelmistokehityksen kustannustehokkuus alkaa jo huolellisesta määrittelyvaiheesta. Kun kehitysprojekti suunnitellaan tarkasti etukäteen, vältetään kalliit muutokset myöhemmissä vaiheissa. Perusteellinen vaatimusmäärittely säästää sekä aikaa että rahaa ja auttaa tiimiä keskittymään olennaiseen. Lisäksi tärkeimmät ominaisuudet kannattaa priorisoida esimerkiksi MVP- tai MLP-ajattelun kautta. Tämä tarkoittaa, että projektin alkuvaiheessa keskitytään tuottamaan minimoitu, mutta käyttäjälle rakastettava kokonaisuus, joka vastaa selkeästi määriteltyihin tarpeisiin.

Ketterän kehityksen ja iteratiivisen ajattelun kautta kehitystyössä voidaan reagoida matalalla kynnyksellä muuttuviin tarpeisiin ja esimerkiksi käyttäjiltä saatuun palautteeseen. Tämä auttaa kohdentamaan budjettia aidosti käyttäjien näkökulmasta tärkeisiin ominaisuuksiin ja kokonaisuuksiin.

Oikean tiimin valitseminen on myös merkittävä tekijä kustannustehokkuuden kannalta. Tiimi, jolla on kokemusta vastaavanlaisista projekteista, pystyy yleensä toimittamaan laadukasta jälkeä ja vastaamaan samalla tehokkaasta ja sujuvasta projektin hallinnasta. Kustannustehokkuus ei aina synny edullisimman toimittajan tai yhteistyökumppanin valitsemisesta vaan ammattitaitoisesta työstä, jossa asiat tehdään alusta asti hyvin.

Hyvin tehty ohjelmistokehitys tuottaa arvoa pitkällä aikavälillä ja mikä tärkeintä, edistää teidän yrityksenne liiketoimintaa. Halpa ja riittämättömällä ammattitaidolla tehty kehitys voi lopulta johtaa kalliisiin korjaustöihin.

Konkreettisia hintaesimerkkejä

Ohjelmistokehityksen hinnoista on vaikeaa puhua kovinkaan tarkasti, mutta toivon, että nämä esimerkit antavat sinulle suuntaa antavan käsityksen ohjelmistokehityksen kustannuksista.

Nämä esimerkit ovat Idention hinnaston mukaisia ja koskevat tarpeisiinne suunniteltua ja kehitettyjä digitaalisia tuotteita ja palveluja sekä konsulttien tuntilaskutushintoja.

Räätälöidyt digitaaliset tuotteet ja palvelut sekä konsulttien tuntilaskutushinnat:

Keskikokoinen ohjelmisto: ~30 000–100 000 €

Laaja räätälöity yritysohjelmisto: ~100 000 € +

Ohjelmistokehitys / IT-konsultin tuntihinta: 80–120 €

UX-suunnittelijan tuntihinta: alkaen 85 €

Ohjelmistokehityksen hinta-arvio

Ohjelmistokehityksen hinta määräytyy siis hyvin tapauskohtaisesti ja toivomme, että tämän artikkelin myötä sait suuntaa-antavaa tietoa investoinnin kokoon liittyen. Toivomme, että pääsemme keskustelemaan kanssasi juuri teidän tarpeistanne ja siitä, mitä ohjelmistokehitys voisi maksaa juuri teidän tilanteessanne.

Ota yhteyttä myyntiimme, niin autamme teitä hahmottamaan ohjelmistokehitystarpeita juuri teidän yrityksellenne. Keskustelun kautta voimme arvioida yhdessä teknisten toteutusten laajuuksia sekä tehdä karkean arvion kehitystyön kustannuksista.

Identio teknologiayrityksenä

Idention ohjelmistokehittäjät ovat erikoistuneet konsultointiin, mikä tarkoittaa, että työskentelemme tiiviissä yhteistyössä asiakkaamme kanssa aina digitaalisen tuotteen tai palvelun suunnittelusta sen kehittämiseen ja ylläpitoon asti.

Suunnittelemme kestäviä ohjelmistoarkkitehtuuriratkaisuja sekä kehitämme digitaalisia tuotteita ja palveluja käyttäjäystävällisesti, skaalautuvasti ja kustannustehokkaasti. Olemme apunanne myös olemassa olevien järjestelmien päivityksessä ja modernisoinnissa.

Ohjelmistokumppanin valinta voi vaikuttaa suoraan liiketoiminnalliseen menestykseenne ja yhteistyöhön sitoutuminen on aina päätös, joka pitää tehdä harkiten. Me Identiolla ymmärrämme tämän asian merkityksen ja suhtaudumme asiakkuuksiimme vakavasti. Haluamme ohjelmistoyrityksenä varmistaa, että teemme aidosti sellaista työtä, joka mahdollistaa jokaisen asiakkaamme menestyksen.

Tässä artikkelissa avaamme, mitä asioita kannattaa ottaa huomioon, kun valitsette juuri teidän yrityksellenne sopivaa ohjelmistokumppania.

1. Ohjelmistoyrityksen ymmärrys liiketoimintasi tarpeista

Hyvä ohjelmistoyritys ei keskity pelkästään teknisiin ratkaisuihin vaan he ymmärtävät myös liiketoimintasi tavoitteet. Ennen kuin teet päätöksen, varmista, että potentiaalinen kumppani kysyy oikeat kysymykset ja osoittaa kiinnostusta yrityksesi toimialaa ja tarpeita kohtaan.

Me Identiolla lähdemme aina liikkeelle siitä, että kehitettävä digitaalinen tuote tai palvelu ratkaisee jonkin liiketoimintanne kannalta keskeisen ongelman. Oikean ongelman ratkaiseminen ja liiketoiminnan tavoitteiden saavuttaminen ovat lähtökohta hedelmälliselle yhteistyölle. Konsulteillmme on vahvaa osaamista eri toimialojen projekteista sekä erilaisissa ja eri kokoisissa kehitystiimeissä työskentelystä.

Jos tavoitteenne on esimerkiksi parantaa asiakaskokemusta, kumppanin pitäisi ehdottaa konkreettisia ratkaisuja käyttäjäystävällisyyden ja käyttäjäkokemuksen parantamiseksi. Kiinnitä huomiota siihen, tarjoaako ohjelmistoyritys ratkaisua juuri siihen tavoitteeseen tai ongelmaan, joka teidän yrityksellänne on.

2. Ohjelmistokumppanin referenssit ja kokemus

Kokemus eri toimialoilta ja vastaavista projekteista on useimmiten eduksi ohjelmistoprojekteissa. Tutustu eri ohjelmistoyritysten aiempiin projekteihin ja katso, löytyykö heidän sivuiltaan lisätietoa aiemmin tehdystä työstä. Kaikki referenssit eivät ole julkisia, joten kannattaa myös ottaa yhteyttä ja kysyä, onko yrityksellä ollut vastaavia asiakkuuksia tai projekteja, jotka eivät ole näkyvissä nettisivuilla. Tämä auttaa sinua arvioimaan, miten hyvin kumppani pystyy tarjoamaan juuri teidän tarpeisiinne sopivan ratkaisun.

Luotettava ohjelmistokumppani on avoin yhteistyön mahdollisuuksista ja potentiaalista sekä arvioi rehellisesti konsultin tai suuremman tiimin sopivuutta juuri kyseiseen asiakastarpeeseen.

3. Teknologinen osaaminen ja skaalautuvat ratkaisut

Ohjelmistokumppanin teknologinen osaaminen on luonnollisesti kriittistä. Varmista, että heidän tarjoamansa osaajat ja teknologiat tukevat yrityksesi kasvua ja liiketoiminnallisia tavoitteita pitkällä aikavälillä. Kuinka hyvin he huomioivat skaalautuvuuden? Pyrkivätkö he varmistamaan, että tuotteen tai palvelun jatkokehitys on mahdollisimman helppoa myös tulevaisuudessa ja vaikkapa toisen kumppanin kanssa?

Hyvä kumppani pyrkii tekemään itsestään asiakkaalle tarpeettoman jollain aikavälillä. Tämä tarkoittaa, että asiakas ei jää loukkuun kyseisen toimittajan kanssa tilanteessa, jossa tämä on ainut taho, joka syystä tai toisesta pystyy jatkamaan kehitystyötä. Konsulttiyrityksen tulee aina huomioida tämä asia omassa työssään ja pitää huolta asiakkaan mahdollisuuksista jatkaa kehitystyötä myös muiden tahojen kanssa.

Valitse ohjelmistokumppani, joka on ajan tasalla uusimmista teknologioista, voi tarjota innovatiivisia ratkaisuja ja joka pyrkii jättämään osaamisensa ja tarvittavat resurssit jatkoa ajatellen myös teidän tiimillenne.

4. Viestintä ja läpinäkyvyys yhteistyössä

Onnistunut yhteistyö ohjelmistokumppanin kanssa lähtee avoimuudesta ja läpinäkyvyydestä. Keskeistä projektin onnistumisen näkökulmasta on se, että asiakkaan ja ohjelmistoyrityksen välillä on hyvä luottamussuhde. On tärkeää, että ohjelmistoyritys pitää asiakkaan jatkuvasti kartalla projektin etenemisestä ja asioista voidaan puhua niiden oikeilla nimillä.

Idention yksi tärkeimmistä arvoista on läpinäyvyys ja se tekee viestinnästä lähtökohtaisesti helppoa. Läpinäkyvyys näkyy työssämme mm. seuraavilla tavoilla:

Varmistamme avoimen viestinnän sekä tiedonkulun tavoitteiden edistymisestä eri tiimien välillä.
Jaamme säännöllisesti tietoa ja päivityksiä projektin kaikkien osapuolten välillä.
Viestimme sekä sisäisesti että asiakkaidemme kanssa rehellisesti, selkeästi ja parhaan osaamisemme mukaan.

5. Joustavuus ja ongelmanratkaisukyky

Ohjelmistoprojektit harvoin etenevät täysin sen mukaan, miten ne on alunperin suunniteltu. Muutoksia voi tuoda esimerkiksi liiketoiminnallisten tarpeiden muuttuminen tai kehitystyön aikana saadut uudet oivallukset tai tekniset haasteet. Siksi on tärkeää valita ohjelmistokumppani, joka osaa mukautua muuttuviin tarpeisiin ja jonka kanssa yhteistyö on joustavaa.

Hyvä ohjelmistokumppani pystyy reagoimaan nopeasti ja rakentavasti odottamattomiin haasteisiin. Tämä tarkoittaa mm. joustavaa projektinhallintaa, ketteriä kehitysmenetelmiä ja ratkaisukeskeistä asennetta. Keskiöön nousee myös avoin viestintä; miten kumppani käsittelee muutostilanteet ja kuinka nopeasti se pystyy tarjoamaan vaihtoehtoisia toimintamalleja?

Joustavuus on yksi tekijä, josta me olemme Identiolla saaneet positiivista palautetta. Emme halua tehdä töitä meidän tavallamme vaan mukaudumme aina jokaisen asiakkaan omiin tarpeisiin.

6. Ohjelmistoyrityksen arvot ja kulttuurinen yhteensopivuus

Ohjelmistokehitys on usein pitkäjänteistä ja sen onnistuminen riippuu myös siitä, kuinka hyvin yrityksen ja konsulttien arvot ja toimintakulttuuri sopivat yhteen oman yrityksenne kanssa. Pelkkä tekninen osaaminen ei riitä, jos työtavat, kommunikaatio ja yhteistyön periaatteet eivät kohtaa.

Kun valitset ohjelmistokumppania, pohdi seuraavia kysymyksiä:

Miten ohjelmistoyritys suhtautuu avoimuuteen ja yhteistyöhön?
Vastaavatko heidän arvonsa yrityksesi toimintaperiaatteita?
Onko heidän työskentelytapansa sellainen, joka tukee teidän tiimiänne ja tavoitteitanne?
Onko konsultti tai tiimi aidosti kiinnostunut tuotteestanne tai palvelustanne ja tavoitteidenne saavuttamisesta.

Me Identiolla uskomme, että parhaat projektit syntyvät avoimen ja luottamuksellisen yhteistyön kautta. Arvomme – läpinäkyvyys, luottamus, turvallisuus, yhteistyö ja kokeilukulttuuri – ohjaavat kaikkea tekemistämme. Haluamme olla kumppani, jonka kanssa yhteistyö tuntuu luontevalta ja joka tuo aidosti lisäarvoa asiakkaan liiketoimintaan.

Kun ohjelmistokumppanin arvot ja kulttuuri sopivat yhteen omiesi kanssa, yhteistyö sujuu jouhevammin ja lopputuloksena syntyy parempia, kestävämpiä ratkaisuja.

Lopuksi

Ohjelmistokumppanin valinta on merkittävä päätös, joka vaikuttaa suoraan yrityksenne kilpailukykyyn ja kehitykseen. Oikean kumppanin valitsemisen ei pidä perustua vain teknologiaosaamiseen tai kokemusvuosiin vaan tärkeää on myös liiketoimintaymmärrys, viestinnän sujuvuus, joustavuus ja arvojen yhteensopivuus. Kun katsomme vaikkapa Ite wikin yrityslistaa, on mahdollisia kumppaneita lukematon määrä.

Kun teet valintaa, kiinnitä huomiota siihen, miten hyvin ohjelmistoyritys ymmärtää tarpeesi ja kuinka avoin ja yhteistyökykyinen se on. Pitkäjänteinen kumppanuus perustuu luottamukseen ja yhteiseen tavoitteeseen luoda kestävää arvoa.

Me Identiolla haluamme olla kumppani, joka ei vain toteuta projekteja, vaan auttaa asiakkaitaan onnistumaan pitkällä aikavälillä. Sitoudumme yhteisiin tavoitteisiin ja olemme valmiita laittamaan myös itsemme likoon. Jos etsit ohjelmistokumppania, jonka kanssa yhteistyö on avointa, joustavaa ja liiketoimintalähtöistä, olemme valmiita keskustelemaan tarpeistanne.

Olemme aina valmiita keskustelemaan teidän tarpeistanne, vaikka se ei johtaisikaan kumppanuuteen. Ota yhteyttä ja jutellaan lisää siitä, voisimmeko me olla teille sopiva kumppani.

Tutustu lisää aiemmin tekemäämme työhön nettisivujemme Työmme-osiosta.

Svenska litteratursällskapet i Finland

Täsmäosaamista modernin sisällönhallintajärjestelmän kehittämiseen

Täsmäosaamista
modernin sisällönhallinta-
järjestelmän kehittämiseen

Svenska litteratursällskapet i Finland (SLS) on tieteellinen seura, joka toimii Suomen ruotsinkielisen kulttuurin parissa. Sen tarkoituksena on kerätä, tutkia ja välittää tietoa Suomen ruotsinkielisestä kulttuurista. Tärkeä osa sitä on ruotsinkielistä Suomea käsittelevien teosten julkaiseminen. Kehitimme yhteistyössä SLS:n kanssa uuden sisällönhallintajärjestelmän (CMS) digitaalisten editioiden sisältöjen hallintaan.

Työnkuvamme

Mies kiikaroimassa Tähtitorninvuorella Helsingissä, 1890–1910 (Gustav Sandberg, SLS 1849_485, CC BY 4.0)

Lähtötilanne

Svenska litteratursällskapetilla oli aiemmin käytössään CMS-järjestelmä, joka oli joiltain osin vanhentunut ja toiminnoiltaan rajallinen. Järjestelmän käyttäminen vaati erityisosaamista sekä piti sisällään manuaalista työtä, joka lisäsi myös inhimillisten virheiden mahdollisuutta. Vanhaa järjestelmää ei kannattanut enää lähteä modernisoimaan tai jatkokehittämään.
SLS halusi kehittää kokonaan uuden – modernin, käyttäjäystävällisen ja intuitiivisen – verkkosovelluksen, jota olisi helppo käyttää teknisistä valmiuksista riippumatta. Uuden CMS-järjestelmän haluttiin olevan skaalautuva, eli sen jatkokehitysmahdollisuudet otettiin huomioon alusta alkaen.

Projektin vaatimukset olivat selkeät. SLS tarvitsi oman backend-kehittäjänsä rinnalle ohjelmistokonsultointiin erikoistuneen frontend-kehittäjän.

Yhteistyössä Idention kanssa arvostamme erityisesti joustavuutta ja sujuvuutta, ammattimaisuuden ja teknologiaosaamisen lisäksi.

– Sebastian Köhler, kehitysvastaava, digitaaliset julkaisut, SLS

Ratkaisu

Kehitimme yhdessä kokonaan uuden sisällönhallintajärjestelmän, jonka kautta SLS hallitsee jatkossa projektejaan. Tässä tapauksessa projekti tarkoittaa digitaalista editiota eli eräänlaista verkkojulkaisua, johon kuuluu esimerkiksi kirjallisia teoksia, kirjeitä ja muita arkistodokumentteja. Idention konsultti oli vastuussa järjestelmän frontend-kehityksestä ja työskenteli yhdessä SLS:n oman backend-kehittäjän kanssa.

Uusi CMS-järjestelmä pitää sisällään käyttäjän kannalta tarpeelliset toiminnot ja se poistaa aiemman järjestelmän vaatimaa manuaalista työtä.

Toteutimme järjestelmään neljä keskeistä ydintoiminnallisuutta:

Skaalautuva rakenne: suunnittelimme ja toteutimme järjestelmän joustavaksi, jotta se on helposti laajennettavissa uusilla toiminnoilla käyttäjien tarpeiden mukaan.
Kirjautuminen: käyttäjä voi valita sekä ympäristön, johon haluaa kirjautua että projektin, jota aikoo muokata.
Projektien hallinta: kehitimme toiminnot projektin luomiseen ja tekstien hallintaan sekä henkilöiden indeksointiin.
Monikielisyys: toteutimme järjestelmään käännöstuen, joka mahdollistaa sisällön hallinnan useilla kielillä.

Kehitystyö sujui nopeasti ja se alitti sekä etukäteen määritellyn aikataulun että budjetin. Siksi pystyimme toteuttamaan järjestelmään myös muita tarpeellisia ominaisuuksia.

Huomioimme projektissa verkkosisältöjä koskevat saavutettavuusstandardit (WCAG AA) ja varmistimme verkkosovelluksen skaalautuvuuden sekä selaimella että tabletilla.

Teknologiat

Miksi tämä on merkityksellistä?

SLS kerää Suomen ruotsinkieliseen kulttuuriin liittyvää dataa ja materiaalia ja julkaisee siihen liittyvää kirjallisuutta, joka on siten saatavilla myös tuleville sukupolville. Vielä tärkeämpää on kuitenkin ruotsinkielisen väestön identiteetin ja itseymmärryksen vahvistaminen.

Kehittämämme sisällönhallintajärjestelmä (CMS) mahdollistaa näiden materiaalien hallinnoinnin ja julkaisemisen nyt ja tulevaisuudessa. Siitä hyötyvät Suomen ruotsinkielisen väestön lisäksi myös mm. tutkijat ja historioitsijat sekä yksityishenkilöt, jotka haluavat perehtyä SLS:n tallentamaan ja julkaisemaan kulttuuriperintöön.

Zacharias Topeliuksen historiallinen romaani Planeternas skyddslingar (1889, suom. Tähtien turvatit) sisältyy Svenska litteratursällskapetin julkaisemaan editioon Zacharias Topelius Skrifter (SLS, CC BY 4.0)

Kaipaatko lisätietoa?

Kerromme mielellämme lisää tekemästämme työstä.

Joonas Korgan

+358 40 568 4617

Turku

Linnankatu 13a B20
20100 Turku

Helsinki

Kaisaniemenkatu 3 A 5 B
00100 Helsinki

+358 40 568 4617

Turku

Linnankatu 13a B20
20100 Turku

Helsinki

Kaisaniemenkatu 3 A 5 B
00100 Helsinki

+358 40 568 4617

MEHILÄINEN

Kumppanuudesta voimaa asiakaslähtöisen digitaalisen terveydenhuollon kehittämiseen

Mehiläisellä on elämä tehtävänä. Palvellakseen asiakkaitaan jatkuvasti paremmin, se rakentaa maailman parasta digitaalista terveydenhuoltoa. Olemme saaneet olla Mehiläisen kumppani matkalla kohti kunnianhimoisten tavoitteiden saavuttamista tajoamalla sille monipuolista teknistä osaamista kehitystiimien vahvistamiseksi.

Työnkuvamme

Teknisiä osaajia ja monipuolisia kehitystiimejä

Mehiläinen tunnetaan myös asiakaslähtöisistä ja turvallisista digitaalisista ratkaisuistaan. Pitkäjänteisen yhteistyömme aikana olemme olleet mukana auttamassa Mehiläistä saavuttamaan liiketoiminnallisia tavoitteitaan teknisen osaamisemme kautta. Mehiläisen digitaalisten palvelujen parissa työskentelee yli 200 asiantuntijaa, jotka kehittävät päivittäin ratkaisuja parantaakseen miljoonien suomalaisten pääsyä laadukkaaseen terveydenhuoltoon. Idention konsultit ovat työskennelleet osana näiden asiantuntijoiden muodostamia kehitystiimejä.

Jatkuvan digitaalisen kehityksen kautta Mehiläinen varmistaa, että asiantuntijat saavat nykyaikaiset välineet oman työnsä hallintaan ja asiakkaat saavat parasta mahdollista palvelua ja käyttäjäystävällisen hoitopolun.

Teknologiat

Meille on tärkeää, että tukenamme on luotettavia kumppaneita, jotka ymmärtävät tehtävämme ja tavoitteemme. Meillä on vahva oma in-house kehitystiimi, mutta tarvitsemme usein myös täsmäosaamista rikastamaan tiimejämme. Idention kanssa yhteistyö on ollut hedelmällistä ja olemme saaneet heiltä emme vähempää emmekä enempää kuin tarpeemme mukaisia ratkaisuja.

– Ossi Laukkanen, Digitaalisten terveyspalveluiden ja sovelluskehityksen johtaja, Mehiläinen

Kokonaisvaltaista ohjelmistokehitystä eri osa-alueilla

Olemme työskennelleet yhdessä sekä järjestelmien päivityksen ja modernisoinnin että uusien kokonaisuuksien ja ominaisuuksien kehittämisessä. Yhteistyöhömme on sisältynyt monia kehitysprojektien kannalta kriittisiä vaiheita, kuten teknologiavalintojen tekemistä ja työskentelytapojen määrittelyä ja kehitystä.

Yhteistyön keskeisiä osa-alueita

Asiakaslähtöisyys ja helppokäyttöisyys: kehityksessä on keskitytty vahvasti asiakaspolkujen ja käyttökokemuksen selkeyteen.
Skaalautuvuus ja integraatiot: palvelut on optimoitu kasvavan käyttäjämäärän tarpeisiin ja niissä on huomioitu mahdolliset tulevaisuuden integraatiot.
Tietoturva: potilastietojen turvallisuus sekä luottamuksellisuus ovat Mehiläisen toiminnalle kriittinen perusta.
Ketteryys ja tiimien työskentelytapojen vahvistaminen: kehitystyön keskiössä ovat olleet tiimiin tehokkaat työskentelytavat.

Yhteenveto

Vanhojen järjestelmien modernisointi, teknologiavalinnat ja skaalautuvuuden varmistaminen

Uusien ominaisuuksien suunnittelu ja full stack -kehitys

Asiakaspolun ja käyttökokemuksen kehittäminen

Työskentelytapojen ja -käytäntöjen kehittäminen

Kaipaatko lisätietoa?

Kerromme mielellämme lisää tekemästämme työstä.a

Joonas Korgan

+358 40 568 4617

Turku

Linnankatu 13a B20
20100 Turku

Helsinki

Kaisaniemenkatu 3 A 5 B
00100 Helsinki

+358 40 568 4617

Turku

Linnankatu 13a B20
20100 Turku

Helsinki

Kaisaniemenkatu 3 A 5 B
00100 Helsinki

+358 40 568 4617

Työskentelen People & Culture -vastaavana Identiolla, ja vastaan oikeastaan kaikista HR:ään eli henkilöstöhallintoon liittyvistä asioista, prosesseista ja niiden kehittämisestä. Työni ytimessä on ihmisten hyvinvointi ja sen varmistaminen, että koko työyhteisö voi tehdä työnsä mahdollisimman hyvin ja sujuvasti.

Tässä tekstissä kerron siitä, miten näen oman roolini identiolaisten hyvinvoinnin tukena ja miten sillä on vaikutusta myös asiakkaidemme menestykseen. Identiolla panostamme henkilöstön hyvinvointiin ja osaamiseen, mikä näkyy asiakkaille laadukkaana ja luotettavana palveluna.

Miksi työntekijöiden hyvinvoinnilla on merkitystä?

Työntekijöiden hyvinvointia tukeva yrityskulttuuri on Identiolla keskeinen voimavara. Haluan omalta osaltani olla luomassa ilmapiirin, jossa jokainen tuntee olonsa turvalliseksi ja innostuneeksi tullessaan töihin. Tavoitteeni on, että jokainen identiolainen tuntee olevansa arvostettu ja osa yhteisöä, jossa ihmisiä tuetaan niin ammatillisessa kuin henkilökohtaisessakin kasvussa. Näin varmistamme, että työntekijämme voivat saavuttaa parhaan mahdollisen potentiaalinsa, ja pystymme olemaan luotettava kumppani sekä palvelemaan asiakkaitamme parhaalla mahdollisella tavalla. Henkilöstön hyvinvointi vaikuttaa suoraan työn laatuun ja projektityön sujuvuuteen.

Työn kuuluu olla voimavaratekijä arjessa ja sen eteen teemme Identiolla töitä. Sosiaaliset kontaktit, työn mielekkyys ja osaamisen kehittyminen, työn sekä vapaa-ajan tasapaino, ovat kaikki tärkeitä seikkoja, jotka tukevat arjessa jaksamista ja hyvinvointia. Kun henkilöstö voi hyvin, se heijastuu myös asiakastyöhön, mikä näkyy sitoutumisena, motivaationa ja haluna tehdä parhaansa asiakkaillemme. Lisäksi se vaikuttaa projektien jatkuvuuteen, kun henkilöstön vaihtuvuus on näiden panostusten ansiosta pienempää. Pitkäaikaiset asiakassuhteet tuovat lisäarvoa asiakkaille, kun tiimi tuntee asiakkaan tarpeet syvällisemmin ja pystyy tarjoamaan tehokkaampia ratkaisuja.

Mitä IT-talon People & Culture Manager tekee käytännössä?

People & Culture -roolini on laaja ja vaihteleva. Se kattaa koko työntekijän elinkaaren, mikä tarkoittaa, että olen mukana niin rekrytoinnissa, perehdytyksessä, kuin joskus myös kehityskeskusteluissakin – ja lopulta myös silloin, kun on aika siirtyä uusiin haasteisiin.

Tärkeä osa työtäni on tehdä yhteistyötä työntekijöiden eli muun muassa People & Culture Taskforcen kanssa. Identiolla on käytössä taskforce-malli, jossa identiolaisista koostuvat työryhmät edistävät erilaisia aiheita ja kehittävät yritystä. Taskforcet muodostuvat yhteispäätöksellä tai työntekijöiden aloitteesta, ja toimivat niin kauan kuin on tarve. Kuka tahansa voi lähteä mukaan itseään kiinnostavan aiheen ympärillä toimivaan taskforceen ja vaikuttaa sillä työyhteisön kehittämiseen. Tällä hetkellä meillä on People & Culture Taskforcen lisäksi esimerkiksi pieni porukka työstämässä Idention pikkujouluja eli Winter Galaa, opiskelijayhteistyötä sekä “Engineering Taskforce” konsulttien osaamisen kehittämisen tukena.

Yhdessä People & Culture Taskforcen kanssa kehitämme toimintatapoja ja edistämme asioita ja hankkeita, jotka koskevat työntekijöiden hyvinvointia ja yrityskulttuuria. Hankkeet ja teemat nousevat useimmiten suoraan henkilöstöltä. Siten ne tukevat ja keskittyvät juuri heidän hyvinvointinsa edistämiseen. Muutamia esimerkkeinä viime aikoina meneillään olevista aiheista: vastuulliseen liiketoiminnan projekti, uusi “Career Dev” eli urakehitysmalli, kuukausittaiset pulssikyselyt työntekijöiden hyvinvoinnin tukena, työsuhde-etujen palveluntarjoajien vertailu sekä Idention sisäinen joulukalenteri. Työhyvinvointi ja työsuojeluasiat ovat olleet myös tämän syksyn teemana. Tiivistimme ja selkeytimme yhteistyötä työsuojelutiimin kesken sekä teimme yhteistyössä työterveyden kanssa työpaikkaselvityksen.

Meillä Identiolla ei ole perinteisiä esihenkilöitä, vaan sisäiset tiimit eli podit toimivat työntekijöiden vertaistukena. Roolini HR-vastaavana korostuu erityisesti silloin, kun joku työntekijöistä kaipaa henkilökohtaista tukea hieman enemmän. Meillä on käytössä varhaisen tuen malli ja järjestän säännöllisiä 1:1-keskusteluja, jotta työntekijät voivat tuoda esiin mahdolliset huolenaiheensa matalalla kynnyksellä. Näin pystymme reagoimaan ajoissa ja auttamaan löytämään ratkaisut, jotka parantavat arkea nopeasti. Olen vastuussa siitä, että jokainen työntekijämme tuntee itsensä arvostetuksi ja tuetuksi alusta loppuun, aina rekrytointivaiheesta mahdolliseen työsuhteen päättymiseen asti.

Hyvinvoiva henkilöstö tuottaa asiakkaille parasta palvelua

Identio on olemassa, jotta voimme auttaa yrityksiä ratkaisemaan liiketoimintaansa liittyviä ongelmia nyt ja tulevaisuudessa. Meidän ja asiakkaidemme menestys syntyy ihmisistä, jotka omalla osaamisellaan ja panoksellaan mahdollistavat oikean suunnan. Panostamalla henkilöstön hyvinvointiin ja kulttuuriin rakennamme kestävää pohjaa menestykselle. Olemme luotettava ja pitkäjänteinen kumppani, joka pystyy vastaamaan asiakkaiden tarpeisiin laadukkaasti. Tämän mahdollistamisessa olen vahvasti mukana omalla työpanoksellani.

Lopulta kaikki panostuksemme työntekijöiden hyvinvointiin tähtäävät yhteen asiaan: hyvinvoivat ja sitoutuneet työntekijät ovat edellytys onnistuneille asiakasprojekteille ja yhteistyölle. Haluamme rakentaa yhdessä menestystä aidosti ihmisistä huolehtien. Lopputuloksena on positiivinen kehä, sillä sitoutumalla yhteiseen menestykseen vaikutetaan myös omaan menestykseen ja hyvinvointiin.

Lue myös Idention resepti – 5 askelta menestyvään yrityskulttuuriin

Kun koemme ymmärtävämme riittävästi sekä yhteistyökumppaneitamme, ratkaistavaa ongelmaa että tuotteen käyttäjiä, olemme valmiita aloittamaan verkkosovelluksen kehittämisen. Pidämme lähestymistavasta, jossa rakennamme ohjelmistotuotteita asiakkaillemme iteratiivisesti.

Aiemmin olemme määritelleet asiat, jotka ovat tärkeimpiä tuotteen menestyksen kannalta, sekä kaikkein haastavimmat teknologiset ongelmat, jotka meidän täytyy ratkaista päästäksemme tavoitteeseemme. Emme kuitenkaan käy näiden kimppuun suoraan, vaan aloitamme tutkimuksen samalla, kun laadimme asiakkaalle rautalankamallia.

Oikeiden teknologioiden valinta

Otamme aina huomioon asiakkaan nykyisin käyttämät ohjelmistopalvelut, erityisesti jos olemme integroimassa uutta ratkaisua olemassa oleviin palveluihin. Kun kehitämme verkkopohjaisia tuotteita, erityisesti täysin alusta lähtien, pidämme tällä hetkellä Next.js:ää parhaana lähtökohtana.

Olemme yleensä melko teknologianeutraaleja. ”Valitse oikea teknologia oikeaan projektiin ja käyttötapaukseen” on ohjelmistosuunnittelussa yleinen mantra, jota mekin noudatamme mielellämme. Jopa täysin uuden tuotteen kehittämisessä on erikoistapauksia, joissa voi olla perusteltua valita jokin toinen vaihtoehto.

Next.js tarjoaa paljon valmiina sen laajan mallipohjakirjaston ansiosta, jota sen kehittäjä Vercel tukee. Kun rakennamme tuotteen alustavaa versiota, haluamme keskittyä toimittamaan kriittiset ominaisuudet, jotka tekevät tuotteestanne arvokkaan ja erittäin käyttökelpoisen jo julkaisuvaiheessa. Olemme työskennelleet Next.js:n kanssa useissa projekteissa saavuttaen erinomaisia tuloksia. Tämä mahdollistaa keskittymisen asiakkaiden ongelmien ratkaisemiseen sen sijaan, että käyttäisimme aikaa teknologian valintaan.

Muut tekniset valinnat

Useimmat merkittävät ohjelmistotuotteet vaativat tietokannan, jonka valitsemme liiketoimintavaatimustenne perusteella. Tavallisimmin suosittelemme SQL-tietokantaa, kuten PostgreSQL:ää sen monipuolisten ominaisuuksien ja erinomaisen toimintavarmuuden vuoksi. Vain harvoissa tapauksissa Postgres ei tarjoa tarvittavia ratkaisuja tuotteen alkuvaiheessa.

Vaihtoehdot Next.js:lle

Meillä on kokemusta myös SvelteKitin ja Remixin kanssa työskentelystä. Nämä tarjoavat yhtä houkuttelevia lähtökohtia hyvien mallipohjiensa ansiosta. Next.js:llä on kuitenkin yleensä laajempi valikoima valmiita mallipohjia, mikä antaa enemmän vaihtoehtoja.

Jotkut asiakkaat saattavat olla vahvasti mieltyneitä tiettyihin teknologioihin. On myös erityistapauksia, joissa muut teknologiat voivat tarjota paremman lähtökohdan kuten esimerkiksi paremman integraation nykyisiin ohjelmistojärjestelmiisi.

Rakastettavan sovelluksen kehittäminen

Rakastettava tuote on se lisäpanostus, joka erottaa tuotteesi kilpailijoista tai saa käyttäjät omaksumaan uuden tuotteen ilman valituksia. Siirtyminen MVP:sta (Minimum Viable Product) MLP:iin (Minimum Lovable Product) tarkoittaa käyttäjäpolkujen suunnittelua yksinkertaisiksi ja intuitiivisiksi. Ensimmäisen version tulisi olla yksinkertainen ja keskittynyt; lisäominaisuuksia voidaan lisätä myöhemmin.

Klassinen esimerkki MLP:sta ohjelmistomaailmassa on deittisovellus Tinder. Sen oikealle tai vasemmalle pyyhkäisyyn keskittyvä käyttöliittymä (UX) nähdään yleisesti ominaisuutena, joka nosti sen kilpailijoiden yläpuolelle ja josta on tullut jopa yleisesti käytetty tapa muissakin yhteyksissä ”tykätä” tai ”olla tykkäämättä”. Lisäominaisuudet, kuten Spotify- ja Instagram-yhteyksien lisääminen, olivat toki mukavia lisäyksiä, mutta eivät olleet sovelluksen alkuvaiheessa keskiössä. Tärkeintä on rakentaa toimiva ratkaisu käyttäjän tarpeeseen – ei vain teknisesti mahdollinen tapa toteuttaa se, vaan myös nautittava kokemus.

Voimme palata aiempaan selitykseemme Minimum Lovable Productista korostaaksemme tätä näkökulmaa.

Minimum Viable Product

Alustava Proof of Concept -tasoinen runko.
Yksinkertaiset ominaisuudet vaatimusten tyydyttämiseksi.
Antaa käyttäjille mahdollisuuden testata ideaa, mutta ei tavallisesti ole tarpeeksi vetovoimainen.

Minimum Lovable Product

Kaikki edellä mainitut.
Käyttäjäkokemuksen kehittäminen ensisijaisten työnkulkujen osalta.
Herättää käyttäjissä myönteisiä tunteita.

Miltä kehitysprosessi näyttää

Kun kehitys alkaa, tavoitteemme on pitää selkeä ja jatkuva keskusteluyhteys asiakkaan kanssa koko prosessin ajan. Tiimi sopii asiakkaan kanssa viikottaisista tai kahden viikon välein pidettävistä kokouksista, joiden aikana priorisoidaan kehitystyötä ja saadaan säännöllistä palautetta varmistaaksemme, että suunta on oikea.

Haluamme korostaa, kuinka tärkeää on saada asiakas mahdollisimman nopeasti käyttökelpoisen version äärelle. Tämä mahdollistaa käyttäjätestauksen aloittamisen projektin varhaisessa vaiheessa. Kun asiakkaalla ja käyttäjillä on konkreettinen tuote esikatseltavana, on todennäköisempää, että keskitymme oikeisiin ominaisuuksiin tässä tuotteen kehityksen kriittisessä alkuvaiheessa.

Kun rakennamme jotain käyttäjäkeskeisestä näkökulmasta, kuten aiemmin kuvailimme, palautteen merkitys korostuu entisestään. Vaikka käytämme tavanomaisia työkaluja, kuten Kanban-tauluja ja ketteriä menetelmiä, emme yleensä työskentele sprinttimuodossa, jotta voimme säilyttää mahdollisimman suuren joustavuuden.

Tämä ei tarkoita, että vältämme kokonaan backlogeja ja estimointeja, mutta nopeatahtinen iterointi hyötyy usein lyhyemmästä palautesyklistä asiakkaan ja käyttäjien kanssa.

Suunnan muuttaminen

Kehitysprosessin aikana saattaa joskus käydä ilmi, että jotkut asiat eivät ole toteutettavissa nykyisessä toimituslaajuudessa. Näissä tilanteissa on tärkeää tuoda esiin ongelmat varhain, jotta voimme tehdä tarvittavat muutokset tavalla, joka säilyttää tuotteen hengen ja mahdollistaa asiakkaan tavoitteiden saavuttamisen. Loppujen lopuksi rakennamme rakastettavia tuotteita, joten on yleensä hyödyllisempää lykätä ominaisuutta, jota ei voida toimittaa rakastettavassa muodossa, kuin heikentää tuotteen kokonaislaatua toteuttamalla keskeneräinen ja ei-kriittinen ominaisuus. Vaihtoehtoisesti voimme toteuttaa rakastettavan mutta väliaikaisen ratkaisun, edellyttäen että se voidaan myöhemmin korvata teknisesti kestävämmällä ratkaisulla ilman, että tuotteen rakastettavat ominaisuudet kärsivät.

Yhteenveto

Tässä toisessa osassa olemme käsitelleet tarkemmin teknologiavalintojamme ja konkreettista kehityssykliä, jonka avulla hyödynnämme tehokkaasti aikaa tuotteen toimittamisessa.

Mielestämme kaikki kiteytyy muutamaan asiaan:

Avoimen viestintäkanavan ylläpitäminen kehitysvaiheen aikana.
Oikeiden teknologioiden valitseminen oikeaan tehtävään.
Konkreettisen tuotteen iterointi ja muutoksiin suhtautuminen avoimin mielin.
Käyttäjien mukaan ottaminen jo varhaisessa vaiheessa.

Kolmannessa osassa tarkastelemme, mitä tapahtuu ja miten asiat voivat muuttua, kun MLP on julkaistu ja käytössä oikeassa maailmassa.

Varoitus. Tämä kolmiosainen artikkeli on melko kantaaottava, ja saatat olla eri mieltä joistakin valinnoistamme ja lähestymistavoistamme. Se ei kuitenkaan haittaa! Olemme havainneet asiakkaidemme kanssa työskennellessämme, että tietyt teknologiset ja toiminnalliset valinnat tekevät asioista sujuvampia. Voit vapaasti olla niistä eri mieltä ja kertoa meille, mitä tiimisi tekee toisin.

Me Identiolla työskentelemme erilaisten yksityisen ja julkisen sektorin asiakkaiden kanssa, jotka ovat elinkaarensa eri vaiheissa. Mielestämme tässä kuvattu lähestymistapa on suhteellisen helposti sovitettavissa eri asiakkaille, mutta se toimii parhaiten alkuvaiheen startup-yrityksille tai yrityksille, joilla on pieni määrä olemassa olevia ohjelmistopalveluja, jotka halutaan integroida uuteen tuotteeseen. Tässä sarjassa tarkastellaan käsitteenä ja kehitysprosessina MLP-tuotetta (Minimum Lovable Product), jonka tavoitteena on tuottaa teknisesti toimivan ohjelmiston lisäksi myös sellainen ohjelmisto, jota käyttäjät käyttävät mielellään.

Olemme jakaneet tämän artikkelin kolmeen osaan, jotka julkaisemme noin viikon välein ja joissa käsittelemme alustavaa tiedonkeruuvaihetta, Minimum Lovable Productin toimittamista ja seuraavia vaiheita, jotka toteutetaan, kun tuotteen ensimmäinen versio on käyttäjien käsissä.

Minimum Lovable Product

Lyhyen johdannon tarjoamiseksi asiaan perehtymättömille, MLP on tuote, joka on kehitetty ja suunniteltu niin, että käyttäjät ottavat sen innokkaasti käyttöön. Helpoin tapa määritellä Minimum Lovable Product käsitteenä, on vertailla sitä ja monille tutumpaa Minimum Viable Productia.

Minimum Viable Product

Alustava Proof of Concept -tasoinen runko.
Yksinkertaiset ominaisuudet vaatimusten tyydyttämiseksi.
Antaa käyttäjille mahdollisuuden testata ideaa, mutta ei tavallisesti ole tarpeeksi vetovoimainen.

Minimum Lovable Product

Kaikki edellä mainitut.
Käyttäjäkokemuksen kehittäminen ensisijaisten työnkulkujen osalta.
Herättää käyttäjissä myönteisiä tunteita.

Määritelmän mukaan MVP:llä saadaan työ tehtyä, mutta usein ohjelmistotuotteet eivät saa käyttäjiä, tai käyttäjät käyttävät työkaluja vastahakoisesti vaihtoehtojen sijaan. Kun käyttäjäkokemus vaikuttaa käyttäjiin suuresti tai kun tavoitteena on saavuttaa laaja käyttäjäkunta, kannattaa nähdä ylimääräistä vaivaa, jotta tuotteen elinkelpoisuus muuttuu rakastettavuudeksi.

Ennen kuin aloitamme

Tuotekehityksen alussa on yleensä muutaman viikon jakso, jolloin tutkimme asioita ja keskustelemme yksityiskohdista, kuten sopimuksista. Aloitamme oppimisprosessin jo osana myyntiprosessia, mutta tutustumme asiakkaaseen kunnolla yhteistyön alkaessa – kick-offin tai design sprintin yhteydessä.

Asiakkaan ymmärtäminen

Haluamme tuntea asiakkaamme ja heidän liiketoimintansa hyvin. Tutustumme tiimiin tai tiimeihin, joiden kanssa työskentelemme, alaan, jolla he työskentelevät sekä heidän päivittäiseen liiketoimintaansa. Alkuvaiheen startup-yrityksissä tämä tarkoittaa yleensä sitä, että tapaamme tiimin ja opimme tuntemaan heidät ja heidän asiantuntemuksensa.

Tuotteen ensimmäisen version rakentaminen on usein pohjimmiltaan selkeää viestintää ja ongelman, jota haluamme ratkaista, ymmärtämistä. Mielestämme on tärkeää ottaa asiakas mukaan kehitysprosessiin jo varhaisessa vaiheessa. Läpinäkyvä tiedonvaihto tekee asioista helpompia myöhemmässä vaiheessa.

Tuotteen vision ymmärtäminen

Kun olemme saaneet selkeämmän käsityksen asiakkaasta, on aika syventyä paremmin ongelmaan. Yleensä se tapahtuu asiakkaan tarjoaman kuvauksen ja tietojen perusteella. Tiimimme ovat parhaimmillaan työskennellessään liiketoimintaongelmien ja teknisten ratkaisujen kehittämisen risteyskohdassa. Pyrimme ymmärtämään parhaamme mukaan seuraavat asiat:

Miksi asiakas on kiinnostunut rakentamaan tämän tuotteen ongelman ratkaisemiseksi?
Miksi asiakas on nimenomaan kiinnostunut ongelman ratkaisemisesta?
Miksi hän haluaa ratkaista ongelman juuri nyt?

Kun saamme vastaukset näihin kysymyksiin, voimme rajata tuotteen ensimmäisen iteraation laajuutta. Ensimmäinen versio tarjoaa yleensä vain osan lopullisen tuotteen toiminnallisuuksista, jotta voimme toimittaa jotain käyttökelpoista, testattavaa ja käyttäjille mieluisaa.

Käyttäjien ymmärtäminen

Vain harvoin asiakas on tuotteen suora käyttäjä, jolloin pelkkä asiakkaan ymmärtäminen riittäisi. Vaikka asiakkaalta saattaisikin saada hyvin selkeän käsityksen käyttäjistä, kannattaa eri käyttäjäryhmien ymmärtämiseen silti käyttää aikaa. Tämä saattaa tarkoittaa esimerkkikäyttäjäpersoonien luomista sekä heidän tarpeidensa ja käyttötapaustensa määrittelyä. Todellisten potentiaalisten käyttäjien ottaminen mukaan alustavaan käyttötapausten määrittelyyn on erittäin hyödyllistä. Käyttäjäkeskeinen lähestymistapa edellyttää jatkuvaa vuoropuhelua aiottujen käyttäjien kanssa, jotta voimme keskittyä ratkaisua vaativaan ongelmaan ja välttää suunnittelemasta ratkaisua, joka ei ratkaisekaan keskeistä ongelmaa.

Kun pureudutaan perustavanlaatuisimpaan asiaan, saattaa myös paljastua, että eri käyttäjäsegmenttien tarpeet ja käyttötapaukset eroavat toisistaan. Niiden ymmärtäminen auttaa myös päättämään, pitäisikö keskittyä yhteen segmenttiin vai voidaanko eri käyttötapaukset ottaa huomioon vaarantamatta käyttäjäkokemusta ja siten tuotteen rakastettavuutta.

Resurssien keskittäminen oikeisiin asioihin

Nyt kun meillä on parempi käsitys ongelmista, joita haluamme ratkaista, voimme keskittyä oikeisiin asioihin:

Mitkä ominaisuudet ovat käyttäjälle ensisijaisia
Mitkä asiat on testattava ensin

Käyttäjäkeskeisten prioriteettien avulla voit keskittyä siihen, miten nämä ominaisuudet toteutetaan. Mitä tarvitaan, jotta käyttötapaus tai käyttäjävirta olisi sujuva ja intuitiivinen? Minkä on toimittava, jotta käyttäjävirta toimii tarkoitetulla tavalla? Mikä edellyttää käyttöliittymäelementtejä ja vuorovaikutusta ja mitä voi tapahtua konepellin alla? Näihin kysymyksiin vastaaminen johtaa yleensä monimutkaisempien teknisten ongelmien kartoittamiseen, jotka saattavat vaatia ratkaisua, ja antaa sinulle kehyksen, jonka varaan voit rakentaa mahdollisen tulevan kehityksen.

Yhteenveto

MLP:n toimittamisen alkuvaiheessa tehdään paljon työtä, jonka avulla saamme paremman käsityksen siitä, mitä asiakas haluaa rakentaa ja miksi. Tämä prosessi jatkuu koko kehitystyön ajan, ja työskentelemme usein iteraatioissa, jotka perustuvat parhaaseen ajan myötä kasvavaan ymmärrykseemme.

Tässä on lyhyt luettelo asioista, joita tarkastelemme tuotetoimituksen alussa:

Asiakkaan ymmärtäminen: ymmärrämme asiakkaan taustan, hänen aiemmat pyrkimyksensä ja sen, miksi hän keskittyy ratkaisemaan ongelman ohjelmistotuotteella.
Ongelman ymmärtäminen: ketä ongelma koskee, miksi se on korjattava ja mitä aiempaa työtä on tehty ongelman ratkaisemiseksi.
Käyttäjien ymmärtäminen: miksi käyttäjät ovat huolissaan tästä ongelmasta, millaisia käyttäjäryhmiä ongelma koskee ja miten tuote sopii heidän nykyisiin työnkulkuihinsa.
Prioriteettien ymmärtäminen: sen selvittäminen, mitkä tuotteen ominaisuudet ovat ratkaisevan tärkeitä ongelman ratkaisemiseksi, sen ymmärtäminen, mitkä ratkaisut ovat käyttäjille tärkeimpiä, ja niiden haasteiden löytäminen, joista meidän on huolehdittava alusta alkaen.

Seuraavaksi: tuotteen rakentaminen

Seuraavassa osassa menemme hieman syvemmälle Work in Progress -vaiheeseen, jossa alamme rakentaa ratkaisua ongelmaan: tuotetta. Kerromme, mitkä teknologiat toimivat mielestämme hyvin tämäntyyppisissä tuotetoimituksissa, ja annamme kuvan siitä, miltä kehitysprosessi näyttää.

Elämme järjestelmien aikakautta, jossa systeemien monimutkaisuus kasvaa ja ongelmat muuttuvat yhä enemmän ja enemmän koko järjestelmään vaikuttaviksi. Monimutkaisten ongelmien ratkaisemiseksi tarvitsemme enemmän kuin pelkästään suoraviivaisen ajattelun työkaluja. Tarvitsemme kykyä ajatella laajemmin, ymmärtää asioiden välisiä suhteita ja nähdä tuo kuuluisa suurempi kuva. Suoraviivainen ajattelu on hyvä lähtökohta, mutta se ei aina riitä. Systeemiajattelu tuo mukanaan uudenlaisen tavan tarkastella ongelmia ja ratkaisuja.

Systeemiajattelu ei ole vain taito, jonka opit – se on käytäntöjä ja näkökulmia. Mielestäni sitä voidaan kutsua jopa elämäntavaksi. Sitä ei voi täysin ymmärtää pelkästään lukemalla, aivan kuten et voi oppia pelaamaan golfia vain lukemalla siitä. Se täytyy kokea ja sitä täytyy harjoitella. Systeemiajattelu vaatii meitä ymmärtämään.

Lineaarinen ajattelu

Monet meistä ajattelevat lineaarisesti, ilman että sitä edes tiedostaa. Tämä ajattelutapa on niin syvään juurtunut, ettemme edes tunnista sitä yhdeksi monista lähestymistavoista. Lineaarinen ajattelu on ennustettavaa ja johonkin tiettyyn, usein opittuun, menettelytapaan perustuvaa. Kuulostaa hyvältä, varsinkin ohjelmistokehityksen kaltaisella alalla, missä pyritään usein lineaarisesti rakentamaan modulaarisia ja mahdollisimman tehokkaita palasia osaksi järjestelmää.

Lineaarinen ajattelutapa onkin varsin hyvä ja tehokas tapa ajatella monessa tilanteessa. Se tarjoaa selkeyttä ja hallittavuutta, mikä varsinkin ohjelmistosuunnittelijoille on työssä tärkeää. Kun lähdemme pohtimaan monimutkaisempia järjestelmiä ja relaatioita järjestelmien osien välillä, olisi ajattelutapaa kuitenkin syytä laajentaa.

Muutos kohti systeemiajattelua

Monimutkaisten järjestelmien suunnittelu on haastavaa ja esiin tulevat ongelmat muuttuvat yhä enemmän koko järjestelmään vaikuttaviksi ja monihaaraisiksi, jolloin lineaarinen ajattelu ei takaa parasta mahdollista lopputulosta. Systeemitason ongelmien ratkaisemiseksi tarvitaan uusia näkökulmia ja työkaluja.

Ajatellaan hyvin yksinkertaistettua esimerkkiä. Jos istutetaan seitsemän kasvin siementä, odotetaan että x päivän kuluttua voidaan korjata satona seitsemän täysikasvuista kasvia. Jos peura syö yhden kasveista, laitetaan aita estämään peuroja tekemästä tuhojaan ja korjataan loppu sato. Tällä tavalla lähestymme usein myös ohjelmistoprojektien suunnittelua.

Todellisuudessa asiat eivät kuitenkaan ole näin yksinkertaisia. Joskus saadaan yhdeksän kasvia, koska kasvit saattoivat jatkaa kasvuaan seuraavanakin vuonna. Toisinaan ei saada yhtään satoa. Syynä voi olla esimerkiksi jänikset, peurat, sade, sen puute tai vaikka liiallinen kylmyys. Lopputulos on käytännössä aina monen tekijän yhdistelmä, jotka vaikuttavat toisiinsa ennalta arvaamattomilla tavoilla.

Koska systeemit harvoin ovat täysin hallittavissa ja niiden käyttäytyminen on monesti ennakoimatonta, emme voi lähestyä monimutkaisempia kokonaisuuksia ainoastaan lineaarisesti ajatellen.

Systeemiajattelu vaatii työtä – mutta se on sen arvoista

Valitettavasti epälineaariset lähestymistavat ovat lähes aina vaikeampia kuin lineaariset. Systeemiajattelu ei tee elämästäsi helpompaa, mutta se tekee sinusta tehokkaamman. Systeemiajattelu lisää kykyäsi kohdata vaikeita haasteita, parantaa päätöksenteon laatua ja auttaa tunnistamaan, mitkä asiat ovat todellisia ongelmia ja mitkä vain oireita jostain muusta. Systeemiajattelun avulla voidaan löytää ja paneutua varsinaiseen signaaliin kaiken kohinan keskellä.

Systeemiajattelussa kyse on kuitenkin enemmän kuin vain ongelman ratkaisemisesta. Pohjimmiltaan kyse on ymmärryksestä – siitä, että ymmärretään koko konteksti, jossa ongelma esiintyy. Tämä vaatii jatkuvaa oppimista, ennen kaikkea sen tiedostamista, kuinka paljon et vielä tiedä. Systeemiajattelijan arvokkaimpia ominaisuuksia onkin, että tiedostaa sen, että ei tiedä kaikkea.

Miten tunnistaa systeemiajattelijan?

Hyvä systeemiajattelija tunnistaa lineaarisen ajattelun hyvät ja huonot puolet ja osaa valita, milloin käyttää lineaarista lähestymistapaa ja milloin asioita pitäisi katsoa koko systeemin perspektiivistä.

Systeemiajattelussa tulee tiedostaa, että tekniset ja sosiaaliset järjestelmät ovat lähes aina toisiinsa kietoutuneita. Pitää ymmärtää konteksti missä toimitaan ja miten tekniset ratkaisut sekä toiminnassa mukana olevat ihmiset vaikuttavat toisiinsa ja pyrkivät näkemään tilanteen useasta eri näkökulmasta.

Tärkeimpänä piirteenä systeemiajattelussa on se, että oppii ja mukautuu jatkuvasti. Hyvä systeemiajattelija on myös itseään reflektoiva ja tietoinen omista ajatusmalleistaan, reaktioistaan ja mahdollisista virhepäätelmistä. Systeemiajattelussa pyritään lisäämään tietoisuutta omasta ajattelusta ja auttaamaan tiimejä ja organisaatioita ymmärtämään, miten yhteiset prosessit, mallit ja päätökset vaikuttavat järjestelmään kokonaisuutena.

Muutamia systeemiajattelijan tunnusmerkkejä:

Ajattelee ajattelemista.
Ymmärtää ja tunnistaa lineaarisen ja epälineaarisen ajattelun ominaisuudet ja erottaa mikä on milloinkin paras lähestymistapa.
Osaa suunnitella ratkaisuja, missä on huomioitu konteksti ja koko systeemin tarpeet.
Ymmärtää että ihmiset ovat osa teknisiä systeemejä.
Pystyy luontevasti vaihtamaan näkökulmaa ratkaisuja etsiessään.
Pyrkii aina kehittämään omaa osaamistaan.
Pystyy ymmärtämään ja löytämään juurisyyt systeemitason ongelmiin ja ratkaisuihin.
Pystyy kommunikoimaan ja ennen kaikkea perustelemaan ideat ja muutosehdotukset.
Pystyy ymmärtämään miten toisistaan riippuvaiset ja toisiinsa liittyvät osat luovat kokonaisuuksia ja miten näitä riippuvuuksia voidaan hyödyntää parhaiten.
Pystyy luomaan perusteltuja malleja ja konsepteja päätöksenteon tueksi.
Ja ennen kaikkea hyväksyy, että epävarmuus on tervetullutta ja luonnollista sekä vääjäämätön osa elämää.

Ohjelmistokehittäjät osana systeemiä

Ohjelmistot eivät ole pelkästään teknisiä, vaan ne ovat itseasiassa sosio-teknisiä systeemejä. Lyhykäisyydessään tarkoittaen tapa, jolla ajattelemme, viestimme ja työskentelemme, on hyvin paljon sidoksissa siihen, miten ohjelmistot kehittyvät. Kun osat toimivat hyvin yhdessä, niin tekniset kuin sosiaalisetkin, on systeemi usein enemmän kuin vain osiensa summa.

Jos haluamme parantaa ohjelmistojärjestelmää, meidän on ensin tunnistettava, miten ohjelmiston parissa työskentelevä tiimi ajattelee siitä ja tarvittaessa pyrittävä muuttamaan tätä ajattelutapaa. Systeemin eheys, eli kuinka hyvin järjestelmän osat (niin tekniset kuin ei teknisetkin) toimivat yhdessä on erittäin tärkeää. Kun ideat ja konseptit ovat koko systeemin tasolla linjassa keskenään, järjestelmät palvelevat paremmin tarkoitustaan. Pienet muutokset ajattelutavassa voivat kantaa suuriin muutoksiin ohjelmistojärjestelmässä.

Kun tämä eheys puuttuu, näemme ongelmia, kuten tietojen siiloutumista, tiimien välisen työskentelyn tehottomuutta, purkkaratkaisuja, ohjelmistojen yhteensopimattomuutta ja teknistä velkaa, mitkä vaikeuttavat järjestelmän kehittämistä ja ylläpitoa.

Relaatiot ovat systeemisuunnittelua

Systeemiajattelussa keskeistä on relaatioiden ymmärtäminen. Ohjelmistosta tulee systeemi vasta, kun sen osat ovat keskinäisessä vuorovaikutuksessa. Kolme erillistä mikropalvelua pilvessä eivät ole vielä systeemi, vaan nämä ohjelmistokomponentit muuttuvat systeemiksi vasta siinä vaiheessa, kun niiden välillä on riippuvuuksia ja relaatioita.

Samoin kehitystiimi voidaan laskea systeemiksi siinä vaiheessa, kun tiimin jäsenet työskentelevät yhdessä ja heidän välillään on suhteita, jotka tukevat yhteistä tavoitetta.

Lineaariset lähestymistavat, joissa strategia tulee ylhäältä ja tiimit vain toteuttavat sen, eivät riitä monimutkaisessa, systeemisessä maailmassa. Organisaatioiden tulee ymmärtää, että muutokset vaikuttavat eri tavalla eri osiin järjestelmää ja että muutoksen onnistuminen riippuu kyvystämme suunnitella ja rakentaa toimivia suhteita systeemin sisällä.

Strategiset muutokset kuten digitaalinen transformaatio, modernisaatio tai vaikka muutos ohjelmistomonoliitistä mikropalveluarkkitehtuuriin ei voi olla vain ylhäältä alaspäin johdettu prosessi, koska muutos itsessään ei ole lineaarinen. Jos tällaista muutosta lähdetään viemään eteenpäin vain lineaarisesti ajatellen, tulee tie olemaan pitkä ja kivinen ja lopputuloksena tuskin saadaan aikaan mitään kovin pysyvää. Toki prosessi saadaan vietyä läpi, mutta todennäköisesti systeemi ei muutosten jälkeen ole kovin toimiva.

Yhteenvetona voidaan sanoa, että systeemiajattelu ei ole helppoa, mutta se on välttämätöntä, jos halutaan onnistua monimutkaisissa, epälineaarisissa ympäristöissä. Kun opitaan ajattelemaan tilannetta koko systeemin näkökulmasta konteksti ymmärtäen, voidaan luoda kestäviä ratkaisuja, jotka palvelevat parhaiten sekä teknisiä että sosiaalisia tavoitteita.

Lue lisää konsultointiin liittyvää sisältöä englanniksi.

Sotkuinen tai epäselvä käyttöliittymä? Ei kiitos. Löydät etsimäsi tiedon, mutta sen etsimiseen meni kolme kertaa odotettua aikaa kauemmin? Ei kiitos. Tämän päivän mobiilisovellusten odotetaan olevan helppokäyttöisiä, nopeita ja luotettavia – ja tarjoavan sitä mitä lupaavat. Jos sovelluksesi ei täytä näitä odotuksia, saatat hyvin todennäköisesti jäädä kilpailijoidesi jalkoihin. Laadukkaiden sovellusten kehittäminen ei kuitenkaan tapahdu käden käänteessä eikä useimmiten myöskään pienin kustannuksin. Mikä siis avuksi? Yksi vaihtoehdoistasi on hyödyntää työkalua, joilla voit kehittää sovelluksen nopeasti toimimaan sekä Android- että iOS-laitteilla, parhaimmillaan myös verkossa. Tällaisia ovat esimerkiksi tässä blogissa kuvaillut React Native ja Flutter. Suoraan suomennettuna ne ovat alustariippumattomia mobiilikehyksiä, joista yleisimmin käytetään niiden englanninkielistä nimitystä cross-platform mobile framework.

Mobiilisovelluksen kehityksestä puhuttaessa alustariippumattomuus tarkoittaa sitä, että sovellus voidaan kehittää Androidille, iOS:lle ja usein myös verkkoon käyttäen samaa koodipohjaa. Tämä taas tarkoittaa, että parhaimmillaan niin suunnittelu, kehitys kuin testauskin vievät vähemmän aikaa ja rahaa kuin kehitettäessä puhtaasti natiivia sovellusta. Natiivisovellus kas kehitetään toimimaan yhdellä alustalla alustan omaa kehitysympäristöä ja ohjelmointikieltä käyttäen, jolloin esimerkiksi Android- sekä iOS-laitteille suunniteltu sovellus pitäisi koodata ensin Androidille sitten iOS:ille. Se, onko yhden koodipohjan taktiikka sinun sovelluksellesi sopivin vaihtoehto, on oma kysymyksensä, mutta tämän kirjoituksen puitteissa sovitaan, että olet niin jo päättänyt. Seuraava kysymyksesi todennäköisesti on, että mikä cross-platform framework – tässä kehys – on paras. Lähdetään tutustumaan yhdessä kahteen tunnetuimpaan kehykseen, jotta saat kysymyksellesi vastinetta.

Kaksi käytetyintä mobiilikehystä

React Native ja Flutter ovat kaksi maailmalla eniten käytettyä mobiilikehystä, joiden avulla voidaan rakentaa mobiilisovelluksia useammalle eri alustalle. Molemmat ovat avoimen lähdekoodin kehyksiä, tukevat yhtä koodipohjaa Androidille ja iOS:lle, sekä sisältävät hot reload -ominaisuuden, joka yksinään jo nopeuttaa niin kehitystä kuin testaustakin.

Mikä on React Native?

Facebookin vuonna 2015 julkaisema React Native on avoimen lähdekoodin mobiilikehys, joka käyttää kunkin alustan natiivikomponentteja antaen sovelluksille niiden alustalle parhaiten istuvan ulkomuodon. Konepellin alla React Native käyttää JavaScriptiä ja JSX:ää (jälkimmäinen mahdollistaa HTML:n kirjoittamisen Reactilla), mikä tarkoittaa, että JavaScriptia osaavat kehittäjät oppivat sen yleensä melko nopeasti. React Nativelta löytyy myös suuri kehittäjäyhteisö ja sen avulla on kehitetty sovelluksia, kuten Discord, Instagram ja Pinterest.

Mikä on Flutter?

Googlen vuonna 2017 julkaisema Flutter on avoimen lähdekoodin mobiilikehys, joka käyttää Googlen omaa Dart-nimistä olio-ohjelmointikieltä. Sen kehittäjäyhteisö on kasvanut nopeasti, ja StackOverflow:n vuoden 2023 verkkokyselyssä se ohitti React Nativen suosituimpien teknologioiden kategoriassa Muut kehykset ja kirjastot. Flutterilla on kehitetty sovelluksia, kuten Google Pay, Etsy ja Phillips Hue.

Kuinka vaikeita React Native ja Flutter ovat oppia?

Tällä hetkellä Googlen Dart-ohjelmointikielellä ei ole muita suosittuja käyttötapauksia kuin Flutter. Siksi kehittäjän, jolla ei ole aiempaa kokemusta Dartista, täytyy Flutter-projektissa opetella täysin uusi kieli. Idention konsulttien kokemusten mukaan Dart-kielen oppimiskäyrä ei kuitenkaan ole niin jyrkkä kuin miltä se voi vaikuttaa. Huomattakoon, että Dartin syntaksi on samankaltainen kuin JavaScriptin, joten kehittäjä, joka osaa JavaScriptiä, ymmärtää luultavasti myös Dartsia hyvin pitkälle. Google on lisäksi pistänyt ekstrapaukkuja uuden projektin aloittamiseen sekä Flutterin dokumentaatioon tehdäkseen ensimmäisestä ripeän ja jälkimmäisestä sekä kattavan että helposti ymmärrettävän.

”Meillä oli Identiolla viikonlopun mittainen työpaja, jossa opettelimme Flutteria. Meitä oli kymmenen henkilöä, joilla ei ollut aiempaa kokemusta kyseisestä teknologiasta. Kaikilla oli tapahtuman päätteeksi toimiva sovellus.”
– Julius Rajala, Software Engineer

Vertailun vuoksi voidaan todeta, että kehittäjä, jolla on kokemusta ReactJS:stä, oppii React Nativen melko nopeasti. Todennäköisesti sinullakin on kehitystiimissäsi ohjelmistokehittäjiä, jotka ovat käyttäneet ReactJS:ää tai ainakin JavaScriptiä. React Nativen dokumentaatio kuitenkin kalpenee Flutteriin verrattuna sekä rakenteeltaan että sisällöltään. Dokumentaation osalta piste siis menee ehdottomasti Flutterille. Kokonaisuutena annan silti pisteet React Nativelle, sillä sen opettelu on kuitenkin selvästi helpompaa.

Onko sovelluksen käyttöliittymän rakentamisessa eroja?

React Native sisältää noin 25 käyttöliittymäkomponenttia. Kaikki ominaisuudet, joita ei voi rakentaa niiden avulla, on toteutettava joko käyttämällä kolmannen osapuolen kirjastoja tai kirjoittamalla ne alusta alkaen itse. Kolmannen osapuolen kirjastojen käyttö voi johtaa ongelmiin yhteensopivuuden kanssa, ja toisaalta ominaisuuksien luominen alusta alkaen on kallista. React Nativea pidetään kuitenkin vakaana kolmannen osapuolen komponenttien käyttämiseen esimerkiksi maksujen käsittelyyn tai geopaikannukseen ja tarjolla onkin laaja valikoima aktiivisesti ylläpidettyjä kirjastoja vastaaviin ominaisuuksiin. React Nativen etu piilee käyttöliittymän kannalta siinä, että se hyödyntää natiivikomponentteja. Natiivikomponentit on rakennettu juuri tiettyjä alustoja ja laitteita varten. Yksi esimerkki natiivikomponentista on jokaiselle tuttu kamerasovellus, joka näyttää erilaiselta ja käyttäytyy eri tavalla jokaisella alustalla.

Flutter taas pitää sisällään vielä kattavamman UI-komponenttikirjaston, sillä se on integroitu Googlen Material Designiin. Jos käyttöliittymä voidaan rakentaa tätä kirjastoa käyttämällä, yhteensopivuusongelmien kanssa ei tarvitse juurikaan taistella. Jos taas tarvetta on sellaiselle, mitä Material Design ei tarjoa, eivät vaihtoehdot kolmannen osapuolen kirjastojen suhteen ole yhtä laajat kuin React Nativella. Etuna tässä on silti se, että Material Design -kirjasto on hyvin suunniteltu ja vastaa useimpien modernien sovellusten tarpeisiin. Sovelluksen voi jopa suunnitella FlutterFlow’n avulla (lue erillinen blogitekstimme aiheesta), mikä tarkoittaa, että suunnittelussa käytetään näitä Flutterin sisäänrakennettuja UI-komponentteja. Se tekee toteutuksesta jo melko suoraviivaista.

Kumman suorituskyky on parempi?

Flutter ottaa suorituskyvyssä johdon, sillä Dartin tehokas käännösprosessi on suorituskyvyltään hieman parempi. Vaikutus käyttäjälle ei kuitenkaan ole niin merkittävä, että Flutterin käyttöä kannattaisi harkita vain tästä syystä. Mutta se on hyvä pitää mielessä.

Kumpi on helpompi ylläpitää?

Ylläpidon suhteen voitaisiin sanoa, että vallan mukana tulee vastuu, mutta tässä tapauksessa sanotaan, että kolmannen osapuolen kirjastojen myötä tulee päänsärky. No, vitsit sikseen. Kolmannen osapuolen kirjastojen käyttäminen tarkoittaa, että sinun on luotettava siihen, että näitä kirjastoja ylläpidetään aktiivisesti esimerkiksi tietoturva- ja yhteensopivuusongelmien välttämiseksi. Sinun on huomioitava myös kirjastojen viimeisimmät päivitykset ja se, pitävätkö nämä päivitykset kyseisen kirjaston yhteensopivana sovelluksesi kanssa. Tämä koskee sekä Flutteria että React Nativea. Itse React Nativen päivittäminen voi myös olla mielenkiintoinen kokemus, ja siitä vastaavalla kehittäjällä kannattaa olla lehmän hermot. Jotain hajoaa lähes aina, eikä vastaan tulleiden haasteiden korjaaminen ole yleensä nopeaa. Jos jätetäänkin huomiotta kolmannen osapuolen kirjastojen käyttö, React Native menettää pisteen ylläpidon suhteen.

Entä virheet ja sovelluspäivitykset?

Oletetaan, että sovelluksesi on saatavilla yleisimmissä jakelukanavissa eli sovelluskaupoissa kuten Google Play ja App Store. Silloin sovelluspäivitysten toimittaminen on melko samanlaista sekä Flutterissa että React Nativessa. Jos eroja huomaa, ne tulevat vastaan todennäköisimmin virheitä korjatessa tai testauksen yhteydessä, joten ne eivät näy niinkään käyttäjille vaan kehittäjille. Flutteriin sisälle on integroitu testausominaisuuksia, kun taas React Nativella ei ole erikseen virallista testauskehystä, vaan siinä käytetään Jestin kaltaisia testauskehyksiä.

Muita huomioitavia asioita React Nativen ja Flutterin välillä?

Tässä vaiheessa on syytä mainita, että emme koskaan tiedä, kuinka kauan nämä kehykset tulevat säilymään. Vain tästä näkökulmasta katsottuna natiivisovellusten kehittäminen voi olla ”turvallisempi” vaihtoehto. Tämä ei kuitenkaan tarkoita, että cross-platform olisi millään lailla huono valinta. React Native on ollut olemassa jo lähes vuosikymmenen ajan ja joitakin maailman suosituimmista sovelluksista on kehitetty sen avulla. Flutterin takana taas on Google. Googlella ei ehkä ole paras mahdollinen maine teknologioidensa pitkäaikaisessa tukemisessa, mutta Flutterin tulevaisuus on kuitenkin näyttänyt erittäin lupaavalta.

Kumpi sopii paremmin tarpeisiini?

Riippuu täysin siitä, mitä olet tekemässä. Mikä on budjettisi ja aikataulusi? Onko sinulla jo valmis suunnitelma? Kuka tai ketkä työskentelevät sovelluksen parissa? Riippuen sovelluksesi toiminnallisuuksista, erot sen kehittämisessä React Nativella tai Flutterilla voivat olla joko merkittäviä tai merkityksettömiä. Voin luvata, että saat toimivan sovelluksen kummallakin, mutta tie siihen voi olla erilainen. Päätös on tehtävä aina tilannekohtaisesti. Jos päätöksenteko on vaikeaa, voit aina kysyä asiaa taholta, jolta löytyy aiheesta enemmän kokemusta.

Kirjoittajan huomiot

Koska monille teistä React Native saattaa olla se tutuin mobiilikehys, halusimme kollegojeni kanssa muistuttaa, että on olemassa toinenkin loistava vaihtoehto – Flutter. Olen itse käyttänyt React Nativea enemmän ja sen puutteista huolimatta nautin edelleen sen parissa työskentelystä. Samalla näen ehdottomasti Flutterin tarjoamat mahdollisuudet ja pidän sitä yhtä varteenotettavana vaihtoehtona mobiilikehitysmaailmassa. Pidäthän Flutterin siis mielessä oman sovellusprojektisi kohdalla, sillä tutuin ei ole aina paras – tärkeintä on se, minkälaista sovellusta kehität ja minkälainen kehitystiimi teiltä löytyy.

Lue myös: FlutterFlow – sovelluskehitystä ilman koodausta

Rust on monipuolinen ohjelmointikieli

Vaikka Rustin suurimmat hyödyt tulevat esille ohjelmissa, joissa suorituskyky, sovellusten turvallinen monisäikeinen ajo sekä pieni muistijalanjälki ovat elintärkeitä, ja joissa esimerkiksi C ja C++ ovat olleet suosittuja vaihtoehtoja jo viimeiset liki 50 vuotta, on Rustista paljon muuhunkin. Muun muassa JavaScriptin ja Pythonin erilaisten kehittäjätyökalujen kirjoittaminen Rustilla on kasvattanut suosiotaan viime aikoina. Rustin laajan käyttäjäyhteisön ja suoraviivaisen paketinhallinnan myötä on Rustille luotu paketteja ja kirjastoja monenlaisiin käyttötarkoituksiin, aina web-ohjelmoinnista pelimoottoreihin ja työpöytäsovelluksiin. Näistä nostona uusi, nopeudestaan tunnettu, AI-avusteinen ja yhteistyöpohjainen koodieditori Zed, joka on kirjoitettu kokonaan Rustilla.

Rustin valttikortti on muistinhallinta

Rustin yksi keskeisimmistä ominaisuuksista on tehokas ja turvallinen muistinhallinta, joka perustuu muistin omistamisen, lainaamisen ja eliniän tarkkoihin sääntöihin, joita kääntäjä automaattisesti valvoo kääntämisvaiheessa. Omistamisen säännöt pähkinänkuoressa ovat:

Jokaisen arvon omistaa jokin muuttuja.
Jokaisella arvolla voi olla vain yksi omistaja kerrallaan.
Kun arvon omistaja katoaa näkyvistä, arvo pudotetaan.

Esimerkkinä näistä säännöistä kaksi lyhyttä funktiota:

fn rules_one_and_two() {	
	let x: String = String::from("Sääntö 2: Jokaisella arvolla voi olla vain yksi omistaja kerrallaan.");

Luodaan muuttuja x ja annetaan sille arvo, joka on tyyppiä String.

let y = x;

Luodaan muuttuja y ja määritetään sille x :n arvo. String on Rustissa tyyppi, jota ei ole ‘halpa’ kopioida (tällaisia ovat tyypit, joiden koko tiedetään kääntämisvaiheessa kuten erilaiset primitiivityypit bool, i32 , char…) joten y:lle siirretään muuttujan x omistama arvo.

   println!("{x}");
}

Makro nimeltään println! yrittää tulostaa stdout:iin muuttujan x. Tämä kuitenkin epäonnistuu, sillä muuttujaa x ei ole enää olemassa arvonsa poissiirtämisen jälkeen eikä sitä voi enää käyttää.

   fn rule_three() {
	let x = 10;

Määritetään uusi funktio ja sen näkymässä määritetään muuttujalle x arvoksi 10.

{
	 println!("x: {x}");
	 let y = 50;
}

Määritetään kaarisuluilla uusi näkymä, jossa tulostetaan jo tutulla println! -makrolla muuttujan x arvo. Koska muuttuja on määritetty ulommassa näkymässä, se on olemassa myös tässä näkymässä ja tulostus tuottaa stdout:iin tekstin x: 10 . Määritetään tässä uudessa näkymässä myös muuttuja y , annetaan sille arvoksi 50 ja suljetaan näkymä.

      println!("y: {y}");
}

Funktion näkymässä muuttujaa y ei ole olemassa ja tulostus epäonnistuu. Tämä tapahtuu siksi, että sisemmän näkymän päätyttyä y on kadonnut näkyvistä ja sen arvo on pudotettu. Lopulta kun funktion näkymä päättyy, katoaa x näkyvistä ja sen arvo putoaa. Muuttujia voi määrittää globaaleina (yleensä) tiedoston alussa näkymien ulkopuolelle, jolloin ne luonnollisesti näkyvät kaikissa näkymissä (eli funktioissa).

Rustin muuttujat (let x = 42) ovat lähtökohtaisesti muuttumattomia. Muuttuja voidaan merkitä muuttuvaksi (let mut x = 42), jolloin sen arvoa voidaan muokata määrityksen jälkeen, mutta vain mikäli sitä ei ole lainattu. Muuttujia voidaan ‘lainata’ toisiin muuttujiin käyttämällä referenssiä muuttujaan. Referenssejä on kahdenlaisia: muuttumattomia referenssejä (let y = &x) tai muuttuvia referenssejä (let y = &mut x). Muuttujalla voi olla samanaikaisesti joko rajaton määrä muuttumattomia referenssejä TAI tasan yksi muuttuva referenssi. Rustin kääntäjä seuraa lainausten elinaikoja tarkasti, joten viittauksia vapautettuun arvoon ei myöskään voi käyttää. Nämä säännöt tekevät rinnakkaisajon tuomista ongelmista (looking at you data races 👀) historiaa!

Esimerkiksi Javasta tuttua roskankeruuta ei Rustissa myöskään ole. Tämä mahdollistaa C/C++ -tasoisen suorituskyvyn ilman manuaalisen muistinhallinnan tuomia ’metkuja’ (nullpointterien tuoma undefined behaviour, buffer overflow, use-after-free anyone?), jotka satavarmasti ovat jossain välissä ilmaantuneet syvinä juonteina jokaisen C/C++ -kehittäjän otsalle. Mikäli ohjelmassa löytyy halua tai tarvetta sääntöjen rikkomiselle tai manuaaliselle muistinhallinnalle (Rust sisältää työkalut myös älykkäiden pointterien hallintaan), tyypillisesti esimerkiksi muiden kielten kanssa kommunikointiin tai erittäin matalan tason koodin kirjoittamiseen, myös tälle on keinonsa. Koodi voidaan määrittää unsafe -avainsanalla. Unsafe tosin on ehdottomasti viimeinen vaihtoehto, jota ennen tulisi testata tarkkaan, onko muussa koodissa mitään vikaa, sillä muutkaan kääntäjän turvatoimet eivät tässä enää päde ja ohjelmasi virheiden ja kaatumisten riski kasvaa huomattavasti.

Tiukat säännöt luovat kynnyksen Rustin käyttämiselle

Jotta tämä kirjoitus ei menisi vain puhtaaksi ylistyslauluksi, puhutaan myös Rustin huonommistakin (onko niitä oikeasti?) puolista. Näistä suurimpana on oppimiskynnys ja koodin kirjoittamiseen kuluva aika verrattuna muihin, ’perinteisempiin’ koodikieliin. Kääntäjän valvomat omistajuus- ja elinaikasäännöt ovat sangen tiukat, joten ratkaisujen keksiminen kääntäjän miellyttämällä tavalla ei välttämättä ole suoraviivaista. Tämä johtaa myös siihen, ettei pienten, nopeiden koodinpätkien ja ohjelmien kirjoittaminen Rustilla ole kaikista mukavin kokemus. Myös kielen suhteellinen nuoruus kuvastuu kirjastojen kypsyydessä ja standardikirjaston ominaisuuksien laajuudessa. Mielestäni ehkä suurin näistä puutteista on hyvän GUI-kirjaston puute. Kielen nuoruus näkyy myös tekijöiden määrässä, sillä C- ja C++-osaajia on vuosien varrella ehtinyt kertymään jo reilusti, kun taas Rust-osaajia ei vielä niin monia ole. Mikäli Stack Overflow’n käyttäjäkyselystä voisi jotakin päätellä, kysyntä loisi myös tarjontaa tekijöistä, sillä halukkaita koodareita Rustia tekemään päivätyökseen olisi runsaasti.

Vaivannäkö palkitaan toimintavarmuudella

Olemassaolevan C- ja C++-koodin määrä maailmassa on valtava, eikä tätä kaikkea kukaan pysty, osaa tai halua kirjoittaa Rustilla uudestaan. Eikä tälle oikeastaan tarvetta olekaan, sillä vanhemman koodin bugit tulevat (pääsääntöisesti) korjatuksi ajan myötä. Rustin paikka mielestäni onkin juuri uusissa projekteissa, jossa etenkin koodin nopeudella ja muistiturvallisuudella on tärkeä rooli. Vaikka nykyaikainen C++ (etenkin versioista C++11/14/17 eteenpäin) onkin kehittynyt huomattavasti mm. muistinhallinnan (älykkäät pointterit ym.) ja moniajon (atomiset muuttujat, jopa STL sisältää niitä nykyään) saralla, on Rustilla ohjelman kirjoittamisen tuoman lisävaivan vastapainona kuitenkin Rust-kääntäjän takuu siitä, ettei määrittelemätöntä käytöstä tai kaatumisia tapahdu. Tämä vaihtokauppa on mielestäni täysin tekemisen arvoinen diili.

Parhaatkin kehittäjät tekevät varmasti virheitä ja bugeja eksyy jossain vaiheessa kaikkiin ohjelmiin. Miksi emme siis käyttäisi työkalua, joka auttaa havaitsemaan mahdolliset virheet jo koodia kirjoittaessa, eli mahdollisimman aikaisessa vaiheessa? Projektinhallinnan näkökulmasta tämä tulee halvemmaksi kuin bugien havaitseminen koodiarvioinnissa, joka tulee halvemmaksi kuin bugien havaitseminen (julkaisu)testaamisessa, joka taas tulee halvemmaksi kuin bugien havaitseminen tuotannossa…

Rust gud

Lue myös: React Native vs Flutter – usein kysytyt kysymykset

ID Academy on Idention sisäinen osaamisen kehittämisen malli. Sen tarkoituksena on mahdollistaa ja varmistaa niin ohjelmistokehittäjien kuin inhouse-rooleissa työskentelevien ihmisten osaamisen kehittäminen työajalla. Malli syntyi työntekijöiden aloitteesta, sillä oman osaamisen kehittämiselle kaivattiin raameja ja pelisääntöjä.

Tässä tekstissä kerron, miksi ID Academy on hyödyllinen kaikille osapuolille ja miten se toimii yrityksemme arjessa.

Asiakas, ohjelmistokehittäjä ja Identio – kaikki hyötyvät

ID Academy on olemassa, jotta voimme yhdessä sovittujen pelisääntöjen puitteissa kehittää ammatillista osaamistamme ja tarjota sen myötä asiakkaillemme parasta mahdollista palvelua. Sen lisäksi, että asiakkaamme saavat aina ajantasaista ja kehittyvää osaamista, on ID Academystä hyötyä myös Identiolle.

Me Identiolla uskomme, että ID Academyn tyyppiset mahdollisuudet ovat välttämättömiä kaltaisellemme yritykselle etenkin pitkässä juoksussa. Kun mahdollistamme osaamisen kehittämisen työajalla ja kannustamme siihen, pidämme ohjelmistokehittäjät motivoituneina ja sitoutuneempina sekä heidän työhönsä että koko yritykseemme.

Osaamisen kehittäminen on tärkeää yritykselle itselleen myös mm. seuraavista syistä:

Teknologian kehitys. IT-alalla uudet teknologiat, ohjelmistot ja työkalut tulevat markkinoille nopeasti. Osaamisen kehittäminen on välttämätöntä kilpailukyvyn ylläpitämiseksi. Asiakkaat odottavat aina parempaa palvelua ja uusia ratkaisuja ja haluamme pystyä vastaamaan tähän tarpeeseen.
Työtehtävien monimuotoisuus. Ohjelmistokehittäjät työskentelevät konsultin roolissa hyvin monipuolisten ja vaihtuvien työtehtävien parissa. Osaamista voidaan vaatia eri osa-alueilla, kuten web- tai mobiiliapplikaatioiden kehittämisessä, pilvipalveluissa, integraatioissa tai DevOpsissa – uusista teknologioista puhumattakaan . Eri roolit voivat vaatia erilaista osaamista ja monimutkaisia asiakastarpeita, mikä korostaa jatkuvasti kehittyvän osaamisen tarvetta.
Asiakaskokemuksen parantaminen. Osaamisen kehittäminen auttaa yritystä luomaan parempia ja käyttäjäystävällisempiä palveluja, mikä parantaa asiakastyytyväisyyttä ja sitoutumista.
Skaalautuvuus ja kasvu. Yritykset, jotka panostavat osaamisen kehittämiseen, ovat valmiimpia kasvamaan ja skaalaamaan liiketoimintaansa.

Miten ID Academy toimii käytännössä?

Oppiminen ja urakehitys olivat Identiolla aiemmin täysin riippuvaisia asiakastyöstä tai keskinäisistä mentorointisuhteista, eikä selkeää ohjeistusta ajankäytölle itsensä kehittämiseen liittyen ollut. Oman osaamisen kehittäminen on aina ollut sallittua jossain määrin ja luonnollisesti työssä vastaan tuleviin, syventymistä kaipaaviin, asioihin on aina käytetty niiden vaatima aika. Työntekijät kaipasivat kuitenkin selkeyttä ja jonkinlaista ”yhteistä sopimusta” ajankäytöstä systemaattisemman osaamisen kehittämisen saralla.

Tällä hetkellä ID Academyyn kuuluvat sekä sille varattu aika että työntekijäkohtainen budjetti. Tämä tarkoittaa, että jokainen työntekijä voi käyttää yhden perjantain kuukaudessa oman osaamisensa kehittämiseen. Päivä sovitaan etukäteen asiakkaan kanssa, eikä kyseisen päivän työajasta luonnollisesti laskuteta asiakasta. ID Academy on siis Idention tekemä investointi sekä asiakkaan että työntekijän ja yrityksen itsensä hyväksi.

Lyhyellä aikavälillä ID Academysta aiheutuu Identiolle kustannuksia laskuttamattoman työajan sekä opiskelumateriaaleihin varatun budjetin muodossa, mutta pidemmällä aikavälillä uskomme sen nostavan työntekijöiden sitoutumisastetta. Voimme myös hyödyntää opittuja asioita työssämme, mikä taas avaa ovia monipuolisempiin projekteihin. Toivomme ID Academyn vaikuttavan positiivisesti myös uusien työntekijöiden rekrytointiin.

Ohjelmistokehittäjät kokevat osaamisen kehittämisen tärkeäksi

Vaihtuvuus IT-alan yritysten henkilöstössä on usein korkeaa. Yhdysvaltalaisen Talentrisen teettämä tutkimus osoitti, että ura- ja kehittymismahdollisuudet ovat toiseksi tärkein tekijä, joka vaikuttaa ohjelmistokehittäjien pysyvyyteen yrityksessä. Tämä korostui etenkin juniorikehittäjien kohdalla, mutta tarve ammatilliseen kehitykseen näkyy oman kokemuksemme mukaan laajasti kaikilla ammatillisilla tasoilla.

Myös monet muut pohjoismaissa ja Euroopassa teetetyt tutkimukset tukevat ammatillisen kehityksen merkitystä ohjelmistokehittäjien pysyvyydessä. Teetimme vuonna 2022 Identiolla kyselyn osaamisen kehittämiseen liittyen. Kyselyn tulosten perusteella ohjelmistokehittäjien ylivoimaisesti suurin este oman osaamisen kehittämiselle oli ajan puute. Esiin nousi myös tilanteita, joissa asiakasprojekti on ollut mielekäs ja sopivan haastava, mutta sen parissa ei ole tullut oppimiskokemuksia sellaisista teknologioista tai teemoista, joihin ohjelmistokehittäjä haluaisi seuraavaksi perehtyä.

Kun kysyimme, mikä olisi merkittävintä osaamisen kehittämisen kannalta, selkeästi yleisimmäksi vastaukseksi nousi sille varattu aika. Muita tekijöitä, joita ohjelmistokehittäjämme arvostivat, olivat mentorointi ja monipuoliset asiakasprojektit. Koska ajan puute nousi vastauksissa esiin huomattavasti muita syitä useammin, on ID Academy suunniteltu vastaamaan etenkin siihen tarpeeseen. Osaamisen kehittäminen on nyt mahdollista työajalla ja samalla tuemme työntekijöidemme hyvinvointia mahdollistamalla entistä tehokkaammin työn ja vapaa-ajan erottamisen toisistaan.

Ohjelmistokehittäjiä, jotka sitoutuvat työhönsä

Olemme keskustelleet asiakkaidemme kanssa heidän aiemmista kokemuksistaan ohjelmistokonsultoinnin ostamisesta. Iso osa projekteista viedään kunnialla maaliin, mutta joissain tapauksissa IT-talon tarjoama osaaminen tai projektiin sitoutuminen eivät ole vastanneet odotettua tasoa. Siksi tiedämme, että konsultoinnin ostaminen herättää monia kysymyksiä ja epävarmuuksia. Näissä tilanteissa keskiöön nousevat kuitenkin tiivis ja rehellinen yhteistyö sekä läpinäkyvyys.

Meille työn korkea laatu tulee aina tärkeimpänä prioriteettina. Arvostamme myös mutkatonta yhteistyötä ja olemme saaneet siitä kiitosta useilta asiakkailtamme. Lue työmme-sivulta, miten olemme auttaneet asiakkaitamme onnistumaan.

Mikä on design sprint?

Entinen Google Venturesin designkumppani Jake Knapp kehitti design sprint -prosessin Googlelle vuonna 2010, ammentaen inspiraatiota muun muassa Googlen omasta tuotekehityskulttuurista ja IDEO:n design thinking -työpajoista. Design sprinteissä tiimit työskentelevät ongelmien ja asetettujen tavoitteiden parissa edeten kehitettävän tuotteen tai palvelun kartoituksesta potentiaalisen ratkaisun testaamiseen tyypillisesti viiden päivän jaksossa.

Sprintit ovat myös keskeinen osa ketterää kehitystä. Design sprintin suurin hyöty on sen säästämä aika, sekä sprintin aikana tehtävät havainnot tulevan tuotteen tai palvelun kehittämisestä, sen mahdollisuuksista ja haasteista. Design sprint antaa selkeän kuvan kehitystyön seuraavista askeleista ja varmistaa, että kehitystiimi on samalla sivulla tavoiteltavasta lopputuloksesta.

Design sprintin viisi vaihetta

Design sprint jakautuu viiteen vaiheeseen, jotka tyypillisesti jaetaan päiväkohtaisesti yhden viikon ajalle tai joskus joustavammin esimerkiksi kahden tai kolmen viikon kehitysjaksolle.

Design sprintin idea on saada mahdollisimman nopeasti ja tehokkaasti kuva kehitettävästä tuotteesta tai palvelusta. Tämän vuoksi kehitysjaksoa ei ole järkevää venyttää liian pitkäksi. Joskus kuitenkin voi olla perusteltua poiketa perinteisestä viikon ajalle jakautuvasta mallista.

1 Kartoitus

Kartoitusvaiheessa jaetaan kaikki olennainen tieto tiimin kesken, jotta kaikilla osapuolilla on yhtenäinen ymmärrys projektin taustoista ja nykytilanteesta. Tämän vaiheen aikana pyritään tunnistamaan ja erittelemään kipukohdat, jotka estävät tai hidastavat tavoitteiden saavuttamista. Näiden kipukohtien perusteellinen ymmärtäminen on tärkeää, sillä ne ohjaavat tulevia suunnittelu- ja kehityspäätöksiä.

Lisäksi kartoitusvaiheessa hahmotellaan projektin kokoluokka, jotta työ pysyy realistisena aikataulun ja resurssien puitteissa.

Idention lähestymistapa

Työpaja #1 – Ensimmäisessä työpajassa käymme läpi yhdessä asiakkaan kanssa projektin kannalta olennaiset asiat. Keskustelemme erityisesti projektin tavoitteista ja teknisistä lähtökohdista.

2 Ideointi

Design sprintin toinen vaihe, ideointi, on luova vaihe, jossa tiimi kehittää potentiaalisia ratkaisuja tuotteen tai palvelun kehittämiseksi. Tavoitteena on vastata kartoitusvaiheessa esiin nousseisiin keskeisiin kysymyksiin ja haasteisiin. Ideointivaiheessa keskitytään erityisesti tunnistettujen kipukohtien ratkaisemiseen uusilla näkökulmilla ja lähestymistavoilla. Tiimi pohtii, miten nämä kipukohdat voidaan ratkoa tekniset lähtökohdat ja käyttäjäkokemus huomioiden. Ideointivaiheen lopputuloksena tiimillä on useampi vaihtoehto, joita seuraavassa vaiheessa lähdetään arvioimaan.

Idention lähestymistapa

Työpaja #2 – Toisessa työpajassa ideoimme vaihtoehtoja yhdessä asiakkaan kanssa Kartoitus-vaiheessa esiin nousseisiin kysymyksiin. Esittelemme myös teknologiaehdotuksemme tuotteen tai palvelun toteuttamiseen.

3 Päätöksenteko

Päätöksentekovaiheessa tiimi keskittyy valitsemaan parhaat ideat, jotka viedään prototyyppivaiheeseen. Päätöksentekoprosessissa käytetään usein apuna erilaisia työkaluja kuten Sticky Decision-menetelmää.

Päätöksenteon jälkeen luodaan storyboard, eli toimintakaavio, joka visualisoi valittujen ideoiden kulkua. Toimintakaavion avulla tarkistetaan mahtuvatko kaikki valitut ideat yhteen prototyyppiin. Storyboardin avulla tiimi voi hahmottaa tuotteen tai palvelun käyttäjäkokemusta ja varmistaa, että valitut ideat muodostavat yhtenäisen ja toimivan kokonaisuuden.

Idention lähestymistapa

Työpaja #3 – Kolmannessa työpajassa priorisoimme ja rajaamme Prototyyppi-vaiheessa toteutettavien interaktiivisten demojen ominaisuudet. Apuna voidaan käyttää esim. Planning poker -menetelmää.

4 Prototyyppi

Design sprintin neljäs vaihe, prototyypit, keskittyy konkreettisten mallien luomiseen päätöksentekovaiheessa valittujen ideoiden pohjalta. Tiimi voi luoda yhden tai useamman prototyypin, jotka edustavat eri ratkaisuja ja lähestymistapoja.

Prototyyppivaiheessa luodaan interaktiivinen demo, joka mahdollistaa tuotteen tai palvelun kokeilemisen. Tämä demo toimii tärkeänä työkaluna seuraavassa vaiheessa, jossa se testataan. Prototyypin tulee olla riittävän realistinen, jotta se tarjoaa todentuntuisen kokemuksen, mutta sen ei tarvitse olla täydellinen tai sisältää kaikkia lopullisia ominaisuuksia. Tärkeintä on, että prototyyppi havainnollistaa keskeiset ideat ja mahdollistaa niiden käytännön testaamisen.

Idention lähestymistapa

Rakennamme interaktiivisen demon hyödyntäen Figma-työkalua. Prototyypin avulla keskustelemme yhdessä asiakkaan kanssa mahdollisista puutteista ja kehityskohdista ennen testausta.

5 Testaus

Testauksen tarkoituksena on saada arvokasta palautetta siitä, miten hyvin prototyyppi vastaa käyttäjien tarpeita ja odotuksia. Tämä vaihe auttaa tunnistamaan myös mahdolliset ongelmakohdat ja käyttäjäkokemuksen puutteet ennen varsinaisen tuotteen kehitystä.

Testauksen aikana kerätty palaute käydään läpi, ja sen pohjalta tehdään tarvittavat korjaukset, jotta varsinaisen tuotteen kehityksessä voidaan välttyä turhalta työltä.

Idention lähestymistapa

Testaamme prototyypin yhdessä asiakkaan kanssa. Kirjaamme ylös testauksen havainnot ja keskustelemme seuraavista askeleista ennen tuotteen tai palvelun kehityksen aloittamista.

Design sprintin kehitystyön apuna

Design sprint auttaa saamaan nopeasti kokonaiskuvan kehitettävän tuotteen tai palvelun tilasta ennen varsinaisen kehitystyön aloittamista.

Design sprintin hyötyjä voivat olla mm.:

Kehitettävän tuotteen tai palvelun tavoitteet ja kipukohdat on kartoitettu ja kehitystiimi on samalla sivulla kehitettävästä tuotteesta tai palvelusta.
Ideointityöpajan ideat on kirjattu, käyty läpi ja priorisoitu.
Alustava kartoitus ja ehdotus teknologiavalinnoista on tehty.
Tuotteesta tai palvelusta on rakennettu interaktiivinen demo, joka auttaa hahmottamaan tavoiteltavaa lopputulosta.
Testauksen avulla kehityskohdat on dokumentoitu.
Varsinaisen tuotteen tai palvelun kehitystyö voidaan aloittaa.

Design sprintin aikana tiimi kartoittaa tavoitteet ja haasteet, ideoi ratkaisuja, valitsee parhaat ideat, rakentaa prototyypin ja testaa sen käytännössä. Tämä prosessi auttaa välttämään mahdolliset sudenkuopat ennen varsinaisen kehitystyön aloittamista ja varmistaa, että tiimi työskentelee kohti yhteistä päämäärää. Jos design sprint kuulostaa teille sopivalta lähestymistavalta, ota meihin rohkeasti yhteyttä.

FIXABLY

Skaalautuvuutta mobiililaitteiden huoltoliiketoimintaan uuden tuotteen avulla

Vielä 90-luvulla mobiililaitteiden ja tietokoneiden teknologiasta tuli vanhentunutta ja käyttökelvotonta vain parissa vuodessa. Tänä päivänä tilanne on toinen. Laitteiden elinkaari on pidentynyt laadun suhteen ja ne kestävät aikaa. Fixablyn missiona on pidentää kymmenen miljardin laitteen elinkaarta. Yritys ei käsittele itse tätä kunnianhimoista määrää laitteita, vaan auttaa asiakkaitaan sitä kohti kehittämällä ohjelmistoja laitteiden kunnostuksen ja jälleenmyynnin helpottamiseksi. Autoimme Fixablya suunnittelemaan ja kehittämään täysin uuden toiminnanohjausjärjestelmän kunnostusprosessien tueksi.

Työnkuvamme

Lähtötilanne ja haasteet

Mobiililaitteiden valmistajilla on pirstaloitunut näkemys markkinasta, kun puhutaan mobiililaitteiden kunnostuksesta ja jälleenmyynnistä. Valtuutettuja takuuhuoltoja tehdään vain noin noin viidelle prosentille laitteista ja iso osa vanhoista puhelimista päätyy käyttämättömänä lipaston pohjalle. Siksi kattavaa dataa niiden elinkaaresta on vaikea saada. Toimialan digitalisointi mahdollistaa laitteiden elinkaaren merkittävän pidentämisen ja uusien käyttötarkoitusten löytämisen.

Fixablyn päätuote Repair kattaa koko yrityksen operaatioiden hallinnan mobiililaitteiden kunnostusprosessista jälleenmyyntiin ja se on käytössä lukuisissa yrityksissä eri maissa. Tuote on kompleksinen ja sen käyttöönotto vie jonkin verran aikaa. Lisäksi asiakasyrityksillä on hyvin moninaisia vaatimuksia operaatioidensa pyörittämiseen ja esimerkiksi tarve erilaisille integraatioille on kovaa. Tuotteelle on ollut laajasti kysyntää ja siksi se on myynyt pitkälti itse itsensä. Sen myyntisyklit ovat kuitenkin pitkiä ja kehitystarpeet toisinaan vaikeasti ennakoitavia.

Syntyi tarve tuotteelle, joka palvelisi paremmin keskisuuria yrityksiä ja jonka käyttöönotto olisi kevyempää. Yritys teki strategisen ratkaisun lähteä kehittämään uutta tuotetta, jonka kehittämiseen tarvittiin kokemusta ja vahvaa osaamista ketterästä ohjelmistokehityksestä. Uuden tuotteen rakentaminen ja toisaalta vaihtelevat kehitystarpeet ovat tilanteita, joissa Fixablyn kaltaisen toimijan on helppo laajentaa hetkellisesti resurssejaan konsulttien avulla.

Idention konsultti oli projektissa hyvin keskeisessä roolissa. Hän suunnitteli ja kehitti koko frontend-frameworkin mentoroiden samalla nuorempaa kehittäjää.

– Harry Forsman, VP of Recommerce

Ratkaisu ja tulevaisuus

Strategisen suunnittelun yhteydessä määriteltiin kehitystiimi tuotteen rakentamiseksi. Idention konsultti toimi projektissa frontend-kehittäjän roolissa osana Fixablyn kehitystiimiä.

Projektissa suunniteltu ja kehitetty täysin uusi tuote on kevyt toiminnanohjausjärjestelmä kunnostusprosessien tueksi. Se on tarkoitettu pienemmille asiakasyrityksille ja myytäväksi suuremmalla volyymilla kuin Repair. Tuote on vähemmän kustomoitava ja sen avulla yritys voi esimerkiksi käynnistää toimintansa. Skaalautuvuutensa vuoksi se mahdollistaa ketterämmät kokeilujaksot, eikä perehdyttäminen järjestelmän käyttöön vaadi huomattavaa määrää aikaa. Tuote pitää sisällään koko työnkulun aina mobiililaitteen sisäänostosta ja kuntotarkastuksesta sen saattamiseksi myyntiin eri markkinapaikoille. Tuotteeseen rakennettiin myös integraatiot kahteen eurooppalaiseen palveluun, jotka myyvät käytettyjä mobiililaitteita.

Projektissa frontend-kehittäjän vastuualueisiin sisältyi koko frontend-arkkitehtuurin rakentaminen ja projektin hyvin ketterästä toteutustavasta vastaaminen. Rooli oli projektin kannalta keskeinen, koska se piti myös huolta sujuvasta kommunikaatiosta eri osapuolten välillä. Frontend itsessään on tärkeä osa tuotetta, sillä se herättää eloon designin ja bisneslogiikan tuoden samalla näkyväksi koko tiimin vision rakennettavasta tuotteesta.

Keskisuurten yritysten palveleminen kevyemmän tuotteen avulla on tärkeässä roolissa Fixablyn liiketoiminnan kannalta. Kun toimijoiden globaali verkosto kasvaa, logistiikka helpottuu ja liiketoiminta tehostuu. Sen myötä myös loppuasiakkaan, eli mobiililaitteen omistajan, asiakaskokemus paranee esimerkiksi laitteen huollon osalta.

Kehitimme tuotetta tietynlaisella perustaja-asenteella. Sellaisella, että teemme enemmän kuin vain toteutamme jonkun muun sanelemia tehtäviä.

Yhteenveto

Strateginen tuotesuunnittelu asiakkaan liiketoiminnan näkökulmasta

Teknologiakartoitus ja -valinnat yhdessä tiimin kanssa

Frontend-arkkitehtuurin rakentaminen ja frontend-kehitys

Ketterän kehitystiimin toiminnasta ja käytännöistä vastaaminen ja tehokas kommunikaatio tiimin ja sidosryhmien välillä

Kaipaatko lisätietoa?

Kerromme mielellämme lisää tekemästämme työstä.

Joonas Korgan

+358 40 568 4617

Turku

Linnankatu 13a B20
20100 Turku

Helsinki

Kaisaniemenkatu 3 A 5 B
00100 Helsinki

+358 40 568 4617

Turku

Linnankatu 13a B20
20100 Turku

Helsinki

Kaisaniemenkatu 3 A 5 B
00100 Helsinki

+358 40 568 4617

Julius Rajala aloittaa Identiolla operatiivisen johtajan (COO) roolissa 19.8.2024.

Siitä lähtien, kun Julius astui sisään Idention ovista joulukuussa 2019, hän on työskennellyt yrityksen kasvuun tähtäävien toimintojen parissa ohjelmistokonsultin työn ohella. Hänen roolinsa on ollut keskeinen muun muassa rekrytoinnin ja yrityskulttuurin kehittämisen saralla.

Tämä muutos vapauttaa Juliuksen konsultointitehtävistä, jolloin hän voi omistautua yrityksen päivittäisen toiminnan johtamiseen täysipäiväisesti. Juliuksen työnkuvaan tulee kuulumaan mm. yrityksen strategian kehittämistä, kasvun ja skaalautuvuuden kehittämistä sekä sparrausta ja valmennusta.

Uuden roolin myötä pystymme hyödyntämään Juliuksen kattavaa ymmärrystä Identiosta ja koko toimialastamme. Haluamme sen kautta varmistaa yrityksemme ja liiketoimintamme kehityksen myös tulevaisuudessa.

Tuore operatiivinen johtaja Julius Rajala suhtautuu uuteen rooliinsa odottavaisin mielin: ”Olen kiitollinen saamastani luottamuksesta Idention suunnalta. Firmamme toimintamallien kehittäminen on ollut minulle pitkään lähellä sydäntä. Meillä on mahtava tiimi, jonka osaamisen esiin tuominen on minulle tärkeä juttu. Uskon että tulevaisuudessa pystymme palvelemaan kumppaneitamme vielä nykyistäkin paremmin rakentamalla jo luomillemme varmoille perustoille.”

Onnea Julius uuden roolin johdosta!

Turun toimistomme muutti uuteen osoitteeseen tiistaina 9.7.2024. Uusi toimistomme sijaitsee edelleen aivan Turun ydinkeskustassa, osoitteessa Linnankatu 13a B20.

Uudet tilat palvelevat paremmin erilaisia käyttötarkoituksia ja toimivamman pohjaratkaisun ansiosta neliöt tulevat tehokkaampaan käyttöön. Kaipasimme pieniä tiloja kokoustarpeisiin ja isompaa avaraa tilaa, joka mahdollistaa työskentelytilan lisäksi myös tapahtumien järjestämisen.

Olet aina tervetullut vierailemaan toimistollamme ja juomaan vaikkapa kupin kahvia kanssamme.

Nähdään tästä eteenpäin Linnankadulla!

Identio Oy
Linnankatu 13a B20 (2. krs)
20100 Turku

Julkaisimme alkuvuodesta blogissamme tekstin, jossa kerroimme, että tavoitteemme on rekrytoida kuusi uutta työntekijää vuoden ensimmäisen puolikkaan aikana. Kuuden työntekijän rekrytoiminen tarkoittaa Idention kokoisessa yrityksessä noin 20 prosentin kasvua henkilöstön määrässä.

Tiimissämme on aloittanut tammi-kesäkuun aikana neljä asiantuntijaa, joista kolme on ollut ohjelmistokehittäjiä ja yksi Art Director.

Lisäksi olemme saaneet allekirjoittaa useampia ohjelmistokehittäjien työsopimuksia. Tiimimme saa siis kesän aikana vielä kolme uutta työntekijää – yhden heinäkuussa ja kaksi elokuussa.

Näin ollen voimme todeta, että allekirjoitimme vuoden ensimmäisen puolikkaan aikana jopa seitsemän uutta työsopimusta. Tämän lisäksi rekrytointiprosessissamme on ollut viime aikoina useampi ohjelmistokehittäjä.

Onnistuminen ei ollut sattumaa

Teemme johdonmukaisesti töitä sen eteen, että Identio on houkutteleva työpaikka ja että työntekijämme viihtyvät ja voivat hyvin. Se vaatii jatkuvaa panostusta ja aktiivista työntekijöiden osallistamista.

Olemme halunneet myös tehdä itsestämme helposti lähestyttävän ja on ollut hienoa, että hakijoilta ja uusilta työntekijöiltä saatu palaute on vastannut tätä tavoitetta.

Lisäksi olemme onnistuneet madaltamaan kynnystä ensimmäisen askeleen ottamiseen ja hakemuksen jättämiseen. Olemme tehneet työnhakuprosessin aloittamisesta helppoa ja nopeaa lyhyen kyselyn avulla. Tällöin CV:n päivittäminen ja lähettäminen ei ole välttämätöntä. Se on osoittautunut toimivaksi ja ratkaissut monen hakijan kohdalla sen, että he ovat päätyneet osaksi Idention tiimiä.

Vielä pari vuotta sitten IT-alalla pohdittiin ratkaisua osaajapulaan. Tilauskirjat olivat täynnä. Vuonna 2023 vauhti kuitenkin hidastui ja IT-alan haastava tilanne nousi otsikoihin.

Identiolla vuosi 2023 oli haastavasta markkinatilanteesta huolimatta kasvun vuosi. Saimme lukuisia uusia asiakkaita ja kasvatimme olemassaolevia asiakkuuksia onnistuneen yhteistyön myötä.

Idention toimitusjohtaja Joonas Korgan kertoo tiimin yhteisistä onnistumisista: ”On ollut hienoa seurata, miten upeaa työtä kaikki ovat tehneet yhdessä asiakkaidemme kanssa. Ohjelmistokehittäjämme ovat toivoneet, että saisivat työskennellä enemmän yhdessä eli samoissa kehitystiimeissä ja etenkin sen toiveen täyttämisessä onnistuimme hyvin.”

Tilikausi piti sisällään onnistuneita rekrytointeja ja toisaalta roolien muutoksia. Palkkasimme People & Culture Managerin heti alkuvuodesta ja syksyllä yksi pitkäaikaisimmista ohjelmistokehittäjistämme hyppäsi myynnin saappaisiin. Nämä molemmat muutokset tekivät Identiosta kypsemmän ja auttoivat osa-alueilla, joita olemme halunneet kehittää.

Liikevaihto ja tulos

Tilikauden 2023 liikevaihto nousi 2,8 miljoonaan euroon, mikä tarkoittaa 16,5 prosentin kasvua edelliseen vuoteen verrattuna. Liiketulos oli erinomainen, 428 000 euroa, vaikkakin hieman edellistä vuotta pienempi. Se vastasi kuitenkin sitä mitä olimme ennustaneet. Tilikauden tulos oli 342 000 euroa.

Tilikaudelta 2024 odottamme kasvun tasaista jatkumista ja liikevaihdon osalta 3 miljoonan ylitystä.

Katso Idention taloustiedot Finderista.

Mitä on kestävä UX-suunnittelu?

Saavutettavuus ja oikeudenmukaisuus ovat osa kestävää designia

Ympäristötietoinen design

Tekoäly ja vastuullisuus

Erottaudu kilpailijoista kestävällä UX-suunnittelulla

Tuotteen julkaisu

Rakastettavan tuotteen ylläpitäminen ja sen jatkokehittäminen

Tie eteenpäin

Lopuksi

Mikä vaikuttaa ohjelmistokehityksen hintaan?

Kehitystiimin koko ja yhteistyömalli

Muita ohjelmistokehityksen hintaan vaikuttavia tekijöitä

Miten tehdä ohjelmistokehitystä kustannustehokkaasti?

Konkreettisia hintaesimerkkejä

Ohjelmistokehityksen hinta-arvio

Identio teknologiayrityksenä

1. Ohjelmistoyrityksen ymmärrys liiketoimintasi tarpeista

2. Ohjelmistokumppanin referenssit ja kokemus

3. Teknologinen osaaminen ja skaalautuvat ratkaisut

4. Viestintä ja läpinäkyvyys yhteistyössä

5. Joustavuus ja ongelmanratkaisukyky

6. Ohjelmistoyrityksen arvot ja kulttuurinen yhteensopivuus

Lopuksi

Svenska litteratursällskapet i Finland

Täsmäosaamista modernin sisällönhallintajärjestelmän kehittämiseen

Täsmäosaamista modernin sisällönhallinta- järjestelmän kehittämiseen

Työnkuvamme

Lähtötilanne

Ratkaisu

Toteutimme järjestelmään neljä keskeistä ydintoiminnallisuutta:

Teknologiat

Miksi tämä on merkityksellistä?

Kaipaatko lisätietoa?

Mielessä yhteistyö?

Turku

Helsinki

Turku

Helsinki

MEHILÄINEN

Kumppanuudesta voimaa asiakaslähtöisen digitaalisen terveydenhuollon kehittämiseen

Työnkuvamme

Teknisiä osaajia ja monipuolisia kehitystiimejä

Teknologiat

Kokonaisvaltaista ohjelmistokehitystä eri osa-alueilla

Yhteistyön keskeisiä osa-alueita

Yhteenveto

Kaipaatko lisätietoa?

Mielessä yhteistyö?

Turku

Helsinki

Turku

Helsinki

Miksi työntekijöiden hyvinvoinnilla on merkitystä?

Mitä IT-talon People & Culture Manager tekee käytännössä?

Hyvinvoiva henkilöstö tuottaa asiakkaille parasta palvelua

Oikeiden teknologioiden valinta

Muut tekniset valinnat

Vaihtoehdot Next.js:lle

Rakastettavan sovelluksen kehittäminen

Miltä kehitysprosessi näyttää

Suunnan muuttaminen

Yhteenveto

Minimum Lovable Product

Ennen kuin aloitamme

Asiakkaan ymmärtäminen

Tuotteen vision ymmärtäminen

Käyttäjien ymmärtäminen

Resurssien keskittäminen oikeisiin asioihin

Yhteenveto

Seuraavaksi: tuotteen rakentaminen

Lineaarinen ajattelu

Muutos kohti systeemiajattelua

Systeemiajattelu vaatii työtä – mutta se on sen arvoista

Miten tunnistaa systeemiajattelijan?

Ohjelmistokehittäjät osana systeemiä

Relaatiot ovat systeemisuunnittelua

Kaksi käytetyintä mobiilikehystä

Mikä on React Native?

Mikä on Flutter?

Kuinka vaikeita React Native ja Flutter ovat oppia?

Täsmäosaamista
modernin sisällönhallinta-
järjestelmän kehittämiseen

Ratkaisu ja tulevaisuus