Löytyykö äppisi Huaweista?

Long story short: Trump ja Kauppasaarto --> uusissa Huawein malleissa ei ole enää Googlen ydinpalveluja (Google Mobile Services, jatkossa GMS) käytössä, ei vaikuta vanhempiin malleihin, kuten esim. Huawei P10, P20, P30, mutta esim. P40 ja P40 Pro eivät sisällä Googlen ydinpalveluja.

Eikö kosketa sinua käyttäjänä tai sovelluksentekijänä?

Kokeillaas toista lähestymistapaa:

Puhelimestasi ei löydy enää Google Play -kauppaa!

Eikä Youtubea. Eikä Gmail-sovellusta!

Alkoiko jo kiinnostamaan?

Eli jos sinulla softan tekijänä tai julkaisijana, startuppina tai yrityksenä on Android-sovellus, niin jatkossa se on ladattava saataville myös Huawei AppGalleryyn, jotta se olisi suoraan ladattavissa Huawein puhelimiin. AppGallery on siis kuten Play-kauppa nykyisissä Android-puhelimissa (tai AppStore Apple-laitteissa.)

Tämän lisäksi tulee huomioida muutamia asioita kehityksessä:

• Sovellus kannattaa alusta lähtien suunnitella siten, että se on ladattavissa sekä Huawein että Googlen kauppaan. Tämä koskee mm. seuraavia toiminnallisuuksia:

  • Push-notifikaatiot: Jos käytät Googlen Push -palvelua, niin Push-viestit eivät tule perille Huaweissa olevaan sovellukseen.

    • Ratkaisu: Toteuta erillinen Huawei variantti sovelluksesta ja käytä siinä Huawein omaa Push-palvelua. 

    • Tämän puutteen ratkaisu ei ole mikään iso homma ja kannattaa myös miettiä, että voiko sovellusta julkaista AppGalleryyn ilman toimivia Push-ilmoituksia, koska moni käyttäjä voi olla tilanteeseen tyytyväisempi kuin sovelluksen täydelliseen puuttumiseen.

  • In-App -Maksutoiminnallisuudet

    • Google Play -palvelut eivät ole käytössä, joten maksut pitää hoitaa toisella tapaa. Tähänkin löytyy Huawein oma toteutus: https://developer.huawei.com/consumer/en/doc/development/AppGallery-connect-Guides/appgallerykit-app-iap-0000001055276890

  • Kartat sovelluksissa

    • Google Mapsista on luovuttava, mutta rehellisesti sanottuna, on olemassa paljon kauniimpiakin toteutuksia, joita voisi käyttää sekä Google että Huawei -versioissa.

      • Esim. Here Maps -SDK:ta voisi ymmärtääkseni käyttää molemmilla alustoilla ja välttää kahden eri version välillä kikkailua.

    • Huaweilta toki löytyy tähänkin oma karttatoteutus, johon siirtyminen on erittäin suoraviivaista: https://developer.huawei.com/consumer/en/doc/development/HMS-Guides/hms-map-migrate

    • Lisäksi itselleni vieraampi https://www.mapbox.com/ pitäisi olla hyvä ratkaisu tarjoilemaan kartat alustariippumattomammin.

Nopea summaukseni onkin, dokumentaatioita tutkittuani, että teknisesti kyseessä ei ole valtava ponnistus seuraavista syistä:

• Googlen ja Huawein -palvelujen tekniset toteutukset ovat koodin näkökulmasta lähes identtiset, joten erillinen "variantti" on helppo toteuttaa.

• Voi johtaa hyvään sekä kehittäjän että käyttäjän kannalta, koska muitakin ekosysteemitaisteluja on käynnissä, mm. Googlen ja Amazonin välillä.

• Johtaa parempaan arkkitehtuuriin, koska komponentit tulee suunniteltua siten, että käytettävät palvelut on helppo korvata / vaihtaa.

Suurimmat ongelmat:

• Päättäjät eivät ymmärrä, että sovelluksien tulee olla molemmissa kaupoissa, koska käyttäjät alkavat jakautumaan entistä tasaisemmin eri sovelluskauppojen välille

  • esim. Säästöpankin tunnistussovellusta ja Säästöpankkisovellusta ei ole tällä hetkellä Huawein AppGalleryssä. Sieltä puuttuu myös EasyPark ja Parkman.

  • Huawei-yhteensopivuudella olisi nyt helppoa ottaa kärkipaikka sovelluskaupassa ja myös positiivinen markkinointikulma edelläkävijuudesta.

  • "Katellaan mitä muut tekee, ei me tehä nyt mitään"

  • Jos kohderyhmänä ovat nuoret, niin esim. Honor-sarjan puhelimet ovat asiakassegmentissä erittäin suosittuja. Älä siis tee päätöksiä perustuen omaan iPhone-kaveripiiriisi perustuen. 

• Negatiivinen käyttäjäpalaute yritystä kohtaan, koska sovellus ei ole saatavilla puhelimeen

  • Tämä ei sinänsä ole julkaisijan vika, mutta ei myöskään Huawein vika.

• Huawei on tällä hetkellä 2. suurin Android-puhelinvalmistaja heti Samsungin jälkeen, Huhtikuun tilastoissa Huawei ohitti valmistajana Samsungin. Molemmilla n. 20% osuus. Lähde: https://www.statista.com/statistics/271496/global-market-share-held-by-smartphone-vendors-since-4th-quarter-2009 ja uudempi lähde: https://www.forbes.com/sites/zakdoffman/2020/06/15/samsung-and-apple-beaten-by-huawei-in-huge-new-smartphone-surprise/

• Ylläpidettävä kehityshaara (joka ei oikeasti työllistä niin paljon)

• Hieman enemmän testattavaa

Lyhyt yhteenveto: Älä stressaa liikaa, mutta ota tämä asia huomioon, ennen kuin negatiivinen palaute osuu tuulettimeen.

Jos mielestäsi kirjoitus oli hyödyllinen, niin arvostaisin sen jakamista, jotta tämä tietoa saadaan mahdollisimman monen mieliin.

5 tapaa ajaa äppiprojekti metsään

1. Ostat vain tiimin resursseja / osaajia

Sinulla on tarve ohjelmistokehitykselle ja haluat ostaa projektin toteutuksen. Joten haluat tehdä sen niin kuin aina on tehty. Pitää löytää ohjelmistoyritys, jolta löytyy projektipäällikkö ja sopivan kokoinen lauma koodaajia. Toisaalla sinulla on mainostoimisto, joka tuottaa graafista materiaalia. Olet tehnyt itse sovelluksesta kuvauksen ja mahdollisesti ostanut jo käyttöliittymäsuunnittelun ja nyt etsit vain sopivaa toteuttajaa, joka kasaa sovelluksen pystyyn. Ei näin.Varsinkin, jos olet Startup-yrittäjä tai teet jonkinlaista ReStartup -projektia isomman yrityksen sisällä, niin todennäköisesti sinulla on kovastikin seuraavanlaisia rajoitteita:

• Budjetti

• Aikataulu

• Tavoite

• Toiminnallisuudet

Siinä missä ostettu tiimi keskittyy näistä asioita kolmeen, niin mielestäni oikea tapa on keskittyä yhteen. Ja se on TAVOITE. Tavoite todennäköisesti summaa jollain tavalla kaikki muut rajoitteet, mutta mikäli tavoite ei ole selkeästi tiedossa valitulla toimittajalla ja keskitytään vain budjettiin, toiminnallisuuksiin ja aikatauluun, niin todennäköisesti vähintään yksi näistä menee pieleen ja näin projektin tavoitekin jää saavuttamatta. Sen sijaan, tiimi, joka tietää tavoitteen (sekä tietenkin budjetin, aikataulun ja halutut toiminnallisuudet) pystyy keskittymään siihen, että yhteinen tavoite projektille on se, johon on PAKKO PÄÄSTÄ. Tällöin tavoitteen ympärille saadaan aikaan keskustelu, jonka kautta voidaan yhteisymmärryksessä säätää kolmea muuta tekijää niin, että projekti voidaan katsoa onnistuneeksi ja sen päälle voidaan alkaa rakentaa (liike-)toimintaa.

2. Et kerro kaikkea

Luottamuspula tai "eihän tämä nyt liity tähän projektiin millään tavalla" on yksiä suurimpia kiistan- ja ongelmanaiheuttajia projekteissa. Otetaan esimerkkeinä vaikka aikataulu- ja budjetti.

Aikataulu

Olet kertonut softakumppanille, että sovelluksen pitäisi olla valmiina tammikuussa 2020. Mutta se, mitä jätät kertomatta on se, että helmikuun 2. päivä on alkamassa kansainväliset messut, joissa sovelluksen tulisi olla yksi vetonauloista osana uutta tuotelanseerausta. Tiimi ei tiedä asiasta mitään ja mahdollisesti epäselvästä viestinnästä tai sairaspoissaoloista johtuen projektin priorisointi painottuu enemmän toiminnallisuuksiin ja budjettiin.Näissä tapauksissa projektissa viestinnästä alkaa tulla tulehtunutta ja ehkä hakataan jopa nyrkkiä pöytään ja ollaan tyytymättömiä. Samaan aikaan tiimi on ihmeissään, koska projektin sisältö ja budjetti ovat erittäin hyvin hallinnassa. Lopulta palaverin jälkeisellä lounaalla yhdessä tiiminvetäjän kanssa tulee puheeksi, että "niin kun nämä messutkin on viikon päästä ja ei tästä nyt tule mitään.."Joten: Kerro mielummin liikaa kuin liian vähän. Ja jos se hirvittää, niin salassapitosopimuksia luodaan juuri sitä varten, että kaikkein sensitiivisin tieto on varmasti turvassa ja sen voi avata huoletta kumppanille.

Budjetti

Rahasta on tyypillisesti vaikea puhua, varsinkin jos ne ovat kyseessä on on rahaa tai yritys, jonka varoja käytät, on vastuullasi. Projektissa voi olla ikävää keskustella siitä, että homma pyörii vahvasti sijoittajien tai esim. julkisen rahoittajan tuella ja projektin tietyt vaiheet sekä onnistumiset ovat kriteereinä lisärahoitukselle tai maksatuksille.Usko tai älä, voin väittää, että minulla on kokemusta lähes kaikista näistä keisseistä ja ymmärrän erittäin hyvin tilanteen, jossa esim. ELY-keskuksen tai Business Finlandin maksatukset ovat myöhässä. Mutta se, mikä alkaa hiertään minua ja toisaalta myös projektia on se, että tehdystä työstä ei tule maksua ja selittely alkaa siinä kohtaa, kun ollaan jo parin laskun verran myöhässä.Älä siis pidä projektin budjettia tai rahoitusta myöskään salassa, koska hyvältä kumppanilta löytyy varmasti ymmärrystä ja myös neuvoja. Esim. projektin toiminnallisuuksista voidaan valita ensin ne, jotka vaikuttavat eniten rahoituksen jatkumiseen tai käyttäjien saamiseen sovellukseen.Mutta muista myös se, että harvalla softafirmalla on varaa toimia kenenkään pankkina.

3. Julkaisukammo

Uskomusteni mukaan kirjailijoilla on usein sellainen olo, että kirja ei ole koskaan valmis. Samaa asennetta löytyy myös sovellusten tilaajilta, aina pitäisi vähän viilata jotain pikseliä tai "ei tätä voi ainakaan ilman tätä ominaisuutta julkaista", vaikka asiasta ei olisikaan mitään faktoihin perustuvaa tietoa.Suosittelemmekin usein hankkimaan luotettavia testausryhmiä (oikeita käyttäjiä), joiden kanssa voidaan kokeilla sovellusta jo varsin aikaisessa vaiheessa ja sitä kautta selvittää, onko sovelluksesta jo hyötyä käyttäjille. Jos on, niin SHIP IT!Hyödyn jälkeen toki pitää päästä siihen vaiheeseen, että sovellus tuottaa liikevaihtoa, tavalla tai toisella.Ja mikäli asiakkaana haluat olla varmempi siitä, mitä käyttäjät oikeasti haluavat, niin kannattaa tehdä heti projektin alussa käyttäjätestausta esim. prototyypeillä sekä haastatella juuri niitä tulevia käyttäjiä.

4. Etsitään syyllisiä

Aina paras tapa pilata mikä tahansa suhde, on lähteä syyttelemään. Esimerkiksi: "Kyllä tämä ennen toimi, tää on teidän vika, en todellakaan maksa tästä mitään", on oiva tapa saada kitkaa aikaa tiimin osaavien kehittäjien kanssa, kun unohdetaan samalla sellainen sivuseikka, että järjestelmään on tullut esimerkiksi kymmeniä miljoonia rivejä dataa sen jälkeen, kun ensimmäinen versio oli testattu toimivaksi 20 000 rivillä.

Asioista toki pitää puhua oikeilla nimillä ja selvittää, mistä mahdolliset ongelmat johtuvat. Ja joskus alaa syvemmin tuntematta tiedon lisääntyminen järjestelmässä ei tunnu isolta asialta. Samaan aikaan kehittäjistä voi tuntua siltä, että asiakas kiusaa, koska pakkohan hänen on ymmärtää, että tiedon määrä vaikuttaa kaikkeen toiminnallisuuteen, varsinkin kun siihen ei olla osattu varautua.Lisäksi useat järjestelmät nykyään käyttävät ulkopuolisia palveluja ja/tai koostuvat useasta erillisjärjestelmästä, joissa on sekä toiminnallisuuksia ja tietoa. Näin ollen, jos yksikin palveluista ei toimi tai muuttuu niin ettei siitä informoida kaikkia osapuolia, niin ei pitäisi lähteä etsimään syyllisiä vaan rakentavasti keskustelemaan siitä, mitä on tapahtunut ja mikä on saattanut aiheuttaa havaitun ongelman.

5. Ei panosteta markkinointiin

Yhteenkään sovellukseen tai palveluun ei ole tullut käyttäjiä ilman markkinointia. Ja miten enemmän ja ammattimaisemmin markkinoit niin sitä parempiin tuloksiin todennäköisesti pääset. Omassa toiminnassamme meillä ei ole paljoakaan eväitä ammattimaiseen markkinointiin tai esim. kasvuhakkerointiosaamista, mutta omista verkostoista sitä löytyy runsaasti ja pyrimmekin aina auttamaan ohjaamalla asiakkaamme oikeanlaisten kumppanien luo.Itse ennemmin lähtisin tekemään juuri sellaista tuotetta, joka näyttää hyvältä, tarjoaa perusominaisuudet ja tuottaa lisäarvoa tai liikevaihtoa brändille ja heti kun tuotteen pystyy julkaisemaan, niin käynnistäisin siihen markkinointitoimenpiteet, koska ilman käyttäjiä millään sovelluksella ei ole arvoa, mutta ei myöskään suuntaa. 

MPASS-kirjautumisen haasteet kunnissa

Ensin hieman taustaa, jotta voimme osoittaa, miksi asiasta voimme väittää jotain tietävämme.

Teemme päivittäin töitä eri oppimisympäristöjen, sähköisten työpöytien, kertakirjautumisintegraatioiden sekä muiden periaatteessa yksikertaisten - mutta käytännössä monimutkaisten ja vaikeasti ymmärrettävien - kokonaisuuksien kanssa.

Ensimmäiset kertakirjautumisratkaisut toimitimme vuonna 2011 Kauniaisiin Unelmakoulu-hankkeeseen, joka onkin toiminut mm. Airo-työpöydän ja Edison-oppimisympäristön sekä Lifelearn Platform -palveluiden lähtökohtana.

Suomessa olemme olleet perustajamme Ilkka Hakkarin edustamana mukana Educloud Alliancessa, joka toimi lähtölaukauksena yhteiselle kirjautumisalustalle, jota MPASSid nykypäivänä edustaa. Ilkan rooli oli toimia pääarkkitehtina, hänen kokemustaan ja pitkää osaamistaan on hyödynnetty koko ratkaisun suunnittelussa ja toteutuksissa, joten Haltulla on vähintäänkin hyvät lähtökohdat toteuttaa näitä kansallisia (ja kansainvälisiä) kirjautumisintegraatioita.

Viimeisimpänä suurena käyttöönottona olemme suunnitelleet ja toteuttaneet MPASSid:n käyttöönottoa Edison-kunnissa. Lähtökohta on sinällään ollut haastava, koska monet "myyntimiehet" markkinoivat alustaa tyylillä "ota käyttöön ja se on siinä". Tilanne on kuitenkin varsin erilainen, jos kunnassa on jo kertakirjautumisratkaisu olemassa ja MPASSid:n myötä käyttäjän identifioima tunnus muuttuu. Tästä luonnollisesti seuraa se, että aiemmin toimineet ja linkitetyt palvelut eivät enää pystykään tunnistamaan käyttäjää vaan oletetaan kyseessä olevan täysin uusi käyttäjä. Vielä suurempaa sotkua saadaan aikaan, jos osa palveluista hyödyntää MPASSid-tunnusta, mutta samalla pyrkii hakemaan eri taustajärjestelmistä tietoa perustuen muuhun kuin MPASSid:n tarjoamaan identiteettiin.

Edisonin tapauksessa Ilkka piirsi kuvia eri skenaarioista, jotka ovat nähtävillä ao. liitteessä (vaatii sähköpostiosoitteen antamisen). Skenaarioiden perusteella ei sinänsä vielä pysty toteuttamaan toimivaa arkkitehtuuria, mutta sen pohjalta pitäisi pystyä ottamaan huomioon tärkeimpiä seikkoja, kun MPASSid:tä ollaan kunnassa ottamassa käyttöön. LATAA TÄSTÄ Tarjoamme myös apua kokonaisuuden suunnitteluun ja käyttöönottoon täysin riippumattomasti tai esimerkiksi ottaa osaa käyttöönottoihin joko etäneuvottelun kautta tai osallistumalla suunnittelupalavereihin.Tarjoamme apua myös palveluntarjoajille MPASSid-tunnistautumisen käyttöönottoon omassa palvelussa, oli sitten kyse teknisestä integraation käyttöönotosta, käyttäjien provisioinnista tai muista teemoista, jotka liittyvät erilaisten integraatioiden toteutukseen, koska olemme melko varmoja, että samat asiat on meillä ratkottu jo vähintäänkin kertaalleen.Ja emme missään nimessä tule ylihinnoittelemaan tätä osaamista "arvopohjaisesti" vaan teemme työtä joko päivä- tai tuntihinnalla, kunhan ensin katsotaan yhdessä, millaisen ongelman kanssa painitaan.

Valtakunnallinen Harrastuspassi -menestyskonsepti

Saimme vinkin verkostostamme, että Opetus- ja kulttuuriministeriö (OKM) on järjestämässä innovaatiokilpailua liittyen nuorten harrastamisen edistämiseen. Päätimme välittömästi osallistua. Tiesimme, että meillä on tähän annettavaa kattavan koulupuolen kokemuksen ansiosta.Haltulta innovaatio-kilpailussa tiiminä oli palvelumuotoilun ja digitalisaation erikoisasiantuntijat Henri Viitanen, Ville Mäkiranta ja Mikko Sävilahti. Haltun tiimi tuli valituksi kilpailuun yhdessä neljän muun yritystiimin kanssa. Lähtökohdat innovaatiokilpailuun olivat selkeät. On tärkeää edistää nuorten harrastamista sillä harrastukset ovat tärkeä osa nuorten elämää.

Harrastuksissa on kyse mieleisestä tekemisestä, kaverisuhteiden vaalimisesta, itsensä kehittämisestä, omista unelmista ja vahvuuksien löytämisestä sekä vuorovaikutuksesta valmentajan tai ohjaajan kanssa. Harrastus on nuoren valinta viettää vapaa-aikaa. Yläkouluiässä harrastukset usein vaihtuvat eikä aina uuden, mieleisen harrastuksen löytäminen tai aloittaminen ole helppoa. Monilla nuorilla ei ole aikaa säännölliseen harrastamiseen, kun on paljon muutakin tekemistä ja on myös tärkeää olla kavereiden kanssa.- Opetus- ja kulttuuriministeriö

Innovaatioprosessin kick-offin aikana meille valkeni kysymykset, joihin vastaamalla OKM:n asettama ongelma ratkeaisi.

• Miksi nuori harrastaisi?
• Mitä nuori harrastaisi?
• Missä nuori harrastaisi?

Lisäksi ratkaisun pitäisi pystyä vastaamaan kahteen lisäkysymykseen.

• Kuinka saada nuori kokeilemaan harrastusta?
• Kuinka saada nuori jatkamaan harrastamista?

Vastausta kysymyksiin lähdettiin hakemaan innovaatiokilpailuun kuuluvassa hackathonissa. Hackathonissa pääsimme keskustelemaan harrastuspassin tulevien käyttäjien, eli nuorten kanssa suoraan, mikä tietysti on olennaista käyttäjäkeskeiselle suunnittelulle. Pystyimme myös osallistamaan nuoria suunnitteluun.Kahden ensimmäisen ryhmän kanssa keskustelimme perinteisesti. Me esitimme kysymyksemme ja niistä keskusteltiin. Jo näistä keskusteluista saimme vastauksia kysymyksiimme, joten päätimme kokeilla seuraavien ryhmien kanssa toisenlaista lähestymistapaa.Jaoimme ryhmät pienemmiksi kahden tai kolmen hengen ryhmiksi. Näille ryhmille annoimme ison paperin, jolle oli piirretty suorakulmiot kuvaamaan älypuhelimen näyttöjä. Tehtävänanto oli yksinkertainen:

Sovelluksen ensimmäinen näkymä on se, joka vetää käyttäjän sisälle sovellukseen. Millainen harrastuspassin aloitusnäkymän tulisi olla, jotta käyttäisit sitä yhä uudestaan? Piirrä tai kirjoita mitä aloitusnäkymä sisältää.

Kymmenenkin minuuttia riitti siihen, että ryhmät saivat aikaan aloitusnäkymiä, joita emme olisi ehkä tulleet ajatelleeksi, jos olisimme vain miettineet asiaa neuvotteluhuoneessa. Lopuksi pienryhmät esittelivät luomuksensa muulle ryhmälle ja niistä keskusteltiin.Kävimme tuloksia tiimin kanssa läpi ja totesimme, että tämä on tässä. Perustuen nuorten tuotoksiin ja heidän kanssaan käytyihin keskusteluihin meillä onkin yhtäkkiä käsissämme menestyskonsepti, jolla voidaan tuottaa aidosti nuoria kiinnostava Harrastuspassi-sovellus valtakunnalliseen käyttöön. Prosessi jatkuu konseptin jalostamisella ja konseptia esitellään Opetus- ja kulttuuriministeriön työryhmälle, jonka jälkeen OKM päättää konseptin toteuttamisesta.