Parkinsonin triviaalisuuden laki on monille tuttu. Tein linkityksen englanninkielisen Wikipedian sivuille, koska siellä laki on kuvattu huomattavasti suomalaisen version tynkätekstiä paremmin. Linkin takaa löytyy myös legendaarinen polkupyöräsuoja-esimerkki sekä mainio tarina yhdeltä Battle Chess ‑pelin graafikolta.
Laki tuli mieleeni muutama päivä sitten, kun erään yrityksen edustaja oli tehnyt yrityksen logoon pieniä muutoksia ja kysyi Facebook-ryhmässä mielipiteitä uudesta logosta. Kymmenet ihmiset osallistuivat keskusteluun. Moni ilmeisesti uskoo että pk-yrityksen liiketoimintaan jotenkin vaikuttaa logon pieni yksityiskohta.
Samaan aikaan tämän yrityksen kotisivujen mobiiliversio näytti suomea ja englantia sekoittavan version, ja eräs kilpailija on löytänyt tuotteistamisen ja rennon asenteen kautta loistavan tavan erottautua kovasti kilpaillulla alalla — ja minulla ei ole edes mitään muistikuvaa tämän kilpailijan logosta.
Monissa yrityksissä käytetään valtavasti aikaa logon ja värien miettimiseen, koska se on helppoa ja kivaa, ja kaikilla on niistä mielipide. Paradoksaalista on, että monet tuottaisivat yritykselle enemmän arvoa jos malttaisivat jättää kommentoinnin väliin.
Ne seikat, joihin oikeasti tulisi keskittyä ja jotka näkyvät viivan alla, eivät sitten olekaan niin helppoja ja kivoja. Jonkun täytyy kuitenkin kyseenalaistaa, onko huomio oikeissa asioissa.
Parkinsonin lain seuraukset ovat yksi ketterän ohjelmistokehityksen ja kokeilukulttuurin pahimpia vihollisia. Katselmointipalavereissa huomio ja keskustelu kiinnittyy helposti nappien paikkoihin ja väreihin olennaisten toiminnallisuuksien sijasta. Pian huomataankin että kaikki aika käytetään käyttöliittymän nysväämiseen ja projekti alkaa junnata. Esittelin kymmenkunta vuotta sitten yhden ratkaisumahdollisuuden.
Alihankittua ohjelmistokehitystä käytettäessä riski on hieman pienempi. Kun toimittaja kysyy asiakkaalta, haluaako se varmasti maksaa 500 euroa otsikon värin vaihtamisesta, alkaa monilla raksuttaa.
Vastaavasti harrastuksena tehtävässä kehityksessä ongelma korostuu entisestään. Olin mukana toteuttamassa erään yhdistyksen kotisivuja ja tietojärjestelmää. Koska työ oli yhdistykselle “Ilmaista”, hallitukselta ja muilta toimihenkilöiltä vyöryi loputtomasti toiveita ja jatkokehitysehdotuksia. Mietimme jopa ratkaisua, jossa jokainen kehitykseen käytetty tunti olisi maksanut euron ja lopuksi kertyneet rahat olisi ohjattu hyväntekeväisyyteen. Tämä nimellinen summa olisi mahdollisesti tuonut mukaan ROI-ajattelua, eli ohjannut kaikkia pohtimaan mihin rajalliset resurssit kannattaa suunnata.
Myös omia tuotekehittäjiä käyttävässä organisaatiossa helposti unohtuu tuotekehityksen kustannus. Palkat ovat kiinteä kulu.
Paranoidi optimisti ‑kirjassaan Risto Siilasmaa korostaa herpaantumattoman fokuksen tärkeyttä. Yritysten ja yksilöiden pitäisi keskittyä oikeasti tärkeisiin asioihin. Parkinsonin lakia tutumpi monille on Pareton periaate. Parhaat tulokset saadaan keskittämällä resurssit kaikessa tekemisessä tärkeimpään 20 prosenttiin.
Mielenkiintoista lukea ohjelmistokehityksestä asiakkaalle! Olet varmaan urasi aikana törmännyt useasti myös siihen, että lopullista tuotetta saatetaan käyttää eri tavalla kuin on tarkoitettu käytettävän? Kaverini kehittää tuotetta mihin liittyy myös sovelluspohjainen käyttöliittymä. Hänellä on ilmeisesti jotain ulkoista apua jo tarjottu tuotteen kehitykseen mutta huomaan, että hän kiinnittää ehkä vääriin asioihin huomiota. Hyvä esimerkki tuo logon viilaaminen millä ei välttämättä ole mitään merkitystä liiketoiminnan kannalta! Kaveri nimittäin on visuaalinen tapaus ja ehkä liikaa keskittyy ulkonäöllisiin asioihin kuin itse tuotteeseen välillä. Täytyy linkittää tämä hyvä kirjoitus hänelle.