Etätöissä Japanissa

Kun syys–lokakuussa huomasimme parin kaverini kanssa, että lennot Japaniin olivat pienessä alennuksessa, päätimme tutkia olisiko mahdollista lähteä sinne porukalla. Olen melko uusi työntekijä Codentolla ja erityisesti tuolloin olin vielä upouusi työntekijä. Tiesin että mahdollisuus lähteä Japaniin olisi joko palkaton reissu tai etätyö.

Codentolla kerrottiin jo hakuprosessin alkuaskeleilla, että mahdollisuuksien mukaan etätyöt myös muualla kuin Suomessa onnistuvat. Päätinkin ottaa Japanin-reissun osalta selvää, kuinka sellainen onnistuisi omalla kohdallani. Codenton etähommissa ei tehdä lainkaan firman omia asioita edistäviä töitä, vaan konsultti keskittyy pelkästään asiakasprojektin edistämiseen. Näin tuetaan asiakkaan tavoitteita sekä edesautetaan asiakkaan mahdollisuutta antaa konsultille lupa lähteä pidemmällekin reissulle etätöihin. Lisäksi yrityksenä ja yksittäisinä konsultteina pyrimme siihen, että hommat tulee tehtyä parhaalla mahdollisella tavalla, olipa konsultti sitten tekemässä töitä missä suunnalla palloa tahansa.

Alkuvalmisteluja ennen matkaa

Keskustelin aluksi toimarimme Petrin kanssa, josko voisin tehdä etähommia matkan aikana. Sain Petriltä siunauksen sillä ehdolla, että myös asiakkaalta tulee vihreää valoa. Meillä Codentolla tehdään pääasiassa asiakasprojekteja, siksi hommia tehdään aina asiakkaan aikataulun mukaan. Seuraavaksi juttelin asiakasprojektin vetäjän kanssa mahdollisesta etätyöstä, kerroin myös että saatan tehdä vajaita päiviä etänä. Projektin vetäjä ei edes epäröinyt vaan lupa tuli saman tien kuin apteekin hyllyltä osaksi varmasti siitä syystä, että luottoa minuun löytyy, mutta myös siksi että luottoa Codentoon löytyy.

Etätyöt matkan suunnittelussa keskiössä

Aloimme suunnittelemaan matkaa hyvissä mielin sekä varasimme lennot. Matkasuunnitelmaa muodosteltiin ja hiottiin, korjailtiin ja muutettiin aikataulujen ja muiden asioiden mukaan. Suunnitteluun kuului oleellisena osana myös etätyöt. Hommat ulkomailla saa varmemmin tehtyä, jos se ei estä näkemästä asioita, joita haluan nähdä. Keskustelin myös muiden codentolaisten kanssa etätöistä ulkomailla, ja parhaaksi vaihtoehdoksi muodostui tehdä osa-aikaisia työpäiviä. Lähempänä lähtöpäivää muistuttelin asiakasta sekä projektityökavereitani lähdöstäni ja osa-aikaisesta työpanoksestani. Muistuttelin ihmisiä myös Codentolla, jotta kukaan ei ihmettelisi missä olen. Sovin meidän markkinointivastaavan Eevan kanssa, että kirjoittelisin blogin kokemuksestani, sekä etätyöstä. Lupasin myös hienoja matkakuvia. Juttelin asiakkaan kanssa vielä tarkemmin työtavoista ja olin valmis lähtemään matkoille.

Ja täällä ollaan!

Olen nyt Japanissa, ja teen noin 2–5 tuntia töitä per päivä. Joka päivä olen ollut yhteyksissä asiakasprojektin tiimiin tavalla tai toisella. Töitä on tullut tehtyä junassa, lentokoneessa, rannalla, hotellissa sekä kahvilassa – sopiva paikka on aina löytynyt tosi hyvin. On ollut mukavaa tehdä välillä omissa oloissa töitä. Vaikka yhteydet internettiin ovat välillä olleet mitä ovat, ja joskus projektin tekeminen on ollut hankalaa, niin haasteista huolimatta on projektissa päästy eteenpäin sovitussa aikataulussa.

Kaiken kaikkiaan kokemus on ollut mahtava ja siitä suurin kiitos Japanille. Mahdollisuudesta tehdä matka ja etätöitä iso kiitos niin asiakkaalle kuin Codentollekin!

Katso Codenton avoimet työpaikat

Vauhtia fronttiin Vuella

Aloitin tammikuussa Codentolla uutena työntekijänä, ja ensimmäisten viikkojen aikana pääsin mukaan mielenkiintoiseen sisäiseen projektiin, jossa tarkoituksena oli tuottaa nopeasti prototyyppi avoimia rajapintoja hyödyntävästä business casesta. Vaikka tällä alalla uuden oppiminen ja uusiin teknologioihin tutustuminen on jatkuvaa, ensivilkaisulla projektin palvelinpuoli näytti silti mukavan tutulta: käytetyt backend-teknologiat olivat Node.js ja Express. Suorastaan ydinmukavuusaluetta!

Käyttöliittymässä tulikin sitten vastaan Javascript-framework, josta en ennalta tiennyt mitään muuta kuin nimen: Vue.js. Se lupaa olevansa progressiivinen, asteittain käyttöönotettava framework reaktiivisten käyttöliittymien rakentamiseen. Tämä tarkoittaa, että Vue integroituu helposti olemassaolevaan web-sovellukseen pala kerrallaan. Esimerkiksi Gitlab on kirjoittanut paljon omista hyvistä kokemuksistaan Vuen käyttöönotossa.

On tosin huomattava, että tämä siirtymä tapahtui melko vanhanaikaisesta, puhtaasti JQueryllä toteutetusta sovelluksesta nykyaikaiseen frameworkiin, ja tässä kohtaa mikä tahansa ratkaisu olisi tarjonnut merkittäviä parannuksia. Heidän tapauksessaan valinta osui silti Vueen – paljolti niistä syistä, jotka ovat olleet sen suosion takana laajemminkin: yksinkertaisuus ja helppokäyttöisyys. Viimeisimmän State of Javascript -raportin mukaan Vuen suosio vaikuttaisikin olevan selkeässä kasvussa.

Usein kehittäjien keskusteluissa Vue vertautuu ennen kaikkea Facebookin tukemaan Reactiin. Vue ja React ovat osapuilleen saman ikäisiä, ja niissä molemmissa tieto liikkuu sovelluksen sisällä esimerkiksi AngularJS:ää kurinalaisemmin. Reactin tapaan Vue käyttää virtuaalista dokumenttipuuta, joka mahdollistaa paljon sujuvamman käyttökokemuksen laajoissa webbisovelluksissa. Vue onkin ominaisuuksiltaan riittävän samankaltainen suhteessa Reactiin, että teknologiavertailu menisi tämän tekstin laajuudessa liian pikkutarkaksi, joten vertaillaan mielummin sitä miltä työkalu tuntuu käteen ja millainen tuntuma sen käytöstä on jäänyt – eli toisin sanoen keskittykäämme kiistelemään makuasioista.

Templatointi tuntuu olevan mielipiteitä jakava kysymys. Vuen tapa käyttää templatointia on hyvin selkeä ja johdonmukainen: .vue-komponentti rakentuu templatesta, ohjelmakoodista ja valinnaisista muotoilumäärittelyistä, jotka ovat kaikki samassa tiedostossa, ja jotka hyvin rakennettuina pystyy hahmottamaan yhdellä vilkaisulla. Vuen templatointikieli tuskin on kenellekään kehittäjälle vaikeaa opetella, koska Vue kehittää eteenpäin monia aiempien ratkaisujen hyviä puolia.

Vue on tällä hetkellä Reactiin verrattuna pitkälti yhden ihmisen projekti. Tästä huolimatta kirjastotuki alkaa olla tuotantokäyttöön riittävä, ja projekti tarjoaa omasta puolestaan useita oleellisimpia peruskirjastoja, kuten esimerkiksi monista muista kirjastoista ja frameworkeista tutut router- ja store-kirjastot. Vuessa vetoaa ennen kaikkea se, miten nopeasti prototyyppejä saa luotua, ja miten helppoa prototyypistä on kasvattaa toimivia webappeja. Sisäisessä projektissamme sekä uuden teknologian haltuunotto että prototyypin tekeminen sujui tuskin paljon viikkoa pidemmässä ajassa, ja kokemukset maailmalta kertovat, että prototyypin jalostaminen tuotantokypsäksi tuotteeksi onnistuu Vuella myös varsin ketterästi.

Tiivistetysti sanottuna Vue tuntuu ennen kaikkea kustannustehokkaalta vaihtoehdolta. Näkymistä ja komponenteista on helppo rakentaa selkeitä ja yksinkertaisia hahmottaa. Projektiin ei välttämättä tarvitse etsiä spesifisti Vue-kehittäjiä, kun oppimiskynnys on kenelle tahansa matala. React jatkaa varmasti ansaitusti menestyksekästä taivaltaan käyttöliittymäteknologiana Vuen suosion kasvusta huolimatta, eli “Reactin tappajaa” Vuesta ei tule löytymään. On silti aina eduksi, että hyviä ja keskenään erilaisia vaihtoehtoja on useita. Siili järjestää 21.3. tietääkseni Suomen ensimmäisen Vue.js -tapaamisen – kuhinaa Vuen ympärillä on siis jo meillä Suomessakin.

 

PS Jos olet kiinnostunut Vuesta, on meillä tilaa osaajille! Täältä pääset hakemaan.

Arvoketjukartta hahmottelee toimintaympäristösi – ja visioi herkullisemman tulevaisuuden

Teimme budjetoinnin ja projektien arvioinnin tueksi lean-projektikartan. Olemme nyt käyneet usean asiakkaan kanssa keskusteluja siitä, miten lean-projektikartta auttaa heitä ja miten sitä voi hyödyntää tekemisen suunnittelussa. Vaikka lean-projektikartta on yksinkertainen täyttää, tarvittavat päätökset eivät aina ole itsestään selviä. Useamman kerran olemme päätyneet keskustelemaan siitä, millä perusteilla pitäisi painottaa toiminnan ylläpitoa tai milloin pitäisi tehdä mullistavaa kokeilua asiakkaan kanssa. Kysymyksiin vastaamiseen tarvitaan kaksi asiaa: 1) Missä tilanteessa ollaan nyt ja 2) Mihin tilanteeseen toivotaan päästävän.

Vastaukset eivät selviä täyttämällä lean-projektikarttaa. Tarvitaan näkemystä toimintaympäristöstä yli ajan – tarvitaan visio.
– Toimiva visio johdattaa organisaatiota kohti haluttua tilaa ja auttaa linjaamaan päivittäiset ratkaisut pitkän ajan tavoitteeseen
– Päivittäisessä työssä auttavan vision pitää olla ymmärrettävä, sitä kohti pitää voida edetä ja sen pitää olla motivoiva

Toimintaympäristön kokonaisvaltaisen ymmärtämisen kautta muodostettu tahtotila organisaation paikasta toimintaympäristössä on tukeva pohja visiolle. Kun vielä ymmärretään organisaation kyvykkyys vaikuttaa omaan positioonsa toimintaympäristössä, ollaan jo hyvän vision jäljillä.

Me Codentolla olemme käyttäneet muun muassa Simon Wardleyn arvoketjukarttaa, kun fasilitoimme toimintaympäristön kuvaamista. Tämä malli on tehokas väline kiinnittämään keskustelu yhteiseen viitekehykseen ja luomaan yli keskustelutilanteiden kantava ja asteittain yhä tarkentuva malli toimintaympäristöstä. Wardley map eli arvoketjukartta esittää asiakkaan keskiössä. Asiakas näkee käyttämänsä palvelun muodostavasta arvoketjusta lähinnä itseään olevat osat. Asiakasta ei yleensä suuremmin kiinnosta, millä alustalla palvelu pyörii tai miten palvelu on varmistanut internet-yhteytensä tai sähkönsaantinsa – palveluntarjoajalle tämä on kriittistä tietoa.

Jos liiketoimintasi on tuottaa asiakkaillesi välitöntä nautintoa vaikkapa ketterällä macaron-keksien toimituspalvelulla, sinun kannattaa miettiä hyvin tarkkaan miten palvelua tuotat nyt ja jatkossa. Siinä missä teknologian hype-sykli kuvaa yksittäisten teknologioiden kypsymistä yli ajan, Wardley map auttaa ymmärtämään sitä toimintaympäristöä, jossa organisaatio toimii nyt ja yli ajan. Siksipä arvoketjukartassa organisaation arvontuottoketjun kannalta olennaiset toimijat kuten esimerkiksi kilpailijat, toimittajat ja jakelijat kuvataan yhteen kuvaan. Samalla arvioidaan, millä tahdilla ne ovat kypsymässä uutuudesta massahyödykkeeksi. Lisäksi mietitään, mihin omaa organisaatiota kannattaisi toimintaympäristössä luotsata. Mikä olisi sen visio.

Saattaa olla että ketterä macaron-keksien toimituspalvelu menestyy juuri nyt hyvin – mutta jatkoa suunniteltaessa on vaarallista katsoa sitä mitä tapahtuu juuri nyt. Asiakkaasi sanovat, että haluavat makuja mielialansa mukaan. Lähdetkö toteuttamaan toivetta upouutta tilausdrone-konseptia kehittämällä vai pelaatko korttisi niin, että olet ensimmäisten joukossa käyttämässä Amazonin tarjoamaa “välittömästi mitä vain” -alustaa? Molemmat voivat olla voittava käsi, mutta onko organisaatiollasi varaa tehdä molemmat? Ja jos ei, millä kriteerillä valitset? Arvoketjukartta auttaa hahmottamaan tulevaisuuden menestysvisiot.

Jos haluat sparrausta, ota yhteyttä! miika.kuha@codento.com

 

 

Ketterän hankinnan trendit

Ketterä hankinta on teema, josta käydään innokkaasti keskustelua – mutta mitä se oikeastaan tarkoittaa? Suomessa ketterällä hankinnalla viitataan tällä hetkellä yleisimmin kolmeen asiaan: 1. Kokeilujen tai protojen hankinta, 2. Määritellyn pienimmän julkaistavan tuotteen (MVP) hankinta + iteratiivinen jatkokehitys ja 3. Resurssien ostaminen itse johdettavaksi. Suomessa vaihtoehdoista suosituin on tällä hetkellä numero 3 eli resurssien ostaminen itse johdettavaksi. 

Trendinä resurssien ostaminen

Kun resurssit ostetaan itse johdettavaksi, ei siis osteta ohjelmistoa tai lopputulosta, vaan hankitaan ohjelmistokehityksen ammattilaiset omaan ohjaukseen työskentelemään kohti parasta mahdollista lopputulosta. Tähän houkuttelee ohjelmistoalan ympärillä kuhiseva tekemisen into ja halu saada aikaan jotakin omaa.

Resurssiprojektit päättyvät vaihtelevin lopputuloksin. Onnellisimmissa tapauksissa tuloksena on intoa piukassa oleva kehitystiimi ja asiakkaat ennennäkemättömän tyytyväiseksi tekevä palvelu. Masentavammissa tapauksissa juututaan vuosiksi ankeaan junnaukseen: tekemistä tuntuu olevan aivan liikaa ja lopputuotteesta tuntuu tulevan vaikeasti hallittava jouluhimmeli.

Miten ketterässä hankinnassa onnistuu?

Millä sitten voi huolehtia siitä, että pääsee onnelliseen onnistujien joukkoon ja ehkä pokkaamaan palkintopokaalinkin softa-alan gaalassa? Varmistettavia asioita on viisi.

1. Läpinäkyvyys. Läpinäkyvyys on ketterän hankinnan tärkein riskienhallintakeino. Huolehdi, että se otetaan vakavasti kaikilla tasoilla. Sisällytä sopimukseen koodin tallentaminen säännöllisesti versionhallintaan. Etsi mittarit, joiden pohjalta projektissa syntyvää (asiakas)arvoa pystytään seuraamaan jatkuvasti. Ja kun olet löytänyt tiimiisi ohjelmistokehityksen kirkkaimmat tähdet, huolehdi läpinäkyvyydellä ja aktiivisella kommunikoinnilla, että heillä on käytössään tieto, jota projektin tavoitteiden saavuttamiseksi tarvitaan.

2. Visionhallinta. Ketterässä projektissa visionhallinta on muutokseen reagoimista, sillä ketteryyden etu tulee kyvystä hyödyntää projektin varrella löydetyt oivallukset. Huolehdi siis, että on olemassa hyvä tapa hankkia käyttäjäpalautetta ja reagoida siihen. Vie priorisoinnin ajatus äärimmilleen: millaisia ovat ne 20 %:n ratkaisut, jotka täyttävät 80 % tarpeesta? Kun niitä löytyy, jää maksimaalisen paljon aikaa palvelun jalostamiseen käyttäjäpalautteen perusteella ja ketteryydestä saadaan irti oikeaa hyötyä.

3. Vastuun ottaminen teknologiavisiosta. Teknologiapäätösten jättäminen kokonaan tiimille johtaa pahimmillaan ylläpito-ongelmiin. Kehittäjät ymmärrettävästi haluavat työskennellä kiinnostavimmilla uusimmilla teknologioilla – ongelmana vain on, että niille ei välttämättä vielä löydy erityisen paljon tukea tai ne voivat jäädä tähdenlennoiksi. Viisaalla ketterällä ostajalla on tukenaan teknologiaa valittaessa joko selvitys markkinatilanteesta tai toinen mielipide, jolla ei ole omaa lehmää projektin ojassa. Niiden avulla kehittäjien mielipiteet loksahtavat osaksi isompaa kuvaa.

4. MVP-budjetointi. Julkaisemalla startup-termein pienimmän julkaistavissa olevan tuotteen (minimum viable product) mahdollisimman aikaisin varmistat, että ketteryydelle eli toiveisiin vastaamiselle jää oikeasti projektissa aikaa. Jos 90 % budjetista käytetään projektin ensimmäisenä päivänä listattuun toiminnallisuuteen, olisit yhtä hyvin voinut ostaa tuotteen toimittajan riskillä ja säästää hermojasi ja resurssejasi. Jos taas pienin julkaistava tuote saadaan julkaistua jo 50 %:n kohdalla budjetista, loppuaika saadaan käytettyä jalostamiseen palautteen pohjalta, ja käyttäjistäsi tulee paljon tyytyväisempiä kuin he olisivat ikinä olleet perinteisellä tavalla tuotetun tuotteen kanssa.

5. Vastuu yhteistyön johtamisesta. Vaikka tiimisi ohjelmistokehittäjät olisivat kuinka lahjakkaita, huono vuorovaikutus pilaa työtehon projektissa kuin projektissa. Testaa siis yhteistyötaidot hankinnan aikana vaikkapa päivän mittaisella koodausleirillä. Varmista, että projektiasi päivittäin johtava tuoteomistaja on vähintään yhtä kokenut kuin kehittäjäsi. Huolehdi, että jatkuvan oppimisen ideaa noudatetaan projektin arjessa ihan käytännössä, vaikkapa retrospektiivien muodossa. Se on ketterä kilpailuetu, josta ei kannata vapaaehtoisesti luopua.

Oletko valmis ketterään hankintaan?

Loppuun ketteryyskonsultin antimainos: Ketterien resurssien ostaminen itse johdettavaksi pitäisi olla aina viimeinen vaihtoehto. Siihen pitäisi päätyä vasta, kun on huolellisen pohdinnan jälkeen todettu, että projektin tuotevisio on niin eksoottinen tai edistyksellinen, ettei sen vaatimuksia mitenkään pystytä muokkaamaan vastaamaan markkinoilla olevaa SaaS-ratkaisua tai valmistuotetta.

Resurssipohjaisen kehityksen ohjaaminen menestykseen vaatii ostavalta organisaatiolta paljon visiota ja energiaa. Molemmat ovat kallisarvoisia voimavaroja, joita ei kannata tuhlata toissijaisiin projekteihin.

Kun tämä varmistus on tehty, ohjelmiston visiolakana on hyvä mittari siitä, oletko valmis ketterään ostokseen. Jos lakanan tiedot on helppo täyttää, kotiläksyt on tehty.

Onnea projektiin (muista myös valmistella se gaalapuhe)!

Voimmeko auttaa?

Ota ketterän hankinnan kysymyksissä yhteyttä joko allekirjoittaneeseen karoliina.luoto@codento.com tai toimitusjohtajaamme petri.aukia@codento.com

Lisää SlideSharessa

Yksityiskohtaisemmin ketterän hankinnan teemoja käsittelee Slideshare-esitys Projektipäiviltä.

 

CV-talkoot kerran kuussa?

Digiperiaate lupaa pyytää tietoa vain kerran

Valtionvarainministeriön kuudes digitalisoinnin periaate sanoo: “Pyydämme uutta tietoa vain kerran.” Tiukasti ja kirjaimellisesti tulkittuna periaate tarkoittaa, että kun jokin julkisen hallinnon osa on kerran pyytänyt – ja saanut – jonkin tiedon kansalaiselta, tieto on kaikkien muidenkin julkisen hallinnon osien käytössä. Tietojen siirto voi olla automaattista, vaikkapa kansallisen palveluväylän kautta, tai viranomaiset voivat kansalaisen tietämättä siirtää tietoja toisilleen esimerkiksi paperilomakkein ja telafaksein. Kansalaista valtio lupaa vaivata kunkin tiedon osalta vain kerran.

Valtionhallinnolle paljon työtä tekevänä konsulttina olen hyvin innostunut digitalisoinnin kuudennesta periaatteesta. Konsulttina näet joudun usein vastaamaan julkisen hallinnon tarjouspyyntöihin – hankintalain mukaan suoraan ei sovi ostaa vaikka puitesopimus olisi voimassa. Olisi suurenmoista, jos kerran julkishallinnolle antamani CV-tietoni olisivat jatkossa julkishallinnon käytettävissä seuraavissakin kilpailutuksissa. Näin ei kuitenkaan ole.

Turhaa työtä jokaisesta kilpailutuksesta

Julkisen hallinnon tarjouspyynnöt ovat kaikki erilaisia. Tarjouspyynnön kohteen erilaisuus on tietenkin luonnollista, sillä eihän samaa työtä ole tarpeen eikä syytä tehdä kahteen kertaan. Konsultin kannalta harmillista on, että aivan jokainen julkishallinnon laatima tarjouspyyntö vaatii jokaisen konsultin CV- ja osaamistiedot uudestaan ja joka kerta erilaiseen ja eri formaatissa olevaan dokumenttiin täytettynä. Tästä seuraa loputon määrä ylimääräistä työtä sekä julkishallinnossa että konsulttifirmoissa. Julkishallinto joutuu joka kerta laatimaan uudet lomakkeet ja manuaalisesti käsittelemään lomakkeilla saamansa tiedot. Konsultit joutuvat täyttämään tietonsa moneen kertaan – vaikkei yksittäisen konsultin työhistoria muutu kilpailutuksesta toiseen.

Kuinka suuresta työmäärästä on kyse? Arvioidaanpa työmäärää erään viimeaikaisen kilpailutuksen perusteella. Tarjouspyyntöön vastataksemme meidän piti täyttää kolmeen kertaan samat tiedot kunkin tarjoamamme konsultin työhistoriasta. Yhteensä saimme aikaiseksi yli 200 sivua taulukkoja Word-muodossa. Meillä tähän meni varmaankin 25 työpäivää. Vastaanottajalla, kilpailutuksen järjestäjällä, menee varmasti useita kymmeniä työpäiviä meidän ja muiden kilpailutukseen osallistuvien konsulttifirmojen toimittamien yhteensä tuhansien sivujen läpikäyntiin, manuaaliseen pisteytykseen ja päätöksen tekemiseen ja perustelemiseen.

Tämän yhden kilpailutuksen työmäärä on siis tarjoajien puolelta satoja työpäiviä ja kilpailuttajan puolelta vähintäänkin kymmeniä työpäiviä. Tämän kilpailutuksen jälkeen nyt tehty työ on arvontonta, koska tällä kertaa kerätyt tiedot ovat formaatiltaan vääriä seuraavassa kilpailutuksessa. Tietojen sisältö on tosin oikein.

Tuottavuusloikka Suomen digitalisointiin

Voisiko tämän tehdä jotenkin helpommin? Olisiko mahdollista rakentaan LinkedInin tapainen konsulttitietopankki, jonne konsultit syöttäisivät CV-tietonsa ja osaamisensa ja josta valtionhallinnon – ja ehkä jopa kuntienkin – kilpailuttajat kävisivät tiedot hakemassa, tarkistamassa ja pisteyttämässä?

Voisipa hyvinkin olla. EU:ssa tällainen jo onkin: Europass. Se ei aivan sellaisenaan sovi Suomen konsulttikilpailutuksiin, mutta muutaman kuukauden kehitystyöllä siitä saisi riittävän hyvän aikaiseksi.

Kelpaisikohan tämä pieneksi tuottavuusloikaksi maamme digitalisointitalkoisiin? Kuka tarttuisi toimeen? Kuka kilpailuttaisi suunnittelu- ja toteutustyön? Hanke on triviaalisti kannattava.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.