Ajankohtaisia ajattomia haasteita

vaatimuksista
kehitys palastellaan
muutos hallitaan

omaperäinen
haiku, senryu syöksyy
teoskynnykseen

Kymmenet IT-alan ammattilaiset kokoontuivat TTL:n IT-kouluttajien jäsentilaisuuteen IT-koulutuksen ajattomia haasteita 11.11.10 verkkoon tai Haaga-Heliaan.
Paula Männistö Qentineliltä kertoi kahdesta tietojärjestelmäprojektista, joista ensimmäisessä kaikki epäonnistui ja toisessa onnistui.
Epäonnistunut projekti
Ensimmäisessä projektissa lähtökohtana oli asiakkaan liiketoimintalähtöinen ylätason vaatimusmääritys kahden nykyisen ERP-järjestelmän yhdistämisestä ja muutamien lisäominaisuuksien kehittämisestä. Projekti määriteltiin reilun vuoden mittaiseksi, mutta sitä ei palasteltu. Asiakas pääsi eri vaiheissa testaamaan järjestelmää, mutta mitään valmistuneista ominaisuuksista ei hyväksytty. Jossain vaiheessa todettiin, että vaatimusmäärityksen lisäksi pitäisi laatia selvitys, jota hierottiin yhdeksän kuukautta. Asiakas ei hyväksynyt selvityksen lopputulosta, ja lopuksi keskeytti koko projektin.
Ehkä nälkä kasvoi syödessä. Jäljellä olisi ollut vielä valtavan suuri työ, vuodessa oli saatu aikaan ehkä vasta neljäsosa siitä, mitä haluttiin. Esimerkiksi vaatimusmääritys ”Tehdään tarvittava raportointi” paisui lopulta 150 raportiksi, eikä kukaan ei osannut päättää, mitkä niistä olisivat tarpeellisia.
Toimittajan oli pakko hyväksyä tehtäväksi kaikki, mitä asiakas keksi pyytää. Sopimus oli kiinteähintainen ja muutostöitä oli vaikea hinnoitella, joten toimittajalle kertyi tappiota. Hälytyskellojen olisi pitänyt soida jo projektin alkumetreillä.
Vanha järjestelmä oli tavallaan määrityksenä, mutta koodin lukeminen on vaikeaa ja haasteellista, ja ennen kaikkea hidasta. Näytöt ja raportit ovat vain ulkoisia ominaisuuksia, ne eivät vielä määrittele järjestelmän toiminnallisuutta. Toimittaja pyrki laatimaan teknisen määrityksen, mutta toimittajan ja asiakkaan ymmärryksen välinen kuilu oli leveä ja syvä.
Tunnetun nyrkkisäännön mukaan aikatauluarviot pitäisi kertoa piillä, mutta siitä tulisi liian pökerryttävä luku asiakkaalle esitettäväksi.
Onnistunut projekti
Toisessa projektissa oli tarkoitus uusia vain vanhan suurkoneympäristössä toimivan tietojärjestelmän käyttöliittymä web-pohjaiseksi. Asiakas ymmärsi nopeasti, että käyttötapauskuvaukset eivät kata koko toimintaa ja liiketoimintaprosessit vaativat hieromista, joten prosesseja mallinnettiin ja uudistettiin samalla kun käyttöliittymää. Prosessit kulkivat eri osastojen välillä eikä ollut selkeää, missä mitäkin tehdään ja kuka tai mikä rooli omistaa prosessit. Jokainen pääsi esittämään oman näkemyksensä. Vähitellen ymmärrettiin, mitä oikeasti tehdään ja saatiin suoraviivaistetuksi monia asioita.
Toteutustyö jakautui eri mittaisiin iteraatioihin puolentoista vuoden ajalle. Tuotantoon siirrettiin kokonaisuus kerrallaan eikä mitään ylimääräistä tai turhaa työtä tarvinnut tehdä. Asiakkaat pääsivät aidosti vaikuttamaan kehitystyöhön. Muutosvastarintaa pyrittiin pehmittämään tekemällä samanlaista kuin vanha järjestelmä oli ollut ja omaksumalla sopivia toimintatapoja. Muutaman iteraatiokierroksen jälkeen oli opittu paljon, ja seuraavien iteraatiokierrosten suunnittelu oli entistä helpompaa. Nälkä kasvaa syödessä ja työmäärä kasvaa, joten muutoshallinta on tärkeää.
Miksi joskus onnistutaan ja joskus ei?
Onnistuneessa projektissa asiakas oli mukana, ja ymmärsi, että kyse oli asiakasyrityksen liiketoiminnan kehittämisestä ja toiminnan muutoksesta. Toimittaja saattoi työskennellä määrämuotoisesti alusta asti, ja suunnitella, miten kehitystyötä lähdetään työstämään ja miten palastellaan.
Ensimmäisessä projektissa oli pari 10-15 hengen ryhmää, toisessa viiden hengen ryhmä laatimassa perusarkkitehtuuria, viiden hengen ryhmä toteutuksessa ja pari henkilöä testauksessa. Prosessimallinnus sitoutti koko asiakkaan organisaation projektiin, ja teki näkyväksi, miten prosessit kulkevat.
Kiinteähintainen, alhaisen hinnan tarjous, jossa toimittaja tekee tappiota, ei ole kenenkään etu. Sen sijaan ymmärrys työmäärän suuruudesta olisi kaikkien etu. Projektin edetessä ymmärrys tarvittavasta tuntimäärästä vakiintui. Yksittäisten henkilöiden erot koodin tuottamisessa olivat valtavia, ja niinpä vaikeimmat kokonaisuudet annettiin tehokkaimmille koodareille. Koodin tuottamisen tehokkuus laskettiin määrittämällä kullekin käyttötapaukselle pistemäärät niiden vaativuuden mukaan ja niiden toteutuksista laskettiin mekanisesti, kuinka monta tuntia kunkin pisteen koodaamiseen kului.
Työmäärien arvioinnissa käytetään usein Planning poker -menetelmää, jossa jokainen toteutustiimin jäsen mielessään arvioi, paljonko aikaa menisi esitellyn työkokonaisuuden toteuttamiseen, ja nostaa sitä vastaavan kortin näkyviin yhtaikaa muiden kanssa. Tämän jälkeen arvioinneista keskustellaan ja annettuja numeroita perustellaan. Menetelmä on mukava, nopea ja sitouttava.
Ohjelmistotuotannon tekijänoikeudet
Tarmo Toikkanen Aalto-yliopiston Taideteollisesta korkeakoulusta valotti IT-koulutukseen liittyvän ohjelmistotuotannon tekijänoikeusviidakkoa jakamalla tuotokset nelikenttään ulottuvuuksille taiteellinen – hyödyllinen ja fyysinen – eteerinen. Alunperin tekijänoikeuslaki suojasi riittävän omaperäisiä ja tekijänsä persoonaa ilmentäviä taiteellisia ja konkreettisia tuotoksia. Vähitellen tekijänoikeuslain suojaan liitettiin tietokirjat, kartat ja tietokoneohjelmat. Nykyisin kirjat, valokuvat ja elokuvat eivät välttämättä enää ole fyysisia tuotteita vaan bittejä, mutta tekijänoikeus suojaa niitä edelleen.
Tekijänoikeuslaki ei edellytä teoksilta oivaltavuutta. Selittävät kaaviot eivät yleensä pääse lähellekään teoskynnystä: kuka tahansa samalla osaamisella voisi tuottaa olennaisesti samanlaiset kaaviot. Nyrkkisääntönä voidaankin pitää sitä, että jos kukaan saman alan tekijöistä ei samassa tehtävässä päädy samanlaiseen tuotokseen kuin sinä, niin tuotoksesi todennäköisesti ylittää teoskynnyksen.
Alunperin brittiläisen tekijänoikeuden oli tarkoitus suojata kirjapainon tuotoksia ja ranskalaisen tekijän moraalisia oikeuksia. Nämä ovat taustalla nykyisessä EU-maiden tekijänoikeuslaissa. Taiteellisen tai kirjallisen teoksen tekijänoikeus on sen tekijällä, luonnollisella henkilöllä. Sen sijaan työsuhteessa tehdyn tietokoneohjelman omistaa työnantaja, koska työpaikalla tietokoneohjelma laaditaan yleensä yhteistyössä. Työnantaja ei omista tietokoneohjelmaa, joka on tehty itsenäisesti opetus- ja tutkimustehtävissä. Sotilasoppilaitoksissa kaikki tekijänoikeudet kuuluvat oppilaitokselle.
Yleisön joukosta kysyttiin, miten tekijänoikeuslaki suhtautuu Andy Warholin tuotoksiin. Tarmo Toikkanen myönsi, että tekijän nimellä on vaikutusta; tekijänoikeuslaki ei välttämättä ole objektiivinen.
Levitysoikeus on tekijän yksinoikeus. Jos hankkii teoskappaleen, sen voi myydä, mutta sitä ei saa vuokrata. Kavereille saa tehdä kopioita yksityiskäyttöön laillisista lähteistä saaduista kopioista. Sen sijaan tietokoneohjelmia ei saa kopioida yksityiskäyttöön. Teoksesta saa tehdä väliaikaisia teknisiä kopioita ja tietokoneohjelmaa saa muuttaa, jos sen käyttö sitä vaatii. Yhteentoimivuuden vuoksi tietokoneohjelman saa palauttaa lähdekoodiin – jos se onnistuu.
Oppilaitoksessa opiskelijat omistavat tekijänoikeudet laatimiinsa ohjelmiin. Nykyinen tekijänoikeuslaki sallii teosten välittämisen lisenssillä, mutta yhtään lisenssiä ei vielä ole tätä varten tehty.