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
Mustavalkoinen kuva, jossa mies katsoo kaukoputkella

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

Mielessä yhteistyö?
Jätä yhteystietosi, niin katsotaan miten voisimme olla teille parhaiten avuksi.
Painamalla Lähetä hyväksyt tietosuojaselosteemme.


+358 40 568 4617


+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
Vihreä seinä, jossa näkyy Mehiläinen-logoteksti kasvien keskellä.

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ä.

Joonas Korgan

+358 40 568 4617

Mielessä yhteistyö?
Jätä yhteystietosi, niin katsotaan miten voisimme olla teille parhaiten avuksi.
Painamalla Lähetä hyväksyt tietosuojaselosteemme.


+358 40 568 4617


+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.

sovelluksen kehityssykli

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.


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 (julkaistaan myöhemmin).

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ää.


Osa 2: Näin rakennamme Minimum Lovable Productin vuonna 2025 (julkaistaan myöhemmin).

Osa 3: näin rakennamme Minimum Lovable Productin vuonna 2025 (julkaistaan myöhemmin).

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.

Apps for everyone

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.

Developing with React Native

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:

  1. Jokaisen arvon omistaa jokin muuttuja.
  2. Jokaisella arvolla voi olla vain yksi omistaja kerrallaan.
  3. 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ä:

  1. 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.
  2. 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.
  3. Asiakaskokemuksen parantaminen. Osaamisen kehittäminen auttaa yritystä luomaan parempia ja käyttäjäystävällisempiä palveluja, mikä parantaa asiakastyytyväisyyttä ja sitoutumista.
  4. 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.:

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

Identio x Fixably ohjelmistokehitys

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ä
Mielessä yhteistyö?
Jätä yhteystietosi, niin katsotaan miten voisimme olla teille parhaiten avuksi.
Painamalla Lähetä hyväksyt tietosuojaselosteemme.


+358 40 568 4617


+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ä.

Idention talousluvut tilikaudella 2023

Katso Idention taloustiedot Finderista.

Identio täyttää marraskuussa 2024 kuusi vuotta. IT-alan markkinatilanteessa on nähty yrityksemme olemassaolon aikana hyvin erilaisia tilanteita. Näköpiirissä on ollut kovaa kysyntää ja toisaalta pandemian ja hyökkäyssodan mukanaan tuomia vaikutuksia. Muuttuvassa ja välillä hyvinkin haastavassa ympäristössä on kysytty pitkäjänteisyyttä ja uskoa omaan tekemiseen. Menestys vaatii kuitenkin uskomisen ja laadukkaan asiakastyön tekemisen lisäksi paljon muutakin, kuten fiksuja toimintatapoja ja jatkuvaa kulttuurin kehitystä.

Mitkä päätökset ovat tukeneet Idention vakaata kasvua? Olen saanut nähdä yrityksen kasvun viidestä hengestä yli 30 henkilöön. Tämä teksti on omiin kokemuksiini pohjautuva resepti tähänastisen menestyksen keskeisistä tekijöistä.

1. Rakenna perustukset huolellisesti

Idention perustajat olivat nähneet konsultointibisneksen eri puolet ennen yrittäjiksi ryhtymistään. Identio sai alkunsa saatesanoilla ”haluamme tuoda eri yritysten parhaat puolet omaan yritykseemme”. Kunnianhimoinen tavoite yrityksen rakentamiselle asetettiin siinä hetkessä.

Identio sai heti matkan alkuvaiheessa pitkäaikaisen kumppanin, jonka myötä rahan virtaaminen kassaan oli hetkeksi taattu. Se mahdollisti ensimmäisten rekrytointien tekemisen. Ehkä hieman epätavallista oli se, että viidestä ensimmäisestä identiolaisesta kolme oli laskuttavia rooleja ja kaksi muuta työskentelivät myynnin ja markkinoinnin parissa. Tämän kautta saimme Idention näkyviin esimerkiksi somessa heti alusta alkaen.

Olemme kasvattaneet yritystä vain tulorahoituksella. Se tarkoittaa, että emme ole ottaneet lainaa kasvun rahoittamiseksi ja olemme aina pitäneet huolta siitä, että kassassa on rahaa. Vakaa taloudellinen tilanne on kantanut myös vaikeampien aikojen yli eikä laiva ole keinunut liikaa, vaikka kaikki ei ole aina mennyt suunnitelmien mukaan.

2. Palkkaa osaavia ihmisiä – myös muihin kuin laskuttaviin rooleihin

Ei ole myytti, että ohjelmistokehittäjistä saa käydä kovaa kilpailua. Idention perustajat halusivat luoda merkityksellisen työpaikan, jossa työntekijät voisivat kokea, että heidän panoksensa on arvokas. On myös bisneksen näkökulmasta tärkeää, että osaajat haluavat pysyä yrityksessä. Pysyvyyttä olemme vahvistaneet mm. omistajuuden kautta. Kaikilla Idention vakituisilla työntekijöillä on mahdollisuus lähteä yrityksen osakkaaksi, jolloin yrityksen menestyksestä pääsee hyötymään konkreettisesti. Meille omistajuus tarkoittaa myös sitä, että seisomme tekemämme työmme takana ja sitoudumme auttamaan asiakkaitamme parhaan osaamisemme mukaan.

Jokaisella osakkaalla on oikeus neljä kertaa vuodessa maksettaviin bonuksiin. Kesällä 2022 yrityksen johto kehitti bonusmallia siten, että se suosii aiempaa enemmän myös pienempiä osuuksia omistavia työntekijöitä.

Kun ohjelmistokehittäjiä eli laskuttavia työntekijöitä on riittävästi, on jossain vaiheessa uskallettava palkata myös muita rooleja. Idention markkinointitiimissä työskentelee tekstin kirjoitushetkellä kaksi täysipäiväistä tekijää. Myös People & Culture Managerin palkkaaminen tammikuussa 2023 oli merkityksellinen askel, joka on vienyt toimintaamme ammattimaisempaan suuntaan ja mahdollistanut entistä tehokkaamman yrityskulttuurin kehittämisen.

3. Tee hyvinvoinnista ja yhdessä tekemisestä kulttuurin kulmakivi

Ilman hyvinvoivia työntekijöitä ei ole menestyvää yritystä. Näin linjasi Idention perustajakaksikko vuonna 2018 ja tästä olemme pitäneet kiinni. Hyvinvointi rakentuu monista asioista ja siihen vaikuttavat keskeisesti mm. johtaminen ja erilaiset toimintatavat. Hyvät työsuhde-edut ovat myös tärkeitä, mutta ne eivät yksinään riitä. Teemme viikottain töitä mm. yrityskulttuurin ja hyvinvoinnin kehittämiseksi ja tähän työhön voi osallistua kuka tahansa Idention henkilöstöstä.

Johto on myös linjannut, että joitakin tapauskohtaisia poikkeuksia lukuunottamatta illat ovat muuta kuin työskentelyä varten. Keneltäkään ei siis odoteta työntekoa toimistoaikojen ulkopuolella. Toki oman työnsä saa järjestää haluamallaan (ja asiakkaan kanssa sovitulla) tavalla, mutta työ ja vapaa-aika on syytä erottaa toisistaan. Jos työntekijät kuitenkin haluavat järjestää yhteisiä, koko henkilöstölle avoimia, aktiviteetteja tai afterworkeja työpäivän jälkeen, antaa yritys tukensa kustantamalla hauskanpidon.

Kysyin identiolaisilta, miksi olemme menestyneet yksilöinä ja yhdessä. Esiin nousi kantava ajatus, josta monet olivat samaa mieltä. Se liittyy vahvasti yhdessä tekemiseen.

”Menestykseemme vaikuttaa omistautuminen ja työkavereiden tuki. Painimme välillä vaikeiden ja stressaavien haasteiden kanssa. Jos joku meistä tarvitsee tukea, sitä on aina saatavilla muilta Idention työntekijöiltä. Tuki voi tarkoittaa vaikeiden asioiden pallottelua yhdessä tai joskus jopa sitä, että projektiin saadaan hetkellisesti lisäkäsiä.”

4. Vaali läpinäkyvää kulttuuria, jossa työntekijöihin luotetaan

Läpinäkyvyys mainitaan usein yrityskulttuurista puhuttaessa, mutta sen toteutuminen voi olla oma tarinansa. Voisimme varmasti tehdä itsekin asioita vielä paremmin, mutta läpinäkyvyys ohjaa monia toimintatapojamme.

Slack-kanavamme ovat kaikille avoimia ja kannustamme siihen, että keskusteluja käytäisiin mahdollisimman paljon julkisilla kanavilla. Lisäksi järjestämme viikottain lyhyen kaikille avoimen kokouksen, jossa käydään läpi kuulumisia yritystoiminnan eri osa-alueilta. Kokouksista tehdään myös muistiot, jotka jaetaan kaikille luettavaksi. Yksi omasta mielestäni keskeisin läpinäkyvyyttä kuvaava asia on se, että kuka tahansa työntekijä voi tarkistaa kuukausitasolla yrityksen tulot, menot ja pankkitilin saldon.

Olemme myös aina pitäneet kiinni siitä, että Identiolla luottamusta ei tarvitse ansaita. Matala hierarkia ja luottamus kiteytyvät myös päätöksentekomallissamme. Prosessin avulla jokainen voi tehdä yritykseen liittyviä päätöksiä.

5. Luo mahdollisuuksia kehittyä ja ole avoin muutokselle

Olen kuullut sanottavan, että mikään ei ole yhtä varmaa kuin muutos. Yksi Idention historian jännittävimmistä ja käänteentekevimmistä päätöksistä oli englannin kielen ottaminen sisäiseksi työkieleksi vuonna 2021. Näin isoon muutokseen liittyy varmasti myös haasteita, mutta omasta mielestäni se oli jälkikäteen katsottuna erittäin hyvä ratkaisu. Se on tuonut Identiolle vahvaa osaamista, kaivattua diversiteettiä sekä upeita ihmisiä.

IT-alalla, kuten monella muullakin alalla, muutos ja kehitys ovat väistämättömiä. Kun kysyimme ohjelmistokehittäjiltämme, mitä he kaipaavat työnantajaltaan, tärkeimmäksi asiaksi nousi mahdollisuus kehittää omaa osaamistaan. Sen myötä kehitimme työntekijälähtöisesti konseptin, joka mahdollistaa opiskelun työajalla. Vaikka itse työ pitää joskus kiireisenä, on tärkeää tietää, että myös oman osaamisen kehittämiselle on varattu aikaa ja siihen on jokaisella mahdollisuus. Tämän myötä varmistamme myös sen, että voimme palvella asiakkaitamme jatkuvasti paremmin.

Menestyvän kulttuurin luominen ei kuulosta paperilla ydinfysiikalta. Se vaatii ripauksen nöyryyttä ja halua tehdä asioita entistä paremmin. Se on tehtävä kaikkia kuunnellen ja ihmisiä osallistaen. Ihmiset ovat kuitenkin tärkeintä, mitä meillä on.


Haluatko lukea lisää kulttuuristamme?
Tutustu siihen, miksi Identio on 100 % tekijöidensä omistama tai lue lisää askeleistamme kohti läpinäkyvämpää yrityskulttuuria.

Etsimme kokenutta ohjelmistokehittäjää osaksi ammattitaitoista ja omistautunutta tiimiämme.

Oletko kiinnostunut auttamaan asiakkaitamme kohti toimivampaa ja kestävämpää teknologiaa?
Haluatko työskennellä yrityksessä, jossa sinulla on mahdollisuus olla merkittävässä roolissa sekä omassa työssäsi että yrityksen kehittämisessä?

Identio on konsultointiin ja kokonaisvaltaisiin toteutuksiin erikoistunut teknologiayritys. Autamme asiakkaitamme hyödyntämään modernia teknologiaa ja rakentamaan toimivampaa digitaalista tulevaisuutta. Työmme keskiössä ovat mm. luottamus ja läpinäkyvyys ja nämä arvot näkyvät asiakastyön lisäksi myös sisäisessä kulttuurissamme.

Työtehtävät

Pääset kanssamme suunnittelemaan ja kehittämään asiakkaidemme digitaalisia palveluja. Pyrimme aina etsimään sinulle projektin, jossa yhdistyvät mielekkäät haasteet sekä mahdollisuudet ammatilliseen kehitykseen.

Päivittäisiin työtehtäviisi kuuluvat muun muassa:

  • Työskentely asiakasympäristössä osana kehitystiimiä
  • Asiakkaan toimintatapojen kehittäminen ohjelmistotuotannossa
  • Laadukkaan ohjelmiston tuottaminen
  • Asiakkaan liiketoiminnan edistäminen oman ammattiosaamisen keinoin

Voit tehdä työtäsi joustavasti etänä tai toimistollamme Helsingin Postitalossa. Jos tarpeellista, identiolaiset työskentelevät tarvittaessa silloin tällöin myös asiakkaan tiloissa.

Mitä odotamme sinulta?

Palkkaus

Tämän hetkinen aloituspalkkamme liikkuu 2700 ja 5000 euron välillä. Palkkataso määräytyy osaamistason perusteella ja siitä keskustellaan aina hakijakohtaisesti. 

Mitä tarjoamme sinulle?

Oman osaamisen kehittäminen työajalla

On tärkeää, että identiolaiset voivat kokea kehittyvänsä työssään. Sen kautta voimme tarjota myös asiakkaillemme entistä vahvempaa osaamista.

Mahdollisuus omistajuuteen

Menestys saavutetaan yhdessä tekemällä. Siksi haluamme tarjota jokaiselle identiolaiselle mahdollisuuden rakentaa jotain omaa ja tulla mukaan osakkaaksi.

Mahdollisuus vaikuttaa yrityksen kehitykseen

Identio ja yrityskulttuurimme ovat työntekijöidemme näköisiä. Tiimissämme jokaisella on mahdollisuus vaikuttaa siihen, miltä yritys näyttää tulevaisuudessa.

Laadukas vapaa-aika

Vapaa-ajan on tarjottava työlle vastapainoa. Tätä ajatusta tukevat mm. liikunta- ja kulttuurietumme, polkupyöräetu sekä erilaiset yrityksen kustantamat aktiviteetit.


+358 40 568 4617


+358 40 568 4617

Scroll to Top

Ura meillä

Identio Prochat

Ajankohtaista