Palveluiden mobiilikäytettävyys ei voi olla vain jälkiajatuksena tehty ominaisuus lisäarvon tuottamiseksi. Tuoreen arvion mukaan yli puolet kaikesta verkon käytöstä tapahtuu mobiililaitteilla vuonna 2018. Goforen blogissa kirjoitettiin pari vuotta sitten palveluiden responsiivisuuden puutteesta. Jo tuolloin mobiilikäyttö oli oleellinen osa palvelusuunnittelua. Palveluiden käyttö näyttää muuttuvan arvioituakin kokonaisvaltaisemmin mobiiliksi ja viimeistään nyt palvelut olisi toteutettava lähtökohtaisesti erilaisille päätelaitteille soveltuviksi.
Ei kannata tuijottaa pelkästään palvelusi analytiikan näyttämiä vähäisiä mobiilikäyttäjien määriä ja käyttää lukuja perusteluna, miksi ei panostettaisi mobiilikäytettävyyteen. Ehkä olemassa oleva palvelusi on vain niin huono mobiililaitteilla, ettei kukaan halua käyttää sitä! Tyypillisesti matalat konversioluvut mobiilikäyttäjillä merkitsevät huonoa mobiilikäytettävyyttä. Panostus palveluiden mobiilikäyttöön vaikuttaa merkittävästi käyttäjien toimintaan. Esimerkiksi Facebook panosti erityisesti vuoden 2013 aikana palveluidensa mobillikäytettävyyteen, ja jo muutamassa kuukaudessa mobiilikäytön määrä nousi 197 %. Näin syntyy kierre, jossa panostus palvelun mobiilikäytettävyyteen lisää käyttöä mobiililaitteilla ja edelleen tarvetta huomioida mobiilikäyttäjät entistäkin paremmin.
Näen, että palvelut, jotka eivät huomioi mobiilikäyttöä tai huomioivat sen vanhanaikaisesti karsimalla mobiilikäyttöä varten sisältöä ja toimintoja tietokoneiden ”täydestä palvelukokemuksesta”, eivät tule menestymään. Perusteluna tälle näkemykselle on uusin trendi, joka osoittaa, että merkittävä joukko käyttäjiä ei edes vieraile palveluissa millään muulla kuin mobiililaitteella – koskaan, ikinä. Kaikilla käyttäjillä ei edes ole käytettävissään ”vanhan liiton” pöytätietokonetta tai kannettavaa tietokonetta. Perheissä on yhä useammin vain puhelimia ja tabletteja, ja näidenkin laitteiden erot käytettävyyden ja ominaisuuksien suhteen ovat muuttumassa lähinnä teoreettisiksi.
”Vain mobiililaitteita” -trendi tulee yhä voimakkaammin esille myös julkishallinnon palveluissa kansalaisten yhdenvertaisuuden kannalta, mikäli ohjataan käyttäjiä digitalisoituihin palveluihin, mutta ei tehdä niitä riittävän hyvin käytettäviksi kaikille – myös ainoastaan mobiililaitteilla palvelua käyttäville kansalaisille. Mobiilikäyttäjät eivät halua tuntea itseään toisen luokan kansalaisiksi. Enää ei ole hyväksyttävää kuvitella, että käyttäjillä olisi käytettävissään vain osa palvelun ominaisuuksista mobiililaitteilla ja loput voitaisiin ohjata käytettäviksi eri päätelaitteella.
Menestyjien on siis välttämätöntä siirtyä erillisten päätelaiteriippuvaisten ”suppeampien” ja ”laajempien” käyttäjäkokemuksien toteuttamisesta kokonaisvaltaisempaan sisällön, toimintojen ja liiketoimintaprosessien suunnitelmalliseen hallintaan. Ilman tätä kokonaisvaltaista lähestymistapaa palvelun mobiilikäytettävyys ei voi olla riittävän korkeatasoista. Esitteleekö toteutustiimisi palvelun mobiilikäytettävyyttä pelkästään tietokoneella vetämällä selainikkunaa kapeammaksi ja väittämällä toteutusta ”mobiiliksi”? Anna heille potkut. Todennäköisesti mobiilinäyttöjen pikselitiheyksiä, mobiililaitteiden ja -selainten ominaisuuksia, käytettyjä käyttöliittymäelementtejä tai kosketusinteraktiota ei ole suunniteltu mitenkään järkevästi. Puhumattakaan edellä mainitusta sisällön suunnittelusta tai liiketoimintaprosessien sovittamisesta mobiililaitteille käyttökelpoiseen muotoon. Käytännön esimerkkinä useat pankkisovellukset eivät pelkästään sopeuta käyttöliittymää mobiilinäyttöön vaan hyödyntävät mobiililaitteiden kameraa laskujen viivakoodin lukemiseen. Mobiilikäyttäjäkokemus on tässä tapauksessa jopa parempi ja ominaisuudet laajemmat kuin perinteisessä verkkopankkipalvelussa.
Varsinkin laajoissa järjestelmähankkeissa aika ei tunnu riittävän kuin ponia suurempien asioiden kunnolliseen huomioimiseen. Mielestäni mobiilikäytettävyys pitäisi olla yksi niistä. Oletko sinä valmis mobiilikäyttäjiin, jotka eivät omista tietokonetta lainkaan? Heitä on jo ja tulee koko ajan lisää. Jokaisessa projektissa olisi syytä käyttää hetki ajatukseen: teemmekö järjestelmää, joka toimii käyttäjän arjessa, johon mobiililaitteet kuuluvat paitsi oleellisena jopa ainoana päätelaitteena palvelulle. IT-projekteille tyypillistä on muuttaa liian suoraviivaisesti paperilomakkeita ja nykyisiä liiketoimintaprosesseja digitaaliseen muotoon. Olisiko aika miettiä, miten organisaatiosi ydinliiketoiminta siirtyy aidosti käytettävimmällä tavalla asiakkaasi mobiililaitteeseen?

Avatar

Jarmo Korhonen

Jarmo is Senior User Experience Designer at Gofore. Being Master of Economics in Information System Sciences and Business Strategies. He knows how to combine user needs with today’s cutting edge technology, mobility and business models. During his 15+ years in the software business, Jarmo has also been invited to speak at international conferences such as JavaOne (US) and SVG Open (DE). But that’s not all – He is also an experienced visual and interaction designer, creating designs that make awesome digital services. Jarmo loves to work fast and lean, and focus on creating real value to the users at every step on the way.

Piditkö lukemastasi? Jaa se myös muille.

Task description

A while ago in a customer project we needed to merge multiple (5) Git repositories into single one retaining full history. The separate repositories had been under active development for the last two years and their combined size had grown to over 600MB. This operation is a bit more involved than basic use of Git so I decided to write a little blog about it.
Further it was required that all the branches and tags from the separate repositories would be merged into the new combined repository. In the process we needed to find and erase the largest unnecessary files from Git history to keep the new repository slim in size. The destination repository would contain the source repositories under their own subdirectories.

Workflow

The implementation plan turned out as in the picture below. The workflow proceeds as follows:

  1. Find out space taking files in the source repositories’ Git history
  2. Clone source repository to workstation
  3. Clean up source repository on workstation
  4. Rewrite source repository’s history on workstation
  5. Merge master branch from source repository to destination repository
  6. Merge other branches from source repositories into destination repository
  7. Merge tags from source repositories into destination repository

git_blogi

Find out space taking files in the source repositories’ Git history

The job starts by finding out the most space taking files in the source repositories’ Git history. The analysis is performed with a script [1] published by Antony Stubbs. The script works by going through the repository’s packfiles [2] and printing them out in order and nicely formatted. The repository has to be optimized with git-gc [3] command for all the files to be included in the scan. After the analysis is complete we have a list of files to be erased from the source repositories’ history in a later phase.

Clone source repository to workstation

The actual migration process starts by cloning the source repository to the workstation including all the branches and all the tags. We perform so called deep clone [4] and this is a prerequisite for the cleaning operation to succeed. After this the remotes of the cloned repositories are removed so that we don’t end up making changes in the original repositories by accident.
https://gist.github.com/iluwatar/fac18d5ada9216ff13c4#file-git_deep_clone_repository-sh

Clean up source repository on workstation

At this stage we perform the cleanup tasks. The files determined to be removed in the analysis phase are erased from the Git repository’s history. The following code shows how a single file (bigfile.zip) and a single directory (bigfolder) can be cleaned up from a repository including all the branches and all the tags.
https://gist.github.com/iluwatar/9cbea3249a4d3c20163b#file-git_cleanup_repository-sh
Here we use the most robust Git history rewriting tool [5] filter-branch [6]. The command has been designed for rewriting large amount of commits in a scriptable way. The most important parameters are –index-filter and –cached which tell the command to process the commits making use of the index instead of the checked out files (as –tree-filter does). This way the processing proceeds significantly faster. The other parameters –tag-name-filter cat processes all the tags and –all all the branches.

Rewrite source repository’s history on workstation

After cleaning up we rewrite the repository’s history to make it look like the files had always resided in a subdirectory. This is needed so that we can still easily access the revision history of the files with git log [7] command without the –follow switch that is normally required after moving files. The following code rewrites the repository’s history to make it look like the files had always been in a subdirectory named myfolder.
https://gist.github.com/iluwatar/9f994a92c3c4ebda440c#file-git_rewrite_history-sh

Merge master branch from source repository to destination repository

Finally we merge the processed repository into the newly founded repository. When all the separate repositories have been merged, we push the result to the remote.
https://gist.github.com/iluwatar/7d950fc1edbaca7b9701#file-git_merge_master-sh

Merge other branches from source repositories into destination repository

At this stage the combined repository’s master branch is complete. Next we merge the other branches from the source repositories.
https://gist.github.com/iluwatar/63e676f80e3e9cec0350#file-git_merge_branches-sh

Merge tags from source repositories into destination repository

Now we have merged all the branches we wanted into the new repository. As the last step, we need to merge the tags. We can accomplish this by creating a new branch from the tag we are processing and then merging the branches into the new repository.
https://gist.github.com/iluwatar/276aa970f5cdea2e9fd9#file-git_merge_tags-sh

Conclusion

Overall, performing this migration took about three hours. Most of the time was spent in the repository cleanup stage. The cleanup operations turned out to be lengthy for large repositories. It would be possible to optimize this time using external tool such as BFG Repo-Cleaner [8] instead of Git’s filter-branch. However, with basic analysis and cleanup we were able to cut the resulting repository’s size in half to about 300MB.
Initially the task seemed difficult. But eventually with the tools Git has to offer, the migration turned out to be rather easy.
Sources:
[1] https://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
[2] http://schacon.github.io/gitbook/7_how_git_stores_objects.html
[3] https://www.kernel.org/pub/software/scm/git/docs/git-gc.html
[4] http://stevelorek.com/how-to-shrink-a-git-repository.html
[5] http://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
[6] http://git-scm.com/docs/git-filter-branch
[7] http://git-scm.com/docs/git-log
[8] https://rtyley.github.io/bfg-repo-cleaner/
 

Avatar

Ilkka Seppälä

Ilkka on kokenut kehittäjä, joka saa motivaationsa teknisistä haasteista ja uusista teknologioista. Tällä hetkellä hänen kiinnostuksen kohteinaan ovat avoimen lähdekoodin projektit, DevOps ja Microservices.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Many developers are probably familiar with code coverage tools such as Clover or Cobertura. These tools help to measure the amount of source code that has been executed by a test suite. It gives a good overview of what areas of the source code have been tested and where tests have been neglected. This information is important in order to understand where additional tests should be added. However, code coverage does not indicate whether the tests are actually effective in finding bugs.
mutation testing_gofore
What is Mutation Testing?
Mutation testing provides information about the effectiveness of a test suite. It works in the following way:

  1. Mutants are created from the original source code, and they contain various faults. A mutant might contain, for example, a negated branch condition or a modified constant. The generated mutant might produce exactly the same output as the original program, in which case the mutant is said to be an equivalent mutant. These mutants are excluded from mutation testing because there is no way that the test suite can detect these kind of mutants. An example of an equivalent mutant is found in snippet 1.
  2. A set of tests from the suite are executed against the mutants. If the tests fail when executed against a mutant, the mutant is said to be killed (which is good in this context). Otherwise the mutant has lived.
  3. When tests have been executed against all the mutants, a mutation score is calculated, which is the ratio between killed mutants and the number of all non-equivalent mutants. A higher score indicates a better test suite effectiveness.

https://gist.github.com/sebastianmonte/6b5228653fa1cd5278a0#file-equivalent_mutant-java
Snippet 1: Equivalent mutant [3]
Simple Mutation Testing Example with Java
A sample project can be found at https://github.com/sebastianmonte/test-mutations that contains the source code of the following example. The project uses a tool called PIT [1], which is responsible for creating the mutants and executing the tests against them.
Consider a simple class that contains a method that checks if a number is a nonnegative:
https://gist.github.com/sebastianmonte/f6f79b64c02a9344d561#file-numberhelper-java

With the appropriate tests:
https://gist.github.com/sebastianmonte/c94b150b4edbeb740868#file-numberhelpertest-java

The test coverage tools would happily report that coverage is 100% and that the source code is throughout tested. But what happens when a fault is inserted in the code?
https://gist.github.com/sebastianmonte/e09661a8d940a333115f#file-numberhelpermutate-java

Our tests would still pass, but there is clearly a logical error that goes unnoticed. Agreed, this is a simplification and we could easily add a boundary test case for the zero input. However, consider a larger program that has thousands of comparisons and operations, how can we be sure that the tests are effective enough to spot these kinds of errors?
When the test suite is run with PIT, the problem is easily spotted. An example of the PIT test report is seen in Figure 1.
mutation testing2_goforeFigure 1: PIT test report
The UI is not the most polished one, but it indicates clearly which lines of code have inadequate test cases. Our mutation lives when the comparison is changed from ”>=” to ”>” indicating that we are not testing the boundary case. By adding the following test case we can get all the mutations killed:
https://gist.github.com/sebastianmonte/60e7a3830b4a50a11f57#file-numberhelpertest-java

Conclusion

Mutation testing seems powerful and research indicates that mutation score is a better predictor of real fault detection rate than code coverage [2]. However, it has not yet received widespread popularity. As one might guess, creating mutations and executing tests against those mutations is not a lightweight process and can take quite a lot of time. However, at least PIT provides a way to limit the source code classes for which to create mutants for, so mutants could only be applied in areas where a lot of conditional logic is present.
In addition to finding bugs, mutation testing is a great way to find redundant code thus making your code cleaner!
In conclusion I think mutation testing is a good addition to code coverage. I believe mutation testing will get more attention in the future once the performance cost is reduced and more tools begin to emerge for developers to use.
[1] http://pitest.org/
[2] http://homes.cs.washington.edu/~rjust/publ/mutants_real_faults_fse_2014.pdf
[3] S. Nica, R. Ramler, and F. Wotawa, ”Is mutation testing scalable for real-world software projects? ,” in Proceedings of the Third International Conference on Advances in System Testing and Validation Lifecycle (VALID 2011), November 2011.

Avatar

Sebastian Monte

Piditkö lukemastasi? Jaa se myös muille.

Opetus- ja kulttuuriministeriö valitsi suomalaisen Gofore Oy:n konsultointipalvelujen tarjoajaksi Avoin tiede ja tutkimus (ATT) sekä Kansallinen digitaalinen kirjasto (KDK) -hankkeiden kokonaisarkkitehtuurin kehittämistyössä.
ATT-hankkeen tavoitteena on, että vuoteen 2017 mennessä Suomi nousee johtavaksi maaksi tieteen ja tutkimuksen avoimuudessa ja että avoimen tieteen mahdollisuudet hyödynnetään laajasti yhteiskunnassa. Lisäksi tavoitteena on edistää tieteen ja tutkimuksen luotettavuutta, tukea avoimen tieteen ja tutkimuksen toimintatavan sisäistämistä tutkijayhteisössä sekä lisätä tutkimuksen ja tieteen yhteiskunnallista ja sosiaalista vaikuttavuutta.
KDK-hankkeen tavoitteena on lisätä kirjastojen, arkistojen ja museoiden digitaalisten aineistojen ja kulttuuriperinnön merkitystä yhteiskunnassa.

Goforen kokemus korkeakoulujen toiminnasta arvioitiin parhaimmaksi

Opetus- ja kulttuuriministeriön toimeksiannosta CSC:n järjestämässä kilpailutuksessa päädyttiin Goforeen yhteensä neljästä tarjouskilpailuun osallistuneesta vaihtoehdosta. Valinnan painotuksessa asiantuntijoiden osaamisen painoarvo oli 70 prosenttia ja hinnan painoarvo 30 prosenttia.
Kilpailutuksen laatuarvioinnissa Goforen tietämys korkeakoulujen toiminnasta osoittautui parhaimmaksi. Tarjottujen asiantuntijoiden taustalta löytyy ammattikorkeakouluille tehty arkkitehtuurimalli, projekteja Opetushallitukselle, opetus- ja kulttuuriministeriölle sekä useille yliopistoille ja ammattikorkeakouluille.

Gofore tuo ketteryyttä julkiselle sektorille

Gofore on ollut vahvasti mukana korkeakoulujen kokonaisarkkitehtuurimalli Kartturin kehittämisessä. Lisäksi yhdeksässä suomalaisessa yliopistossa käytössä oleva Oodi-opintohallinnon järjestelmä on Goforen voimin siirretty ketterän kehityksen toimintatapaan.
Yhteistyön jatkuminen opetus- ja kulttuuriministeriön sekä CSC:n kanssa tukee Goforen tavoitetta olla opetus- ja kulttuuriministeriön toimialan  julkisen hallinnon arkkitehtuurin kokonaisvaltainen osaaja sekä toivotuin kumppani.
 
Lisätietoja:
www.kdk.fi
www.avointiede.fi
www.gofore.com/asiakkaat/
Mikael Nylund
Gofore Oy
Liiketoimintajohtaja, sähköisten palveluiden arkkitehtuuritoimisto
040 540 2280, mikael.nylund@gofore.com

Avatar

Mikael Nylund

Mikael on Goforen johdon konsultoinnin palveluista ja yritysjärjestelyistä vastaava johtaja sekä toimitusjohtajan sijainen. Hän on työskennellyt Goforessa vuodesta 2010 lähtien ja auttanut sinä aikana lukuisia organisaatioita polulla kohti digitaalista liiketoimintaa. Mikael ajattelee, että parempi tulevaisuus tehdään teknologian avulla ihmisten ehdoilla.

Piditkö lukemastasi? Jaa se myös muille.

Käyttäjäkokemuksen suunnittelijana törmää usein olettamukseen, että tarpeeksi ammattitaitoinen UX-suunnittelija riittää takaamaan hyvän käyttäjäkokemuksen palvelussa, eikä käyttäjiä tai käyttäjäkokemusta tarvitse erityisemmin tutkia tai testata. On toki totta, että osaava ja kokenut suunnittelija osaa välttää monet huonon käytettävyyden karikot, mutta hyvän käyttäjäkokemuksen luominen ilman aitojen käyttäjien hyödyntämistä ja tutkimista on pitkälti arpapeliä.

UX_gofore_blogi
Kuvan lähde: http://www.boredpanda.com
Näitkö yllä olevassa kuvassa olevan kissan? Katso uudelleen. Nyt kun tiedät kissan siellä olevan, et voi olla näkemättä sitä kuvassa. Uusi katsoja taas ei näe kissaa välttämättä lainkaan. Näin tapahtuu myös suunnittelijalle, joka sokeutuu omalle työlleen – on vaikeaa tarkastella sitä uuden käyttäjän silmin. Kun jonkun toiminnon tietää olevan näkymässä, tuntuu käsittämättömältä, ettei joku toinen sitä huomaa. Tai jos tietää, kuinka systeemi toimii, on vaikea kuvitella sen käyttämistä ilman samaa tietoa, vaikka kovasti yrittäisikin.
Tarvitsemme siis tietoa, miten järjestelmän tai palvelun loppukäyttäjät eri asiat näkevät ja mieltävät eri käyttötilanteissa. Kognitiotiede tarjoaa tutkittua tietoa mm. siitä, miten ihmisen muisti ja oppiminen toimivat, ja tähän tietoon perustuu myös iso osa käyttäjäkokemuksen suunnittelusta. Opittavuus ja muistinkuormitus ovat olennaisia käytettävyyteen vaikuttavia seikkoja, joten palvelu jonka käytön oppii vaivattomasti ja jonka käyttö ei kuormita tarpeettomasti tai liikaa käyttäjän muistia, koetaan usein myös miellyttävänä käyttää. Hienoa, olemme taklanneet hyvän käytettävyyden perustason!
Käyttäjäkokemuksella voidaan saavuttaa sen sijaan paljon korkeampiakin tavoitteita. Verkkopankin tai terveydenhuoltopalvelun käyttämisen halutaan tuntuvan luotettavalta ja turvalliselta, pelin tulee imaista mukaansa ja viihdyttää, ravintolan nettisivujen tulee välittää elämyksiä ja tunnelmaa, ja työkalusovelluksen tulee olla hyödyllinen apuri ja istua käyttäjien työprosessiin kuin hyvä hansikas käteen. Jotta näihin tavoitteisiin päästäisiin, täytyy ymmärtää, mitkä asiat tarkoittavat palvelun käyttäjille toivottuja asioita ja mitkä ominaisuudet tukevat palvelun tai sovelluksen käyttäjäkokemukselle asetettuja tavoitteita. Meidän täytyy tutkia ja analysoida käyttäjien toimia, nykytilannetta, toiveita, tarpeita ja ympäristöä ja tehdä näistä tarvittavat päätelmät.

 ”On miltei mahdotonta arvata toisen ihmisen mentaalimalleja tutustumatta häneen ensin.”

Törmäämme erilaisiin mentaalimalleihin. Mentaalimallit ovat yksilöllisiä tapoja hahmottaa erilaisia asioita ja ennustaa niiden toimintaa. Jokaisella käyttäjällä on omansa, ja myös suunnittelemassamme palvelussa on oma vastaava mallinsa, konseptimalli. Palvelumme mallin tulisi sopia käyttäjien malliin, jotta he kokisivat palvelun käyttämisen luontevana ja miellyttävänä. On miltei mahdotonta arvata toisen ihmisen mentaalimalleja tutustumatta häneen ensin. On siis tutustuttava palvelumme käyttäjiin, tutkittava heidän toimintaansa omassa ympäristössään, kyseltävä ja ihmeteltävä. Puhutaan käyttäjälähtöisen suunnittelun menetelmistä, joiden käyttöä Arto omassa kirjoituksessaan hyvin perusteli. Menetelmiä on useita, esim. mentaalimalleja voi selvittää haastatellen ja havainnoiden käyttäjiä sekä analysoimalla heidän nykyistä toimintaansa. Matti on kirjoittanut Desire paths -metodista, jossa käyttäjien annetaan ensin itse löytää luonteva tapansa toimia, jonka jälkeen suunnittelu pohjataan sille.
Tutustuttuamme henkilöön emme vieläkään voi tarkalleen tietää kuinka hän asioita hahmottaa, voimme korkeintaan esittää valistuneita arvauksia saamamme tiedon ja aikaisemman kokemuksemme pohjalta. Emme myöskään voi päätellä kuinka hän toimisi tutkimalla täysin toisen tyyppisen henkilön toimintaa. Arvaus muuttuu todennetuksi tiedoksi vasta näkemällä kuinka kyseinen henkilö itse aidossa tilanteessa toimii. Suunnittelutyössä on siis kerättävä käyttäjäpalautetta palvelun aidoilta loppukäyttäjiltä, ja tehtävä esim. käytettävyystestausta, jossa testihenkilö käyttää palvelua ja yrittää suorittaa sillä tyypillisiä tehtäviään. Tässä vaiheessa paljastuu, noudattaako palvelumme konseptimalli samaa logiikkaa käyttäjien mentaalimallin kanssa.

 ”Käyttäjätkin kehittyvät, oppivat ja tottuvat aina vain parempiin ja kehittyneempiin ratkaisuihin.”

Käyttäjien tilanteen tunteminen vaatii myös jatkuvuutta. Käyttäjätkin kehittyvät, oppivat ja tottuvat aina vain parempiin ja kehittyneempiin ratkaisuihin. Käytämme vapaa-ajallamme kaiken aikaa erilaisia verkkopalveluita ja laitteita, joiden käyttäjäkokemuksien luontiin on panostettu aikaa ja rahaa, joten on vain luonnollista, että myös työssä ja asioidessa odotamme kohtaavamme yhtä hyviä kokemuksia. Käyttäjistä tulee siis koko ajan laatutietoisempia, ja he osaavat odottaa sovelluksilta hyvää käyttäjäkokemusta. Enää ei siis riitä, että käyttäjiä havainnoidaan kerran hankkeen alkuvaiheessa, vaan loppukäyttäjiä täytyy hyödyntää koko järjestelmän tai palvelun kehityskaaren ajan, säännöllisesti. Tietenkin matkan varrella tietämys palvelun käyttäjistä kasvaa, mikä mahdollistaa nopeampien ja kevyempien menetelmien käyttämisen suunnittelutyössä, mutta perustarve ei muutu: käyttäjien kehityksen kyydissä on pysyttävä.
Käyttäjäkokemuksen suunnittelutyössä valistuneiden arvauksien avulla voi edetä vain osan matkaa, mutta hyvin harvoin maaliin, tavoiteltuun käyttäjäkokemukseen saakka. Ja tässä ei kovinkaan UX-suunnittelija onnistu ilman loppukäyttäjien kuulemista ja kohtaamista.
UX_Valistunut_arvaus_gofore

Avatar

Virve Kuorelahti

Virve työskentelee Senior Designerina Goforella. Tehtyään vuosikymmeniä digitaalisten palveluiden suunnittelua (interaktio- ja käyttöliittymäsuunnittelua, määrittelyä ja konsepteja) hän löysi viimein kodin palvelumuotoilusta.

Piditkö lukemastasi? Jaa se myös muille.

Gofore on Suomen parhaat työpaikat 2015 -tutkimuksen mukaan Suomen kolmanneksi paras työpaikka. Lista julkistettiin torstaina 5.2. Helsingissä.
”Olemme ylpeitä sijoittumisestamme aivan kärkeen yli 150 organisaation joukossa. Tämä on goforelaisten yhteinen saavutus, sillä jokainen meillä on mukana kehittämässä Goforea yhä paremmaksi”, sanoo Goforen toimitusjohtaja Timur Kärki.
Hieno listasijoitus sai aikaan äänekästä innostusta ja iloista pöhinää goforelaisten joukossa. Tärkein saavutus oli kuitenkin tiedossa jo ennen listan julkistusta.
”Sata prosenttia goforelaisista vastasi tutkimuksessa, että töihin on mieluista tulla joka päivä. Se kertoo, että olemme onnistuneet toteuttamaan tärkeimmän arvomme: olemaan hyvä työpaikka jokaiselle goforelaiselle”, Kärki sanoo
Suomen parhaat työpaikat -listasijoituksessa painottuvat työntekijöiden arviot työpaikastaan. Gofore sai tässä Trust Index -tutkimuksessa goforelaisilta erinomaiset pisteet.

’Työmme tarkoitus on pelastaa Suomi’

Goforella on takana yli kymmenen peräkkäistä kannattavan kasvun vuotta. Keskimääräinen liikevaihdon kasvu kymmenen vuoden ajalta on yli 40 %. Toissa vuonna kasvua oli 60 %, viime vuonna 50 %, ja sama tahti jatkuu tänäkin vuonna. Kasvuluvut ovat jopa ICT-toimialla poikkeukselliset, kuten alla oleva kuva kertoo.
gofore-oy-kasvu

Kärki sanoo, että taloudellinen menestys ja henkilöstön hyvinvointi ovat toistensa edellytys ja seuraus. Goforen menestystekijöistä Kärki nostaa kuitenkin yhden ylitse muiden.
”Työllämme on itseämme ja yritystämme suurempi tarkoitus. Tehtävämme on pelastaa Suomi. Tämä tavoite ja arvomme ohjaavat kaikkea tekemistä meillä joka päivä.”
”Merkityksellinen työ innostaa ihmisiä, ja kun osaaminen on huipputasoa ja työtä tehdään yhdessä hyvän porukan kanssa, saamme asiakkaidemme kanssa aikaan uusia, toimintaa parantavia sähköisiä palveluja.”
Gofore on parhaillaankin mukana useissa keskeisissä kansallisissa tietoyhteiskunnan kehityshankkeissa. Gofore tuo sähköisten palvelujen ja järjestelmien kehittämiseen kokonaisvaltaista näkemystä, ammattikielellä arkkitehtuuriosaamista, joka on julkisten palvelujen ja toimintojen uudistumisen ja tehostamisen lähtökohta ja edellytys.
”Me kaikki goforelaiset tiedostamme vahvasti, että meillä on tärkeä rooli digitalisoitumisen vauhdittamassa yhteiskunnallisessa murroksessa, ja haluamme auttaa yrityksiä ja julkista sektoria uudistumaan ja kehittymään, niin että Suomi ja suomalaiset pärjäävät ja voivat hyvin globaalissa ympäristössä.”

Avoimuus ja yhdessä tekeminen kuuluvat 2000-luvun työkulttuuriin

”Samalla kun uudistamme digitalisoitumisen keinoin uutta tietoyhteiskuntaa, luomme ja kehitämme uudenlaista ihmislähtöistä työkulttuuria. Se on ollut ääneen lausuttu ja arvoihin kirjattu tavoitteemme yrityksen perustamisesta asti, ” Kärki sanoo.
Henkilöstön tyytyväisyyttä on tutkittu Goforessa systemaattisesti vuodesta 2010. Ulkopuolisen tekemät tutkimukset ovat antaneet impulsseja työviihtyvyyden jatkuvaan kehittämiseen. Suomen parhaat työpaikat -tutkimukseen Gofore osallistui nyt ensimmäistä kertaa.
”Goforen yltäminen ensikertalaisena parhaiden työpaikkojen listalle on erinomainen osoitus siitä, että hyvä työpaikka on Goforen johdon arvovalinta, johon organisaation johtamiskäytännöt nojautuvat kokonaisvaltaisesti. Suomalainen työelämä tarvitsee lisää Goforen kaltaisia inspiroivia esimerkkejä yrityksistä, joissa kannattavaa kasvua tehdään ihmisiä arvostavalla tavalla ja aitoa välittämistä huokuvassa yrityskulttuurissa,” sanoo Great Place to Work® Institute Finlandin toimitusjohtaja Mona Rundberg.
Suomen parhaat työpaikat 2015 -tutkimukseen osallistui 153 organisaatiota. Tutkimuksen pohjana on hyvän työpaikan määritelmä: hyvä työpaikka on sellainen, jossa työntekijät luottavat organisaationsa johtoon, ovat ylpeitä siitä mitä tekevät ja nauttivat työtovereidensa kanssa työskentelystä. Great Place to Work® Finland on koonnut listan Suomen parhaista työpaikoista jo 13 vuoden ajan.
Lisätietoja: Gofore Oy, toimitusjohtaja Timur Kärki, p. 040 828 5886040 828 5886, timur.karki@gofore.com, www.gofore.com
Goforen työntekijöiden blogaukset: Erkki Salminen: Suomen paras työpaikkani (http://gofore.com/ajankohtaista/suomen-paras-tyopaikkani/) Jenna Fröjd: Paras työpaikkani (http://gofore.com/ajankohtaista/paras-tyopaikkani/)

Avatar

Riikka Nurminen

Piditkö lukemastasi? Jaa se myös muille.

Tampereen Teknillisen yliopiston tiedote:
Mitä haasteita suomalaiset julkisen hallinnon organisaatiot kohtaavat kokonaisarkkitehtuurin saattamisessa osaksi toiminnan kehittämistä ja johtamista? Miten haasteet voidaan ratkaista? Kysymyksiin vastaa Juuso Tuomola Tampereen teknillisessä yliopistossa tekemässään diplomityössä.
Juuso_Tuomola_kokonaisarkkitehtuuri
–Kokonaisarkkitehtuurin koetaan olevan ylimääräistä työtä, joka vain kuluttaa jo valmiiksi tiukkoja resursseja, toteaa diplomi-insinööri Juuso Tuomola.
Tuomola selvitti Tampereen teknillisen yliopiston tietojohtamisen opintoihin liittyvässä diplomityössään julkisen hallinnon organisaatioiden kokemuksia kokonaisarkkitehtuurin nivomisesta toiminnan kehittämiseen ja johtamiseen. Gofore Oy:n toimeksiannosta tehtyä diplomityötään varten hän haastatteli kymmentä terveys- ja hyvinvointisektorin virastoissa ja laitoksissa työskentelevää. Diplomityö valmistui loppuvuodesta 2014.

”Kyse on vain normaalista toiminnan kehittämisestä”

Tuomolan mukaan haastatteluissa keskeisimpiä esiin nousseita haasteita ovat julkishallinnon laajaan organisaatiorakenteeseen liittyvät ongelmat, johdon sitoutuminen, resurssien puute sekä kokonaisarkkitehtuurin kokeminen ylimääräisenä vaivana.
–Menetelmä tuntuu vieraalta ja liian tekniseltä henkilöille, joilla ei ole osaamista tietotekniikasta. Sen ei myöskään koeta sopivan julkisen sektorin moniorganisaatiomalliin. Kokonaisarkkitehtuuri nähdään lisäksi usein tietohallinnon omana menetelmänä tai asiana, joka kuuluu vain arkkitehdeille. Resurssien ja ymmärryksen puute jarruttivat kokonaisarkkitehtuurin käyttöä, Tuomola luettelee.
Askarruttavia asioita olivat myös käytetty kokonaisarkkitehtuurimenetelmä, kokonaisarkkitehtuurin puuttuminen lainsäädäntöprosesseista, kokonaisarkkitehtuuriosaamisen puute sekä IT:n ja liiketoiminnan yhteistyön haasteet.
–Haastatellut kokivat kokonaisarkkitehtuurin liian tekniseksi ja luotaantyöntäväksi. Sen myynnissä johdolle ja työntekijöille ei ollut onnistuttu, vaikka sen avulla saavutettavat hyödyt ovat merkittäviä.
Tuomolan mukaan organisaatioiden pitäisi keskittyä avoimeen ja jatkuvaan kommunikaatioon, aitoon organisaatiorajat ylittävään yhteistyöhön ja eri osa-alueiden yhteistyön tiivistämiseen. Organisaation kokonaisarkkitehtuuria tulisi käytännöllistää, kokonaisarkkitehtuurimenetelmiä kehittää ja sovittaa niitä organisaatioon. Lisäksi tulisi kiinnittää huomiota kokonaisarkkitehtuurin myymiseen, resurssien uudelleenkohdistamiseen sekä osaajien kouluttamiseen, osaamisen jakamiseen ja kokonaisarkkitehtuuritietouden lisäämiseen.
–Loppujen lopuksi kyse on kuitenkin vain normaalista toiminnan kehittämisestä.
Kokonaisarkkitehtuuri pitäisi ottaa mukaan lainsäädäntöprosesseihin. Julkisella sektorilla kokonaisarkkitehtuuria on käytetty toiminnan suunnittelussa tietohallintolain velvoittamana syksystä 2011 lähtien. Lukuisia haasteita on kuitenkin ratkaistavana, jotta kokonaisarkkitehtuuri nivoutuu kiinteästi osaksi toiminnan kehittämistä ja johtamista.
Tuomola antaa diplomityössään suosituksia julkishallinnon kokonaisarkkitehtuurin saattamiseksi osaksi toiminnan kehittämistä ja johtamista. Diplomityön toimeksiantaja Gofore Oy palkkasi Tuomolan diplomityöprojektin alkaessa nuoremmaksi palveluarkkitehdiksi.
–TTY:n tietojohtamisen opinnoista sain erinomaiset valmiudet konsulttina työskentelyyn. Diplomityön tekeminen Goforella antoi hyviä kontakteja ja työpaikan loistavassa yrityksessä. Nyt minulla on mahdollisuus syventää osaamistani entisestään ja todella vaikuttaa yhteiskuntaamme, Tuomola sanoo.
Lisätietoja:
Gofore Oy
Juuso Tuomola, nuorempi palveluarkkitehti
puh. 040 869 9162, juuso.tuomola@gofore.com
Tampereen teknillinen yliopisto
Professori Samuli Pekkola
puh. 040 586 0791, samuli.pekkola@tut.fi
Juuson blogikirjoitus: Pöytälaatikkoarkkitehtuurista keskeiseksi johtamisen ja kehittämisen välineeksi
Juuson diplomityö: Kokonaisarkkitehtuurityön saattaminen osaksi toiminnan kehittämistä ja johtamista: terveyden ja hyvinvoinnin kohdealue
 
 
 

Avatar

Juuso Tuomola

Piditkö lukemastasi? Jaa se myös muille.

Kirjoitin joulukuussa terveisiä LeWeb-seminaarista ja kerroin siellä kiteytyneistä ajatuksistani disruptiosta. Maailma muuttuu kiihtyvällä tahdilla – rakenteet murtuvat uuden teknologian ja sen ympärille syntyvien palveluinnovaatioiden myötä.
Uber myllyttää taksikenttää, Airbnb majoitustarjontaa. Isoin myllerrys on kuitenkin tulossa hyvinvointipalveluiden tiimoilla, kukaan ei vaan tarkkaan ottaen tiedä millainen. Itse varsinkaan, teknologian ja johtamisen ammattilaisena, en tätä täysin hahmota. Joitakin arvauksia voin kuitenkin esittää omaan taustaani pohjautuen.
Väitän, että kahdenkymmenen vuoden kuluttua tarve lääkäreille ja hoitohenkilökunnalle per henkilö on selvästi vähäisempi kuin nykyään. Lääkäriä ei tarvitse tavata yleisempien diagnoosien tekemiseen ollenkaan, vaan he voivat keskittyä vaikeampiin tapauksiin ja varsinaisiin hoitotoimenpiteisiin.
Tekniset anturit mittaavat jo nyt tekemisiämme juoksulenkillä ja matkapuhelimemme kertovat päivän aikana kulkemamme kilometrit ja noustut kerrokset. Dataa kertyy jatkossa merkittävästi enemmän puettavan teknologian ansiosta – vaatteisiin ja kehoon on tarjolla jos jonkinlaista anturia, jotka kertovat aktiivisuutemme lisäksi elintoiminnoistamme.
Kun kerätty tieto yhdistyy henkilön sairaus- ja lääkintähistoriaan sekä perinnöllisiin sairauksiin liittyviin riskitietoihin, dataa onkin jo aika paljon tiedossa erilaisia diagnooseja varten. Tai mennään vielä pidemmälle – käytetty päätelaite tietää myös sijaintihistoriamme. Mitä tartuntatauteja on ollut lähistöllä? Missä ravintoloissa olet syönyt, onko ruokamyrkytyksiä? Saammeko jatkossa tiedon, että ”75 % todennäköisyydellä olet sairastunut influenssaan”, ennen kuin itse havaitsemme mitään oireita? Tähän liittyy myös ympäristödata. Mikäli olet viettänyt radon-alueella aikaasi, se lienee merkityksellistä diagnoosin kannalta. Jos olet juossut ilmansaasteisella alueella, siitäkin voidaan päätellä jotain.
Kun kaiken mitatun datan yhdistää itsediagnoosipalveluun, jossa henkilöä pyydetään kuvaamaan oireet, tullaan saamaan hyvin kustannustehokkaasti ja erittäin varmasti diagnoosi, eikä fyysistä lääkäriä enää tarvita. Tähän voidaan yhdistää myös kuva-analyysit soveltuvin osin.
Mutta kuka hallinnoi sitä palvelua, johon kirjaudut terveystilaasi tarkastellessasi? Tai jos suuntaat startup-yrittäjäksi ja tuotat jotain terveystietoihin tukeutuvaa palvelua, mihin olet yhteydessä, mistä saat tiedon käyttöösi? Tällä hetkellä on melkoinen kisa käynnissä Applen ja Googlen välillä terveyspalveluiden ekosysteemien suhteen. Samaan aikaan pääomasijoittajat investoivat suuria summia erilaisiin terveystietoa hyödyntäviä palveluita tuottaviin yhtiöihin. Tuolla saralla siis tapahtuu paljon ja aivan lähiaikoina.
Mielestäni olisikin erittäin tärkeää Suomessa tunnistaa tämä kehitys ja miettiä meidän oma strategiamme asian suhteen. Kunnallisten tai valtion palveluiden ei ole mitään järkeä lähteä kilpailemaan kansainvälisten ekosysteemien tai edes startupien kanssa teknisten palveluiden tuottamisen suhteen. Mutta voisimme tehdä paljonkin mahdollistaaksemme parhaan mahdollisen kasvualustan innovaatioille ja startupeille liittyen tähän toimintakenttään. Voisiko Suomi olla laboratorio kaikkein villeimmille palveluinnovaatioille? Eikö se olisi kovin sopivaa, kun juuri Suomessa yhdistyy huippuluokan insinööritaito käsillä olevaan ikärakenneongelmaan? Mitä se vaatisi, mikä olisi kaikkein hienointa, mitä voisimme googleille, appleille ja startupeille tarjota?
 

Avatar

Timur Kärki

Timur on Gofore Oy:n toimitusjohtaja ja yksi perustajaosakkaista. Hänellä on yli viidentoista vuoden kokemus haasteellisista tietojärjestelmien kehittämishankkeista. Erityisen kiinnostunut Timur on Suomen pelastamisesta onnistuneilla ja innovatiivisilla sähköisillä palveluilla yhdessä Goforen asiakkaiden ja työntekijöiden kanssa. Timur itse konsultoi asiakkaita liittyen kokonaisarkkitehtuurityöhön, vaatimusmäärittelyihin sekä kilpailutusprosesseihin.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.