21.03.2018 / Nanni Koski

Lyhenteiden viidakossa kehitin itselleni muistukseksi uuden: DBD. Mistä tämä sitten on lyhennys? Käydään ensin katsomassa Googlesta, jos satuttiin osumaan johonkin nuorison käyttämään hypetermiin. Itse asiassa Urban Dictionaryn kaksi ylintä termiä sopii teemaan, joten pidetään vielä jännitystä yllä.

 DBD = ”Damn, bro, damn”

Yleensä käytetty ilmaisemaan ilmeisesti vaikuttuneisuutta, mutta tässä tapauksessa toi mieleeni päivän, joka tuntui data scientistin painajaiselta. Olen erityisen ihastunut kreikkalaisiin aakkosiin, joten otetaan ne mukaan selventämään tilannetta. Eli latinalaiset aakkoset viittaavat tunnettuihin asioihin ja kreikkalaiset johonkin tuntemattomaan, mikä ei suorilta ole selvää. Sanottakoon, että projektin vetohahmo sattui olemaan tänä päivänä lomalla, mikä lisäsi tulevan tehtävän haastetta.

Tehtävä: Asiakas A lähettää Excel-tiedoston B, jonka välilehdistä osalla, merkitään [math] \alpha_1, \ldots, \alpha_\beta [/math]  on tietoja, jotka tulee päivittää tiedostoon / tiedostoihin [math] \gamma_1, \ldots, \gamma_\delta [/math] kansiossa [math] \varepsilon [/math] palvelimella [math] \zeta [/math] ja sen jälkeen ajaa tauluihin [math] \eta_1, \ldots, \eta_\theta [/math] kannassa [math] \iota [/math] latauksilla [math] \kappa_1, \ldots, \kappa_\lambda [/math].

Juuri niin helppoa kuin se ääneen luettuna kuulostaa olevan.

Vaikea palapeli

Ehkä tunnin työ, jos kreikkalaisten aakkosten merkitys tässä kontekstissa on tuttu. Jos selvittäminen vaatii valistuneita arvauksia, niin tällaista ongelmaa ei ratkaista googlettamalla.

Tästä päästään sanakirjan seuraavaan ehdotukseen:

DBD = ”Don’t be Dumb”

Sanonnan kirjaimellinen käännös sopii aiheeseen paremmin kuin tarkoitettu ”Don’t worry”. Eli älä ole typerä – dokumentoi tekemisesi.

Mitä uusia muuttujia dataan luotiin, miksi ja millä tavalla? Rajattiinko osa havainnoista tarkastelun ulkopuolelle? Toki osa asioista on haastavampia dokumentoida. Ja joskus vasta kokeilut osoittavat, mikä toimii ja mikä ei. Ja kyllähän sen muistaa, miksi koodi meni näin ja missä järjestyksessä eri tiedostot tulee ajaa. Se on selvää, että tämä koodi löytyy täältä kansioista. Ja tuo tiedosto valitaan tässä tietyssä tilanteessa. Ja se päivitettävä osio koodissa on juuri tuo. Ja että jos haluaa saada aikaan tämän, niin käy muuttamassa tuolla valikossa arvoja. Niin ja muuttujien datatyyppien muunnokset pitää ottaa huomioon. Mutta sehän on selvää tulevan virheilmoituksen perusteella, jos sen sattuu saamaan. Eikö vaan?

Liian monta sekavaa ohjetta

No ei.

Miksi, mitä, miten ja mihin siis dokumentoida? Ja se tärkein eli:

Kuka? Sinä, juuri sinä. Just do it.

Mitä? Ajatukset ja toteutukset projektiin liittyen.

Miksi? Asiantuntemus. Muistipaikkojen vapauttaminen omasta päästä. Lähimmäisenrakkaus. Sharing is caring. Ja ehkä silloin saa viettää jonkun lomapäivän tarvitsematta vastata yhteenkään työpuheluun.

Miten? Tiimin / Asiakkaan saataville. Vaikka Wordillä, PowerPointilla, Notepadilla, R Markdownilla tai Trelloon.

Mihin? Dokumentoinnista ei ole hyötyä, jos sitä tarvitseva ei sitä löydä. Eli varmista, että tiimille on selvää, mistä työsi hedelmät on poimittavissa muidenkin iloksi.

Ehkä suurin ongelma dokumentoinnissa on kuitenkin se, kun into lähtee lapasesta ja perille pääsee nopeammin raskaalla kaasujalalla kuin jokaisen taukopaikan kautta. Kun tässä eräänä päivänä lisäilin koodin joukkoon jälkikäteen selityksiä siitä, miksi olin muokannut dataa esitetyllä tavalla, totesin, että eipä olisi ollut suuri vaiva kirjoittaa ne jo tehdessä.

DBD = ”Document before Doing”

Tästä eteenpäin pyrin seuraavaan: Sunnittele – kirjoita ylös – tee – vaikutu tuloksista tai yritä uudestaan. Sitä tarkoittaa minun DBD. Ihan aina ei (ehkä) ole mahdollista kirjoittaa suunnitelmia ja toteutuksia ylös ennen tekemistä.  Ja joskus on hyvä työskennellä flown mukana. Mutta tavoitteena on selvät ohjeet tai muistiinpanot edes kaikesta lopputuloksen kannalta oleellisesta tai toimivan tuotteen toiminnasta. Ehkä sitten pääsee käyttämään ensimmäistä fraasia alkuperäisessä tarkoituksessa.

Suuri vaikuttuneisuuden huudahdus: Wow!

Pahimmassa tapauksessa dokumentoinnin puuttuminen aiheuttaa moninkertaisen työn siihen vaivaan verrattuna, että asiat voi käydä tarkistamassa jostain. Datamuokkauksien tekeminen uudelle dataversiolle ajamalla siistit koodit läpi mahdollistaa useamman päivän työn tekemisen muutamassa minuutissa.

Mielelläni kuulisin lukijoiden kokemuksia toimivasta tai ei niin toimivasta dokumentoinnista. Tai jäikö jotain oleellista puuttumaan?

Tästä on hyvä siirtyä kahden viikon lomalle. Toivottavasti kaikki tieto on saatu välitettyä työkavereiden ulottuville ja löydettäväksi eivätkä päivät kaadu piilotteleviin dokumentaatioihin. Tai siihen minulle ihan itsestään selvään asiaan. Bye!


7.09.2017 / Erkka Puusti

15.8.2017 käynnistyi Metsä Fibren uusi biotuotetehdas Äänekoskella. Käyttöönottoajaksi oli määritetty jo kolme vuotta sitten elokuun 15 päivä, klo: 6.00. Kun käyttöönoton aika lopulta tuli, niin tuotanto pärähti käyntiin klo: 5.53, siis
7 minuuttia etuajassa ja budjetissa. Monella mittapuulla huomioiden tämä on erittäin mahtava saavutus. Jäljelle jääneen 7 minuuttiahan voi käyttää vaikkapa kananmunan kovaksi keittämiseen, tehokkaaseen pikatreeniin, tai teinivuosien leikkiin ’7 minuuttia taivaassa’.

Tai sitten voi lukaista seuraavat ajatukset ja varmistaa, että omalla vastuulla olevan kehitysprojektin aikataulu, laajuus ja budjetti pysyvät hallinnassa. Myös ilman munakelloa.

1. Pilko kokonaisuus

Vanha, kulunut norsuteoria toimii niin elämänmuutosten kuin IT-projektienkin edessä nikotellessa. Pilko pieniksi. Pienet kokonaisuudet voi tarvittaessa kilpailuttaa erikseen. Ketterän kehityksen ja jatkuvan validoinnin avulla pystytään nopeammin tunnistamaan mahdolliset haasteet. Voidaan tehdä korjausliikkeitä, jotka ovat pienemmän osakokonaisuuden sisällä hallittavissa.

2. Suunnittele vähän, suunnittele jatkuvasti

Sen sijaan, että projektin alussa käytetään pitkä aika ratkaisun yksityiskohtaiseen suunnitteluun, kannattaa suunnittelusta tehdä säännöllinen osa kehitystä. Alussa on tietenkin hyvä luonnostella kokonaisuus ja sen pääpiirteet. Liian tarkka, aikaa vievä ja kallis etukäteen suunnittelu kannattaa unohtaa.

3. Priorisoi

Jos budjetti ja aikataulu ohjaavat tekemistä on tärkeä hyväksyä, ettei kaikki ole mahdollista. Jatkuvan suunnittelun yhteydessä tehtävän priorisoinnin kautta varmistetaan, että kriittiset liiketoiminnan ja loppukäyttäjien vaatimukset tulevat varmasti huomioitua. Vähemmän kriittiset jätettäköön sovinnolla odottamaan jatkokehitystä.

4. Validoi usein

Jatkuva suunnittelu ja priorisointi edellyttää että toteutusta tarkastellaan ja testataan yhdessä säännöllisesti ja usein. Säännölliset demot ja läpikäynnit ovat hyvä lähtökohta validoinnille, mutta todellinen hyöty saadaan jatkuvan loppukäyttäjä testauksen kautta. Mitä myöhemmin käyttäjät pääsevät tutustumaan ratkaisuun, niin sen varmempaa on että ratkaisusta löytyy puutteita.

5. Älä oleta

Varmista että päätöksesi pohjautuvat empiiriseen tietoon eikä arvauksiin. Kun töitä hallitaan pienissä kokonaisuuksissa, usein suunnitellen ja validoiden konkreettisten tuotosten kautta, on helpompaa tehdä selkeitä päätöksiä. Opitun pohjalta ratkaisua pystytään tarvittaessa ja hyvissä ajoin ohjaamaan oikeaan suuntaan.

6. Mittaa toteutuneen ei suunnitellun mukaan

Pitkien suunnitteluvaiheiden edistymää on kiva ja helppo seurata ja raportoida, mutta toteutuman arvo on 0. Ainoa oikea mittari saavutetulle arvolle on toimiva ratkaisu.
Kun kokonaisuus pilkotaan pieniin osiin, missä pitkän suunnittelun sijaan keskitytään toteutukseen, jota pystytään validoimaan usein ja säännöllisesti niin pystytään paremmin mittaamaan edistymää sekä käytetyn ajan ja budjetin tuoma arvoa.

7. Luo ympäristö joka pohjautuu luottamukseen ja läpinäkyvyyteen

Mikään yllämainituista ei ole millään tasolla mahdollista jos työtä ei tehdä läpinäkyvästi ja yhtenä tiiminä. Mikään ei tuhoa tehokasta työskentelyä pahemmin kuin mikromanagerointi, tiedon panttaaminen ja siilomainen ajattelu.

Edistymän pitää olla tasapuolisesti kaikkien nähtävillä. Kun onnistumisista, epäselvyyksistä sekä ongelmista kerrotaan heti ja avoimesti, niin varmistetaan että kehitys tuottaa laadukkaimman lopputuloksen.


24.10.2013 / Ville Niemijärvi

Konsulttiurani alussa sain projektipäällikön pestin. Tehtävänä oli hoitaa asiakkaalle pienimuotoinen tietovarasto- ja raportointiprojekti.

Kyseessä oli 3 eri lähdejärjestelmää ja nippu tekstitiedostoja, jotka piti viedä SQL Server SSIS:llä tietovarastoon, johon tuli pari-kolme faktataulua ja kymmenisen dimensiota. Tähän päälle metamalli Cognoksen Framework Managerilla ja  iso joukko raportointikuutioita Cognos Transformerilla. Toisin sanoen hyvin suoraviivainen oppikirjaesimerkki. Ei mikään pienin mahdollinen toteutus (ottaen huomioon useat lähdejärjestelmät ja kuutiotkin olivat aika laajoja sisällöltään) mutta ei suurikaan.

Asiakas pyysi työmääräarviota. Tuumailin hieman, katsoin asiakkaan tekemiä esimäärittelyjä ja totesin, että tämä tehdään 20 päivässä.

Kun kerroin tämän tiiminvetäjälleni, häneltä meinasi leuka tippua. “Kuules Ville, en ole koskaan nähnyt, että DW-projektia olisi tehty alle 50 päivän, saati sitten 20 päivän.”

Kaverilla oli silloin lähes 10 vuoden kokemus alalta joten varmasti tiesi mitä puhui.

Homma kesti 21 htpv. Ylitin budjetin ja pahoittelin sitä asiakkaalle, joka ei ollut siitä moksiskaan. Tein siis kokeneen konsultin arvioiman vähintään 50 htpv työn 20 päivään ja se ei tehnyt edes tiukkaa. Miten tämä oli mahdollista? Tässä muutama pointti miksi homma toimi:

1. Keskity olennaiseen –  Jätä kaikki turha pois.

Koska kyseessä on suoraviivainen toteutusprojekti jossa tiedetään mitä halutaan, mistä data haetaan ja miten sitä pitää käsitellä, ilman 3. osapuolia, ei tarvita monia niitä vaiheita mitä isommissa hankkeissa on. Ei tarvitse käyttää päiviä projektinhallintaan, johtoryhmän kokouksiin, projektisuunnittelman ja riskimatriisien kirjoittamiseen. Testaus on hyvin suoraviivaista lukujen mätsäämistä raporteilta tietovarastoon ja siitä lähdetauluun.

Mitä vähemmän liikkuvia osia sitä parempi. Ammattilainen osaa arvioida milloin voidaan jättää projektisuunnitelmasta osia pois ja milloin ne pitää ehdottomasti pitää mukana.

2. Uusiokäytä, kierrätä

Tässä casessa asiakkaalla oli käytössä vanha raportointijärjestelmä josta pystyimme nappaamaan SQL-lauseet ja muokkaamalla niitä hieman, upottamaan suoraan tietovaraston ETL:ää varten. Meidän ei tarvinnut tehdä syvällistä lähdejärjestelmien analysointia ja etl-prosessi pystyttiin viemään kymmenesosalla siitä mitä se normaalisti olisi vienyt (oppikirjasääntö: etl-toteutus vie normaalisti n. 70% koko DWBI-hankkeen kestosta).

Sama homma lähdetietokantojen “uusiokäyttämisen” kanssa. Useimmiten sama tietokantajärjestelmä sisältää samat tiedot samoissa tauluissa ja kentissä siirryttäessä yrityksestä toiseen. Toisin sanoen jos olet hakenut joskus myyntidataa Oraclesta tai SAP:sta ja siirryt toiselle asiakkaalle tekemään samaa homma, löydät samat myyntitilausotsikot ja -rivit aivan samoista tauluista. Toisin sanoen voit uusiokäyttää edellisessä projektissa tehtyjä SQL-kyselyitä ja jopa kokonaisia etl-ajoketjuja – ja säästää asiakkaalle kymmeniä tuhansia euroja.

Tietovarastoarkkitehtuuri on kolmas kierrättämisen paikka. Väitän, että sama  tähtimalli sopii 9/10 tietovarastoprojekteista. Aivan, sinun yritykseksi on tietenkin juuri poikkeus joka tekee aivan erilaista liiketoimintaa kuin kukaan muu maailmassa. Voi olla, mutta silti valtaosa teollisuus- tai kaupan alan yrityksistä valmistaa/ostaa tuotteita, varastoi niitä ja lopulta myy asiakkailleen. Toisin sanoen heillä on faktatapahtumia (ostotilaukset, saldot ja myynnit). Lisäksi heillä on asiakkaita, tuotteita ja myyjiä/myymälöitä, toisin sanoen dimensioita.

Tästä saadaan tietovaraston tietomalli, jonka olen toteuttanut kymmenille suomalaisille yrityksille lähtien kansainvälisistä teollisuuden pörssiyrityksistä, suuriin vähittäiskauppoihin, tukkukauppoihin ja pieniin konepajoihin. Tietenkin kentät tauluissa hieman vaihtelevat mutta pääasiallisesti rakenne on identtinen. Jos olet siis tekemässä tällaiseen ympäristöön tietovarastoa, ei sen mallintamiseen tarvita kymmeniä päiviä määrittely- ja suunnittelutyötä, minulla on sinulle malli valmiina ja säästät taas kymmeniä tuhansia.

Kierrätystä on tietenkin toimittajan tuotteistus lähtien aina raporttimäärittelypohjista, joiden avulla edetään nopeasti ja määrätietoisesti. Tämä antaa asiakkaallekin kuvan, että toimittajalla on homma hanskassa.

3. Vähemmän porukkaa on parempi

Jos kullekin työvaiheelle on oma roolinsa: vaatimusmäärittely, testaus, etl, raportointi ja projektipäällikkö, tulee paljon ylimääräistä viestitystä ja työtä. Ammattilaiset osaavat useampia asioita, tulisi ainakin osata.

Tässä nimenomaisessa projektissa kollegani hoiti etl-työn ja etl:n testaamisen. Minä hoidin kaiken muun. Kaksi ammattilaista riittää useimmiten tekemään alle 100 henkilötyöpäivän hankkeet. Miksei isompiakin jos aikataulu sen sallii.

Esimerkiksi projektipäällikön ei siis pidä olla vain hallinnollinen kumileimasin ja tuntien tarkkailija, varsinkaan pienissä ja keskisuurissa hankkeissa. Tästä on minulla yleensä vain huonoja kokemuksia. Jos projektipäällikkö ei osallistu edes määrittelyihin ja ei tunne laisinkaan kohdealuetta tai projektin tuotoksia, on hän yleensä vain kiviriippa. Toisessa laidassa on tietenkin näitä +1000 henkilötyöpäivän ultramaratonhankkeita, joissa pp:n ei ole mahdollisuuttakaan ottaa osaa itse työhön. Näissä massiivivissa hankkeissa tosin on paljon isompiakin ongelmia (vinkki: älä lähde tekemään överimassiivisia DW-hankkeita kerralla, pilko ne aina pienempiin projekteihin. Kukaan, koskaan, missään ei ole niissä onnistunut).

Erillistä testaajaa ei kannata edes harkita, se on hukkainvestointi. Testaajat, teidän ammattitaitoa vastaan ei ole mitään enkä halua väheksyä testaamisen merkitystä. Ongelma on siinä että tietovarastohankkeiden testaamista ei kannata irroittaa  aihealueen osaamisesta (liiketoiminta) tai tietovaraston sisällön osaamisesta (eli testaaja tuntee DW:n rakenteen). Parasta onkin, että raportoinnin testauksen suorittaa business käyttäjät, usein yrityksen controllerit jotka muutenkin pyörittelevät samoja lukuja. He näkevät heti jos luvuissa on jotain mätää.

Erillinen toimittajan tarjoama testaaja voi luoda testitapauksia tuhansia ja ihmetellä niitä edes takaisin mutta hän ei välttämättä saa kiinni olennaisia virheitä itse luvuissa. Syy on siinä, että välttämättä virhe ei ole etl-prosessissa tai raporteissa vaan koko logiikka on väärin. Ja usein tämän tajuaa vasta kun loppuasiakas näkee luvut raporteilla (vinkki: kun teet tietovarastoa, pyri siihen että alle kuukauden sisällä asiakas näkee ensimmäiset raportit ja pystyy validoimaan lukuja. Tästä alkaa vasta varsinainen kehitystyö).

4. Toimittaja osaa asiansa

Tunnet toimialan, työvälineet ja prosessit. Tunnustetaan tosiasiat: on päteviä tyyppejä ja sitten on niitä joita ei soisi edes pahimmalle viholliselleen töihin. Samaan työhön saattaa mennä yhdeltä kaverilta päivä ja toiselta viisi. Vinkki asiakkaalle: selvitä työntekijöiden osaamistaso, vaadi parasta. Pyydä referenssit. Tiedä mitä haluat.

5. Asiakas osaa asiansa

Annetaan todellinen kunnia sinne minne se kuuluu: tämän nimenomaisen projektin onnistumisen suurin syy oli asiakas. He olivat tehneet tietotarvemäärityksen lähes valmiiksi. He olivat poimineet valmiiksi nuo edellä mainitut sql-kyselyt. He tiesivät mitä haluavat, he tunsivat lähdejärjestelmän, datan ja sen käyttäytymisen. Ja luonnollisesti liiketoiminnan. Heiltä sai täyden tuen lyhyen projektin aikana. Olisin oikeasti joutunut tekemään töitä jotta olisin voinut töpeksiä tuon hankkeen.

Tämä ei tarkoita, että projektit onnistuvat vain kun käy niin hyvä tuuri, että toimittaja kohtaa tietovarastoinnin ja raportoinnin suhteen valveutuneen asiakkaan. Toimittajan tehtävänä on ennen projektin aloitusta ja sen aikana vaatia asiakkaalta noita edellä mainittuja ominaisuuksia. Asiakkaalta saa vaatia omistautumista projektille. Heiltä pitää vaatia liiketoiminnan tuntemusta ja heille tulee ehdottomasti teroittaa mikä merkitys niin ajallisesti kuin rahallisesti on sillä, että asiakas tietää todella mitä haluaa. Ja jos ei tiedä, niin toimittajan tehtävänä on auttaa selvittämään tuo tarve ennen kuin lähdetään itse toteutustyöhön.

Esimerkki tietovarastoprojektin työmääristä

No mihin se 21 päivää sitten meni? Päivät käytettiin jotakuinkin näin:

  1. Aloituspalaveri, tietotarvemäärittely, projektisuunnitelma: 1 htpv
  2. Tietomallinnus, lähdejärjestelmien ja tietomallin mäppäys: 2 htpv
  3. ETL-työ eli tietovaraston rakennus: 12 htpv
  4. Raportoinnin metamalli: Cognos Framework Manager -työ: 1 htpv
  5. Raportointikuution toteutus: Cognos Transformer -työ: 3 htpv
  6. Kuutioiden julkaisu, ajoketjujen automatisointi, virheiden valvonta: 1 htpv
  7. Testaus, parit pienet fiksaukset etl:ssä ja kuutioissa: 1 htpv
    YHTEENSÄ 21 henkilötyöpäivää

Tuon uran alkuaikojen projektin jälkeen olen tehnyt lisää 20 htpv projekteja ja osa reilusti alle. Tietovarastohankkeiden ei tarvitse siis olla ikuisuusprojekteja ja ne voi myös pysyä budjetissa. Kun hankit seuraavan kerran konsulttia tekemään hommaa, kysy häneltä reilusti referenssejä ja pyydä pilkkomaan työmääräarviot mahdollisimman pieniin paloihin. Tai sitten pyydä tosiammattilaiset paikalle.