Moni ohjelmoija lienee sitä mieltä, että ohjelmointi on parhaimmillaan taidetta. Nerokasta ohjelmakoodia voi ihailla kuin upeaa maalausta tai sinfoniaa. Monesti tällaista taiteellista ja luovaa koodia syntyy yhden henkilön sydänveriprojekteissa. Mitä tapahtuu, kun vaatimukset, käytettävät teknologiat ja rajoitteet määritellään ylhäältä käsin kuten yleensä ohjelmistoprojektissa? Kuoleeko ohjelmoijan luovuus?
Ensin on tarpeellista pohtia sitä, miksi luovuus on ylipäätään tärkeää ja tavoittelun arvoista. Luovuus on yksi ihmisen luontaisista tarpeista. Kun luodaan uutta ja saadaan aikaan jotain itselle ja muille merkittävää, se tuottaa mielihyvää. Luova ihminen on onnellinen ihminen. Mitä enemmän tekijä kokee, että hän saa käyttää omaa luovuuttaan, sitä paremmin hän viihtyy työssään ja tulokset ovat laadukkaampia. Sivutuotteena saattaa joskus syntyä myös mullistavia innovaatioita.
Luovuus vaatii prosessina neljä peruspilaria. Näiden neljän pilarin avulla voimme tunnistaa keinoja vaalia luovuutta myös isommissa ohjelmistoprojekteissa. Keskityn tässä ohjelmoijan näkökulmaan.
1. Tavoite
Luova prosessi lähtee tavoitteesta. Alkuperäinen idea määritellään ratkaistavaksi ongelmaksi, jonka lopputuote ratkaisee. Ohjelmistoprojektissa lopputuotteen vaatimukset pilkotaan käyttäjätarinoiksi ja edelleen pienemmiksi tehtäviksi.
Rajoitteet sekä auttavat että haittaavat luovuutta. Jos poistamme täysin kaikki rajoitteet ja reunaehdot, olemme täysin tyhjän päällä ja vaihtoehtoja on liikaa mietittäväksi. Jos taas määrittelemme jokaisen tehtävän niin tarkasti kuin voimme – käytännössä sanelemalla miten ratkaisu pitäisi tehdä – tapamme vapauden, jota luovuus tarvitsee. Käyttäjätarinat ja niitä seuraava tiketöinti pitää tehdä oikealla tasolla: riittävän yksiselitteisesti, mutta samalla jättäen ratkaisuvaihtoehdoille tilaa. Oikea taso riippuu ohjelmointitiimistä: kokeneempi tiimi tarvitsee vähemmän kädestä pitämistä.
Jotta tiedetään, milloin ongelma on ratkaistu, tulisi tavoitteiden olla konkreettisesti määriteltyjä. Käyttäjätarinoista tulee selvitä kuka haluaa tehdä mitä ja miksi. Miksi-osuus on tärkeä, koska sen avulla voidaan joskus kyseenalaistaa tikettien tarpeellisuus tai löytää parempi ratkaisuvaihtoehto. Ohjelmoinnissa voi hyödyntää testivetoista kehitystä (TDD/BDD) ja saada automaattitestien avulla nopea palaute siitä, onko ongelma ratkaistu.
2. Motivaatio
Kun tavoite on selvillä, tarvitaan motivaatiota päästä tavoitteeseen. Käyttäjätarinan miksi-osuus liittyy myös motivaatioon. On mukavampi tehdä työtä, jolla on järkevä tarkoitus.
Motivaatio voi ilmetä sisäisesti, kuten halu parantaa omia taitoja, tai ulkoisesti, kuten esimiehen kehut tai työstä saatu palkka. Sisäinen motivaatio on voimakkaampaa, ja ideaalitapauksessa itse ongelma on niin kiehtova, että ohjelmoija haluaa ratkaista sen pelkästä saavutuksen ilosta. Mitä enemmän ohjelmoija saa pelivaraa ja mahdollisuuksia käyttää omia vahvuuksiaan ongelmanratkaisuun, sitä mielekkäämpää tekeminen on.
3. Lahjakkuus
Luovuus vaatii tarvittavan lahjakkuuden alaan ja riittävän määrän tietoa ja taitoa. Ohjelmoijan tulisi tietää käytettävän ohjelmointikielen mahdollisuudet, ja jonkinlainen käsitys yleisesti käytetyistä ratkaisumalleista lienee hyödyksi.
Kokeneilla tekijöillä voi joskus esiintyä ”kyllä minä tiedän”-tautia. Samaa asiaa toistamalla siitä tulee tapa, ja tapaa – kuten ajatusmalliakin – voi olla vaikea huomata ja muuttaa. Ohjelmistoala on nopeasti kehittyvä, ja omaa tietämystä on syytä päivittää tasaisin väliajoin. Avoimuus, ennakkoluulottomuus ja rohkea kyseenalaistaminen ovatkin luovan ihmisen tärkeitä ominaisuuksia, joita tiimitasollakin kannattaa edistää.
Sekoittamalla kokemattomia ja kokeneita ohjelmoijia saadaan herkullista dynamiikkaa, jossa oppimista tapahtuu kumpaankin suuntaan. Kokemattomilla ei ole menneisyyden painolastia, ja he voivat haastaa vanhoja käsityksiä nykypäivän näkökulmasta. Kokeneet voivat toimia mentoreina ja jakaa eteenpäin omat oppinsa.
Tiedon ja taidon leviämistä tiimissä voidaan auttaa esimerkiksi pariohjelmoinnilla, koodikatselmoinneilla, koulutuksilla ja tietoiskuilla.
4. Aikaa ja työtä
Itse ongelmanratkaisu vaatii kovaa työtä ja aikaa. Ongelmaa pyöritellään päässä, paperilla tai koodieditorissa. Haastavat ongelmat saattavat vaatia taukojen ja kovan työn vuorottelua.
Deadlinella on pelottava ja ahdistava kaiku, mutta se on luovuuden ja tuottavuuden yksi tärkeimmistä työkaluista. Voisi luulla, että täysin vapaa työskentely ilman aikarajoja nostaisi luovuutta. Näin ei kuitenkaan ole. Sopivan tiukka deadline voi parhaimmillaan tuoda esiin ratkaisun, jossa on keskitytty vain oleelliseen. Jos tavoitellaan taitojen kehittymistä, tekemisellä pitäisi aina olla deadline. Kuten tavoitteetkin, deadlinen tiukkuus riippuu yksilöistä. Sen pitäisi olla juuri sillä rajalla, jossa tekijä joutuu hieman puskemaan epämukavuusalueeltaan ulos.
Ohjelmointityö kärsii liiasta katkonaisuudesta. Ylimääräiset häiriöt ja turhat toiminnot kannattaa minimoida. Epäoleelliset palaverit tulisi karsia ja kutsua niihin vain oikeat henkilöt. Oma työpiste ja työvälineet kannattaa virittää itselle sopiviksi ja mahdollisimman vähän ylläpitoa vaativiksi. Silmille hyppivät ilmoitukset (esim. sähköposti) kannattaa kytkeä pois jos mahdollista.
Joku pääsee flow-tilaan helpommin musiikkia kuunnellessa, toinen hiljaisuudessa. Luovuus ja parhaat työskentelytavat ovat yksilöllisiä, joten kaikkia ei pitäisi pakottaa samaan muottiin. Jokaisella tulisi olla mahdollisuus muovata itselleen optimaalinen työtila, oikeat työvälineet ja toimiva aikataulu.
Luovuus vaatii myös luppoaikaa. Netin selailu, kikkerimatsi keskellä päivää tai rupattelu kahvikupin äärellä ei ole hukkaan heitettyä aikaa. Kun teet välillä jotain aivan muuta, annat aivoillesi mahdollisuuden löytää luovan ratkaisun ongelmaan itsestään.
Nämä neljä pilaria muodostavat luovuudelle välttämättömän pohjan, jonka päälle yksilön ja tiimin luovuutta voi alkaa hioa huippuunsa. Ohjelmistoprojekti voi näyttäytyä ohjelmoijalle jäykkänä rakennelmana tiukkoine vaatimuksineen, sääntöineen ja rajoituksineen, mutta sen sydämessä ovat silti luovat yksilöt. Luovuudelle on aina tilaa. Pienillä huomioilla ja avustusliikkeillä ohjelmistotyöstä saadaan itseilmaisun väline, jonka tuotokset ovat kaikille merkittäviä – sekä tekijöille, asiakkaille että yhteiskunnalle.
