Digitalisaatio ei tarkoita vain olemassa olevan liiketoiminnan sähköistämistä. Se ei myöskään tarkoita vain tuotantoarkkitehtuurin muokkaamista siten, että se mahdollistaa tulevaisuudessa tarvittavat palvelut ja tuotteet. Digitaalinen muutos vaatii organisaation liiketoimintastrategian ja sen markkinoilla toimimisen tavan täydellistä uudelleenajattelua. Gofore auttaa asiakkaitaan tämän muutoksen toteuttamisessa.
Niinpä meillä on ilo ilmoittaa Johda-palvelun uusimasta vahvistuksesta Juha Mustosen aloittaessa Goforella elokuussa. Juhalla on yli kahdenkymmen vuoden kokemus erilaisten digitaalisten tuote- ja liiketoimintamallien kehittämisessä ja johtamisessa sekä teleoperaattori- että medialiiketoiminnassa, niin kuluttaja- kuin B2B-liiketoimintasegmenteissäkin. Juha tulee toimimaan Goforella johdon konsulttina osallistuen myös Johda-palvelun sisällöllisen tarjonnan kehittämiseen. Jatkossa Gofore tukee asiakkaitaan entistä paremmin myös digitaalisen liiketoiminnan edellyttämän sisäisen muutosprosessin toteuttamisessa.
Toivotamme Juhan tervetulleeksi goforelaisten kasvavaan joukkoon!
 
Lisätietoja:
Gofore Oy
Mikael Nylund
Johdon neuvonantaja, digitaalinen liiketoiminta
040 540 2280, mikael.nylund@gofore.com
 
Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Puhelimien ja tablettien käytön kasvu on ollut räjähdysmäistä ja yhä useammat tekevät sovelluksia suoraan suunnaten ne puhelimelle tai tabletille. Olen itse tehnyt mobiilipuolelle sovelluksia suurimmaksi osaksi vain harrastuksena ja vain vähän ammattimaisesti. Vaihtoehtoja on lukuisia, ja yritän vähän avata eri tyyppisiä vaihtoehtoja.

Natiivisovellukset

Natiivisovellukset ovat alustan omilla kehitysvälineillä toteutettuja sovelluksia. Android-sovelluksia yleensä kehitetään Javalla. Applen iOS-alustaan sovelluksia kehitetään Swift-kielellä. Kummallekin alustalle on tarjolla oma kehitysympäristönsä.
Natiivisovelluksilla saadaan sujuvin käyttöliittymä, koska kaikki komponentit voivat olla natiivikomponentteja ja toimivat samalla tavoin kuin alustassa yleensäkin. Sovelluksen toteuttamisen nopeus riippuu tekijöiden natiiviosaamisesta ja jokainen sovellus pitää tehdä kullekin alustalle erikseen. Tällä kuitenkin voidaan saada paras lopputulos, mutta luultavasti toteutusaika on pidempi kuin muissa vaihtoehdoissa ja vaatii kehittäjiltä hyvää osaamista Andoir- ja iOS-alustoista. Usein näitä huippuosaajia on valitettavan harvassa.

Natiivikomponenteiksi kääntyvät alustat

Koska toteutus jokaiselle alustalle erikseen on työlästä, ovat esille nousseet toteutukset jotka yrittävät abstraktoida natiivikomponentteja yleisiksi komponenteiksi, jotka voisivat toimia jokaisessa alustassa samalla tavalla. Esimerkkejä näistä ovat React Native, NativeScript ja Xamarin. Tavoitteena olisi, että toteutus tarvitsisi suurimmaksi osaksi tehdä vain kerran; vain se osa toteutuksesta, joka täytyy tehdä erikseen eri alustoilla, tehdään erikseen. Tavoitteena on lyhentää sovelluksien kehitysaikaa ja saada lopputulos aikaiseksi vähemmällä vaivalla ja nopeammin. Usein natiiviosaajia ei enää tarvita niin montaa ja osa kehityksestä onnistuu esimerkiksi Web-kehittäjien tai muiden kehittäjien toimesta. Usein käytön sujuvuus saadaan natiivin kaltaiseksi. Monesti käyttäjä ei huomaa käyttävänsä hybridisovellusta natiivin sijasta. Tiimissä olisi silti hyvä olla joku, joka ymmärtää natiivialustojen toimintaa, koska projekti kuitenkin paketoidaan sovellukseksi alustojen omiin verkkokauppoihin ja yleensä sisältää joko kirjastojen tai projektin myötä tulevaa natiivikoodia.

Web-pohjaiset mobiilialustat

Web-pohjaisissa mobiilialustoissa, kuten Ionic tai Phonegap, toteutuskoodi on yleensä HTML:ää ja JavaScriptiä ja tyylit on tehty CSS:llä. Käytön sujuvuus jää aina hieman natiivitoteutuksesta, mutta verkkoyhteys ei ole välttämätön, toisin kuin perinteisissä verkkopalveluissa. Käyttöliittymä saadaan ulkonäöllisesti kyllä säädettyä hienon oloiseksi, mutta helposti animaatiot ja siirtymät eri näkymien välillä eroavat natiivista toteutuksesta.
Web-pohjaisten mobiilialustojen etuna on se, että natiiviosaamista ei juurikaan tarvita ja toteutus voidaan lähes kokonaan tehdä web-kehittäjien toimesta. Eri sukupolven laitteissa voi olla hyvinkin erilainen toteutus web-sisällön näytölle, mikä saattaa aiheuttaa ongelmia. Kuten natiivikomponenteiksi kääntyvissä alustoissa, myös web-pohjaisten mobiilialustojen osalta olisi hyvä olla joku joka ymmärtää natiivialustoista. Usein kuitenkin tarvitaan jotain natiivikomponentteja apuna. Esimerkiksi Ionic-sovelluskehyksessä on omia komponentteja, joilla saadaan parempi käyttötuntuma kuin mitä upotettuun web-näkymään on mahdollista saada.

Prototypointityökalut

Moni on jo tarjoamassa web-käyttöliittymässä muokattavaa prototyypinteko-työkalua, kuten FeedHenry tai Appgyverin Composer, jolla voidaan tehdä prototyyppi lähes ilman koodausta. Käyttötuntuma on riippuvainen työkalun toteutuksesta ja voi olla vaikea saada tehtyä siihen isompia muutoksia. Tuollainen prototyyppi voi olla hyvä kuitenkin esimerkiksi johonkin demoon tai ensimmäiseksi tuotetestaukseksi. Jos on todella kiire saada tuote ulos, niin nämäkin voi olla ihan validi vaihtoehto.

Mitä kannattaa valita?

Paras käyttötuntuma saadaan ehdottomasti natiivitoteutuksella. Toisaalta useat natiiviksi kääntyvät alustat, kuten React Native, NativeScript ja Xamarin alkavat päästä lähelle samaa tuntumaa. Erilaiset Web-pohjaiset ja Webview-näkymiin perustuvat toteutukset jäävät kyllä käyttötuntumaltaan natiivisovelluksista jälkeen. Toisaalta ne ovat toteutukseltaan ehkä hieman helpompia tehdä ja voidaan ehkä tehdä jopa puhtaasti web käyttöliittymässä ilman tarvetta erityisille alustakohtaisille kehitystyövälineille. Se, mitä kannattaa valita, riippuu kehitystiimisi osaamistaustasta, rakennettavan sovelluksen tarpeista ja toteutuksen aikataulusta. Sujuvan sovelluksen tekeminen vie aina aikaa riippumatta käytettävästä välineestä.

Avatar

Toni Ristola

Toni on kokenut ohjelmistosuunnittelija, joka on osallistunut useisiin yksityisten sektorin ja joihinkin julkisen sektorin projekteihin. Hänellä on suunnittelu- ja toteutuskokemusta monista palvelinalustoista. Tonin ystävät pitävät häntä teknologiahippinä. Tämä saattaa johtua hänen kiinnostuksestaan uusiin välineisiin, kuten esimerkiksi Docker ja NodeJS.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Gofore ja Solita on valittu Espoon ja Vantaan yhteisen varhaiskasvatuksen ohjausjärjestelmän kehjittäjiksi. Espoo ja Vantaa parantavat kaupunkilaistensa palvelua yhtenäisen sähköisen järjestelmän avulla. Poikkeuksellisella toimittaja- ja kuntarajat ylittävällä yhteistyöllä varmistetaan avoin, toimittajariippumaton ja moderni tulevaisuuden varhaiskasvatuksen palvelujen kehittäminen Espoon ja Vantaan asukkaille.
Espoo ja Vantaa saavat käyttöönsä asiantuntevat digitaalisten palveluiden kehittäjät Goforen ja Solitan valikoituessa varhaiskasvatuksen ohjausjärjestelmän palveluiden toimittajiksi KL-Kuntahankintojen-puitesopimuksen kevennetyssä kilpailutuksessa. Toimittajakaksikko tarjoaa hankkeeseen yli 600 asiantuntijan kehittämispoolin. Kehitysmalli tullaan räätälöimään kaupunkien tarpeisiin sopivaksi. Tärkeitä periaatteita kehitystyössä ovat avoimuus, toimittajariippumattomuus, teknologinen edelläkävijyys, ketterä kehittäminen sekä yhtenäisen käyttäjäkokemuksen luominen kaupunkilaisille.
Yhteistyöllä avointa kehittämistä ja parempaa asiakaskokemusta
– Espoon ja Vantaan varhaiskasvatuksessa odotetaan tulevalta ohjausjärjestelmältä helppokäyttöisyyttä ja toimivuutta erilaisissa päätelaitteissa. Tavoitteena on saada nykyaikainen, entistä paremmin kuntalaisten tarpeita palveleva järjestelmä, joka säästää henkilökunnan aikaa varsinaiselle varhaiskasvatustyölle sekä antaa varhaiskasvatuksen johdolle uusia työkaluja tiedolla johtamiseen, toteaa Espoon varhaiskasvatuksen johtaja Titta Tossavainen.
Vantaan varhaiskasvatuksen johtaja Sole Askola-Vehviläisen mukaan uusiutuvissa  varhaiskasvatuspalveluissa on tärkeää tavoitella nykyistä parempaa palvelutasoa ja asikaskokemusta. Uuden  järjestelmän avulla saadaan sujuvampia ja tehokkaampia prosesseja  ja työn tuottavuus kasvaa. Tieto liikkuu nopeasti ja on käytössä heti. Tästä hyötyvät tulevaisuudessa niin varhaiskasvatuksen työntekijät kuin palvelutuotannon johtajatkin, Sole Askola-Vehviläinen arvioi.
– Tämäntasoinen kuntarajat ylittävä yhteistyö palveluiden kehittämisessä on hieno edistysaskel. Modernit kehitysmenetelmät, sujuva toimittajayhteistyö ja avoimen lähdekoodin hyödyntäminen ovat tulevaisuuden julkisten palvelujen luomisen kivijalkaa. Kahden lapsen espoolaisena isänä odotankin innolla erityisesti varhaiskasvatukseen liittyviä sähköisiä palveluita, Solitan Lauri Helenius kertoo.
– On erittäin hienoa päästä kehittämään  varhaiskasvatuksen ohjausjärjestelmän palveluita yhteistyössä Vantaan ja Espoon kaupunkien kanssa. Me Goforessa uskomme, että yhteistyössä on voimaa. Odotammekin innolla, että pääsemme käärimään hihat ja täyttämään kuntalaisten toiveet, Goforen myyntijohtaja Juha Virtanen sanoo.

Lisätietoja:

Gofore Oy
Kristiina Härkönen
Liiketoimintapäällikkö, Hyvinvointi, kunnat & aluehallinto
kristiina.harkonen@gofore.com, 040 742 3411
www.gofore.com

Solita Oy
Lauri Helenius
Liiketoimintajohtaja, Julkishallinto
lauri.helenius@solita.fi, 040 529 4354
www.solita.fi
Espoon kaupunki
Sirpa Puumalainen
Varhaiskasvatuksen digikehittämisasiantuntija
sirpa.puumalainen@espoo.fi, 043 824 7205
www.espoo.fi
Vantaan kaupunki
Merja Asikainen
Suunnittelija
09 83923607, 040 513 8604
www.vantaa.fi
 

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Kirjekaverini muurin tuolla puolen

Joudutko kotonasi anomaan kirjeitse talonmiehen apua tuulettamiseen tai roskien vientiin? Et tietenkään, sehän olisi täysin hölmöä. Töissä joudun kuitenkin kirjoittamaan tällaisia anomuksia jatkuvasti.
Ketterästä kehittämisestä on tullut arkipäivää. Ketteryydestä puhutaan kuitenkin kapeakatseisesti, keskittyen vain ohjelmistokehittämisen menetelmiin. ”Meillä on itsenäinen, ketterä kehitystiimi!”, tilaaja kerskuu hankinnastaan. Samalla hän kuitenkin vaatii tiimiä hankkimaan palvelimet kauan sitten valitulta, keskitetyltä käyttöpalvelukumppanilta.

Talonmies ei tunne asukkaiden tarpeita

Yksityisen ja julkisen sektorin ohjelmistoprojekteissa kehittäjät ja ylläpitäjät ovat pitkään kamppailleet kankeita yhteistyömalleja vastaan.
Vanhanaikainen käyttöpalvelutoimittaja vastaa kaikista infraan liittyvistä muutoksista, niin palvelimien, tietokantojen kuin verkkojenkin osalta. Kehitystiimi ei saa tehdä muutoksia itse palvelimille. Käyttöpalvelutoimittaja ottaa muutospyynnöt vastaan vain käsin tarkasti muotoilluilla Word-lomakkeilla.
Ensin Word-lomakkeet menevät muutosjonoon odottamaan. Sieltä lomakkeita käsittelee harmaa massa kaukaisia ylläpitäjiä, jotka eivät osallistu projekteihin täysiverisinä tiiminjäseninä. Tällainen geneerinen ylläpitäjä ei tunne palvelun käyttötarkoitusta tai historiaa. Lomakkeesta huolimatta tiedot saattavat olla puutteellisia tai väärin täytettyjä, jolloin ylläpitäjä joutuu pyytämään tarkennuksia.
Sähköposti ja lomakkeet pakottavat molemmat osapuolet manuaaliseen apinan hommaan. Suurin osa palvelupyynnöistä on yksinkertaisia tehtäviä ja täysin automatisoitavissa. “Saisimmeko kolme uutta palvelinta”, ”Voisitteko avata palomuuriportin”, ”Tämä reititysmuutos olisi kiva”. Yksinkertaisetkin tehtävät kasautuvat infratoimittajan jonoon seisomaan, kalenteriaika juoksee ja kehitystiimi odottaa.
Kirjekaverini muurin tuolla puolen
Kun ulkopuolinen ylläpitäjä ei ymmärrä projektin tarpeita, eikä projektitiimi näe suoraan infran nykykonfiguraatiota, palvelutoimittajan ja kehitystiimin välille syntyy muuri.
Kehitystiimit monesti kiertävät kankeutta ostamalla kehitys- ja testiympäristöt pilvestä omaan hallintaan. Tämä sujuvoittaa kehitystä, mutta pidemmällä aikavälillä ympäristöt elävät ja kehittyvät projektin aikana.
Jos sen sijaan infraa hallittaisiin automatisoiduin työkaluin (esimerkiksi CloudFormation ja Terraform), voitaisiin yksiselitteinen, ajantasainen ja koneluettava kuvaus palvelusta tallentaa versionhallintaan. Ympäristöjen eriytyminen pysähtyy hyvällä hallinnalla.

Mikä on infran toimittajan tuottama lisäarvo?

Ylläpidon keskittämisellä tilaaja tavoittelee kustannustehokkuutta ja toimintavarmuutta. Korkean muurin takaa tapahtuva sokkoylläpito jarruttaa kuitenkin kehitystä, ja synnyttää piilokustannuksia. Moni tilaaja on kokemustensa kautta havahtunut tilanteeseen ja hiljalleen oivaltanut pilvipalveluiden merkityksen.
Äskettäin julkaistussa pilvialustoja kartoittavassa tietopyynnössä on useita loistavia vaatimuksia, joista poimin ja tiivistin tähän pari:

  • Itsepalvelumahdollisuus ja ohjelmoitavat rajapinnat. Kehittäjien tulisi olla vastuussa siitä, että ohjelmisto toimii myös tuotannossa. Palvelukohtainen ylläpitotyö pitäisi olla osa projektia, ja se pitäisi erottaa pohjainfrastruktuurin ylläpidosta. Ohjelmoitavat rajapinnat mahdollistavat infran automatisoinnin. Plussaa saa erityisesti siitä, jos toteuttaa yleisesti käytössä olevan rajapinnan.
  • Kapasiteetin ja kustannusten skaalautuminen käytön mukaan. Kun infraa saa tarpeen mukaan, ja hinnat pyörivät sadoissa euroissa kymmenientuhansien sijaan, kokeiluille ei muodostu kynnystä.

Mikä onkaan se lisäarvo, josta infran toimittajalle maksat? Perusinfran tarjoamisen tekevät globaalit pilvitoimittajat laadukkaasti, ja kilpailussa hinnat on poljettu maahan. Tuotantoonvienti ja sovelluspäivitykset onnistuvat kehitystiimiltä heittämällä nykyaikaisin työkaluin. 24/7 valvonta ja ylläpito hoituu pitkälti automaatiolla.
Ketterä kehitys ei onnistu sellaisen käyttöpalvelutoimittajan kanssa, joka piileksii muurin takana sopimuspapereitaan sivelemässä. Mielestäni on täysin selvää, että sellaiset yritykset joutuvat tulevaisuudessa joko keskittymään pilvipalveluiden tarjoamiseen tai osallistumaan aktiivisemmin ohjelmistokehitysprojekteihin. Kummalla tavalla muuri murretaan, sillä ei ole minulle niinkään väliä.

Avatar

Ville Seppänen

Ville edistää Goforella kokeilevan ohjelmistokehittämisen kulttuuria. Ohjelmistokehittämisen ohella hän konsultoi pilvipalveluiden käytössä. Palveluväylä- ja Avoindata.fi-projektien kautta Ville on auttanut Suomen julkishallintoa avaamaan tietovarantojaan.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

My View on “Lean UX” with Small Resources in Projects

I’ve been working in some smallish projects as a half-time UX-designer, usually with one team (most of the time an average of 3 developers doing both front and backend) and thought It would be helpful to open up a bit on the ways we have found most useful to use my limited time in the projects.
Our projects are usually run in two week sprints. At the beginning of the sprint we plan both the development tasks and the UX-tasks, they run on the same board and are visible to the whole team and project members.
In a small team with limited resources it’s usually important for the UX-designer to be able to wear multiple hats. We simply don’t have a person for user research and testing, interaction design, visual design, prototyping, etc. So it’s  necessary to be able to do most of these things yourself – at a pretty advanced level.
This also needs a team that is constantly available for communication and sparring – ideally everyone sits on the same room to minimize distance. The team members must be interested in being involved in all aspects of the process and share the same simple goal to make the product as good as possible, giving whatever it takes and contributing to the shared goal instead of each one just contributing to their own ”part”. It also helps to have varied skills and interests inside the team, that skill and interest-knowledge will be shared with other people during the process when everything is done together.

The Sprint

We have a pretty good understanding of how much I can deliver in a sprint, so we usually try to get 2-4 UI/visual design tasks. 2-5 user testing tasks and bunch of smaller tasks for me per two week sprint. There is always at least one day worth of planning and communicating and one day of general maintenance, bug fixes and visual fixes to do. So with 50 % work time that leaves you with about 3-4 full days per sprint to do the actually design and testing work. Use-that-time-well.
lean-ux

The Work

The work from sprint to sprint varies a lot depending of what we are doing. The tasks that are in the sprint have typically been validated and researched to a large degree to be at this stage. Most UX-tasks are brought to the sprints by the product owner, who keeps track of the bigger picture and prioritizes what the team should be working on next. The UX-tasks are typically one sprint ahead of the development tasks to leave enough room to do the design and testing.  Here’s a rundown how a task runs through “the machine”:
1) Sprint Planning
Go over the design task at hand with the whole team and product owner, break it up to smaller pieces if possible.
Goal: Discuss about the task at hand from all viewpoints and try to find questions and problems or better solutions as a whole team.
2) Concept Design / Wire-framing
Usually I’ll draw the task using pen and paper together with a developer, the product owner, a user or with specialist on the subject, I’ll mark all questions that arise in a separate “parking lot” and get to those at a later time.
Goal: to draw the whole task from beginning to end from the eyes of the user trying to accomplish the task at hand.
3) Test the Task
Our product owner usually has actual users for me to test the tasks and i’ll try to arrange 2-3 tests that take from half an hour to an hour, I use actual users on the tasks and people from the team/company to do simple UI-tasks that don’t necessary need an actual user. We use a common sense approach to user testing with limited time used on documentation of the results and presenting them to people. Instead we test and immediately do changes to the task at hand and continue the testing cycle couple of times and end up with a rough design that has been user tested. The most important thing is to polish the design, get out of “guessing” the design and get feedback <-> design <-> development cycle as small as possible without the overhead of the normal cycle (design › test › document › present › fix and redesign › test › document › present › ) to ( design › test › fix and redesign › test › fix and redesign)
Goal: Get real user feedback on the task, fix possible problems immediately and get the task validated
4) Design and Deliver
I try to design and deliver as much as possible with the paper prototype or a simple Balsamiq mockup – yes – our developers accept low fidelity paper prototypes as we can communicate most of the visuals by talking it over. (Most of the UI-library should be in advanced stage and ”bigger” visual styles done already) Most of the responsiveness and stuff are better off explained and tried out – instead of using the – again – limited time at designing pixel perfect images
If there is some new visuals to do, I usually use either prototyping in the browser using developer tools on small stuff, or occasionally i design from pretty much scratch. Most of the visuals are done in Illustrator and at advanced stage of projects you don’t really need to do that much visual design.
Goal: Get the task “done” for the development to start and to be completed as fast as possible.
5) Down Time – As in Stuff not Doing the Above ^
Fix bugs and visuals on the project, install developer tools and get your hands dirty, use all down time to fix stuff instead of telling people that needs to be fixed
Goal: Free developer time for more advanced and bigger tasks

What Does This All Mean for the Designer – Skill-wise?

To be successful in surroundings and projects like these, try to get into multiple areas of “ux-design” – the most important thing is to get yourself into developing, user testing and research. Start by doing Codeacademy courses (HTML+CSS+JS) and forcing yourself to do as much of your stuff in the browser ( and get into development. No one expects (or should expect)) you to be as good as the hardcore frontend guys (there’s a reason they are in the project) but try to get out of simply handing over projects and work, instead get into projects that require constant communication, sitting with developers and no deliverables.
Carry out testing and designing with real users, other members of the team and the product owner as early as possible. There is no need for the “lone designer” in modern agile software projects.

“Lean UX” in Nutshell

Pros:
+ Time feels well spent, instead of presenting and documenting stuff, you are fixing and making stuff.
+ You learn a lot by getting your hands dirty and doing a lot of stuff (try to be out of your comfort zone 90 % of the time 🙂
+ You meet and design with real users, get the feedback and do the corrections and fixes yourself instead of someone else.
+ With developer tools its great to fix stuff yourself instead of depending on others and you get a real idea of how things are built that you can use in the design part.
Cons:
– Doing the developing aspect for me is sometimes hard and you feel a bit lost as it is not your main expertise, but it helps to have good team members that are willing to help.
– Content switching when moving fast.
– Sometimes you lose the big picture when working in small increments.

Avatar

Jyrki Anttila

Jyrki on kokenut käytettävyyden, käyttäjäkokemuksen, graafisen suunnittelun ja käyttöliittymien visualisoinnin ammattilainen. Hän on työurallaan ollut mukana Suomen suurimpien digitoteutusten teossa. Visuaalinen suunnittelu, Art Direction, käyttöliittymäsuunnittelu, käytettävyystestaus ja käyttäjäkokemuksen suunnittelu ovat Jyrkin osaamisen keskiössä.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Gofore on valittu toista kertaa yhdeksi Euroopan parhaista työpaikoista. Tämänvuotinen sijoitus nousi 20 pykälää, ja Gofore sijoittui hienosti kuudenneksi.
Vuoden 2016 Euroopan parhaiden työpaikkojen lista julkistettiin Dublinissa torstai-iltana 16.6. Listalle valittiin 100 parhaaksi arvioitua työpaikkaa yli 2250 yrityksen joukosta. Lista perustuu Great Place to Workin® toteuttamiin kansallisiin tutkimuksiin 19 eri Euroopan maassa.
Gofore osallistui parhaiden työpaikkojen tutkimukseen tänä vuonna toista kertaa. Yhtiö on valittu Suomen 3. parhaaksi työpaikaksi vuosina 2015 ja 2016. Molempina vuosina tuloksena on ollut myös sijoitus Euroopan parhaiden työpaikkojen listalla.
Goforen kulttuurista ja osaamisista vastaava johtaja Erkki Salminen on valinnasta ylpeä. ”Viimevuotinen tunnustus tuntui upealta, mutta pidän tämänvuotista sijoitustamme Euroopan työpaikkojen kirkkaimmassa kärjessä vieläkin hienompana. Olemme kasvaneet hurjaa vauhtia ja silti samaan aikaan onnistuneet noudattamaan ensimmäistä arvoamme eli olemaan hyvä työpaikka jokaiselle goforelaiselle”, Salminen sanoo.
Katso kaikki Euroopan parhaiden työpaikkojen listasijoitukset.
Lisätietoja:
Erkki Salminen
Johtaja, Kulttuuri ja osaamiset, Gofore Oy
+358 40 738 5650, erkki.salminen@gofore.com
Twitter: @SalminenErkki
Erkki matkustaa Dubliniin edustamaan Goforea. Hänet tavoittaa parhaiten puhelimitse tai tekstiviestillä, jolla voi jättää myös soittopyynnön.
Riikka Peltonen
Markkinointipäällikkö, Gofore Oy
+358 50 486 8600, riikka.peltonen@gofore.com
Timur Kärki
Toimitusjohtaja, Gofore Oy
+358 40 828 5886, timur.karki@gofore.com

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Oletko ajatellut, että palvelujen tarjoaminen ja käyttäminen on aina kaupankäyntiä? Palvelujen parissa käydään vaihtokauppaa siitä, mitä palvelu tarjoaa ja mitä käyttäjän pitää antaa. On kyse sitten sähköisistä palveluista tai palvelupoluista, joissa digitaalisuus on vain osa kokonaisuudesta, hyvän palvelun muotoileminen vaatii ymmärryksen siitä, mitä käyttäjiltä vaihtokaupassa vaaditaan ja mihin heillä on varaa – enkä puhu nyt vain rahasta.
Tiedät varmasti miltä tuntuu, kun sinulla ei ole varaa jonkin palvelun käyttöön. Kyse ei ole siitä, että rahasi eivät riitä, vaan siitä hetkestä kun toteat: ”en jaksa”. Välttelemme luonnostamme epämiellyttäviä asioita: roskien vientiä, viemärikaivon puhdistamista – ja myös hankalia käyttöliittymiä ja huonoja palveluja. Jätämme asioita tekemättä useammin henkisistä kuin taloudellisista syistä. Emme vain näe riittävää hyötyä oletettuun vaivaan nähden.

Vaivanarvoista palvelua

Käyttäjien ”varallisuutta” kannattaa mielestäni pohtia kolmessa vaiheessa:

  1. Kuinka saamme käyttäjän hakeutumaan palvelun pariin.
  2. Kuinka saamme käyttäjän kokeilemaan palvelua.
  3. Kuinka saamme käyttäjän käyttämään palvelua.

Kun kyseessä on uusi palvelu, vaiva on ennen kaikkea olettamus siitä, mitä palvelun käyttäminen fyysisesti ja henkisesti vaatii. Mitä enemmän vaivaa käyttäjä arvelee palvelun häneltä edellyttävän, sitä enemmän hyötyä hän haluaa kokeakseen, että hänellä on varaa ryhtyä palvelun käyttäjäksi.
Olettamukset vaivasta ja palvelun hyödyllisyydestä muodostuvat hyvin varhaisessa vaiheessa ja monista lähteistä, jo ennen palvelun pariin siirtymistä. Palvelu todennäköisesti muistuttaa käyttäjiä jostakin heidän aiemmin käyttämästään palvelusta ja se kertoo jotenkin tarjoamastaan sisällöstä. Tärkeintä on se, miten mahdollisuudet käyttäjälle viestitään.

Vaiston varassa

Mielenkiinto, tarve, pakko, kokeilunhalu… Syitä uuden palvelun kokeiluun voi olla monia. Myös tapoja, joilla meihin voi käyttäjinä vedota on lukuisia. Parhaiten onnistutaan, kun ymmärretään ihmisen tarpeita ja vaistoja. Suunnittelin muutama vuosi sitten ratkaisun, joka houkutteli ihmiset julkisen kosketusnäytön luokse. Miten se onnistui? Kosketusnäytöllä näkyi liikettä, mutta käyttäjä ei saanut siitä kunnolla selvää menemättä lähelle.
Kun olet saanut houkuteltua käyttäjän palvelusi pariin, pidä huoli, ettet menetä häntä. Digitaalisten palvelujen käyttöliittymissä käyttöönotto on perinteisesti ratkaistu vaiheistamalla ja visualisoimalla niin, että käyttäjä näkee missä vaiheessa hän on menossa. Nykyisin suositaan useimmiten ultra-yksinkertaista tapaa, jossa annetaan ymmärtää, että palvelun käyttöönotto onnistuu yhtä nappia painamalla.

Kauppa se on, mikä kannattaa

On jo pieni voitto, että käyttäjä painaa esimerkiksi rekisteröitymispainiketta tai suorittaa ensimmäisen haun. Olet jo ehtinyt vakuuttaa käyttäjän siitä, että hänellä on varaa kokeilla palveluasi.
Palvelujen suunnittelussa täytyy kuitenkin muistaa, että jokainen hetki palvelun parissa on kaupankäyntiä. Käyttäjä arvioi joka hetki palvelusi tarjoamaa arvoa suhteessa sen vaatimaan vaivannäköön. Hän saattaa tuhahdella, hymistä, olla painamatta jotakin nappia ja jättää asioita tekemättä jos vaihtokauppa ei miellytä. Hän saattaa olla hiljaa, toimia tehokkaasti, nauttia, hieman hymyilläkin ja tehdä asioita toivomallasi tavalla, jos vaihtokauppa on mieluinen.
Jokaisen linkin, napin, sivun ja kuvan kohdalla käyt palveluntarjoajana tätä hiljaista keskustelua käyttäjän kanssa. Yksi nappi lisää voi olla yksi nappi liikaa. Tärkein ohjenuorani on: ”Jos et voi tarjota mitään, älä pyydäkään mitään.”
 

Gofore muotoilee -blogisarja. Digitalisaatio, asiakaslähtöisyys ja ketteryys ovat päivän sanoja. Puhujia ja tekijöitä on moneen lähtöön. Me Goforessa tiedämme mistä puhumme, sillä hallitsemme digitaalisen muutoksen koko ketjua asiakkaan liiketoimintamallin kehittämisestä suunnitteluun ja palveluiden toteuttamiseen. Vahvuutemme on muotoilun osaaminen ja kokemus asiakkaalta asiakkaalle. Gofore muotoilee -blogisarja kertoo osaamisestamme, ajatuksistamme ja kokemuksistamme modernin työkulttuurin, palveluiden sekä toiminnan kehittämisessä.

 
Lue myös blogisarjan aikaisemmat kirjoitukset:

Avatar

Arto Puikkonen

Arto on kokenut palveluiden muotoilija ja UX-suunnittelija. Hän on urallaan huolehtinut kymmenien web-, mobiili- ja työpöytäsovellusten muotoilusta. Arton ydinosaamista ovat käyttäjätyö sen moninaisimmissa muodoissaan sekä käyttöliittymäsuunnittelu. Goforella Arto vastaa yrityksen muotoilupalveluista

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

After using Docker for a while, you quickly realize that you spend a lot of time downloading or distributing images. This is not necessarily a bad thing for some but for others that scale their infrastructure are required to store a copy of every image that’s running on each Docker host. One solution to make your images lean is to use Alpine Linux which is a security-oriented, lightweight Linux distribution.
Lately I’ve been working with our Docker images for Java and Node.js microservices and when our stack consist of over twenty services, one thing to consider is how we build our docker images and what distributions to use. Building images upon Debian based distributions like Ubuntu works nicely but it gives packages and services which we don’t need. And that’s why developers are aiming to create the thinnest most usable image possible either by stripping conventional distributions, or using minimal distributions like Alpine Linux.

Choosing Linux Distribution for Your Docker Containers

What’s a good choice of Linux distribution to be used with Docker containers? There was a good discussion in Hacker News about small Docker images, which had good points in the comment section to consider when choosing container operating system.
For some, size is a tiny concern, and far more important concerns are, for example:

  • All the packages in the base system are well maintained and updated with security fixes.
  • It’s still maintained a few years from now.
  • It handles all the special corner cases with Docker.

In the end the choice depends on your needs and how you want to run your services. Some like to use the quite large Phusion Ubuntu base image which is modified for Docker-friendliness, whereas others like to keep things simple and minimal with Alpine Linux.

Divide and Conquer?

One question to ask yourself is: do you need full operating system? If you dump an operating system in a container you are treating it like a lightweight virtual machine and that might be fine in some cases. If you however restrict it to exactly what you need and its runtime dependencies plus absolutely nothing more then suddenly it’s something else entirely – it’s process isolation, or better yet, it’s portable process isolation.
Other thing to think about is if you should combine multiple processes in single container. For example if you care about logging you shouldn’t use a logger daemon or logrotate in a container, but you probably want to store them externally – in a volume or mounted host directory. SSH server in container could be useful for diagnosing problems in production, but if you have to log in to a container running in production – you’re doing something wrong (and there’s docker exec anyways). And for cron, run it in a separate container and give access to the exact things your cronjob needs.
There are a couple of different schools of thought about how to use docker containers: as a way to distribute and run a single process, or as a lighter form of a virtual machine. It depends on what you’re doing with docker and how you manage your containers/applications. It makes sense to combine some services, but on the other hand you should still separate everything. It’s preferred to isolate every single process and explicitly telling it how to communicate with other processes. It’s sane from many perspectives: security, maintainability, flexibility and speed. But again, where you draw the line is almost always a personal, aesthetic choice. In my opinion it could make sense to combine nginx and php-fpm in a single container.

Minimal Approach

Lately, there has been some movement towards minimal distributions like Alpine Linux, and it has got a lot of positive attention from the Docker community. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox using a grsecurity/PaX patched Linux kernel and OpenRC as its init system. In its x86_64 ISO flavor, it weighs in at an 82 MB and a container requires no more than 8 MB. Alpine provides a wealth of possible packages via its apk package manager. As it uses musl, you may run into some issues with environments expecting glibc-like behaviour (for example Kubernetes or with compiling some npm modules), but for most use cases it should work just fine. And with minimal base images it’s more convenient to divide your processes to many small containers.
Some advantages for using Alpine Linux are:

  • Speed in which the image is downloaded, installed and running on your Docker host.
  • Security is improved as the image has a smaller footprint thus making the attack surface also smaller.
  • Faster migration between hosts which is especially helpful in high availability and disaster recovery configurations.
  • Your system admin won’t complain as much as you will use less disk space.

For my purposes, I needed to run Spring Boot and Node.js applications on Docker containers, and they were easily switched from Debian based images to Alpine Linux without any changes. There are official Docker images for OpenJDK/OpenJRE on Alpine and Dockerfiles for running Oracle Java on Alpine. Although there isn’t an official Node.js image built on Alpine, you can easily make your own Dockerfile or use community provided files. When official Java Docker image is 642 MB, Alpine Linux with OpenJDK 8 is 150 MB and with Oracle JDK 382 MB (can be stripped down to 172 MB). With official Node.js image it’s 651 MB (or if using slim 211 MB) and with Alpine Linux that’s 36 MB. That’s a quite a reduction in size.
Examples of using minimal container based on Alpine Linux:
For Node.js:

FROM alpine:edge
ENV NODE_ALPINE_VERSION=6.2.0-r0
RUN apk update && apk upgrade \
    && apk add nodejs="$NODE_ALPINE_VERSION"

For Java applications with OpenJDK:

FROM alpine:edge
ENV LANG C.UTF-8
RUN { \
      echo '#!/bin/sh'; \
      echo 'set -e'; \
      echo; \
      echo 'dirname "$(dirname "$(readlink -f "$(which javac || which java)")")"'; \
   } > /usr/local/bin/docker-java-home \
   && chmod +x /usr/local/bin/docker-java-home
ENV JAVA_HOME /usr/lib/jvm/java-1.8-openjdk
ENV PATH $PATH:$JAVA_HOME/bin
ENV JAVA_VERSION 8u92
ENV JAVA_ALPINE_VERSION 8.92.14-r0
RUN set -x \
    && apk update && apk upgrade \
    && apk add --no-cache bash \
    && apk add --no-cache \
      openjdk8="$JAVA_ALPINE_VERSION" \
    && [ "$JAVA_HOME" = "$(docker-java-home)" ]

If you want to read more about running services on Alpine Linux, check Atlassian’s Nicola Paolucci’s nice article about experiences of running Java apps on Alpine.

Go Small or Go Home?

So, should you use Alpine Linux for running your application on Docker? As also Docker official images are moving to Alpine Linux then it seems to make perfect sense from both a performance and security perspectives to switch to Alpine. And if you don’t want to take the leap from Debian or Ubuntu or want support from the downstream vendor you should consider stripping it from unneeded files to make it smaller.
This article was originally published on Rule of Tech, author’s personal blog about technology and software development.

Avatar

Marko Wallin

Marko Wallin työskentelee ohjelmistosuunnittelijana Goforella ja muuttaa maailmaa paremmaksi digitalisaation keinoin. Hänellä on vuosien kokemus ohjelmistokehityksestä, ketteristä menetelmistä ja ohjelmoinnista sekä käyttöliittymän, taustapalveluiden että tietokantojen osalta. Vapaa-ajallaan Marko jakaa teknistä osaamistaan blogiensa kautta ja kehittämällä muun muassa avoimen lähdekoodin mobiilisovelluksia. Sovelluskehityksen lisäksi hän harrastaa maastopyöräilyä.

Piditkö lukemastasi? Jaa se myös muille.

Ongelmanratkaisua by perkele

Olen tähän asti ajatellut, että ongelmanratkaisukyky käsittää lähinnä riittävän kovan pään. Kaikki ongelmat ratkeavat yrittämällä niihin erilaisia ratkaisuita. Hakkaamalla päätä seinään riittävän pitkään, seinä hajoaa. Lopulta löytyy ratkaisu joka toimii!
Ajattelin tällaisen ”problem solving by perkeleen” olevan ihan hyvä tapa ratkaista asioita. Näin jopa kunnia-asiana, että useita erilaisia ratkaisuita rakentamalla löytyy lopulta hyvä vaihtoehto.
Onko tämä teidän kehitystyössä tavallista? Kuuletko tällaisia lauseita kehitystiimiltä?

  • ”Kokeilen ensin tätä ja katsotaan sitten.”
  • ”Mikähän tässä nyt on, toimisikohan tämä jos tekisin näin…”
  • ”Tähän voisi kokeilla tällaista apukirjastoa.” (Javascript-maailmassa)

Näin tein itsekin kunnes luin kirjan. Lopussa paljastan vielä minkä kirjan!

Ratkaisu liian aikaisessa vaiheessa vaikeuttaa ymmärtämistä

Luen paljon kirjoja ja suurin osa luetusta tulee samaa vauhtia ulos kuin menee sisäänkin. Välillä vastaan tulee kirja, joka jysähtää. Tällä kertaa kirja osui ytimeen niin hyvin, että haluan jakaa keskeisen löydöksen myös teille.
Ja se on tässä:

Kun ymmärtää ongelman, ratkaisu on ilmeinen.

Tadaa! Noin yksinkertaista.
Lause tarkoittaa sitä, että kun ymmärtää ongelman läpikotaisin, niin ratkaisuvaihtoehtoja tai korjauksia on noin yksi. Tämä ratkaisu on niin ilmeinen, ettei useita ratkaisuvaihtoehtoja tarvita.
Erilaisten ratkaisuiden esittäminen liian aikaisessa vaiheessa hankaloittaa ongelman ymmärtämistä. Ratkaisuyritykset lisäävät vaihtelua, hämärtävät kokonaisuutta, luovat kohinaa ympärille ja vievät huomion pois itse ongelmasta.
Ratkaisukeskeisyydestä eroon pääseminen on kuitenkin vaikeaa. Siitä kertoo tarina seuraavasta aamusta.

Seuraavana aamuna…

Kirjan lukemisen viimeistelyn jälkeisenä aamuna olin taas ongelman edessä. Palvelimen automaattitesti ei mennyt läpi.
Palvelin tarkistaa saako dokumenttiin tehtyjä muutoksia tallentaa. Dokumentin lukittuja kenttiä saa muokata vain korkeimmillä käyttäjäoikeuksilla. Kaikki käyttäjät voivat muokata lukitsemattomia kenttiä. Automaattitesteissä tämän viimeisen asian testaava testi ei mennyt läpi.
Olin innoissani kokeilemassa uutta ongelmanratkaisutapaa tähän ongelmaan. Halusin ymmärtää ongelman perinpohjaisesti. Avasin koodit, lisäsin debuggausrivejä, perkasin koodia ja ajonaikaisia muuttujia läpi ymmärtääkseni toiminnallisuuden kulun.
Huomasin, että dokumenttien vertailussa verrattiin kahta kenttää, joiden ominaisuudet olivat eri järjestyksessä. Tutkin Javascriptin dokumentaatiota ja huomasin, että Javascriptissä ominaisuudet voivat olla eri järjestyksessä ja sen vuoksi vertailu voisi mennä pieleen.
Vaihdoin siis vertailun. Korjasin koodin kääntymään ja ajoin testit innokkaan optimismin vallassa. Olin oppinut uuden asian Javascriptistä, ongelmaan oli vain yksi järkevä ratkaisu ja se ratkaisu vaikutti hyvältä!
Mutta testi ei mennyt läpi.
Lyhyet chatit kokeneempien Javascript-vääntäjien kanssa (työkaverit, Goforen paras työsuhde-etu) ja kohta esillä oli lyhyet testikoodit. Testikoodit olivat hyvin lyhyet ja kokeilivat vain ongelman syyksi epäiltyä vertailua. Ne osoittivat, että alkuperäinen vertailu olikin toimiva. Olin ymmärtänyt ongelman väärin. Olin tehnyt väärän korjauksen ja vika oli toisaalla.
Lopulta ongelma oli itse testissä. Sovellus estää usean käyttäjän yhtäaikaisen muokkauksen aikaleimoja vertailemalla. Edellinen testi muokkasi dokumenttia tallentamatta aikaleimaa, jolloin tämä seuraava testi ei mennyt läpi.
Tarinan opetus: Ongelman syyn todistaminen oli tekemättä. Halusin mieluummin ratkaista ongelman kuin ymmärtää sen. En ollut tarpeeksi syvällä ongelmassa ja ratkaisu oli väärä.

Ongelma ei ole kenenkään vika

Kirja oli nimeltään Toyota Kata Managing Improvement Adaptiveness (löytyy Amazonin kirjakaupasta http://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238 ja Goforen kirjahyllystä https://gofore.com/en/join-the-team/)  Toyotan henkilökunnan tapa ratkaista ongelmia on keskeistä yhtiön tavassa kehittää omaa toimintaa. Yhtiö myös kehittää mentoreiden avulla henkilökunnan ongelmanratkaisutaitoja systemaattisesti.
Toyotalta on peräisin paljon useita tuotantoon liittyviä keksintöjä, joita länsimaissa on otettu käyttöön 70-luvulta lähtien. Toyotan näkökulmasta nämä keksinnöt ovat tulosta tästä henkilökunnan taidosta ratkaista ongelmia. Toyota ei menesty keksintöjen vuoksi vaan taitavan henkilökunnan vuoksi.
Keskeinen elementti Toyotan ongelman ymmärtämisessä on asialähtöinen näkökulma. Kirjassa toistuvia käytäntöjä olivat ”mennään katsomaan” ja ”näytä minulle”. Ketään ei syyllistetä ja kaikki osallistuvat ongelman ymmärtämiseen kuin muurahaisia tutkivat lapset. Aivan mahtavia asiakeskeisiä käytäntöjä ihmisten kanssa työskentelyyn!
Toyotalla ongelmat eivät sisällä negatiivisia tai positiivisia mielikuvia. Ne ovat vain ongelmia.

Avatar

Juho Pentikäinen

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Digitaalisia palveluja suunnitteleva ja rakentava Gofore täydentää koulutustarjontaansa ja tarjoaa Angular 2 -koulutusta ensimmäisenä Suomessa.
Angular 2 on uusi versio maailman ehkä suosituimmasta Angular-käyttöliittymäkehyksestä. Goforen koulutus perehdyttää Angular 2 -teknologian parhaisiin käytäntöihin ja eroihin Angulariin verrattuna. Kurssin avulla päivität käyttöliittymäosaamisesi seuraavalle tasolle.
Uuden oppiminen on kriittistä luotaessa digitaalisia palveluja. Joskus menetelmien ja teknologioiden käyttöönottaminen on kuitenkin haastavaa:

  • Miten uudistan käyttöliittymäni vastaamaan tämän päivän käyttötapoja?
  • Kuinka valitulla teknologialla päästään nopeasti vauhtiin?
  • Voinko luottaa netistä löytämääni teknologiablogiin?
  • Miten koulutan tiimini uuden menetelmän käyttöön?

Goforen asiantuntijat tekevät töitä Suomen parhaiden digitaalisten palveluiden parissa. Meille on muodostunut viisaus siitä, mikä toimii ja mikä ei. Kaikki koulutuspaketit räätälöidään tilaajan tarpeiden mukaisesti.
Lue lisää: Working on the Bleeding Edge – Building an Angular 2 Application During Beta Phase.
Katso Goforen kaikki koulutukset.
Ota yhteyttä: Gofore, Juha Virtanen, juha.virtanen@gofore.com, 050 413 3136.

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.