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.

GitLab ja infrakustannukset

Yrityksemme on ollut olemassa jo yli 8 vuotta, tänä aikana kaikki ohjelmistokehityksen ja projektinhallinnan työkalut ovat kehittyneet huimasti. Varsinkin alussa vertailimme ja etsimme parhaita (sopivimpia) työkaluja juuri meidän toimintatapaamme pitäen mielessä kasvun myötä tulevat muuttuvat vaatimukset. Kaiken pitäisi kuitenkin sujua mahdollisimman ketterästi ja toisaalta työkalujen on koko ajan pitänyt mahdollistaa läpinäkyvyys asiakkaalle asti.

Olemme - kuten moni muukin ohjelmistotalo - rakentaneet tärkeimpiä järjestelmiä itse ja investoineet näihin tuhansia ja taas tuhansia tunteja työaikaa. Päädyimme rakentamaan tärkeimmän osan työkalupakistamme itse koska toisistaan irrallisia työkaluja löytyi, mutta selkeää kokonaisuutta niistä oli vaikea rakentaa, eikä yksikään niistä sopinut, tai riittänyt, sellaisenaan.

Tärkein työkaluistamme on Seepra -niminen toiminnanohjaustyökalu, jossa hallitaan projekteja, asiakkaita sekä kirjataan tunnit - aina työtehtäväkohtaisesti ja siten, että ylimääräistä aikaa ei kulu eri järjestelmien käyttöön.

Toiseksi tärkein työkalu meidän toimintamme kannalta on nykyään ehdottomasti GitLab, joka yhdistää ihanasti versiohallinnan, tehtävähallinnan sekä projektinhallinnan ja CI:n (Continuous integration). Käytimme pitkään sisäisesti Mercurialia versionhallintaan ja rakensimme sen ympärille omat työkalut. Meillä oli periaattessa kaikki Gitlabin tuomat ominaisuudet rakennettuna Mercurialin ympärille. Mutta ylläpitokustannukset vain kasvoivat vuosi vuodelta. Siirtymään Mercurialista Git:iin suurin syy olikin se, että Git:n päälle rakennettu työkaluvalikoima on moninkertaisesti kattavampi ja niiden ympärillä on aktiivinen kehittäjäyhteisö.

Ylläpidämme Gitlabista omaa instanssia, koska se on keskeisessä roolissa kaikissa meidän prosesseissa henkilöhallinnosta projektinhallintaan. Gitlabin ylläpito itse ei sinänsä ole valtava kustannus. Jopa päinvastoin. Gitlabin käyttöönoton jälkeen meidän sisäisen työkaluvalikoiman ylläpitokustannukset putosivat murto-osaan entisestä kun pystyimme luopumaan suuresta määrästä itse rakennetuista ja ylläpidetyistä työkaluista. Olemme harkinneet maksullisten lisenssien hankkimista, mutta vielä se ei ole tullut aiheelliseksi. Kasvun myötä tosin se päivä lähenee jatkuvasti.

Ylläpidämme vastaavanlaista ympäristöä myös muutamalle asiakkaallemme ja useilla asiakkailla on pääsy meidän GitLabiin heidän projekteihin. GitLab onkin teknologiastartupille mahtava työkalu sillä se sisältää kaiken tarvittavan yhdessä paketissa. Siitä on helppo lähteä laajentumaan kun vaatimukset kasvavat. Gitlabin ylläpitoon ei välttämättä kannata itse lähteä - varsinkin koska mm. meiltä löytyy intressi pitää omat ympäristömme ajantasalla - samalla pystymme tekemään sen myös asiakkaillemme - järkevällä hinnalla.Kustannustehokkuus ja takaisinmaksuaika Gitlabin käyttöönotolle on ollut selvä: Gitlab on vähentänyt meiltä kehittämisen työkalujen kustannuksia niin selkeästi että emme enää halua takaisin entiseen aikaan ja kymmeniin eri työkaluihin ja niiden ylläpitoon. Olemme jo aloittaneet purkutyöt, ja pala kerrallaan siirrymme tukeutumaan Gitlabiin.

APItalistisika rikastuu toisten avoimuudella!

Tartun nyt uuteen trendiin, joka tuntuu koko ajan vain kasvavan tällä ohjelmistoalalla. Jatkuvasti kuulee enemmän apeista ja rajapinnoista - sekä vastenmielisestä avoimuudesta. Lisäksi näitä on mm. Helsingin kaupunki vienyt törkeästi käytäntöön - ja vielä verorahoilla! Projekteja vaivaa myös aivan törkyinen läpinäkyvyys, jossa melkein kuka vaan voi päästä kärryille, missä mennään ja millaisella laadulla asioita tehdään. Ei kuulosta vanhalta kunnon Länsimetro-projektilta lainkaan - Apotista puhumattakaan! Tämä toiminta onkin alkanut synnyttämään Suomeen ison kasan apitalisteja. Noita sikoja, jotka käyttävät järjestelmää häikäilettömästi omaksi ja toisten eduksi. Olenkin tunnistanut 3 asiaa, joista tällaisen it-alan loisen tunnistaa:

1. Se kyttää sun järjestelmistä saatavaa avointa dataa

Oletko saanut epäilyttäviä puheluja, sähköpostiviestejä tahi twiittejä, joissa tiedustellaan järjestelmistäsi saatavaa avointa dataa ja rajapintoja? Kun olet tuskaillen joutunut myöntämään asian tilan, niin sitten on painostettu dokumentaatiolla ja avoimen lähdekoodin Github-projekteilla? Kuulostaako tutulta? Pitäisi kuulostaa, koska tätä se maailmanmeno nykyään on. Missään ei saa takoa rahaa vain itselleen, vaan aina on joku muu hyötymässä sun suljetusta järjestelmästä ilman niin tuottavia lisenssimaksuja.

2. Se rakentaa sovelluksia toisten keräämien tietojen pohjalle

Kun olet viimeinkin saanut jonkun tolkun omien rajapintojesi hallinnasta, käyttöoikeuksista ja jostain API-avaimista, niin huomaatkin, että tämä peijoona on tehnyt jo sovelluksen, joka käyttää sun dataa. Sitä dataa, minkä olet projektissa kerännyt ja ajatellut panttaavasi maailmanloppuun - vaikka koko homma on kehitetty julkisessa hankinnassa kilpailutetussa projektissa, jonka hinta ylitti markkinahinnan moninkertaisesti. Ihan vaan koska sun yrityksellä sattui olemaan paras osaaminen vuosikymmenten takaa tehdyistä ATK-hankkeista. Apitalisti otti verorahoilla tehdyn projektin hyödyt ja loi siitä jotain entistä parempaa - mobiilisovelluksen tai peräti sellaisen botin feisbuukkiin. Ja nyt tuota tietoa käytetään digitaaliseen liiketoimintaan, tarjousten laskemiseen ja se on visualisoitu niin hienosti, että siitä tämä riistäjä pyytää jopa rahaa.Pahimpia ovat ne yksilöt, jotka yhdistävät tietoa eri lähteistä ja rikastavat sitä - ja samalla toki itseään! Nämä ovat niitä niin kutsuttuja innovaatioita, joita ennen tätä nykyaikaa pystyttiin välttelemään kuin ruttoa.

3. Se tuputtaa sullekin ajatuksiaan

Hännän huipuksi tämä kaveri toimii kuin sanansaattaja ja alkaa pikkuhiljaa syöttämään samoja ajatuksia myös sulle. Se sanoo, että voisitkin itseasiassa saada enemmän liiketoimintaa ja sitoutuneempia asiakkaita, jos vähän nostaisit rajapinnan helmaa ja päästäisit muutkin sinne tutkimaan. Keskusteluissa alkaa nopeasti kuulumaan termit kuten avoin lähdekoodi, REST, GraphQL, JSON, kontribuutio ja yhdessä kehittäminen. Eikä mene aikaakaan kun huomaat olevasi COSS:n jäsen ja vielä maksavasi siitä. Voitaisko me perua tämä internet ja avoimuus?Jos siis haluat tietää lisää näistä pahiksista, niin otappa meihin yhteyttä - kerrotaan lisää tai hommataan sulle kontakti oikeanlaiseen asiantuntijaan. Meiltä saat myös tulkkausapua ja vertaistukea.Voit myös vakoilla tätä toimintaa mm osoitteessa http://apiops.net, apitalisteista esim. Twitterissä turhankin aktiivisesti viestii mm. Jarkko Moilanen https://twitter.com/kyyberi