Recent Post
Miten Oulun IT-Yritykset hallinnoivat ohjelmistoprojekteja ilman omia kehittäjia?
Eivät kaikki ohjelmistoprojektit ole sama ongelma. Joskus ohjelmistoa tarvitaan nopeasti, mutta yritys ei ole mitään kehittäjiä. Joskus teknistä osaamista voi löytyä, muttasitäei ole tehtävään riittävän pätevä; työ tulisi saada päätökseen lähikuukausien aikana.
Silloinedessä on Käytännössä kaksi eri päätöstä, jotka on helppo sekoittaa keskenään.
Ensimmäinen liittyy ohjelmistoon. Mitä ollaan rakentamassa ja miksi?
Toinen näkökulma liittyy mukana oleviin ihmisiin. Mitä osaamista työn tekeminen vaatii ja kuinka paljon aikaa siihen tarvitaan?
Ei aina jälkimmäinen ole Järkevä ratkaisu uuden vakituisen rekrytoinnin kautta.
Oulussatähän on On myös paikallinen lähtöpiste. Kaupungin ICT-Ekosysteemiin kuuluu ohjelmistoyrityksiä, tutkimusta, tuotekehitys- ja teknologiahankkeet, joten ohjelmistotyötä voidaan järjestää monin eri tavoin – pelkän sisäisen kehitysosaston perustamisen lisäksi.
Oulun yliopiston ohjelmistotuotannon tutkimuksessa tarkastellaan esimerkiksi ohjelmistoarkkitehtuureja ja pilviympäristöjä, IoT-järjestelmät, testaus ja ohjelmistokehitysprosessit.
Mutta Itse hankkeessa näille taustatekijöille ei vielä tehdä mitään.
Jossain vaiheessa tehtäväluettelo on avattava ja päätettävä, kuka työn tekee.
Yksi hanke ei vielä paljasta, millaisen organisaation yritys tarvitsee.
Ohjelmistokehittäjän palkkaamista on helppo perustella, jos kehitystyötä on jatkuvasti. Jos yrityksellä on useita tuotteita ja sen sisäiset järjestelmät vaativat jatkuvaa ylläpitoa sekä uusien ominaisuuksien lisäämistä kuukausitasolla, yrityksen oma kehitystiimi muodostuu luontevaksi osaksi toimintaa.
Ensimmäinen ohjelmistoprojekti voi olla tilanteena täysin erilainen.
Hanke saattaa kestää kahdeksan kuukautta. Sen jälkeen tarvitaan ehkä vain ylläpitoa. Tai järjestelmän ensimmäinen versio valmistuu, mutta seuraava kehitysvaihe ei ole vielä tiedossa.
Rekrytointi kuitenkin toteutetaan helposti ikään kuin työmäärä pysyisi ennallaan.
Näin ei yleensä tapahdu ohjelmistoprojekteissa.
Aluksi tarvitaan aikaa esimerkiksi arkkitehtuurin suunnitteluun ja teknisiin valintoihin. Tämän jälkeen suurin osa työstä voi liittyä käyttöliittymän ja palvelinpuolen komponenttien toteuttamiseen. Kun ensimmäiset ominaisuudet ovat valmiina, painopiste siirtyy integraatioihin, testaukseen ja käyttöoikeuksiin. Julkaisun jälkeen voi ilmaantua aivan toisenlaisia tehtäviä, kuten suorituskyvyn ja lokien analysointia, virheiden korjaamista sekä tuotantoympäristöön tehtäviä muutoksia.
Tarvittava osaaminen liikkuu hankkeen mukana.
Tästä syystä ulkopuolinen kehittäjä ei välttämättä ole merkki siitä, että yritykseltä puuttuisi sisäistä teknistä osaamista; hänet on saatettu ottaa mukaan vain siksi aikaa, kun kyseistä erityisosaamista tarvitaan.
Kehittäjää saatetaan tarvita vain tiettyä osa-aluetta varten.
Yleinen esimerkki on integraatio.
Yritys käyttää jo toiminnanohjausjärjestelmää tai muuta liiketoimintajärjestelmää ja haluaa ottaa sen rinnalle uuden verkkopalvelun. Käyttäjälle kokonaisuus näyttäytyy yhtenä järjestelmänä, mutta taustalla järjestelmien välillä on siirrettävä tietoa.
Käyttöliittymä on suunniteltava. Tiedot on muunnettava oikeaan muotoon. Käyttäjän tunnistaminen on ratkaistava. Virhetilanteet on käsiteltävä. Lisäksi on päätettävä, mitä tapahtuu, jos toinen järjestelmä ei vastaa.
Jos yrityksen oma henkilöstö ymmärtää liiketoimintalogiikan mutta siltä puuttuu osaamista esimerkiksi REST-rajapinnoista, tietoturvasta tai tietyn teknologiapinon toteuttamisesta, projektiin voidaan ottaa mukaan ulkopuolinen kehittäjä.
Hänen ei tarvitse jäädä yritykseen pysyvästi.
Sama pätee olemassa olevan järjestelmän uudistamiseen. Jos vuosia käytössä ollut sovellus toimii yhä, mutta sen rakennetta on vaikea ylläpitää, ensimmäinen askel voi olla nykytilan arviointi. Tähän kuuluu lähdekoodin riippuvuuksien tunnistaminen, tietokantarakenteiden tarkastelu sekä sen selvittäminen – rajapintojen kautta – mitä muut järjestelmät todellisuudessa käyttävät.
Vasta silloin voidaan tehdä päätös siitä, mitä kannattaa tavoitella.
Tällainen vaihe on usein huomattavasti pienempi urakka kuin uuden kehitystiimin rakentaminen.
Ongelmana ei yleensä ole se, mistä kehittäjä löytyy.
Vaikeampi kysymys on, miten ulkopuolinen kehittäjä saadaan mukaan hankkeeseen.
Jos yrityksellä ei vielä ole teknistä tiimiä, sen tulisi pystyä selvittämään ainakin nykyinen ympäristö, tavoitteet ja hankkeen rajaukset ulkopuoliselle toimittajalle.
”Rakennetaan itsellemme uusi palvelu” ei vielä ole kehitystehtävä.
Tarvitaan tietoa siitä, mitä palvelun on tehtävä, mitä olemassa olevia järjestelmiä se käyttää ja miten valmis ratkaisu toteutetaan.
Olemassa olevan ohjelmiston kohdalla tarvitaan myös pääsy asianmukaisiin ympäristöihin sekä pääsy versionhallintaan ja dokumentaatioon. Jos dokumentaatiota ei ole, jonkun on ensin selvitettävä, miten järjestelmä toimii.
Hankkeen omistajalla on merkittävä rooli tässä vaiheessa.
Ulkopuolinen kehittäjä voi hoitaa teknisen toteutuksen, mutta hän ei voi yksin päättää, miten yrityksen liiketoimintaa tulisi harjoittaa. Hän ei myöskään voi tuntea kaikkia niitä käytäntöjä, jotka ovat muotoutuneet yrityksessä vuosien varrella.
Siksi onnistunut yhteistyö ei ala siitä, että kehittäjälle annetaan tehtävälista.
Kaikki alkaa siitä, että molemmat osapuolet tietävät, mitä ollaan muuttamassa.
Oulussa tätä osaamista löytyy monilta tahoilta.
Oulun ohjelmisto- ja teknologiaekosysteemissä on pitkät perinteet työstä, jossa ohjelmistokehitys yhdistetään muun muassa teollisuuteen, langattomaan teknologiaan, terveysteknologiaan ja sulautettuihin järjestelmiin. Oulun yliopistossa ohjelmistokehitys on osa laajempaa teknologista kokonaisuutta.
Tämä on merkittävää silloin, kun yrityksen tarpeet ylittävät tavanomaisen verkkosivuprojektin laajuuden.
Jos järjestelmän on viestittävä tuotantolaitoksen laitteiston kanssa, käsiteltävä suuria määriä tapahtumia tai toimittava välittäjänä useiden taustajärjestelmien välillä, tarvitaan hieman erilaisia taitoja kuin tavallista verkkopalvelua rakennettaessa.
Kaikkea tätä osaamista ei ole välttämätöntä hankkia yritykseen.
Yksi hanke saattaa esimerkiksi edellyttää pilviympäristön rakentamista. Toisessa tarvitaan apua tietokannan suorituskyvyn parantamisessa. Kolmannessa ongelma liittyy testausautomaatioon. Jos tarve on rajallinen, myös yhteistyö voi olla rajattua.
Tämä on yksi syy siihen, miksi kehitystyön ulkoistamista ei tulisi pitää pelkkänä vaihtoehdolle yrityksen sisäiselle kehitystiimille.
Joskus kyse on yksinkertaisesti työn tietystä vaiheesta.
Kun hanke alkaa kasvaa, tilanne muuttuu.
Alkuperäinenkään suunnitelma ei aina pidä.
Pieni sisäinen työkalu voi kehittyä asiakkaiden käyttämäksi palveluksi. Yksittäinen integraatio voi kasvaa järjestelmäksi, joka koostuu useista osista. Ensimmäinen versio saattaa paljastaa tarpeita, joita ei tiedetty hankkeen alussa.
Ulkoisen kehityksen rooli saattaa muuttua.
Aluksi mukana on yksi asiantuntija. Myöhemmin tarvitaan osaamista sekä backend- että frontend-kehityksessä. Jossain vaiheessa yrityksen kannattaa ehkä palkata oma tekninen asiantuntija ottamaan järjestelmästä laajempaa vastuuta.
Tämä lähestymistapa saattaa olla yritykselle helpompi kuin yrittää ennustaa heti alussa, miltä tekninen organisaatio näyttää kolmen vuoden kuluttua.
Omistautunut tiimi voidaan muodostaa, kun jatkuvalle työlle on todellinen tarve.
Hanketta voidaan viedä eteenpäin ulkopuolisen asiantuntemuksen avulla.
Ulkopuolista kehittäjää ei saa jättää tyhjin käsin projektin päättyessä.
Yksi käytännön seikka jää usein liian vähälle huomiolle: mitä tapahtuu, kun ulkopuolinen kehittäjä lähtee?
Jos vastaus on ”seuraava kehittäjä selvittää asian myöhemmin”, hankkeen aikana syntynyt tieto on päätynyt väärään paikkaan.
Lähdekoodi yksinään ei riitä.
On myös ymmärrettävä, miten sovellus rakennetaan ja julkaistaan, missä ympäristössä se toimii, mitä ulkoisia palveluita se hyödyntää sekä järjestelmän riippuvuudet.
Tässä yhteydessä hyödyllisiä ovat automatisoidut testit sekä versionhallinta, selkeä CI/CD-putki ja riittävä tekninen dokumentaatio. Kun ympäristö on dokumentoitu ja käyttöönottoprosessi on toistettavissa ilman riippuvuutta yksittäisen henkilön muistista, tehtävän seuraavaksi ottavan henkilön ei tarvitse aloittaa alusta.
Tämäkin on sellainen asia, jossa ulkoistetun kehitystyön laatu käy ilmi vasta myöhemmin.
Valmis ominaisuus voidaan ottaa tuotantoon nopeasti. Sen todellinen arvo paljastuu vasta, kun joku muu joutuu muokkaamaan sitä kuuden kuukauden kuluttua.
Juuri silloin hankkeen jäljellä oleva osuus ratkaisee lopputuloksen.
Ei ainoastaan ohjelmakoodi, vaan myös rakenne, testit, päätökset ja järjestelmän ylläpitoon tarvittava tieto.
Oululaiselle IT-yritykselle ulkopuolisen kehittäjän hyödyntäminen on yksi mahdollinen tapa järjestää työ. Kaikkea teknistä osaamista ei ole välttämätöntä pitää jatkuvasti organisaation sisällä; tärkeämpää on tietää, mitkä työtehtävät ovat jatkuvaluonteisia ja mitkä liittyvät vain tiettyyn projektiin.
Kun tämä ero on selvä, myös päätös yrityksen sisäisestä rekrytoinnista muuttuu huomattavasti konkreettisemmaksi.