projektin aloitus

Aloitan nyt uuden blogikirjoitusten sarjan, jossa esittelen omaa sisäistä kehitysprojektiani. Tarkoituksena on toisaalta esitellä työskentelytapojani sekä asioita, joita osaan tehdä, mutta myös esitellä uudenlaisia ideoita liittyen digitaalisten järjestelmien kehittämiseen.

Tavoitteena on rakentaa oppiva datan analysointijärjestelmä, jota voisi käyttää erilaisilla laitteilla ja myös verkkoselaimessa. Lyhyellä tähtäimellä sen on tarkoitus olla pienimuotoinen referenssiprojekti, jolla voisi esitellä ja kokeilla erilaisia ideoita, mutta keskipitkällä aikavälillä toivoisin voivani kehittää sen pohjalta suoraan asiakkaille markkinoitavan tuotteen. Tämä tietysti edellyttäisi yrityksen laajentamista tai sopivien yhteistyökumppanien löytämistä. Tekniikka on kuitenkin kehittynyt niin pitkälle, että prototyypin pystyy rakentamaan yksinäänkin.

Käynnistän projektin yleensä jonkinlaisella selvitysvaiheella, jossa tutkin millaisia tekniikoita ja työkaluja tarvitaan halutun lopputuloksen saavuttamiseksi. Tässä vaiheessa yleensä myös teen kokeiluja ja rakentelen nopeita prototyyppejä saadakseni käytännön tuntumaa ideoihini. En takerru sellaisiin työkaluihin ja tekniikoihin, jotka tunnen jo valmiiksi, vaan yritän selvittää sopivimmat vaihtoehdot, koska en pelkää uusien asioiden opettelua. Joitakin rajoitteita täytyy kuitenkin asettaa, jotta päästään liikkeelle ripeästi. Kaikkea ei kannata tehdä täysin uusilla työkaluilla.

Tärkeimmät rajoitteet tässä projektissa tulevat siitä, että haluan käyttää funktio-ohjelmointia ja graafitietokantoja dataa käsittelevissä ydinmoduuleissa. Kirjoitan näistä aiheista lisää myöhemmin, mutta näihin päätöksiin vaikuttavat omat kokemukseni siitä, että funktio-ohjelmoinnilla saa tehtyä vaativia algoritmillisia asioita hallittavammin ja nopeammin kuin perinteisemmillä ohjelmointikielillä. Käyttämäni menetelmät puolestaan ovat graafipohjaisia, ja käsiteltävä data on hyvin monimuotoista, joten graafitietokannat tekevät datan käsittelystä luontevampaa ja helpompaa.

Projektiin täytyy ilmiselvästi kuulua palvelinkomponentteja, jotta samaa dataa voidaan käyttää useilla laitteilla ja verkkoselaimilla. En halua käyttää aikaa laitteiden kanssa tappelemiseen, joten vuokrattavat pilvipalvelimet ovat helppo ratkaisu. Haluan myös käyttää Suomessa sijaitsevia palvelimia, ja palvelun täytyy olla skaalautuva jotta laajentuminen on mahdollista tulevaisuudessa. Koska työskentelen yksin, haluan käyttää mahdollisimman paljon valmiita, toimiviksi todettuja moduuleita. Tämän vuoksi pilvialustan täytyy tukea Dockeria, joka mahdollistaa tällaisten valmiiksi paketoitujen modulaaristen palikoiden helpon käyttöönoton.

Näillä perusteilla alustava projektiympäristö on hahmottunut seuraavasti: pilvipalvelinten tarjoajaksi valikoitui kotimainen Nebula. Heiltä saan skaalautuvat OpenStack-palvelimet valmiilla Docker-tuella. Graafitietokannaksi on valikoitunut neo4j, koska siinä on hyvä skaalautuvuus tulevaisuutta ajatellen, valmiita rajapintoja useisiin työkaluihin sekä valmis Docker-paketti. Vakuutuin myös siitä, millä tavalla itse graafitietokanta on rakennettu, mutta tästä lisää myöhemmin. Palvelinpuolen ohjelmointia teen alkuun Haskellilla ja Yesodilla, koska ne ovat minulle tuttuja ja niillä pääsen nopeasti liikkeelle. Tuotantokäyttöön tulevia sovelluksia varten on kuitenkin löydettävä kypsemmät työkalut, ja alustavasti olen aikonut tutkia Scala-ohjelmointikieltä ja Apache Sparkia, mutta selvitän muitakin vaihtoehtoja. Selaimen puolella haluan pitäytyä mahdollisimman kevyissä ratkaisuissa, ja minulle tutuista työkaluista Bootstrap ja jQuery ovat tällä hetkellä vahvimpia. Työpöytä- ja mobiilisovellusten kanssa en halua käyttää liikaa aikaa, joten Qt ja Android ovat tuttuina ja yleisinä ympäristöinä luonteva valinta.

Seuraava vaihe on se, että pystytän palvelimelle neo4j-tietokannan ja teen kevyen prototyyppisovelluksen, jolla pystyn selaamaan tietokantaa ja tekemään siihen pieniä muutoksia. Raportoin edistymisestä ensi viikolla, ja samalla käyn läpi mietteitäni graafitietokannoista yleisesti.

ohjelmistojen pientuottajan bisnesmallista

Viime viikon aikana tapasin lukuisia ihmisiä ja keskustelin liikeideastani sekä tarjoamistani palveluista. Tämä oli hyvin hyödyllistä, sillä jouduin terävöittämään viestiäni ja ottamaan huomioon monenlaisia ohjelmistobisneksen realiteetteja. Ensimmäisen toimintakuukauteni lopuksi päätin kirjoitella hieman ajatuksiani bisnesmallistani.

Toimintaani voisi kutsua konsultoinniksi tai alihankinnaksi. Näillä sanoilla on hieman negatiivinen kaiku, ja ne liitetään yleensä suurempiin organisaatioihin, joten yksittäisen tekijän organisaationa haluaisin mieluiten puhua ohjelmistojen ja ohjelmistotyön tuottamisesta. Keskeisimpiä kilpailijoita minulle ovat yritysten omat työntekijät, kun taas alihankintaa tekevät yritykset ovat potentiaalisia yhteistyökumppaneita, joiden kanssa voidaan toteuttaa suurempia tuotantoja. Liiketoimintani on ohjelmistojen ja niiden komponenttien tuottamiseen osallistumista.

Keskeinen realiteetti ohjelmistoalalla on se, että osaaville tekijöille on kova tarve ja heitä on hidasta rekrytoida. Siinä mielessä alihankinnalla voitaisiin saavuttaa joustavuutta. Yritykset kuitenkin haluaisivat ensisijaisesti vahvistaa omaa tiimiään ja palkata vakituisia työntekijöitä. Kasvaville yrityksille henkilöstön määrä on tärkeä mittari, toisaalta osaaminen halutaan pitää omassa hallinnassa ja työvoiman on oltava käytettävissä ennakoitavasti.

Ohjelmistotyön ostaminen on monella tapaa ongelmallista. Tekijöiden kyvyt vaihtelevat suuresti, ja tiettyyn tehtävään kuluvaa aikaa olisi vaikea arvioida vaikka tekijät olisivatkin samanlaisia. Työn edistymistä ja valmiusastetta on vaikea arvioida ja seurata. Varsinkin aivan uudenlaisten asioiden kehittäminen on riskialtista. Ryhtyessään alihankintaprojektiin ostajan on selvitettävä itselleen, millaista rahallista riskiä on valmis sietämään, ja seurattava työn edistymistä sekä onnistumismahdollisuuksia tiiviisti. Toimittajan on tietysti omalta osaltaan sitouduttava toimimaan eettisesti ja vastuullisesti. Työn edistymisestä ja käytetystä ajasta on annettava tietoa mahdollisimman läpinäkyvästi.

Ohjelmistoalan pitäisi vielä kypsyä; pitäisi toisaalta oppia ostamaan palveluita ja hallitsemaan useiden toimittajien projekteja. Toisaalta ohjelmistoja pitäisi oppia tekemään hallitusti, ennustettavasti ja seurattavasti, yhteistyössä useiden toimijoiden kesken. Uuden sovelluksen kehitystyötä kannattaisi tehdä ketterästi, ylläpitäen jatkuvasti toimivaa prototyyppiä ja lisäämällä siihen toiminnallisuuksia looginen pala kerrallaan. Toteutettuja osia pitää luonnollisesti testata jatkuvasti, sekä yhdessä että erikseen. Yhteiset toimintatavat auttavat, ja yhtenäisillä sopimuskäytännöillä voidaan edistää näiden määrittämistä. Olen itse ottanut käyttöön IT2015-sopimusehdot, joista saa hyvän pohjan myös käytännön toimintatapojen organisoinnille.

Ohjelmistotyön ostaminen on helpompaa, jos ostaja tietää tarkasti mitä pitää tehdä ja miten vaativaa se on. Tämä auttaa ostajaa määrittämään työn arvon. Itse haluaisin pyrkiä arvoperusteiseen hinnoitteluun, jossa hinta määräytyisi sen mukaan mikä on lopputuloksen arvo ostajalle. Vaikka arvo olisi helppo määritellä, on edelleen haasteena valita sopiva toimittaja työlle, sillä pitäisi tuntea toimittajan kyvyt. Tämän vuoksi tarvitaan verkosto toimittajia, joiden kyvyistä saadaan käsitys useiden lyhyiden toimeksiantojen perusteella. Tämä vaatii tietysti paljon vaivannäköä ja perehtymistä. Vakituisen oman henkilöstön palkkaaminen tuntuu turvallisemmalta vaihtoehdolta. Kuinka moni työnantaja kuitenkaan tietää omienkaan työntekijöidensä kyvyt riittävällä tarkkuudella? Olisiko hyvä tietää?

Jatkan edelleen bisnesmallini pohdintaa, ja erityisesti toimintatavoista ja sopimuskäytännöistä minulla on vielä paljon sanomista.