by

Ohjelmistotuotanto

Paluu juurille. Joskus pitää kirjoittaa myös siitä, mitä on koulussa oppinut. Tai miten tieto on ehkä jalostunut päässä. Tai ei ole jalostunut. Ja siitä, kuinka kaikki muut ovat väärässä. Tällä kertaa ei siis puhuta hiihdosta, vaan koodauksesta ja sen johtamisesta.

Lappeenrannassa tuotantotalous ja tietotekniikka niputettiin jossain määrin hallinnollisesti yhteen ja lopputulos oli tietotekniikan ja tuotantotalouden tiedekunta. Lyhyellä tähtäimellä muutoksia ei ole tulossa, titellä osaston sisäiset asiat ovat yhtä vinksallaan kuin aina ennenkin. Tutalaista naurattaa, mutta olkoon varovaisena, ettei ongelmat vaan pääse leviämään.

En tiedä mitä tutalla ajatellaan, mutta titeläiset pitävät tutaa yleisesti puppana, johon ei tarvita kaksisia taitoja. Nopat irtoaa helpommin opiskeltaessa ja pakollisia koodauskursseja suorittaessa tutalaiset ovat usein hukassa. Niin ovat titeläisetkin. Osastojen välinen yhteistyö aiemmin on ollut aivan minimissä. Se ehkä kuvastaa kaikkia muitakin osastoja, mutta edes professoritasolla ei ilmeisesti ole nähty tietotekniikan ja tuotantotalouden yhteneväisyyttä muuten kuin siten, että ohjelmistoja voidaan käyttää päätösten tukijärjestelminä. Mutta eihän se niin ole. Tuotantotalous kuuluu jokaiseen yritykseen, tavalla tai toisella. Diplomi-insinöörit (toivottavasti) eivät yleensä kovin montaa vuotta toimi rivikoodarina, projektipäällikön (tai linjaukkojen) olisi hyvä olla jotain käsitystä taloudesta. Ei välttämättä käytynä yhtään kurssia tai muuta (en yleensäkään usko koulutuksen ylivoimaiseen tapaan todistaa asiasta tietäminen), mutta että asioita, joita sieltä puolelta tulee, ei pidettäisi ainakaan turhina.

Keskivertokoodari on skeptikko ja konservatiivi – siltä ainakin tuntuu. Toisaalta, he ovat tottuneet loputtomaan hypetykseen ja toistuviin odotusten alittamiseen. Siksi hienot termit, kuten ketterä ohjelmistotuotanto eivät välttämättä aiheuta riemunkiljahduksia. Yleensä lähinnä nauretaan uusille toimintatavoille, pidetään niitä turhina. Kuitenkin kyse on paljon muustakin kuin fancy wordseistä. Ohjelmistotuotannon evoluutiosta, siitä, että tehdään hyväksi huomattuja asioita enemmän, kuin niitä, jotka on jo huomattu huonoiksi. Onnistuneita esimerkkejä on paljon, epäonnistumisista varmastikin vaietaan.

Jotenkin ohjelmistoalalle valmistuvia (en tunne riittävän montaa varsinaista työntekijää voidakseni vahvistaa tämän) vaivaa sellainen älä tule neuvomaan -syndrooma. Ollaan kiinnostuneempia teknisista ratkaisuista, vaikkapa jonkun oikeaoppisen kerrosmallin toteuttamisesta, kuin siitä, että pysyttäisiin vaaditulla tasolla muissa asioissa – aikataulussa ja budjetissa. Syntyy perinteinen tilanne. Projektipäällikkö ja tiimi muodostavat ryhmän, jonka pahimmat vastustajat ovat yrityksen talousosasto ja yrityksen johto. Ehkä myös asiakas. Asiakas kun on väärässä, ei tiedä mitä haluaa ja valittaa turhaa. Kun he eivät vaan tajua. Todellisuudessa juuri näiden linkkien – ymmärtämisen – eteen olisi panostettava eniten koko yrityksessä. Panostus ei toimi tietenkään yksisuuntaisesti, vaan sen täytyy olla kaikkien intressi. Tätä vaikeuttaa se, jos projektipäälliköillä tai rivikoodareillakin on asennevamma johtamista ja taloutta kohtaan. Kuitenkin markkinataloudessa lopulta mennään rahan ehdoilla, halusipa koodari koodata minkälaisia widgettejä tahansa. Tietysti, jos asiakas pitää koodareita omina orjapojuinaan ja toivoo, että uusi ominaisuus toteutettaisiin viikonlopun aikana, niin olisi ehkä katsottava peiliin sielläkin suunnassa.

Kun tutkin kesällä töissä asioita, jotka voisivat muodostua Suomelle kilpailueduksi ohjelmistokehityksestä kilpailtaessa, vastaan tuli oikeastaan vain yksi asia. Laatu. Ei välttämättä se, että ohjelmisto toimii hyvin (se on siis tärkeää, mutta on muitakin asioita), vaan myös se, että pysytään aikataulussa, budjetissa ja ollaan oikea-aikaisia. Asiakas saa sitä mitä on tilannut. Ylläpito toimii. Linkki asiakkaan ja toimittajan välillä on hyvä. Nämä ovat niitä asioita, jotka usein eivät toimi esimerkiksi Intiassa. Joskus toimivat, usein eivät. Syynä ovat monet eri asiat. Niitä on turha alkaa käymään läpi. Ohjelmistoyritysten ulkoistuksista löytyy varmasti juttua, jos joku siitä jaksaa innostua.

Projektit kasvavat, käytetään alihankkijoita. Koodaamassa on satoja ihmisiä. Siinä ei yhden ihmisen äärimmäinen tekninen osaaminen paina paljoakaan. Tietysti voi painaa ratkaisevasti, mutta jos hänet korvataan normaalitaitoisella koodarilla, ei lopputulos todennäköisesti ole merkittävästi huonompi. Sen sijaan ihmiset, jotka eivät näe, tai kieltäytyvät näkemästä isoa kuvaa, kokonaistilannetta, voivat olla enemmän haittana, kuin esimerkiksi heikkotasoinen koodari. Koodaus on kuitenkin nykyisin oikeastaan ainut jäljellä oleva ala, joka on lähes täysin käsityötä ja jossa tarvitaan yhteistyötä enemmän kuin missään.

No nyt kun joku on tänne saakka tämän lukenut, tuntuu olo tyhjältä. Mitä Jasmo yrittää oikein postauksessaan sanoa? Siinäpä onkin bloggaamisen hienous. Voin kirjoittaa hajanaisia mielipiteitä asiasta. Ehkä kirjoitusprosessi oli enemmänkin omien ajatuksien hahmottamista. Nyt voisin poistaa tekstin ja olla tyytyväinen – olen ajatuksien suhinasta löytänyt jotain piirteitä, jotka ovat mielestäni tärkeitä. En kuitenkaan tee sitä, tykkään niin kovasti julkaista tekstejä blogissani. Tulipa anteeksipyytelevä lopetus. No, korjaan sen käyttämällä kirosanaa.

Perkele.

Kommentoi

Comment

  1. Projektitiimin, asiakkaan ja yrityksen johdon välien kiristymisen syynhän näkee sidosryhmäanalyysin kautta arvioimalla, mitkä on kullekin sidosryhmälle tärkeimmät asiat.
    Esimerkiksi näin (tärkeysjärjestys):
    Projekti: toiminnallisuus, aikataulu, laatu.
    Asiakas: laatu, hinta, aikataulu.
    Yrityksen johto: aikataulu, hinta, laatu

    Riippuu tietenkin paljon projektin luonteesta yms, mutta on selvää, että oikean rahan projekteissa näistä asioista varmasti tulee keskustelua, jos ja kun jokin näistä pettää.