ICT Ladies -kerhon seminaariristeily Tallinnaan 10.12.04
Artikkelin on kirjoittanut Eija Kalliala
ICT-leidien seminaariristeily oli tuttuun tapaan täynnä Hetkyn aktiivisia naisia. Aloitimme verkostoitumisen aamiaisella, jatkoimme kokoustilassa vankan asian parissa, tutustumme Tallinnassa Linetten tietojärjestelmiin ja hetken hengähdystauon jälkeen juhlimme pikkujoulua päivällisellä laivan ravintolassa. Tilaisuus oli erinomaisesti järjestetty: yhteen päivään mahtui monipuolinen kokemusten kirjo.
Projektisopimusten erityispiirteet
Minna Ääri IBM:ltä kertoi meille projektisopimusten erityispiirteistä. Hän oli parhaillaan äitiyslomalla hoitamassa kahta pientä poikaansa ja kehui työnantajan joustavaa suhtautumista, josta molemmat osapuolet hyötyvät.
Sopimus syntyy tarjouksesta, siihen annetusta myönteisestä vastauksesta ja neuvottelusta. Niinpä tarjoukseen panostetaan yhtä paljon kuin sopimuksiin ja niistä neuvottelemiseen. Järkevästi toimiva yritys ottaa lakimiehensä ja projektipäällikön mukaan neuvotteluihin mahdollisimman varhaisessa vaiheessa.
Elävästä elämästä löytyy varottavia esimerkkejä siitä, miksi kunnolla laaditut sopimukset ja prosessin dokumentointi ovat kullan arvoisia. Erään yrityksen toimitusjohtaja reklamoi toimittajalle tietojärjestelmästä, koska alaiset kieltäytyivät käyttämästä sitä. Onneksi toimittajan projektipäällikkö oli dokumentoinut kaikki kokoukset ja neuvottelut. Dokumentein toimittaja pystyi osoittamaan, että toimitettu tietojärjestelmä vastasi asiakkaan asettamia vaatimuksia.
Nykyiset projektit ovat usein monitoimittajaprojekteja, mutta niissäkin jonkin tahon pitäisi ottaa kokonaisvastuu toimituksesta ja työstä. Tähän on erilaisia vaihtoehtoja: joko yksi toimittajista ottaa kokonaisvastuun tai projektiin otetaan lisää yksi kokonaisuudesta vastaava toimittaja.
Kaupan kohde pitää määritellä ja dokumentoida riittävän selkeästi, ja samoja termejä pitää käyttää kaikissa sopimusketjun dokumenteissa kuten tarjouksessa, sopimuksessa ja projektisuunnitelmassa. Projektisuunnitelman juridinen painoarvo on suuri. Jos toimittaja tekee ”sutta”, niin asiakkaan pitää olla valppaana ja huomata, missä mennään. Kirjallisin sopimuksin asiakas voi osoittaa, mitä on tilannut ja mistä luvannut maksaa.
Määritysdokumentti on peili, johon toimitusta verrataan. Virhe on määrityksen vastaisuus. Virheiden korjaaminen on eri asia kuin muutosten tekeminen – eikä näitä kahta saa yhdistää. Muutoksista sovitaan aina erikseen.
Toimittajalla ei ole velvollisuutta toimittaa lähdekoodia, ellei siitä erikseen sovita.
Tekijänoikeus suojaa muodon, ei ideaa. Lain mukaan tekijänoikeus jää aina tekijälle ja asiakas saa käyttöoikeuden. Jos ohjelmoija tekee koodia yrityksessä, tekijänoikeus on työnantajalla. Asiakas ei tarvitse tekijänoikeuksia vaan laajat käyttöoikeudet, joihin voi kuulua oikeus muutoksiin ja edelleen luovutukseen.
Takuu pitää määritellä sopimukseen. Joskus on tullut vastaan tulkintaepäselvyyksiä, onko kyse virheestä vai ominaisuudesta. Kun takuu on määritelty, sillä saa virheenkorjauksen – sitten kun ehditään. Ylläpitosopimuksella virheet korjataan vähän nopeammin.
Kun toimitus on hyväksytty, takuu ja ylläpito alkavat yhtaikaa – mutta takuulla saa vain virheenkorjaukset.
Projektityön kuolemanmarssi
Pirjo Salo TietoEnatorilta nauratti meitä vankkaan kokemukseensa ja laajaan kirjallisuuden tuntemukseensa perustuvalla esityksellään projektityön kuolemanmarssista. Hän aloitti minimalistisesta ja absurdista tuotannostaan tunnetun Samuel Beckettin runolla:
Ever tried
Ever failed
No matter
Try again
Fail again
Fail better
Pirjo Salo kysyi, onko meille tuttua, että kilpailutilanteessa projektin aikataulu ja resurssit kutistetaan minimiinsä – ja silti joku saattaa olla ansaitsemassa kannuksiaan.
Työntekijähän tekee mitä tahansa työnantajalleen, mutta jossain vaiheessa pitää tehdä valinta – ja sen tekee työntekijä itse.
Pirjo Salon mukaan sotakirjoissa on erinomaisia projektityöohjeita. Niinpä hän suositteli projekteihin osallistuville kirjoja Waterloo ja Sun Tzun jo 700 eKr kirjoittamaa Sodankäynnin taitoa.
Miksi projekti kääntyy selviytymiseksi? Vastauksia voisivat olla:
* juonittelu ja lehmänkäännökset
* usko markkinoiden lupauksiin
* yltiöpäinen optimismi
* ensimmäinen kerta ja kokemattomuus
* vuorokaudessa on vain 24 tuntia
* todellisuus muuttuu oletettua nopeammin
* katastrofit.
Monitoimittajaprojekteissa saattaa olla asennetta: ”Noiden kanssa leikitään, mutta noiden toisten kanssa ei.”
Eräässä yrityksessä oli kuultu, että XP-versionvaihto ei aiheuta ongelmia. No, ehkä se ei aiheuttanut ongelmia, mutta kaikki työasemissa olevat sovellukset aiheuttivat. Niinpä versionvaihdoksen jälkeen mikrotuki paiski kolme päivää töitä ennen kuin työasemat taas toimivat.
Kastrofi on tapahtuma, johon ei voida etukäteen varautua, esimerkiksi seuraavanlainen: Syyskuussa huomataan, että lain mukaan jokin asia pitää hoitaa vuoden vaihteeseen mennessä. Projektin päämäärittelijä joutuu auto-onnettomuuteen, kakkosmäärittelijän aviomies saa infarktin ja projektipäällikkö sairastuu. Projektista katoaa siis lyhyessä ajassa kolme resurssia, kolme avainhenkilöä.
Tuntematon sotilas kuvaa hyvin suomalaista projektityötä. Miksi osallistumme mahdottomaan? Miksi ohjelmoija koodaa itsenäisyyspäivänä? Miksi jollekulle soitetaan joulusaunaan – ja miksi hän vastaa? Pidämmekö uhkista ja riskeistä? Ajattelemmeko, että tulos tai ulos? Koemmeko, että mahdoton projekti tarjoaa herkulliset oppimismahdollisuudet? Tunnemmeko, että näin saamme jotain CV:hemme?
Eikö meillä projektityön lisäksi ole muuta elämää? Eikö mikään tunnu miltään ellei vähintään kuusi palloa ole yhtaikaa ilmassa? Haluammeko osallistua kaikkiin kuolemanmarsseihin?
Pirjo Salo kuvasi projektin onnistumismahdollisuuksia ja projektiin osallistuvien tyytyväisyyttä seuraavalla nelikentällä:
Onnistumismahdollisuudet / Tyytyväisyys Pienet Suuret
Suuri Kamikaze Mission Impossible
Pieni Kurjat Uhrilampaat
Projekteissa voi joskus syntyä flow-tunne: silloin, kun kaikki tietävät, että onnistuminen ei ole mahdollista – ja sitten tapahtuu ihme.
StarWars on hyvä opas projektityöntekijälle. Kun päätät lähteä matkaan, ota mukaan:
1. Parhaat tähdet ja anna heille mahdollisuus – onni voi olla myötä.
2. Ryhmä, joka on jo onnistunut mahdottomassa – kokemus auttaa.
3. Hyvät, ja kerro heille, mihin he ovat osallistumassa – tieto ei lisää tuskaa.
4. Kuka tahansa – ja odota ihmettä.
Aku Ankkakin on opettavainen. Strategia on itse valittava: asiat, jotka on pakko tehdä, tehtävät, jotka pitäisi tehdä ja ominaisuudet, jotka voidaan tehdä – ehkä. Valinnat voivat joskus olla eettisiä. Elämäntapa-epäonnistujan rooli on helppo ottaa, mutta siitä on vaikea päästä irti. Sellaiseen henkilöön kannattaa ottaa etäisyyttä – ellei satu olemaan se itse.
Tietotekniikan liiton eettiset säännöt kannattaa lukea; asiantuntijan ei tarvitse hyväksyä huonoa ratkaisua.
Projektityön selviämisvälineitä ovat mm. seuraavat:
* puhuminen ja vuorovaikutus
* seuranta
* oman ajan ja tapojen hallinta
* eteneminen avoimin silmin ja harkiten
* vastuun ottaminen omista päätöksistä
* oikeus onneen
* suunnittelu.
Vuorikiipeilijöiden K2-strategia on monille tuttua, mutta unohdettua:
* päämäärä pidetään jatkuvasti mielessä
* edetään lyhyin askelin
* valmistaudutaan ja varmistetaan huolto matkalla
* hankitaan taustajoukot
* muistetaan, että kyse on tiimistä ja tiimityöstä
* säilytetään luottamus
* osataan myös luopua ja yrittää uudestaan.
Sivu päivitetty 29.8.05
Eija Kalliala, [email protected]
Vastaa