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

Mitä Hackathonista voi oppia? Case StreetReboot  

StreetReboot: mikä, miksi, mitä ja miten?

Osallistuimme IndustryHackin järjestämään StreetReboot Hackathoniin. Hackathon on muutaman viikon ja loppurutistuspäivien kuumeinen ohjelmointisessio, jonka järjestäjä tai sen rahoittaja on laittanut aluille, ja jonka toiveena ratkaista jokin iso ongelma tuomalla pöytään monenlaisia näkökulmia.

Tyypillisesti järjestämisvaiheessa tuohon ongelmaan ei vielä ole pienintäkään ratkaisuideaa, kun perimmäinen syykin on erittäin suuri kysymysmerkki. Hackathonissa on siis tarkoitus saada iso joukko kehittäjiä eri ryhmissä toimien ja ratkaisten eri näkökulmia annettuun haasteeseen liittyen. IndustryHack on Hackathon tapahtumien järjestämiseen erikoistunut Startup. Heidän tehtävänsä on toimia kokeneena fasilitaattorina hackathonin aikana.

StreetReboot järjestettiin digitalisoimaan Staran toimintaa. Stara lienee monelle tuttu Helsingin kaupungin katujen ja viheralueiden ylläpidosta vastaava yritys. Heidän vastuullaan on lähes 70% Helsingin katu- ja viheralueista.

Miten homma eteni?

Codenton Team Cityketut – eli devaajat Turo Mikkonen, Miili Halkka ja Jukka Purma – osallistui Staran haasteiden ratkomiseen. Alla Turon yhteenveto projektin etenemisestä ja  tiimin kokemuksista.  

Hakemus ja hyväksyntä

Staran haaste innosti heti ja kaihot äänet kehittäjien keskuudessa antoivat ymmärtää kiinnostuksensa. Ideoita heräsi tiimin kesken ja puhetta riitti muun muassa muurahaisalgoritmeista, machine learning -tekniikasta sekä datan visualisoinnista. Tiimin kesken tehtiin omat profiilit, sekä tietysti itse hakemus järjestäjälle eli IndustryHackille.

Pian saimme tietää, että pääsimme valittuun timanttiseen kahdeksan tiimin joukkoon. Itselläni oli loistava fiilis ja erittäin positiivinen asenne eteenpäin mentäessä.

StreetReboot Kickoff 22.9.2017

Ensimmäinen virallinen työpäivä StreetReboot -hankkeessa. Suuntasimme Staran varikolle, jossa meille tarjottiin kahvia, leipää ja aimo annos tietoa käytettävistä API-pisteistä, lisätietoa Staran pääasiallisesta työstä, sekä hiukan lisää tietoa koko tapahtumasta ja sen järjestäjistä.

Jokaiselle tiimille osoitettiin Staralta mentori, jolla siis on kokemusta itse työstä ja sen tarpeista. Meidän tiimimme mentoriksi tuli Staran hoitopäällikkö Juha-Pekka Tissari.

Juha-Pekka kertoi meille monista hankalista työtehtävistä, mitä voisi korjata tai muuttaa heidän tarpeisiinsa sopivimmiksi. Lisäksi kaikille tiimeille demonstroitiin Staran hoitokalustoa. Kävimme katsomassa tarkemmin koneiden sisältöä, työkaluja, sekä työtehtävien raportointiapplikaatiota. Aikataulut venyivät iltaan, mutta paljon informaatiota sulattaneena ideoimme vielä vähän samana päivänä työtapoja sekä lopullista demoa.

StreetReboot Hackathon 6.-7.10.2017

Ennen itse Hackathon tapahtumaa olimme sopineet työmme aiheen, data-pisteet, työkalut sekä vastuualueet. Testiympäristönä käytimme Lego Technic -sarjan aura-autoa, jonka auraa tarkkailemme Arduinolla. Datan käsittely, tutkimus ja esittely taas hoidettiin Pythonilla ja JavaScriptillä.

Hackathon järjestettiin Elisa HQ:ssa, eli Pasilan pääkonttorilla. Saavuimme paikalle, ja meille ojennettiin vihreät StreetReboot -hupparit sekä nimikyltit. Päivä alkoi käytännön asioilla, jonka jälkeen ryhdyttiin hommiin.

Aluksi sovimme tarkemmin mitä kukakin tekee, sillä osa datasta kerrottiin vasta äskettäin. Teimme Kanban-boardin ja tiketit, sekä ryhdyimme hommiin. Tapahtuma oli erittäin hyvin järjestetty, saimme ruokaa ja välipaloja työn äärellä ja tiimin omat työhuoneet auttoivat keskittymisessä erittäin paljon.

Ensimmäinen päivä menikin vauhdikkaasti ja saimme paljon aikaan. Oli kunnon tekemisen meininki! Toisena päivänä tavoitteena oli saada demoesitys kuntoon. Rajoitetun ajan takia kuitenkin emme päässeet haluttuun lopputulokseen, mutta meillä oli back-up -suunnitelmana auran statuksen muuttavaa dataa. Saimme kuitenkin itse Demo Fair -osuuden aikana asiat toimimaan halutulla tavalla. Vaikka haluttuun lopputulokseen ei ihan päästy, en usko sen vaikuttaneen tuomarien päätöksiin.

Emme yltäneet voittoon, mutta kokemus oli mainio! Pidin erityisesti tiimini yhteistyöstä, toimimme erittäin hyvin yhteen ja vastuut jakautuivat oman osaamisen mukaisesti. Emme ole Miilin ja Jukan kanssa samoissa projekteissa olleet, mutta tämä kokemus antoi minulle erittäin positiivisen kuvan heidän kanssaan työskentelystä.

Jos jotain olisin tehnyt vielä paremmin, niin omaan tiimiin olisin ottanut vielä yhden henkilön lisää, jolloin joko minä tai tuo kuvitteellinen neljäs tiimiläinen olisi keskittynyt enemmän idean esitelmöintiin, dokumentointiin sekä myymiseen. Näillä eväillä olisi hackathon voitettu vuoren varmasti!

Turon vinkit Hackathon-tapahtumiin osallistuville

Olen jo muutamaan ‘hackathonmaiseen’ tapahtumaan osallistunut, ja näistä kokemuksista oppineena haluan suositella Hackathoniin osallistujille muutamaa hyväksi todettua tapaa.

  1. Ensiksikin teknologioista ja tekniikoista. Suosittelen, että käytätte teille tuttuja tekniikoita suurimmassa osassa työtänne, tämä mahdollistaa nopean ja toimivan tuotoksen, joka valmistuu ainakin suurimmaksi osaksi jo tapahtuman aikana. Tiimille tuntemattomia teknologioita kannattaa ottaa vain muutama, joita sitten tutkitaan ja testataan jo ennen tapahtumaa.
  2. Toiseksi markkinointi ja dokumentointi. Tärkein osuus, niin hyvässä asiakas projektissa, kuin voittavassa Hackathon tiimissä on dokumentointi ja asiakkaalle idean kommunikointi. Hackathon tapahtumissa usein vain aika määrittelee sen miten paljon voidaan pistää tykkejä kunnon markkinointiin ja viestin edustamiseen, siksi olisi erittäin tärkeää yhden tiimin jäsenen keskittyä viestin suunnitteluun ja toteutukseen.
  3. Kolmas, mutta ehdottomasti tärkein pointti, on pitää hauskaa ja oppia jokaisesta pienestäkin virheestä tai odottamattomasta käänteestä projektin osalta. Hyvin usein tämän kaltaisiin tapahtumiin tulee ns. “Suorittaja-tiimi”, jonka pääasiallinen tavoite on saada voitto ja murehtia muista asioista, sitten tapahtuman jälkeen. Harvoin nämä tiimit voittavat, sillä ajatukset hyvin usein pyörivät vanhojen “hyväksi”-todettujen ratkaisujen ympärillä, eikä asiakas välttämättä ole etsimässä niitä vanhoja ratkaisuja vaan pussillisen uusia.

Projektimme tuotos ja käytetyt teknologiat

Teknologia ja tekniikat, osuuden sanoisin meidän tiimissämme onnistuneen erittäin hyvin. Meille Python ja JavaScript ovat erittäin tuttuja kieliä, sekä niiden avulla datan käsittely ja esittely olivat helppoja nakkeja, mutta tietysti suurin osa työstä tehtiin näiden teknologioiden päälle, joten niiden pyörittelyyn varattiin aikaa.

Meille tuntemattomampi osuus oli Arduino- ja C++ -ohjelmointi, mutta niistä taas minulla oli jo jonkin verran kokemusta, joten hoidin sen puolen työstämme. Markkinointi ja dokumentointi osuus, oli meidän tiimimme heikkous. Ei niinkään ettemme olisi niitä tehneet, mutta tiimin koko ja aikataulut, eivät antaneet periksi sen vertaa, että kunnon esitelmää olisi saatu luonnehdittua tuomariston esitystä varten. Tämä harmittaa itseäni erityisesti, sillä aikaisemmissa samankaltaisissa tapahtumissa olen korostanut esitelmöinnin tärkeyttä, mutta Hackathon tapahtumien luonne ei anna tarpeeksi aikaa, jotta jokainen aspekti työstä olisi varmasti valmis tulosten esitelmöinti vaiheessa.

Jatkossa otan itse opiksi, sekä varaan aikaa omasta työstäni esityksen hiomiseen. Kolmas aspekti ainakin omasta mielestäni onnistui tiimiltä erinomaisesti! Olimme sopivasti uusien aspektien kanssa tekemisissä. Omasta mielestäni koko tapahtuman ajan oli kunnon tekemisen meininki. Pidin myös erityisesti Miilin ja Jukan kanssa työskentelystä, osaamisemme sivusivat sopivasti toistemme osaamisia, joten keskustelu projektista, etenemiseen tarvittavista asioista ja työn kulusta oli helppoa ja mukavaa. Päällekkäinen, toisiaan täydentävä osaaminen oli vahvuutemme!

Vielä pari sanaa tuotoksestamme. Codenton – ja CityKettujen – it-arkkitehti Jukka Purma luonnehti projektiamme seuraavanlaisesti:

“Kalliita työkoneita käyttävissä yrityksissä sensoreiden mahdollistamaa digitalisaatiota (mennee IoT:n alle) ei kannata tehdä projekteissa tai isoissa harppauksissa: täytyy kehittää toimintamenetelmät, joilla varikot, IT, hallinto, työntekijät ja ‘älykkäät järjestelmät’ kaikki *sietävät* sen, että sensorit muuttuvat, katoavat, vaihdetaan toisenlaiseksi, lisätään ad hoc -tarpeeseen ym. Nopean muutoksen kausi tällä saralla tulee jatkumaan vielä seuraavat kymmenen vuotta, mutta työkoneita ei kannata uusia sen ehdoilla: pitää olla tottumus ja käytännöt kuinka ‘lisätä älyä’ vanhoihin koneisiin.

Menetelmien suunnittelu, koodaaminen tai kiveen hakkaaminen olisi kuin DevOps, mutta työalue on isompi: pitää voida sanoa johdolle että vain käyttämällä näitä menetelmiä, voitte hyötyä näistä uusista tietokanavista, IT-porukalle että on päästettävä tällaista tietoa sisään ja ulos, ja juteltava työntekijöiden kanssa missä on pullonkauloja joissa IoT voisi auttaa. Käytännössä tämä olisi vaativa työrooli monipuoliselle osaajalle, mutta niin kauan kuin sellaista tehtävää ei ole eikä täyttä ymmärrystä miten sen roolin täyttäjään pitäisi suhtautua, se on parempi toteuttaa konsulttien avulla: monta henkilöä yhdistää osaamisensa ja keskittyy joksikin aikaa ratkomaan tuota ongelmaketjua, tavoitteena luoda alustavat (turvalliset) käytännöt joita sitten joku asiakasyrityksestä nousee jatkamaan.”

 

IndustryHackin järjestämään Street Reboot -tapahtumaan osallistuneet CityKetut ovat:

Turo Mikkonen: “Tiimini kanssa tekeminen oli erityisen palkitsevaa näiden ihmisten kanssa ja pidin tästä kunnon tekemisen meiningistä”

Jukka Purma: “Tekeminen oli hauskaa ja jännää, enemmän alamäkijuoksua kuin maratonia: koska tahansa saattoi askelvalinta osoittautua vääräksi ja homma mennä turvalleen, mutta selvittiin ehjänä maaliin suunnilleen sitä reittiä mitä lähdettiin yrittämään.“

Miili Halkka: “Kokonaisuutena hackahton oli hieno kokemus, oman tiimin mutkaton toiminta, muiden tiimien tuotoksien näkeminen ja verkostoituminen monenlaisten osaajien kanssa antoi elämyksen, jonka kaltaista normaalissa työprojektissa on mahdoton saavuttaa muutamassa päivässä. Nopea palaute tehdystä työstä palkitsee aina.”

Codenton CityKettujen tuotokseen voi tutustua Githubissa: https://github.com/codento/snowplow_sense

Lisätietoja hankkeesta myös täällä:
https://6aika.fi/in-english/
http://rebootthecity.fi/

PyCon Ireland 2016: parhaat pointit

Kävin viime syksynä Irlannin PyConissa (lue myös aiempi blogaukseni Suomen PyConista) ja nyt viimein esitysvideotkin on laitettu YouTubeen.

Seminaaripäivä alkoi viiden herätyksellä, jota seurasi välilasku tunnin taaksepäin ajassa, ja sitten toinen tunti taaksepäin Irlantiin. Dublinia en valitettavasti päässyt näkemään kovin paljoa, vaikka päivälle kertyi reilu 22 tuntia valveillaoloa. Illalla kävimme konferenssihotellilla katsomassa ympärillemme ja otimme oluet muiden paikallaolevien konferenssivieraiden kanssa.

Lauantaina virkeänä paikalle, erittäin sikeiden unien jälkeen. Tämä konferenssi oli noin kahdesti Suomen konferenssia isompi, myös kestoltaan ja hektisyydeltään – hyvällä tavalla, totta kai. Sponsoriständit suoraan salien edessä käytävällä rajoittivat kulkua ja nostivat äänenvoimakkuutta kenties turhankin paljon, mutta toisaalta ne sai käytyä läpi tauoilla.

Paikallinen työministeri Mary Mitchell-O’Connor avasi tapahtuman. Enpä tiennyt, että Irlannin viennistä 40 % on teknologiaa, tai että neljä viidestä suurimmasta vientiyrityksestä ovat teknologia-alalla! Valitettavasti hän ei tainnut jäädä paikalle seuraamaan tapahtumaa pidemmäksi aikaa, jonkinlainen jutustelu olisi ollut varmasti antoisaa.

Pythonin käyttö yleistyy Mozilla Firefoxissa

Ensimmäisen keynoten piti Tarek Ziadé Mozillalta, otsikko sopivasti Mozilla & Python. Hän kertoi miten Pythonin käyttö on yleistynyt Mozillalla Firefox-selaimen julkaisuketjussa. Vielä vuonna 2009 Mozillalla oli erittäin sekalainen seurakunta ohjelmointikieliä ja -kehyksiä, mutta nyt suurin osa on Pythonia ja Djangoa.

CertBot: olennainen osa tietoturvaa

Hienoa heijastusta Suomen PyConiin tuli Justin Mayerin Essential Python Security -esityksessä, kun hän mainitsi CertBotin (aiemmin Let’s Encrypt Client) olennaisena osana tietoturvallista infrastruktuuria. Esityksessä käytiin lähinnä läpi paljon hyviä käytäntöjä ja ratkaisuja, eli kalvot kannattaa katsoa – ne ovat niin oleellisia, että kaivoin linkinkin tähän artikkeliin!

Pythonilla helppoa käsitellä suuriakin määriä dataa

Heijastusta Suomen konferenssiin tuli myös tietojenkäsittelyteemasta. Irlannissa sitä oli puolen ohjelman verran. Zalandon Ana Peleteiro Ramallo veti perustason esityksen Introduction to Data Science in Python. Oikein hyvä perustason lähtö, jos ei tunne alaa. Tämä, seuraava Ali Kingin Data Pipeline Evolution ja Breandan Considinen Experimenting in Tensorflow – yhdistetynä Suomen konferenssin puheisiin aiheesta – antoi ymmärtää vain yhden asian: Pythonilla on todella helppoa ja tehokasta päästä käsittelemään suuriakin määrää dataa. Sitten täytyy vain oppia matematiikka ja tilastotiede.

Läheltä liippasi Johannes Ahlmannin How to Merge Noisy Datasets. Joskus, tai pikemminkin yleensä, kerätty tieto on eri tavoin sotkuista. On erilaisia merkistöjä, eri kulttuureissa ihmiset nimetään eri tavoin ja osoitteet ovat eri maissa erilaisia. Puhuja esitteli miten näihin saadaan tolkkua erilaisten Python-kirjastojen avulla. Siellä oli monta kirjastoa, joista olisi ollut hyötyä, jos niitä olisi ollut aikoinaan olemassa.

Python-tulkki

Pythonin sisäisestä toiminnasta on aina kiva kuulla myös. Stephane Wirtel puhui otsikolla CPython Bytecode and VM siitä, miten Python-tulkki (virallisen toteutuksen nimihän on CPython) kääntää ihmisluettavan ohjelmakoodin väliaikaiseen muotoon, jota tulkki itse asiassa tulkitsee. Hän kävi läpi tiedon rakenteen ja miten ihminen voi sitäkin lukea.

Säielukon poistaminen Pythonista

Toinen keynote liippaa läheltä. Se tuli Larry Hastingsilta, joka on Pythonin ydinkehittäjiä. Hänen esityksensä nimi oli GILectomy. (Kyseinen video ei ole juuri tästä seminaarista, mutta puheen sisältö on suunnilleen sama.) Kyseessä on nk. GILin, prosessinlaajuisen säielukon (Global Inerpreter Lock) poistaminen Pythonista. GIL on suorituskykyinen ja elegantti tapa taata säikeelle vapaat kädet koodin suorittamiseen, mutta vastapainona monisäikeiset ohjelmat hidastuvat moniytimisillä koneilla. Pythonin kehittäjä Guido van Rossum toi sen kieleen vuonna 1992, jolloin tietokoneissa ei ollut kuin yksi ydin, ennen kuin Linuxissa oli tukea säikeille.

Ongelma on alkanut muodostua nykyään, kun moniytimiset suorittimet alkavat yleistyä jopa älykelloissa. Tällä hetkellä Hastingsilla on ideoita miten ratkoa tämä tilanne, mutta hän etsii vielä parhaita kompromisseja. Suorituskyky ei ole vielä riittävän hyvä yksisäikeisille ohjelmille ja C-ohjelmointikielellä kirjoitetut moduulit saattavat hajota. Moduulien hajoamisen voisi välttää esimerkiksi toimittamalla kaksi versiota kielestä, mutta päätöksiä ei vielä ole. Odotamme siis innolla mitä tästä tulee!

Oma esitykseni: Plug in with Python

Pääsin itsekin lavalle. Uusin aiemmassa Suomen PyConissa olleen Plug in with Python -esitykseni. Tällä kertaa olin laajentanut kalvosettiä, ettei aika pääsisi loppumaan kesken. Ikävä kyllä videotykin kanssa oli ongelmia, kuten kaikilla muillakin, joten esityksessä tuli hieman kiire. Jouduin karsimaan jonkin verran mielenkiintoista materiaalia pois, mutta toisaalta esitys saattoi pysyä tämän ansiosta paremmin kasassa. Voit itse katsoa tähän upotetusta videosta mitä mieltä olet.

***
Kuva: Flickr Creative Commons, Cazz.

PyCon Finland 2016

Viikon sisään kaksi konferenssia! Sokerina pohjalla molempien aiheena oli Python-ohjelmointikieli. Ensimmäinen oli PyCon Finland ja toinen PyCon Ireland.  Julkaisen PyCon Irelandista kertovan blogauksen myöhemmin.

Suomen konferenssi kesti yhden maanantaipäivän, mutta oli sitäkin paremmin täynnä ohjelmaa. Päivän alussa järjestettiin salamapuheet, nuo korkeintaan viisi minuuttia kestävät esitykset, joiden aihe on vapaa. Yleensä nämä pidetään tapahtuman päätteeksi, mutta tapahtuman lopussa kannettavien ja projektorien kanssa säätämisen välttämiseksi nämä oli siirretty alkuun. Tämä tosin rajoitti kenties osallistumista, koska usein ideoita voi tulla konferenssin aikana aiheista, joista puhua. Ehkä ajatuksena oli, että ei päätetä konferenssia turhautumiseen ja ainakin salamapuheet olivat hyviä. Varsinaisista esityksistä minulle mieleenpainuvimmat olivat tietojenkäsittelyyn ja tekoälyyn liittyviä.

Käsialatunnistustietokanta

Aleksei Tiulpinin esitys Machine Learning with Python havainnollisti MNISTin käsialantunnistustietokannan käyttöä www-palveluna. Hän kävi läpi teoriaa ja esitteli sitten tekemäänsä ohjelmistoa, jossa selaimeen pystyi piirtämään numeron ja palvelun takana pyörivä tekoäly kertoi minkä numeron luulee olevan kyseessä milläkin todennäköisyydellä.

Tekoälyä työpaikkailmoituksiin

Myös Clemens Westrupin Representation Learning and Deep Sequential Modeling for Predicting Topics of Sentences in Job Advertisements oli mainio. Puhuja kävi läpi miten Oikotien englanninkielisiä työpaikkailmoituksia voi luokitella tekoälyn avulla, kunhan ensin saa kerättyä dataa siitä, mitä sisältö yleensä on.

Yksikkötestit data-analyysin maailmassa

Viimeisenä tästä kategoriasta täytyy mainita Unit Testing in the Scientific Python Stack, jonka piti Antti Kaihola. Tässä puhuja näytti, miten data-analyysin maailmassa voidaan suorittaa yksikkötestejä – eri menetelmiä ja havaintoja sekä bugin kirjastossa.

Valtavirran unohtama ZODB

Lisäksi nostaisin Asko Soukan ZODB-esityksen korkealle. ZODB on valtavirran kenties unohtama – tai tiedostamaton – Python-objektitietokanta. Tähän tietokantaan voi tallentaa suoraan Python-ohjelman ajonaikaisia rakenteita. Yleensä ajonaikaiset rakenteet käännetään JSON-muotoon tallennettavaksi, joten oli mielenkiintoista kuulla miten muutoin tämän voi tehdä. Lisäksi ZODB:ssä on suurin osa vakiintuneiden tietokantojen ominaisuuksista.

Älä unohda tietoturvaa

Päällekkäisyyksien takia ainakin Joona Hoikkalan CertBot-aiheinen esitys Closing the gap with TLS adoption täytyy ehdottomasti katsoa Youtubesta. Tietoturva on tärkeä asia, joka laiminlyödään liian usein.

***
Kuva: Flickr Creative Commons, Chris Parker.

Onnistuneen lean-muutoksen malli

Puhuimme kollegani Karoliina Luodon kanssa Lean day 2016:ssa kokonaisvaltaisesta muutoksen ymmärtämisestä; miksi ja miten kannattaa muuttua. Kävimme läpi tasot, joille organisaation tekeminen ja muutokset voidaan jäsentää.

Kävimme muutoksen tasojen hahmottamista lean-visiolakanan linssin läpi. Muutos ja muutoksen aspektit tiivistyvät ennen tekemisen aloittamista lean-visiolakanaan. Nostimme kultakin tasolta välineitä, joilla ottaa muutosta haltuun.

Vertaisoppimiskokemuksemme oli yhtäältä varmistus, että kokonaisuuden katsomiselle lean-perspektiivistä on tilaus (Lean day 2016:sta Net Promoter Score eli NPS on 76 %), ja toisaalta se että laajojen kokonaisuuksien käsittelyyn tarvitaan aikaa ja erilaisia näkökulmia jotta mallit ja ajattelu mallien taustalla välittyy ja siihen on mahdollista saada palautetta jatkokehitystä ajatellen. Pyrimme jatkuvasti parantamaan – muuttumaan. Mallista tullut palaute kiteytyy seuraavaan lausahdukseen: “Paljon asiaa, hieman abstraktia.” Näin helposti käy, kun suuri määrä erityistapauksia pyritään kiteyttämään yleiseksi malliksi. Tämä oli kimmoke avata samaa kehittämisen kehystä toisesta suunnasta.

Muutos ja muutoskyky on voimavara ja iloinen asia, muutos on mahdollisuus poistaa ikäviä ja hankalia asioita. Joillekin muutos tarkoittaa uhkaa ja on epämiellyttävä ajatus. Tässä kirjoituksessa muutos on kuitenkin synonyymi asioiden kehittämiselle ja hankaluuden poistamiselle – energialle joka vapautuu, kun lakkaamme tekemästä turhia asioita ja keskitymme siihen mistä syntyy asiakkaalle arvoa.

Lähestymme nyt lean-muutosta 3 vuoden muutoshankkeen kautta. Organisaatiosi saattaa olla nopeampi ja vastaanottavaisempi ja voi olla, että teillä on jo osa asioista hyvissä kantimissa. Varaa tällöin ajatuksissasi vaikka 3 kuukautta kullekin vaiheelle.

Tein tämän blogauksen tueksi diasetin, jonka voit katsoa tästä:

Muutoksen ajaminen toimintaan – ajattelu lean-visiolakanan täyttämisen takana

Käymme nyt mallin läpi konkreettisesti tekemisen tasolla. Oletamme, että lean-tekeminen ei ole organisaatiossa vielä keskiössä, ja että organisaation nykytila ei ole kaikilta osin tyydyttävä, eli meillä on tilaus lean-muutokselle.

Asiakas keskiössä (1. vuosi tai 3 kk) – vastaansanomaton lähtökohta kehitykselle

Organisaatio on olemassa jostain syystä ja palvelee jotain asiakasta. Tämän asiakkaan tunteminen on äärimmäisen tärkeää. Asiakkaan ja asiakkaan tarpeen pitäisi olla jokaisella tiedossa ja sen tärkeys organisaatiossa ymmärrettynä. Tämä on ensimmäinen asia, joka pitää laittaa paikoilleen – muut asiat rakentuvat tämän ympärille.

Yksinkertaisimmillaan tämän voi tehdä kysymällä asiakkaalta, kuinka todennäköisesti asiakas suosittelisi ystävälleen palvelua jota tuotat. Pyydä myös asiakasta kertomaan, miksi. Tämä on NPS-luku. Saat tulokseksi yhden numeron. Se kuinka suuri numeron tulisi olla riippuu siitä, kuinka hyvää palvelua haluat tuottaa ja onko kilpailijoillasi mahdollisuus tuottaa parempaa.

Asiakkaan kanssa oleville syntyy ensimmäisenä käsitys siitä, mille olisi tilausta. Helposti ollaan tilanteessa, jossa asiakasrajapinta kokee että organisaatio ei suoriudu asiakkaan palvelemisesta niin hyvin kuin olisi toivottavaa.

Jos yhteinen toimintatapa puuttuu, koordinointi ja varmisteleminen haukkaavat valtavan osan ajasta – tai jäävät tekemättä, mikä on vielä suurempi haaste.

Tunne, ettei organisaatio toimi niin hyvin kuin voisi, voi toki syntyä täysin asiakkaasta riippumatta. Asioiden muuttamisen kannalta oleellista on kuitenkin tunnistaa se taho, jota varten organisaatio on olemassa, ja käyttää asiakkaan tarvetta selkänojana tulevissa muutoksissa. Tavoite voi olla esimerkiksi, että haluatte 8 yksikköä paremman NPS-tuloksen.

Yli siilojen mittaus ja ohjaus (2. vuosi, tai seuraavat 3kk) – luonnollinen mittaamalla johtamisen laajeneminen

Pääsääntöisesti toimimme osana kokonaisuutta ja jotta voisimme tehdä merkityksellisiä asioita, olemme riippuvaisia yhteistyöstä toisten kanssa. Tämä on totta yksilötasolla, eikä itseasiassa ole kovin erilaista organisaatiotasollakaan, vaikka organisaation tehokkuus tai tehottomuus on helposti kovin vaikeasti havaittavaa. Kuitenkin on tunnusomaista, että tehokkaasti toimivan organisaation osat toimivat yhteisen päämäärän eteen.

Hyödyt kokonaisvaltaisesta päivittäisjohtamisesta on tunnistettu, rajoja kaadetaan.

Asiakasmittari, esimerkiksi NPS, kertoo meille, miten hyvin vastaamme asiakkaan tarpeeseen. Mutta se ei yleensä riitä kertomaan mitä pitäisi muuttaa, jotta voisimme vielä paremmin tuottaa lisäarvoa asiakkaalle. Meidän pitää ymmärtää, mitä me teemme tyydyttääksemme asiakkaan tarpeen. Siis todella! Lisäksi meidän pitää ymmärtää miten me teemme sen mitä me teemme. Siis todella, toisen kerran!

Nykytila, tapa toimia

Keihäänkärkimenetelmänä tässä vaiheessa on arvovirtakartoitus. Tämä on edellytys laittaa paikoilleen seuraava mittari: asiakkaalle tehtävän lisäarvoon käytetyn ajan suhde kokonaisuudessaan käytettyyn aikaan. Tämän mittarin antamaa luku on ”Process Cycle Efficiency” tai toiminnan tehokkuus. Arvovirran konkretisoiminen osallistuttaa ja sitouttaa parhaimmillaan koko henkilöstön. Jokainen tietää, että kuka se asiakas nyt olikaan ja lisäksi sen, miten minun päivittäinen tekeminen auttaa asiakasta saamaan lisäarvoa. Sillä että työntekijät kokevat omakseen sen, miten arvoa tuotetaan asiakkaalle on aivan erityinen asema lean-muutoksen tapahtumisessa. Kuinka helppoa onkaan poistaa turhaa tekemistä, kun lisäarvon tuottaminen saadaan erotettua muusta toiminnasta.

Monozukuri wa hitozukuri – asioiden tekeminen on ihmisten kasvamisen edistämistä.

Jos kaikki on edellä mennyt suunnitelmien mukaan, tässä vaiheessa organisaatiolla pitäisi olla kyvykkyys tehdä sitä mitä on huomattu asiakkaan tarvitsevan. Sen lisäksi organisaatio pystyy jatkuvasti parantamaan toimintaansa: karsimaan kuluja ja tekemään enemmän samoilla resursseilla. Eikä nyt tarkoiteta, että yksilöitä kuormitetaan enemmän, vaan että tehdään oikeat asiat ja jätetään turhat tietoisesti ja faktoihin pohjaten tekemättä.

Muutostarve ja muutoksen kuvaus

Muutostarve syntyy aidosta ymmärryksestä, mitä asiakas tarvitsee, miten me sen teemme ja missä kohdin voimme tehdä sen vielä paremmin. Tämä ymmärrys kiteytyy muutoksen visiolakanaan.

Toteutus ja muutoksen teko

Toteuta muutokset niin lähellä päivittäistä työn tekemistä kuin mahdollista. Älä kirjoita niitä työlistalle, jos voit tehdä ne heti. Muista kuitenkin, että olet osa organisaatiota, jonka voima tulee siitä, että teette yhdessä. Osaoptimointi on pahimmillaan haitallista asiakkaan kannalta. Suuremmissa muutoksissa valitaan tapa, joka parhaiten vastaa muutoksen mittakaavaa ja asioita joita pitää muuttaa.

Yleensä on parempi ottaa paljon pieniä askeleita oikeaan suuntaan, kuin valmistella pitkää loikkaa. Pienten muutosten tapa nostaa pintaan muutoksen positiivisen voiman; kyllähän nyt jokainen voi pienen muutoksen tehdä, ja sitten seuraavan, ja seuraavan. Ja ennen pitkää onkin jo tultu pitkä matka, vaikka ei tehtykään kuin ihan pieni muutos.

Mittaa myös muutoksen toteutumista. Askelten välillä on helpompi muuttaa suuntaa, kuin kesken ilmalennon. Kysy palautetta ja kuuntele, mitä asiakas tuumaa.

Optimoitu muutoksen hallinta (3. vuosi) – mahdollistaa jatkuvan kehittämisen kulttuurin

Seuranta ja ohjaus

Oli kyse asiakkaan kokeman arvon ymmärtämisestä tai muutoksen toteutuksesta on tärkeää, että ymmärretään, mitä yritetään saavuttaa ja mitä mittarit kertovat. Intuitiivinen tuntuma organisaation toimintaan on asia joka luo johtajalle kokemuksen tunnetta, tämä tuntuma syntyy yleensä pitkän kokemuksen kautta, mutta voi olla myös väärä. Daniel Kahneman antaa kirjassaan hyviä esimerkkejä. Ja kaikilla ei kuitenkaan ole sama intuitio samasta tilanteesta. Intuition lisäksi on oikeasti hyvä idea laittaa paikoilleen niin objektiiviset mittarit kuin mahdollista.

Katso toimintaympäristöäsi arvoketjujen kautta

Järjestelmä nimeltä toimintaympäristö on kehys, jossa organisaatio toimii. Organisaatio ei ole yksin tässä kehyksessä. Kanssatoimijat, toiminnan säätelijät, sattuma sekä erilaiset vuorovaikutusilmiöt ovat myös jatkuvasti läsnä. Toimintajärjestelmä on jatkuvassa muutostilassa ja tämä vaikuttaa organisaatioon. Jos organisaation tendenssi on vastustaa tai sulkea silmänsä muutokselta, toimintajärjestelmän voi jättää huomiotta. Tällainen velan ottaminen tulee kuitenkin erääntymään.

Muutos ei ole taakka. Siihen ei kulu kohtuuttomasti energiaa, vaan se nähdään mahdollisuutena.

Organisaatio voi ymmärtää asiakkaan ja tarpeen, toimittaa lisäarvoa jota asiakas rakastaa, olla briljantti oman toimintansa hiomisessa vastaamaan asiakkaan tarvetta – ja kuihtua silti pois toimintaympäristön muutoksessa.

Muutosta kannattaa katsoa kokonaisuuksien kautta, nähdä toimintaympäristön arvoketjut ja millaisilla muutoksilla organisaation asemaa voi parantaa. Ymmärtää mikä on omassa työnkuvassa tapahtuvan muutoksen linkki toisiin työntekijöihin ja miten tämä vaikuttaa asiakkaalle toimitettavaan arvoon. Johtajan tehtävä on varmistaa, että asiakas ja toimintaympäristövetoinen muutos organisaatiossa on luontevaa ja jatkuvaa.